ESPHome 2026.11 lets micro_wake_word buffer up to a second of audio for speakers that play music while listening

On a voice satellite that also plays music, wake word detection has to share the ESP32 with audio decoding and playback. If the detection task falls behind for a moment, the small buffer holding microphone audio fills up and ESPHome throws its contents away. A new option in ESPHome 2026.11 lets you make that buffer bigger. Contributor mbrudka opened the pull request on 16 October, and J. Nick Koston (bdraco) merged it on 18 October at 04:43 Polish time, together with its documentation.

What the option does

The micro_wake_word component gets ring_buffer_duration. It accepts values from 120ms to 1s. If you leave it out, the buffer stays at the current 120 ms, so existing configurations behave as before.

micro_wake_word:
  microphone: my_microphone
  ring_buffer_duration: 800ms
  models:
    - model: okay_nabu

Wake word models need 16 kHz, mono, 16-bit audio, which works out to 32 bytes per millisecond. The default 120 ms takes 3,840 bytes and 800 ms takes 25,600 bytes, plus a little allocation overhead. The maximum of one second comes to 32,000 bytes.

Why it helps

When the buffer runs out of space, ESPHome resets it and logs a warning: "Not enough free bytes in ring buffer to store incoming audio data. Resetting the ring buffer. Wake word detection accuracy will temporarily be reduced." In other words, the audio in the buffer at that moment never reaches the model, and a wake word spoken then may be missed.

The author tested this on a Raspiaudio Muse Luxe playing MP3 files at the same time. With a 400 ms buffer, the buffer overflowed in one of two starts. With 800 ms, it did not overflow in any of eight starts with the same audio source. The pull request calls those starts "uninstrumented", so treat them as a field report rather than a benchmark.

What it does not fix

The documentation and the pull request are explicit about the limits. A longer buffer does not make inference faster and does not add a delay at start-up. It only absorbs short stalls, and the pull request says it does not cure sustained CPU starvation: if other tasks keep the processor busy for long stretches, detection will still fall behind.

A sensible way to use it: if your logs show the ring buffer warning while the device plays audio, raise ring_buffer_duration in steps, for example to 400 ms and then 800 ms, and watch whether the warning goes away. If you never see the warning, leave the option out.