mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-30 19:09:28 +00:00
eb8d88f33a
'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. |
||
|---|---|---|
| .. | ||
| app | ||
| assets/tiers | ||
| components | ||
| contrib | ||
| debug | ||
| fonts | ||
| hooks | ||
| i18n | ||
| lib | ||
| plugins | ||
| sdk | ||
| store | ||
| themes | ||
| types | ||
| global.d.ts | ||
| hermes-cron-scope.test.ts | ||
| hermes-parity.test.ts | ||
| hermes-profile-scope.test.ts | ||
| hermes.test.ts | ||
| hermes.ts | ||
| main.tsx | ||
| styles.css | ||
| vite-env.d.ts | ||
| webhooks-rest.test.ts | ||