/voice dictation intermittently captures nothing on WSL2/WSLg (PvRecorder read failure during RDP audio reconnect)

voice-server の実装で PvRecorder の読み取りループを探し、~/.copilot/logs/voice-server-*.log と /mnt/wslg/pulseaudio.log を監視しながら、WSL2/WSLg で /voice を再現します。一時的なハードウェアエラーが上限付きのリトライで復旧し、復旧に成功するとトランスクリプトが生成されれば完了です。それ以外の場合は、ユーザーに明確に表示されるエラーまたはリトライが提示されます。

Describe the bug

Built-in voice dictation (/voice) intermittently captures nothing on an attempt — no transcript, no visible error — even when the speech-to-text session has already fully warmed up. This happens sporadically, not on every use, across a session running for an hour or more.

Root cause (diagnosed via local logs). ~/.copilot/logs/voice-server-*.log shows the underlying error: [voice-mic] read loop failed (hardware-error): Error: PvRecorder failed to read audio data frame. /mnt/wslg/pulseaudio.log (WSLg's built-in PulseAudio server) shows its RDP audio source continuously reconnecting during the same window: module-rdp-source.c: RDP Source - Trying to connect ... Connected to fd 27 (repeating). When a PvRecorder mic frame read happens to land in the middle of one of these RDP-relay reconnects, the read throws a hardware-error and the capture fails outright with no retry. This is a WSLg platform-level audio-relay instability, not a problem with the speech-to-text model or transcription accuracy — transcription is accurate every time a read actually succeeds.

Suggested fix: Add bounded retry-on-transient-error handling to the voice-server's PvRecorder read loop: on a hardware-error read failure, retry the frame read a small number of times before giving up, instead of failing the capture immediately. In manual testing, a simple retry recovered successfully ~100% of the time, so this fix would likely eliminate the failure class entirely for WSL/WSLg users with no other user-visible change.

Affected version

GitHub Copilot CLI 1.0.82

Steps to reproduce the behavior

Use /voice (or the voice dictation entry point) inside a WSL2 + WSLg environment (Windows Terminal), then speak normally after the recording indicator appears. Repeat dictation attempts across a session (multiple times over roughly 1–2 hours). Occasionally — not every time — a given attempt produces no transcript at all, as if nothing was recorded. Retrying the same attempt immediately afterward succeeds.

Expected behavior

Every dictation attempt should either capture and transcribe audio, or surface a clear, user-visible error/retry — not silently produce nothing.

Additional context

Operating system: Windows + WSL2 (WSLg). Terminal emulator: Windows Terminal. Feature: built-in /voice dictation engine. Impact: low-to-moderate — intermittent, recoverable by retrying manually, but currently silent/confusing (looks like dictation "did nothing" with no error explanation).