Intermittent blank transcriptions after stop (silent buffer; worse on rapid re-record)

[flesler]

Summary

On VocaMac 0.7.0, roughly 10–25% of dictations finish with:

Transcribing Ns of audio...
Transcription completed in ~0.35s
Result: ...
Transcription produced no usable text (silence or blank audio)

WhisperKit is fine — it receives a full-length PCM buffer that is effectively silence. Empty buffers exit earlier (audioData.isEmpty → idle, no "Transcribing" line), so this is silent capture, not a failed start.

Evidence (local logs, M5 Max, built-in mic)

Gap since previous transcription	Blank rate
0–3s	60% (3/5)
3–10s	15%
10–30s	9%
30–120s	9%
120s+	7%

Clear long failures also exist (7.6s / 12.9s / 24.9s of "audio" → blank), so it isn't only accidental short taps.

Also seeing frequent startRecording called in processing state — force recovering when the previous transcription hasn't returned to idle yet.

Likely cause

#136 / PR #136 made AVAudioEngine lazy: create on startRecording, releaseEngine() immediately on stopRecording. That frees the input route for AirPods/HFP (good), but every dictation cold-reacquires the mic.

Rapid back-to-back dictations (common in push-to-talk) hit that cold path hardest — matching the 60% blank rate for gaps < 3s.

engine.start() can succeed while early (or all) tap buffers are still near-zero until Core Audio finishes opening the device. Duration is sample-count based, so the UI/log still show a full N seconds of "audio".

Suggested fix

Defer idle teardown by a few seconds so quick re-records reuse a warm engine; still release after idle for #136. Also call prepare() on acquire.

Patch against v0.7.0 (works for me conceptually; couldn't rebuild locally — no full Xcode, only CLT):

• Cancel pending release in acquireEngine()
• newEngine.prepare() before return
• stopRecording() → scheduleEngineRelease() (3s) instead of immediate releaseEngine()
• Keep immediate releaseEngine() on force-reset / config-change / start-failure

Happy to open a PR if useful.

Environment

• VocaMac 0.7.0
• Apple M5 Max, 64 GB
• Model: openai_whisper-large-v3-v20240930_turbo_632MB
• Mode: push-to-talk (F11 / keyCode 103)
• Mic: System Default → MacBook Pro Microphone
• ZoomAudioDevice is installed (not selected as default)
• Permissions: mic / accessibility / input monitoring all granted

Notes

• Pinning mic via selectedAudioDeviceID=BuiltInMicrophoneDevice is not a workaround — hits open Mic instantly stop when try to use any Input Method (Microphone) other than System Default #174 (preferred device triggers immediate config-change stop loop).
• No Audio configuration changed lines in my blank cases (unlike Mic instantly stop when try to use any Input Method (Microphone) other than System Default #174).

[jatinkrmalik]

Thanks for the detailed report, @flesler. The gap-rate table and the note that WhisperKit was receiving full-length silent PCM made this much easier to reason about.

I have opened a draft fix here: #178

The PR keeps the stopped engine warm for a short 3 second idle window, cancels that pending release if another recording starts, and still releases immediately on force reset, config change, or start failure so we preserve the AirPods/HFP behavior from #136. I also put prepare() in the protected start path before engine.start().

If you are able to try the PR build on your setup, that would be especially helpful since your machine reproduces the rapid re-record blanks much better than mine.

[flesler]

commented on the PR, we'll keep it going there from now on.

[flesler]

Follow-up after testing the warm-engine draft in #178:

Warm-keeping helps some rapid re-records, but most of my dictations are cold, and short takes still blanked even inside the 3s warm window. I left a longer write-up on the PR with what I think is the better holistic fix: don’t show “speak now” (red) until capture is actually live — reuse the existing purple indicator as an arming state, flip to red on real audio level/VAD, and drop near-silent buffers if the user releases early.

Full comment with code pointers: #178 (comment)

[flesler]

New evidence on stock 0.7.0: two long dictations (19.5s and 13.9s) returned fully blank at silence-speed decode (~0.35s), with zero ERROR/WARNING/AudioEngine lines around them — only “no usable text.”

That argues against “slow mic warmup clips the first words.” A brief cold-start delay would still leave most of a 19s take intact. These look like the entire buffer was near-silent while engine.start() still succeeded.

Full write-up on the PR: #178 (comment)

[flesler]

Retested the updated #178 build (8ab6a77). Medium/long OK; short blanks still go to Whisper — the new near-silent RMS drop never fired (threshold may be too low for my failing buffers).

Details: #178 (comment)

[flesler]

Just upgraded to 0.7.1 and hit the same short-take silent capture again.

Fresh launch after install, three quick push-to-talks:

1. 0.5s → blank (Transcription produced no usable text)
2. 0.9s → blank (same)
3. 1.8s → worked: Okay, well fine, no....

No near-silent drop / warm-engine log lines — Whisper still got empty-looking audio on the first two. Same failure mode as before on very short takes right after startup.

[jatinkrmalik]

@flesler mind raising a PR fix? Are you trying to say something really quickly in case 1 and 2?

[flesler]

Happens with quick but also long messages, anyway, I'll circle back if I find more. Just wanted to report I switched to .1 and still happens