Measure the six handoffs before you retune an ESP32-S3 wake word

Count the stages. The path in the post runs MEMS microphone, I2S or PDM capture, device buffer, Wi-Fi upload, the Assist pipeline on the Home Assistant side, TTS return, then I2S playback out of the speaker ^[9]. The count is seven stages and six handoffs between them ^[18]. Wake word detection is one item in the Assist list ^[2], or it runs on the device when Micro Wake Word is used ^[8]. The post does not include latency measurements for any stage ^[20], so its answer on which boundary usually stalls is an argument.

The resource warning is the part I would act on first. The post treats it as an architecture boundary that defines the node's scope ^[4]. A voice satellite is usually already running continuous microphone capture, wake or button activation, API or WebSocket transport, LED status indication, speaker playback, and logs with remote debugging ^[10]. Six jobs on two cores ^[19]. Remote debug logging is on that list too, which is easy to forget while tailing logs to chase a dropout.

The microphone interface is hardest to walk back. A standard I2S bus uses BCLK, LRCLK/WS and DIN/DOUT, and PDM microphones use a different clock and data pattern ^[12]. Espressif's ESP32-S3 documentation treats standard I2S, TDM and PDM as distinct modes ^[13]. Before ordering a module, the post asks whether the microphone's output mode matches what the ESPHome component supports, whether sample rate, bit width and channel settings match what the Assist pipeline expects, and whether the device can buffer audio through short Wi-Fi, logging and playback jitter ^[14].

For the whole-path claim to transfer to your build, one topology has to hold: the device captures and plays, and Home Assistant does the understanding and the action ^[15]. If speech-to-text sits in a cloud service, the upload you need to instrument is not the one on this list. If the wake word runs locally, that inference competes for the same two cores as capture and upload ^[7][8], and a late wake is then a device-side problem.

The device half needs its own tests. The post's sequence is to drive the microphone path with short repeated phrases and inspect noise, clipping and gain before entering a full conversation, watch device stability and logs before adding optional components, and use Home Assistant's pipeline debug tools to isolate STT and intent behaviour ^[11]. Its warning for anyone whose config boots and records clean audio is that capture is all this proves; the stream still has to hold up under network jitter and playback competition ^[16].

According to the post, a slow assistant is rarely one bad function. It is usually four latencies, in capture, network, pipeline and playback, that nobody measured separately ^[17].