fix(audio): expliziter AudioFocus-Request beim TTS-Start — Spotify resumed wieder zuverlaessig
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.
This commit is contained in:
@@ -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); }
|
||||
});
|
||||
|
||||
Reference in New Issue
Block a user