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

Tìm vòng lặp đọc của PvRecorder trong phần triển khai voice-server, sau đó tái hiện /voice trên WSL2/WSLg trong khi theo dõi ~/.copilot/logs/voice-server-*.log và /mnt/wslg/pulseaudio.log. Được xem là hoàn tất khi các lỗi phần cứng tạm thời được khôi phục trong số lần thử lại có giới hạn và việc khôi phục thành công tạo ra bản chép lời; nếu không, một lỗi rõ ràng hiển thị cho người dùng hoặc một lần thử lại sẽ được đưa ra.

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).