The corpus is the asset, so the same phrase can wake a microcontroller too #93

New issue

Open

opened 2026-08-15 12:26:44 +00:00 by aiko · 0 comments

aiko commented

2026-08-15 12:26:44 +00:00

Owner

The expensive part of #87 is not the model. It is the corpus — some thousands of synthetic "Hey Denpa" utterances across a designed spread of speakers, plus the near-miss negatives that stop it firing at the television. The keyword head that comes out the far end trains in minutes and weighs 200 KB.

That corpus is reusable, and a second model trained from it puts the same wake phrase on hardware that could never run openWakeWord. Raised 2026-08-15 as a want, not a commitment.

Why openWakeWord cannot go there

The chain in #88 is three ONNX graphs behind an ONNX Runtime that #44 already measured at 27 MB. That is fine on a laptop and survivable on a phone. On a microcontroller it is not a size problem, it is a category error — there is no runtime to put it in.

microWakeWord is the sibling built for that constraint: an inception network converted for streaming, quantised to INT8, running under TensorFlow Lite Micro. It executes an inference in under 10 ms on an ESP32-S3, which is the class of part it targets. It is what ESPHome and Home Assistant Voice actually ship for on-device waking, so it is well-trodden rather than a science project.

The audio frontend is different and does not carry over: 40 features over a 30 ms window at a 20 ms stride, deliberately lighter than a mel spectrogram. So the model is not shared, only the corpus. That is the whole proposition and it is worth being precise about — nothing from #88 is reused, and nothing here feeds back into it.

Two things to settle before it is worth doing

Which device, actually. This only pays for microcontroller-class hardware — ESP32-S3 specifically, which needs the PSRAM and the vector instructions; a classic ESP32 will not run it. For anything Linux-class, a Pi or an SBC, the answer is to run #88's openWakeWord as-is and train nothing new. Half the value of this issue is deciding which of those the target is, because one of the answers is "no work".
A second phrase, or the same one. Waking a room sensor and waking the pal she lives in are different acts with different consequences, and giving them the same trigger means one always fires when you wanted the other. Worth thinking about before a shared corpus makes "the same phrase everywhere" the path of least resistance.

Order

Strictly after #87 has a corpus worth reusing. Training a micro model from a corpus that has not yet been validated — the cosine-spread check in #87's comments — would just produce a second model with the same undiagnosed flaw in a place that is harder to update.

There is no client-side work here at all. Nothing in denpa-client changes; this is an artefact for hardware that does not run it.

#87 — the corpus, and the check that says whether it is any good
#88 — the model that cannot go on a microcontroller, and why
#44 — the 27 MB runtime that is the reason it cannot

The expensive part of `#87` is not the model. It is the corpus — some thousands of synthetic "Hey Denpa" utterances across a designed spread of speakers, plus the near-miss negatives that stop it firing at the television. The keyword head that comes out the far end trains in minutes and weighs 200 KB. **That corpus is reusable, and a second model trained from it puts the same wake phrase on hardware that could never run openWakeWord.** Raised 2026-08-15 as a want, not a commitment. ## Why openWakeWord cannot go there The chain in `#88` is three ONNX graphs behind an ONNX Runtime that `#44` already measured at 27 MB. That is fine on a laptop and survivable on a phone. On a microcontroller it is not a size problem, it is a category error — there is no runtime to put it in. **microWakeWord** is the sibling built for that constraint: an inception network converted for streaming, quantised to INT8, running under TensorFlow Lite Micro. It executes an inference in **under 10 ms on an ESP32-S3**, which is the class of part it targets. It is what ESPHome and Home Assistant Voice actually ship for on-device waking, so it is well-trodden rather than a science project. The audio frontend is different and does not carry over: 40 features over a 30 ms window at a 20 ms stride, deliberately lighter than a mel spectrogram. **So the model is not shared, only the corpus.** That is the whole proposition and it is worth being precise about — nothing from `#88` is reused, and nothing here feeds back into it. ## Two things to settle before it is worth doing - **Which device, actually.** This only pays for microcontroller-class hardware — ESP32-S3 specifically, which needs the PSRAM and the vector instructions; a classic ESP32 will not run it. For anything Linux-class, a Pi or an SBC, the answer is to run `#88`'s openWakeWord as-is and train nothing new. Half the value of this issue is deciding which of those the target is, because one of the answers is "no work". - **A second phrase, or the same one.** Waking a room sensor and waking the pal she lives in are different acts with different consequences, and giving them the same trigger means one always fires when you wanted the other. Worth thinking about before a shared corpus makes "the same phrase everywhere" the path of least resistance. ## Order Strictly after `#87` has a corpus worth reusing. Training a micro model from a corpus that has not yet been validated — the cosine-spread check in `#87`'s comments — would just produce a second model with the same undiagnosed flaw in a place that is harder to update. There is no client-side work here at all. Nothing in `denpa-client` changes; this is an artefact for hardware that does not run it. ## Related - `#87` — the corpus, and the check that says whether it is any good - `#88` — the model that cannot go on a microcontroller, and why - `#44` — the 27 MB runtime that is the reason it cannot

aiko added the

ready-for-human

labels

2026-08-15 12:26:44 +00:00