DEV Community

voicute
voicute

Posted on Edited on

openWakeWord vs an online wake word generator: two paths to a custom model

openWakeWord vs an online wake word generator: two paths to a custom model

openWakeWord is the default answer when Home Assistant users want custom wake words, and for good reason: it's free, open source, and ships with a set of official pretrained models. I've used it, and parts of my own product exist because of its limitations.

Because people ask me to compare it with Voicute — the online generator I built — here is an honest breakdown: what openWakeWord's training path actually involves, where it struggles, and what a hosted generator changes. (microWakeWord, the ESP32-side cousin of openWakeWord, gets its own post.)

First, the right mental model

These are not two versions of the same thing. openWakeWord is a pipeline you operate: open-source training notebooks, open weights, open runtime, and you own every step. Voicute is a hosted workflow that operates the pipeline for you — type a phrase, get a model. The training platform is closed source; the inference engine and the exported models are open.

If your decision criterion is "must the training code be open?", this comparison is over — pick openWakeWord and be done. The comparison below is for everyone else.

What custom training on openWakeWord looks like

For the official pretrained models, openWakeWord is excellent — download, load, done. The story changes when your phrase isn't one of them:

  • Generate synthetic positive samples with the Piper sample generator (free, open TTS)
  • Assemble negative datasets: background audio, speech, music
  • Run the training notebook (Colab or local Python)
  • Export ONNX/tflite, test on the real device, and usually iterate

One structural fact explains most of the pain: the speech embedding backbone is frozen. Custom models are small classifiers on top of a fixed feature space. When your phrase lives in a badly-covered region of that space, no amount of training steps pulls recall up — I've measured swings from roughly 25% to 90% between two words trained with the identical recipe. Lowering the threshold to recover recall buys you false wakes.

Also note the language situation: the official pretrained models are English. The training notebook can synthesize samples in other languages via Piper voices, but you own the entire validation burden — nobody has tuned that path for you.

What the hosted generator does differently

Same goal, different allocation of work:

openWakeWord Voicute
Code fully open (training + runtime) training closed; engine + models open (GitHub)
Sample TTS Piper (free) commercial neural TTS
Architecture frozen embedding + small classifier head from-scratch TCN per model
Real recordings DIY — record, re-run notebook, repeat upload in browser, retrain is one click
Multi-keyword one model per word, stacked at runtime 2–10 words in one model (~128 KB, <5 ms)
Languages English pretrained; others DIY Chinese, English, German, French, Japanese workflows
Output ONNX / tflite ONNX + TFLite, standard formats
Time to first model hours–days, notebook fluency required minutes to a testable model

Three of these deserve a paragraph each.

No frozen embedding. Because Voicute trains from scratch per model, the network can shape its feature space around your specific phrase instead of drawing a boundary inside a fixed one. That's the direct answer to the "word-picking" problem above — not magic, just not inheriting someone else's frozen features.

Commercial TTS + real recordings. Piper is impressive for a fully open pipeline, but synthetic samples are the only positive evidence an openWakeWord model ever sees, and Piper's prosody/accent range is narrow. Voicute starts from commercial-grade neural TTS — closer to natural speech, fewer retrain cycles — and, more importantly, treats real recordings as a first-class step: when recall disappoints on real hardware, you record a small varied set of the actual phrase, upload it, and retrain. A small varied set beats hundreds of duplicate takes. All of this is possible in openWakeWord's world too; it's just you, scripts, and an afternoon each time.

Multi-keyword in one model. openWakeWord trains one model per word, and your runtime stacks them. A wake word plus four commands means five models to tune and serve. Voicute trains 2–10 keywords into a single model with one inference pass — ~128 KB and under 5 ms on an ESP32-S3.

When openWakeWord is still the right call

  • Your phrase is close to an official pretrained model — free, proven, done.
  • You need the training pipeline itself open and auditable end to end.
  • You're researching, not shipping, and the notebook loop is part of the fun.

When the generator earns its keep

  • The phrase is non-English, or English-but-picky (the 25%-recall kind).
  • Recall must be stable without per-device threshold tuning.
  • You need wake word + commands in one small model.
  • The person doing this is a firmware engineer with a deadline, not an ML hobbyist.

That's the whole trade: open pipeline you operate vs hosted workflow that operates it for you, with different TTS, different model architecture, and a real-recording loop measured in minutes. If runtime openness matters to you, note that Voicute's engine and models are on GitHub — measure recall yourself rather than trusting any "90%+" claim, mine included.


Disclaimer: I'm the creator of Voicute. openWakeWord is referenced fairly as far as I can — it's a genuinely good project; if I've mischaracterized anything, tell me and I'll correct it..

Top comments (0)