dualfroz
affe71f68c
The greeting and announcingIdleTimeout states accepted SPEECH_START unconditionally, so the caller cut the first message and the idle prompt short even with allowUserBargeIn set to false, unlike processingUserRequest and waitingForSpeechTimeout which already guard that event. Guarding the event alone would drop the utterance: idle only listens for SPEECH_START, so speech produced while the assistant was talking would never be processed. Both playing states now buffer SPEECH_RESULT without stopping playback and hand it to waitingForSpeechTimeout when the message finishes, and idle accepts a SPEECH_RESULT that lands right after playback ended. Closes #891