A wake word is the short spoken phrase ("Alexa", "Hey Siri", "OK Google") that tells an always-listening device to start paying attention. Wake word detection (also called keyword spotting or hotword detection) is the task of catching that phrase in a continuous audio stream, on-device, using as little power as possible, while ignoring everything else people say all day.
The engineering problem is unusual and unforgiving. The detector must run 24/7 on milliwatt power budgets, react in a few hundred milliseconds, and fire reliably when the phrase is spoken by any voice at any distance in any noise. It must also almost never fire when the phrase wasn't spoken. A device that misses commands is annoying; a device that activates from the TV is a privacy incident.
This guide covers how wake word detection works, the false-accept/false-reject tradeoff that governs everything, the main tools for building a custom wake word, and the data problem that ultimately decides whether your wake word feels like magic or like a beta.
What is a wake word and why devices need one
Continuously streaming microphone audio to the cloud is a non-starter for privacy, bandwidth, and battery. The wake word is the gate: a small model runs locally, examines audio in real time, and discards everything until the trigger phrase appears. Only after detection does the device light up, start streaming, and hand off to the full speech recognition stack.
Good wake words are chosen deliberately: typically 3+ syllables, phonetically distinctive, and rare in normal conversation. "Alexa" works well; a two-syllable common word would fire constantly. This is also why brands agonize over wake word choice. It's a UX decision, an acoustics decision, and a brand decision at once.
How wake word detection works: on-device keyword spotting
Modern wake word engines are small neural classifiers, not ASR systems. A typical architecture:
- Feature extraction. Audio is converted to mel spectrogram / MFCC-style features, usually over a sliding window of one to a few seconds.
- A tiny always-on model. A compact network (depthwise-separable CNNs, small CRNNs, or streaming variants) scores each window for the wake phrase. These models are deliberately minuscule: from tens of kilobytes (microcontroller deployments, e.g. microWakeWord on ESP32-class chips) to a few megabytes. Some SoCs run the first stage on a dedicated low-power DSP so the main CPU stays asleep.
- Cascaded verification. Because stage one must be tiny, it's tuned sensitive, and its detections are then confirmed by a larger second-stage model, on the application processor or in the cloud, before the assistant actually activates. This cascade is how commercial assistants get both low power and low false accepts; some stacks add speaker verification here too, so the device responds only to enrolled voices.
- Endpointing and handoff. On confirmation, the device typically passes the wake word audio plus the following utterance downstream, often with a VAD determining where the command ends.
The whole loop has to complete within a few hundred milliseconds of the phrase ending, or the interaction feels broken.
False accepts vs. false rejects: the tradeoff that defines the product
Wake word quality is measured on two axes, and every design decision trades one against the other:
- False reject rate (FRR): the wake word was spoken, the device didn't respond. Measured as a percentage of genuine attempts missed.
- False accept rate (FAR): the device activated without the wake word. Because non-wake-word audio is unbounded, this is measured per unit time: false accepts per hour (or per day) of ambient audio.
Raising the detection threshold lowers false accepts and raises false rejects; lowering it does the reverse. Published operating points give a sense of the achievable range: Picovoice reports Porcupine detecting over 97% of utterances at under 1 false alarm per 10 hours of noisy audio, and openWakeWord's documentation suggests ≤5% FRR at under 0.5 false accepts per hour as a realistic target for its pre-trained models. Commercial flagship assistants aim far lower on false accepts, since a device sitting in a living room for months accumulates enormous exposure time.
The hardest test cases are hard negatives: phrases phonetically close to the wake word ("Alex ate…" vs "Alexa"), the wake word spoken on TV, and speech-like noise. Serious evaluations use hours of "dinner-party" audio, media playback, and confusable phrase lists, not just clean positives.
| Metric | What it measures | Typical target (practical) |
|---|---|---|
| False reject rate | Missed genuine activations | < 5% (clean), < 10% (noisy/far-field) |
| False accept rate | Spurious activations | ≪ 1 per 10 hours of ambient audio for products; < 0.5/hour acceptable for hobbyist use |
| Latency | Phrase end → activation | ~200-500 ms |
| Footprint | Model size / compute | Tens of KB (MCU) to a few MB (SoC) |
Tools for building a custom wake word
- Picovoice Porcupine. Commercial, closed-source engine with SDKs for basically every platform (MCUs to browsers). Its standout feature: you type your custom wake word into the Picovoice Console and get a trained model in minutes, no data collection required. Strong accuracy benchmarks; licensing costs apply for commercial use.
- openWakeWord. Open-source (Python/ONNX), built by David Scripka. Trains custom models almost entirely on synthetic speech (thousands of TTS-generated pronunciations of your phrase) plus large negative datasets. Realistic accuracy for many phrases, very low effort, and free; widely used with Home Assistant.
- microWakeWord. Open-source framework producing tiny streaming models (via TensorFlow Lite for Microcontrollers) that run on ESP32-S3-class hardware. This is the engine behind on-device wake words in ESPHome/Home Assistant voice hardware. Also trained largely on synthetic positives.
- Google Speech Commands dataset. The standard public benchmark for keyword spotting research: one-second clips of 35 short words from thousands of speakers. Useful for benchmarking architectures, though note it benchmarks word classification, which is easier than open-world wake word detection against unbounded negatives.
- Other options: Sensory TrulyHandsfree and Cyberon (commercial embedded), plus the deprecated-but-still-referenced Snowboy and Mycroft Precise.
The synthetic-data approach (openWakeWord, microWakeWord) is the interesting recent development: modern TTS is good enough to bootstrap a usable detector with zero recordings. But "usable" and "shippable" are different bars, which brings us to data.
The wake word data problem
A wake word model's job is to recognize one phrase from anyone, anywhere, under any conditions. That makes its training data requirements peculiar and brutal:
- Speaker diversity. Thousands of distinct speakers saying the phrase, across genders, ages (children are notoriously hard), accents, and native/non-native pronunciations. A model trained on one demographic will systematically reject others, and wake word bias is a highly visible product failure.
- Acoustic diversity. Near-field and far-field (2-5 m), reverberant rooms, device playing music over its own detection ("barge-in"), car cabins, kitchen noise. Teams augment with room impulse responses and noise mixing (e.g., MUSAN), but augmentation of a narrow speaker base only stretches so far.
- Hard negatives at scale. Hours upon hours of speech that is not the wake word, including deliberately confusable phrases, to push the false accept rate down. Negatives are cheap in bulk (podcasts, conversational corpora) but the near-miss confusables usually have to be collected on purpose.
- On-device channel match. Recordings through the actual device microphone array, post-AEC, matter for the last stretch of accuracy.
Synthetic TTS positives get you surprisingly far for a prototype. For a product, teams almost always end up commissioning a targeted collection: a defined phrase list (wake word + confusables), a speaker quota spanning specific accents and demographics, prescribed distances and noise conditions, and recording through representative hardware. This is exactly the shape of project our custom speech data collection service runs. You specify speakers, languages, environments, and prompts; we deliver consented, metadata-rich recordings ready for training. For the negative side and for the languages your assistant must ignore-but-coexist-with, off-the-shelf conversational datasets in languages like US English and Hindi supply realistic ambient speech at scale.
Practical recipe for a custom wake word
- Pick a 3-4 syllable, phonetically distinctive phrase; test it against your product languages for accidental confusables.
- Prototype with openWakeWord or Porcupine to validate UX before investing in data.
- Define your operating point (FRR at a fixed FAR) and build a real test set: diverse recorded positives + many hours of ambient negatives including media audio.
- If prototype accuracy plateaus, collect real positives (thousands of speakers) and targeted hard negatives; retrain and re-evaluate at the same operating point.
- Re-test after every hardware or AEC change. The channel is part of the model's input distribution.
Need training data?
Whether you need thousands of consented speakers recording a custom wake phrase or bulk conversational audio for hard negatives, we can supply both, off-the-shelf in 60 languages or collected to your spec. Browse the datasets or contact us to scope a wake word collection.