[BUG] Windows: about half the audio is silently lost from the Remote Desktop microphone ("Remote Audio") with the default capture buffer

Reproduced on 0.9.8 with a different RDP client, plus a local control on the same machine.

Setup: Windows 11 Pro (build 26300) host, Parakeet TDT 0.6B v3 (Q8_0 GGUF), Silero VAD on, default settings. Client: Microsoft Windows App on macOS with microphone redirection ("Remoteaudio").

Recording window (TranscribeAction start → stop, whole seconds from the log) vs. samples retrieved at 16 kHz:

The RDP recordings sound sped up, the local one sounds normal. Parakeet still transcribes most of the RDP audio (64 words in 13.9 s of kept audio), so the loss is easy to miss in casual testing. One transcript partly switched to English.

Our use case is dictation on Windows terminal servers (RDS) with thin clients, where the redirected Remote Audio device is the only microphone. A larger capture buffer for this device would make Handy usable there. Happy to test a build.

Sorry for the slow reply, it's been a busy week at work.

I installed and tested the build you shared: same issue, no difference at all. Over Remote Desktop, recordings from the "Remote Audio" mic still come out about half length and choppy, while Windows Sound Recorder on the same mic is clean.

So that's now two of us confirming it on this build. Happy to test another one, or run the buffer-size script from my first post again, if that helps.

Thanks for looking into it!

Thanks for confirmation, I've got a few big things in the works at the moment, once they are merged I'll be back to this!

I could confirm the root cause in the current capture stack and test a fix over RDP. On Windows the input stream uses BufferSize::Default, so WASAPI gets its smallest shared-mode buffer and the Remote Audio bursts overflow it.

Where

• 0.9.8: recorder.rs uses config.clone().into(), i.e. BufferSize::Default.
• Test build and main (handy-recorder 0.1.0): a fixed buffer is only set for PulseAudio (mod.rs). That's why the test build changed nothing.
• handy-cpal passes BufferSize::Default to IAudioClient::Initialize as a buffer duration of 0 (device.rs#L1440).

Test

Small binary on handy-recorder 0.1.0, patched to set BufferSize::Fixed on Windows, recording 10 s inside the RDP session (same setup as my comment above, LAN, device "Remoteaudio" at 44.1 kHz / 2 ch):

The missing 3 % at 200 ms is startup latency (first audio after 337 ms). The xruns are Windows' DATA_DISCONTINUITY flags, and main already logs them as the platform reported N xruns during the recording. The local mic on the same machine accepts 200 ms to 2 s with 100 % received.

Suggested fix in CpalOpenDevice::start, for all Windows devices:

#[cfg(target_os = "windows")]
{
    // Callbacks still come every device period; this only adds headroom
    // for devices that deliver in bursts (RDP Remote Audio).
    config.buffer_size = cpal::BufferSize::Fixed(config.sample_rate / 2); // 500 ms
}

I'd use 500 ms to 1 s. 100–200 ms is enough on a LAN, but thin clients over WAN or VPN will likely see bigger bursts, and the extra buffer costs no latency in normal operation. One catch: handy-cpal reports the supported range as min = max = device period (device.rs#L687-L697), so clamping the request to it would undo the fix.

Happy to test a build over RDP.

@DeLuke84 can you submit a PR please? Would love to fix this