Start of speech is clipped when speaking immediately after the hotkey press

[ChaliceForAuri]

Observed (dictated feedback, 2026-08-19)

One thing I am noticing is that if I start speaking too soon, it doesn't get the start of what I'm saying, so I should wait a little bit. I press it, then I wait a little bit. There's a [warm-up] period there.

Reported from real daily use on the Release build, WH-1000XM4 (Bluetooth).

Analysis

Between the hotkey press and the first buffer actually reaching the tap there is dead time nothing captures:

1. AVAudioEngine.start() latency on the press
2. Bluetooth input wake — an idle BT headset takes ~200–500 ms to activate its mic route; likely the dominant term on this hardware
3. The overlay says "Listening…" immediately (by design, for perceived latency) — so it invites speech before audio is flowing

Candidate fixes, in the order to try them

1. Make readiness visible. The waveform already renders only when levels arrive; the text should match — show "…" until the first buffer lands, then "Listening". Cheap, honest, probably sufficient.
2. Measure it: per-stage timestamps (press → engine started → first buffer) so we know the real number per device class before engineering around it.
3. Keep the engine warm briefly after each dictation (rapid re-press is common). Bounded, no privacy cost while the session is hot.
4. Rejected by default: an always-on pre-roll ring buffer. A permanently hot mic keeps the system's mic-in-use indicator lit and contradicts the entire privacy posture for a convenience (GDR-0001/0006). Only revisit with a very explicit opt-in story.

Notes

First entry in the feedback record (backstage design §8). Fix should come with a latency measurement, not just vibes — same discipline as ADR-0004.