Make dictation engine start non-blocking with audio route resilience

[devin-ai-integration]

Eliminates the 2+ second main-thread stall during PTT dictation by making the audio engine start asynchronously (withCheckedContinuation) and moving DictationContextCapture to a detached Task, so the overlay/chime appear instantly and key-up events are never blocked by hardware init or AX timeouts.

---

• Requested by: @tkheyfets
• Session: https://app.devin.ai/sessions/73a3a8780ea0402b9e0de32d52d9e6be

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[tkheyfets]

@codex review

[tkheyfets]

@codex review

[tkheyfets]

@codex review

[tkheyfets]

@codex review

[tkheyfets]

@codex review

[devin-ai-integration]

Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it.

[devin-ai-integration]

Devin Review found 4 new potential issues.

View 8 additional findings in Devin Review.

[devin-ai-integration]

🟡 stopContinuousRecording() missing recognitionTask == nil guard — can leave isRecording stuck and violate endAudio contract

stopRecordingForDictation() was correctly updated (lines 894-906) with a guard for recognitionTask == nil to handle the new async engine start flow where the recognition task hasn't been created yet. However, the structurally identical stopContinuousRecording() was not updated with the same guard.

If stopContinuousRecording() is called before the async installTapAndStartAsync completes: (1) recognitionTask is nil so no callback will deliver isFinal, (2) isRecording stays true permanently, (3) endAudio() is called on the request. When the async task eventually completes, it passes the generation check (same session), creates a recognition task with a request that already had endAudio() called, and the tap starts appending buffers after endAudio() — violating SFSpeechAudioBufferRecognitionRequest's contract.

Comparison with the fix in stopRecordingForDictation

stopRecordingForDictation() handles this at lines 894-906:

guard recognitionTask != nil else {
    recognitionRequest = nil
    isRecording = false
    // ... full cleanup
    return
}

stopContinuousRecording() at lines 260-277 has no such guard.

(Refers to lines 260-277)

Prompt for agents

The stopContinuousRecording() method at line 260 needs the same recognitionTask == nil guard that was added to stopRecordingForDictation() at lines 894-906. Without it, if stopContinuousRecording() is called while the async engine start is still in progress, isRecording remains true forever and endAudio() is called on a request before its recognition task exists.

After the hasInstalledTap = false line (line 272), add a guard checking recognitionTask != nil. If nil, perform direct cleanup: set recognitionRequest = nil, isRecording = false, reset amplitude state, and return early. The cleanup should mirror what stopRecordingForDictation does in its equivalent guard block (lines 894-906), but adapted for the continuous recording context (no overlay dismiss, no dictation context reset).

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Stale session's tap appends audio to request after endAudio() in rapid stop/start

In a rapid stop→start scenario, a stale session's audio tap can feed buffers to a SFSpeechAudioBufferRecognitionRequest after endAudio() has been called — violating the API contract explicitly noted at AudioEngineController.swift:188-189.

Detailed sequence

1. Session A (gen=1): beginRecording() sets isRecording=true, creates request_A, launches async engine start
2. User stops: stopRecording() → tearDownAudioState() calls request_A.endAudio(), sets recognitionRequest=nil. But hasInstalledTap is false so the engine is NOT stopped.
3. Session B (gen=2): beginRecording() creates request_B, launches another async engine start
4. Audio queue executes A's installTapAndStartImpl: installs tap_A (closure captures request_A), starts engine
5. tap_A fires on the audio thread, calling request_A.append(buffer) — after endAudio() was already called
6. A's continuation resumes: stale check (gen=1≠2) → skips teardown because isRecording=true ("session B owns engine")
7. Audio queue executes B's impl: removes tap_A, installs tap_B — but audio was already appended to the ended request

The old synchronous installTapAndStart maintained the invariant (remove tap → then endAudio) because by the time beginRecording() returned, the tap was installed and hasInstalledTap=true, so tearDownAudioState() always removed the tap first. The new async path breaks this invariant. The window is narrow (between engine start and the next serial queue item removing the tap), but with the 2+ second Bluetooth latency the PR is designed to handle, the user can easily trigger a stop/start within that window.

Prompt for agents

The stale generation handler at VoiceInputManager.swift:732-742 correctly detects stale sessions but doesn't prevent the stale tap from feeding audio to a request that had endAudio() called. The root cause is that tearDownAudioState() (line 237-246) calls recognitionRequest?.endAudio() when hasInstalledTap is false (async start pending), but the stale session's tap will later install and start feeding audio to the captured request.

Possible approaches:
1. In tearDownAudioState(), when hasInstalledTap is false but a request exists, avoid calling endAudio() — let the stale completion handler clean up instead. The stale handler would need to call endAudio on the captured request after stopAndRemoveTap.
2. Track whether endAudio has been called on the current request (e.g. a flag) and have the tap block check it before appending.
3. In the stale generation handler, when success is true and isRecording is true (newer session active), still call stopAndRemoveTap() to remove the stale tap immediately, rather than relying on the newer session's installTapAndStartAsync to eventually replace it. The newer session's impl will re-install its own tap when it runs on the serial queue.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 Engine start failure path doesn't play deactivation chime after activation chime was already played

The activation chime is now played immediately at VoiceInputManager.swift:672 (before the async engine start) for instant user feedback. But when the engine subsequently fails to start, the failure handler at lines 735-743 dismisses the overlay and resets state without playing the deactivation chime. The user hears the activation chime indicating recording has started, but gets no audible signal that it failed. In the pre-PR code, the chime was played after the engine was confirmed started, so engine failures never had an orphaned activation chime.

Suggested change

	guard success else {
	log.error("Audio engine failed to start — invalid format or engine error")
	self.isRecording = false
	self.onRecordingStateChanged?(false)
	self.currentDictationContext = nil
	self.recognitionRequest = nil
	self.overlayWindow.dismiss()
	self.resetAudioEngine()
	return
	guard success else {
	log.error("Audio engine failed to start — invalid format or engine error")
	self.isRecording = false
	self.onRecordingStateChanged?(false)
	self.currentDictationContext = nil
	self.recognitionRequest = nil
	self.overlayWindow.dismiss()
	self.resetAudioEngine()
	VoiceFeedback.playDeactivationChime()
	return
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🚩 Activation chime now plays before engine is ready — verify no audio conflict

The activation chime (VoiceFeedback.playActivationChime() at line 672) now plays immediately when isRecording is set, BEFORE the audio engine starts asynchronously. Previously it played AFTER the engine was running (old line 738). This achieves the stated goal of instant feedback. However, if VoiceFeedback.playActivationChime() uses AVAudioPlayer or a system sound API that interacts with the audio session, it could potentially conflict with the audio engine starting shortly after. This is worth verifying but likely fine since system sounds typically use a separate audio path from AVAudioEngine's input node.

---

Was this helpful? React with 👍 or 👎 to provide feedback.