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).
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-*.logshows 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
/voicedictation engine. Impact: low-to-moderate — intermittent, recoverable by retrying manually, but currently silent/confusing (looks like dictation "did nothing" with no error explanation).