Custom Wake Word for Existing Hardware
A product does not always need a new voice module or a new main controller. If the existing device can capture microphone audio and run a compatible model, a custom offline wake word can often be added as a software feature.
First check the hardware boundary
Confirm the microphone path, sample rate, available RAM and flash, processor load, power budget and operating system. The model format matters too: ONNX is useful on systems with an ONNX runtime, while TFLite Micro is a common route for constrained embedded targets.
| Existing product | Possible integration path | Key question |
|---|---|---|
| Android app or device | Local microphone input plus ONNX runtime | Can the app keep listening within its power and permission limits? |
| Web tool or kiosk | Browser microphone plus ONNX/WASM inference | Does the browser and microphone permission flow work for the target users? |
| Linux, Windows or macOS product | Python or native ONNX runtime | Are the audio device and packaging stable across the supported systems? |
| Embedded board | TFLite Micro or a board-specific runtime | Is the exact board, microphone and firmware path tested? |
Wake word or fixed commands?
Use a wake word when the product needs to start a second voice interaction layer. Use a multi-keyword model when a short list of phrases should map directly to actions such as next, stop, open or turn on. Do not use either as a substitute for open-ended ASR.
What changes in the product
- Microphone capture and permission handling;
- audio framing and feature extraction;
- model loading and threshold configuration;
- cooldown and repeated-trigger protection;
- callbacks that connect a recognized phrase to a safe product action;
- testing on the final enclosure and microphone.
What Voicute can deliver
Voicute lets the team enter its target phrase, train a custom model online and test the result before downloading. The delivery can include a compact model, standard ONNX or TFLite formats, inference examples and optional real-voice or false-trigger optimization. The final result still needs testing on the customer's own hardware.
A practical validation sequence
- Train the target phrase and test it with several speakers.
- Run the model on the closest available target environment.
- Measure recall, false triggers, latency and power use with real background noise.
- Test the action callback, cooldown and failure behavior.
- Repeat with the final enclosure, microphone and firmware.
“Works in the browser” means the keyword is worth testing further. It does not guarantee the same result after a microphone, enclosure, distance or noise environment changes.
Train your wake word first →