Describe the bug
When AirPods (or another Bluetooth headset) are the active input device, dictation is noticeably worse than with the built-in microphone: transcriptions come out garbled or time-stretched, the first words of a dictation are often missing, and overall accuracy drops. The built-in microphone works correctly on the same machine.
Root causes (verified in the code)
- The direct Core Audio capture backend (enabled by default) reads the input stream's virtual format once in
fv_core_audio_capture_create and never revalidates it. When the AirPods Bluetooth route switches from A2DP to HFP as input IO starts, the cached sample rate and byte layout go stale, and every packet is decoded and resampled with the wrong parameters, producing stretched/garbled audio that wrecks transcription.
- There are no listeners for
kAudioStreamPropertyVirtualFormat or kAudioDevicePropertyNominalSampleRate, so a mid-session format change is never detected and capture is never rebuilt.
onCaptureStarted fires immediately after AudioDeviceStart returns, but a Bluetooth mic can take 1 to 2 seconds to deliver its first packet, and audio timestamped before recording start is trimmed, so words spoken during HFP negotiation are silently lost. The UI tells the user to speak before the mic is actually live.- The 16 kHz conversion for ASR uses stateful linear interpolation with no anti-alias filter, folding content above 8 kHz into the speech band.
To Reproduce
- Connect AirPods and let macOS make them the default input device.
- Start dictation and begin speaking immediately.
- Compare the transcript with the same sentence dictated via the built-in MacBook microphone.
Expected behavior
Dictation through AirPods should be reliable: no garbled/stretched audio, no missing first words, and accuracy close to the built-in microphone (within the physical limits of the Bluetooth HFP microphone route).
Environment:
- macOS Version: 26.5.2 (25F84)
- App Version: built from
main @ 690b26c
- Architecture: Apple Silicon (
arm64)
- Audio devices observed: AirPods (Bluetooth) input/output; MacBook Pro Microphone built-in
Additional context
Crash Logs
No crash occurs.
Describe the bug
When AirPods (or another Bluetooth headset) are the active input device, dictation is noticeably worse than with the built-in microphone: transcriptions come out garbled or time-stretched, the first words of a dictation are often missing, and overall accuracy drops. The built-in microphone works correctly on the same machine.
Root causes (verified in the code)
fv_core_audio_capture_createand never revalidates it. When the AirPods Bluetooth route switches from A2DP to HFP as input IO starts, the cached sample rate and byte layout go stale, and every packet is decoded and resampled with the wrong parameters, producing stretched/garbled audio that wrecks transcription.kAudioStreamPropertyVirtualFormatorkAudioDevicePropertyNominalSampleRate, so a mid-session format change is never detected and capture is never rebuilt.onCaptureStartedfires immediately afterAudioDeviceStartreturns, but a Bluetooth mic can take 1 to 2 seconds to deliver its first packet, and audio timestamped before recording start is trimmed, so words spoken during HFP negotiation are silently lost. The UI tells the user to speak before the mic is actually live.To Reproduce
Expected behavior
Dictation through AirPods should be reliable: no garbled/stretched audio, no missing first words, and accuracy close to the built-in microphone (within the physical limits of the Bluetooth HFP microphone route).
Environment:
main@ 690b26carm64)Additional context
Crash Logs
No crash occurs.