e9615d987e
Race-Condition entdeckt im Log: nach jeder ARIA-Antwort lief endConversation 5s nach TTS-Start (= "letzter Chunk eingetroffen"), nicht wenn der AudioTrack-Hardware-Buffer wirklich am Ende war. ARIA sprach also noch hoerbar, waehrend OpenWakeWord schon re-armte. Folge: ARIAs eigene Stimme ging direkt nach AudioRecord.startRecording ins Mikro. Die OpenWakeWord-Sessions von AudioRecord und AudioTrack sind verschieden → AcousticEchoCanceler kann den Output nicht subtrahieren (kein gemeinsamer Reference-Stream). Threshold + Patience-State der Wake-Word-Inferenz wird durch ARIAs konstante Audio-Eingabe verwirrt, der naechste echte "Computer"-Trigger geht unter. Fix: Listener-Fire aus handlePcmChunk(isFinal=true) raus, dafuer in den schon existierenden PcmPlaybackFinished-Native-Event-Handler rein. Die Kotlin-Seite emittiert das Event aus dem Writer-Thread- finally-Block — also genau dann wenn AudioTrack alle Samples durchgeschrieben hat. Side-Effect: UI-Konsumenten von onPlaybackFinished sehen den "finished"-State jetzt 1-2s spaeter (= ehrlicher zur Realitaet, ist eigentlich eine UX-Verbesserung).