mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-29 18:46:59 +00:00
'Clicked voice chat but it never starts listening' — a mic-device contention race. Starting a voice conversation fires wake.pause (to free the mic from the wake-word listener) and opens the conversation's own mic in two separate effects, both keyed on voiceConversationActive with no ordering between them. wake.pause was fire-and-forget, so getUserMedia often raced the wake listener's stream teardown (which joins a reader thread + closes the device in a finally). On Windows the capture device is effectively single-owner, so opening it while wake still held it failed and the conversation never started listening. Wake-word-initiated starts don't hit this: the backend's _on_detect calls pause_listening synchronously before emitting wake.detected, so the mic is already free by the time the frontend opens it. Only the button/hotkey path raced — matching the report. Fix: pauseWakeForVoice now returns an awaitable barrier for the in-flight wake.pause round-trip, and useVoiceConversation awaits a new beforeMicOpen hook (wired to that barrier) right before handle.start(), re-checking enabled/muted/busy/idle after the wait. No behavior change when the wake word isn't running (barrier is null → no wait). tsc + eslint clean, 39 desktop voice/wake tests green. |
||
|---|---|---|
| .. | ||
| bootstrap-installer | ||
| desktop | ||
| shared | ||