1.6.6: dictation trigger key has a startup delay and drops opening/closing words (regresses from 1.6.5)

[mjaverto]

Summary

• Since 1.6.6: about a 1-second apparent delay before the overlay shows up after the trigger key, and the opening and closing words of the dictation are commonly missing.
• Downgrading to 1.6.5 fixes it, reliably.
• Turning off "Faster Recording Start" does not.
• Traces to PR Improve core audio resiliency #732, shipped in 1.6.6 (commit 09ad577).

Possible cause 1: new readiness wait, on both audio backends

• AudioCaptureReadinessGate is new in 1.6.6 (Sources/Fluid/Services/AudioCaptureReadinessGate.swift), absent at tag v1.6.5 (git show v1.6.5:<path> errors: not present at that tag). ASRService.start() now blocks on it for the first real PCM sample (ASRService.swift:1495-1499), up to a 2-second timeout.
• The wait isn't gated by the "Faster Recording Start" setting. Both the Direct Core Audio and legacy AVAudioEngine paths feed the same AudioCapturePipeline and signal the same gate through onFirstAudio. That would explain why the toggle doesn't change the symptom.
• Discrepancy worth tracing: showRecordingOverlayImmediately() (ContentView.swift:3099, MenuBarManager.swift:238-277) reads as fully synchronous with no sleeps or awaits, so the reported ~1s delay may actually be the waveform staying flat rather than the panel itself appearing late. The app already logs overlayBench/appBench lines (instant_show_request, show_workitem_execute, first_pcm_wait_begin, first_pcm_wait_end) with timestamps that would settle this.

Possible cause 2: packet gate closes before the hardware actually stops, Direct Core Audio only

• fv_core_audio_capture_stop() sets packetGateOpen = false, then calls AudioDeviceStop() (CoreAudioCaptureSupport.c:461-465). The realtime HAL callback fv_io_proc skips the ring-buffer write whenever packetGateOpen is false (:275-280), so a callback landing in that window would be dropped, not drained. That contradicts the "captures the complete tail" comment at DirectCoreAudioInput.swift:548.
• We can't confirm from source alone that a callback lands in that window on a given stop, or that it would hold speech rather than silence. Treat this as plausible, not proven.
• This is specific to Direct Core Audio, which sits oddly against the toggle not fixing the symptom.

Ask

The strongest evidence here is the repro itself: 1.6.5 doesn't have the problem, 1.6.6 does, and the backend toggle doesn't change it. The two gates above are plausible reads of the diff, not a confirmed root cause. Given the existing ASR_BENCH/APP_BENCH logging already in the code, a maintainer trace on 1.6.6, with the toggle both on and off, would confirm whether these gates are where the words go missing, or whether something else in PR #732 is responsible.

[neiffer]

I can confirm similar behavior. It also appears to hang with longer messages. No problems in 1.6.5, unusable in 1.6.6.

[grohith327]

Hey folks, can you share additional logs that would help cause I am unable to reproduce it. We made some changes outside of that PR in the model audio processing layer, that could also be an issue.

Can you confirm the following two things:

1. Is "Faster recording start on" ?
2. Are you using parakeet for your voice model ?