From 9c0c13d1f64cda2da8f91c51becc9c834f0867de Mon Sep 17 00:00:00 2001
From: duffyduck <info@hacker-net.de>
Date: Sun, 31 May 2026 23:51:43 +0200
Subject: [PATCH] =?UTF-8?q?fix(audio):=20expliziter=20AudioFocus-Request?=
 =?UTF-8?q?=20beim=20TTS-Start=20=E2=80=94=20Spotify=20resumed=20wieder=20?=
 =?UTF-8?q?zuverlaessig?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Stefan-Symptom: Spotify pausiert wenn ARIA zuhoert/spricht ✓, aber
resumed nach TTS-Ende NICHT (oder nur unzuverlaessig).

Diagnose aus dem Log-Trace:

  Manual-Button-Flow:
    recording start → AudioFocus.requestExclusive (Spotify pausiert)
    STT-Endpoint    → _cleanupStreamLocal → _releaseFocusDeferred → 800ms
                      Timer → release+nudge (Spotify wuerde resumen)
    Brain processing 50s lang...
    TTS-Start       → KEIN expliziter Focus-Request! AudioTrack-USAGE_
                      ASSISTANT pausiert Spotify nur IMPLIZIT (versions-
                      abhaengig). Wir wissen nicht ob Spotify gerade
                      gepaust ist.
    TTS-End         → release+nudge — aber wenn Spotify implizit-paused
                      ist, hat es keinen sauberen Focus-Owner gesehen
                      und nudge alleine reicht nicht zum Resume.

  Wake-Word-Flow:
    Aehnliches Problem wenn state schon armed ist beim TTS-Ende
    (vom 'no-speech in conv-window'-Pfad), dann ist mein
    endConversation ein noop → releaseConversationFocus laeuft nie,
    nur die PcmPlaybackFinished-Direkt-Release greift, hat aber
    dasselbe nudge-zu-schwach-Problem.

Fix in _firePlaybackStarted (audio.ts): EXPLIZITES AudioFocus.requestDuck
beim ersten TTS-PCM-Chunk. Damit IST Spotify ueber unseren Focus
gepaused, statt nur implizit. Der spaetere release beim Pcm-Playback-
Finished ist dann das normale 'Owner ist fertig'-Pattern das Spotify
zuverlaessig zum Resume triggert.

Idempotenz: requestDuck released vorher den vorigen Focus (in Kotlin),
also harmlos wenn wake-word-acquireConversationFocus eh schon requestDuck
gerufen hat. Plus _cancelDeferredFocusRelease vorne, damit kein noch
pendender 800ms-Timer mitten in der TTS Spotify falsch resumed.

Stefan testet im Auto und auf dem Tisch — beide Spotify-Versionen
sollten mit explizitem Focus-Owner-Wechsel sauber pausieren+resumen.
---
 android/src/services/audio.ts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/android/src/services/audio.ts b/android/src/services/audio.ts
index 7cd5903..21b2262 100644
--- a/android/src/services/audio.ts
+++ b/android/src/services/audio.ts
@@ -1518,6 +1518,18 @@ class AudioService {
       this.playbackStartTime = Date.now();
       this.currentPlaybackMsgId = this.pcmMessageId;
     }
+    // AudioFocus EXPLIZIT fuer TTS halten — sonst pausiert Spotify zwar
+    // beim Recording-requestExclusive, der wird aber 800ms nach STT-Endpoint
+    // released (Brain-Processing-Gap), und wenn dann TTS startet ist niemand
+    // mehr Focus-Owner. Spotify pausiert evtl. implizit beim AudioTrack-
+    // USAGE_ASSISTANT, aber unsere nachtraegliche release+nudge-Sequenz
+    // kann es dann nicht zuverlaessig wieder anstossen. Mit explizitem
+    // requestDuck IST Spotify sauber-via-Focus pausiert, und der Release
+    // beim PcmPlaybackFinished triggert das normale "Owner fertig → resume"-
+    // Pattern in Spotify — funktioniert versionsunabhaengig.
+    // Pending Release-Timer canceln damit der nicht mitten in der TTS feuert.
+    this._cancelDeferredFocusRelease();
+    AudioFocus?.requestDuck().catch(() => {});
     this.playbackStartedListeners.forEach(cb => {
       try { cb(); } catch (e) { console.warn('[Audio] playbackStarted listener err:', e); }
     });