Commit Graph
6 Commits
Author SHA1 Message Date
imonlinux 1da9ac1fac Update audio_engine.py
Summary

Add thread-safe locking for wake word reload logic

Problem

Wake word reload logic accessed self.state.wake_words_changed flag without synchronization, creating a potential race condition when wake words are dynamically switched via Home Assistant.

Changes

Added self._wake_words_lock = threading.Lock() in __init__
Wrapped wake word reload block with with self._wake_words_lock: context manager
Ensures atomic read-modify-write of wake_words_changed flag
Impact

Risk: Very low - purely defensive improvement
Benefit: Eliminates race condition in wake word switching
Performance: Negligible overhead (lock only held during reload check)
2026-01-10 13:23:33 -08:00
imonlinux 77c2299453 Update audio_engine.py
reverting the revert
2025-12-22 11:46:09 -08:00
imonlinux ae9b834ee3 Update audio_engine.py
Revert refractory bug fix
2025-12-22 09:54:01 -08:00
imonlinux 8d135dc51b Update audio_engine.py issue: 48
Behavioral changes:

Each wake word has its own timer.

Rapid repeats of the same phrase within the refractory window still get rejected (which is desirable).

A misfire of “Hey Jarvis” no longer locks out “Okay Nabu” immediately afterward.

If a user really wants to disable the gating, they can set:

"wake_word": {
  "refractory_seconds": 0
}


and this code will treat it as “no refractory” (max(..., 0.0) above).
2025-12-06 19:32:29 -08:00
imonlinux 0151b64810 Update audio_engine.py
Behavioral & logging changes

Improved the wake word processing loop to make the following clearly visible in DEBUG logs:

The current set of active wake word IDs (MWW/OWW).

When the Stop wake word:

is activated by the model,

is accepted (i.e. meets refractory timing + is currently allowed), and

is ignored because it is no longer in active_wake_words.

Ensured the special stop model:

Is only treated as “active” when state.stop_word.is_active is True.

Is flipped back to inactive immediately after satellite.stop() is called, so:

The first “Stop” that passes all checks cancels playback and alarm tones.

Subsequent detections in the same moment appear as “TRIGGERED but IGNORED” (expected and now clearly logged).

Why this matters

When the LVA is playing audio (TTS or timer alarm), you can now:

See exactly when the Stop model fires.

Confirm that playback is being canceled at the right time.

Understand why you might see multiple “Stop wake word ACTIVATED” messages even though the alarm already stopped (model still “hearing” the tail, but logically ignored).

This matches the behavior seen in your logs:

At lower volumes / with AEC, stop is reliably accepted and playback stops immediately.

At high volumes without AEC, the model sees far less “clean” speech, so activations are rare or absent.
2025-11-20 20:01:13 -08:00
imonlinux 6eb3f46cbe Create audio_engine.py
Brand new file. Encapsulates audio logic, suppresses warnings, fixes busy wait.
2025-11-19 18:48:44 -08:00