Wake Word Training Data: How Much You Need and What to Record

Wake word training data has three parts. Positives: many different people saying your exact phrase, recorded on the devices, at the distances and in the rooms where your product will listen. Negatives: phrases that sound like the wake word, ordinary speech, and the noise, music and TV the device hears all day. And a held-out test set from speakers the model never trained on, scored as false accepts per hour of negative audio and as the false reject rate, the share of genuine attempts the model misses.

The numbers to settle before anyone records are speakers, repetitions per speaker, devices, distances, rooms, noise and the hours of negative audio you will test against. Published research gives reference points: the public Hey Snips dataset holds about 11,000 recordings of one wake phrase from over 2,200 speakers, with no more than 10 per speaker. This guide works through those numbers from the buyer's side and ends with a spec table you can paste into a brief. For how the detector itself works, see our explainer on wake word detection.

What a wake word dataset contains

A complete set has five kinds of recordings, and each one answers a different question about the model.

• Wake phrase positives. The exact phrase, said naturally by many speakers. They teach the model what to fire on.
• Phrase plus command. If users say "Hey Juniper, turn off the lights" in one breath, record it that way too. Apple's RepCNN paper describes a training set of 1 million utterances, "each of which includes the wake-word followed by a user query". Planning the commands themselves is a separate job, covered in our guide to voice command data.
• Confusable phrases. Words and phrases that share most of the wake word's sounds. These negatives decide the false accept rate.
• General negatives. Conversation, media audio and household noise with no wake word in them. They come in bulk and need no custom prompts.
• A held-out test set. Positives and negatives from speakers kept out of training, recorded in the conditions of use.

What open datasets tell you about scale

Three public datasets are common starting points for keyword spotting research. None contains your wake phrase, but their numbers and design choices show what a collection needs.

Three lessons follow from them.

Speakers matter more than repetitions. Pete Warden set out to record as many different people as he could for Speech Commands, because keyword spotting models are "much more useful if they're speaker-independent". Each contributor said each core word five times, in a session of 135 prompts that took about six minutes. Hey Snips capped each speaker at 10 positives and 30 negatives. Both designs spread the data across many voices rather than many takes from a few.

Record negatives in the same conditions as positives. The Hey Snips negatives were recorded in the same conditions as the wake word, so both classes came "from the same domain (speaker, hardware, environment, etc.)". Otherwise a model can learn to separate the classes by microphone or room instead of by what was said. In a custom collection, that means the same speakers record the confusables in the same sessions as the wake word.

Generic keywords are not your brand phrase. Speech Commands holds isolated single words, and contributors were not asked for gender or other attributes, so its accent coverage can't be checked. The MSWC words were cut from read sentences by an automatic aligner, and the paper reports its speakers as 60% male, 15% female and 25% unknown. Hey Snips is one English phrase recorded close to the microphone, and its authors named "recording hardware, accents, or far-field settings" as future work.

Hey Snips is also research-only: the Sonos repository that distributes it says "No commercial use", while Speech Commands and MSWC are released under CC BY 4.0. A custom wake word needs its own recordings.

How much data to train a wake word

No single number fits every phrase and device, but published work brackets the answer.

• Published first models: about 6,000 to 10,000 recorded positives. Hey Snips trained on 5,876 positive utterances from 1,179 speakers, about five takes each. On its own close-talk test set, its best model has a false reject rate of 0.12% on clean audio and 1.60% with noise at 5 dB SNR, both at 0.5 false alarms per hour. In an Amazon study, a new wake word started from 9,487 utterances (10.18 hours) recorded on a close-talk microphone in a quiet room.
• Augmentation and mining stretch that start. The Amazon team simulated far-field audio with room impulse responses and noise, then mined wake word and confusable examples from untranscribed speech with an ASR model. They report performance comparable to a production model trained on 375 hours of far-field data, "saving 97% of the amount of WW-specific data collection". That result depended on an existing speech recognizer and a large untranscribed corpus, which a new product may not have.
• Production assistants go far beyond it. Apple's RepCNN paper trains on 1 million utterances, and an Amazon Alexa paper used 12 million wake word examples and 5 million negatives from far-field audio of the kind Alexa devices hear. Numbers like these describe mature assistants, not a first collection.

For planning, treat the first range as a starting point for one language and one device class, and spread it across speakers. At a cap of 10 takes per speaker, 6,000 positives need at least 600 speakers; Hey Snips used about twice that by taking fewer from each. Then add speakers for every accent, age group and device you plan to report on separately, because each slice needs enough voices of its own to measure.

Synthetic positives and their limits

The fastest route to a first model skips recording. openWakeWord says its included models "were all trained with 100% synthetic speech generated from text-to-speech models". The documentation for its "alexa" model lists about 100,000 generated clips from two multi-speaker TTS models, with speaker embeddings mixed to create new voices, plus about 31,000 hours of negative audio, including synthetic phrases built to sound like the wake word, such as "annex uh". For new phrases, the README recommends "a minimum of several thousand" generated examples.

The method has research behind it, with a condition. In a Google study on the Speech Commands words, a model trained from scratch on synthetic speech alone reached 56.7% accuracy, against 88.7% for the same number of real recordings. With a pre-trained speech embedding underneath, the synthetic-only model reached 92.6%, against 95.3% for the same number of real recordings and 97.7% for the full real dataset. openWakeWord builds on that same embedding model.

The limits are stated by the tools themselves:

• Language. openWakeWord "only supports English, primarily because the pre-trained text-to-speech models used to generate training data are all based on english datasets."
• Voice variety. LiveKit's wake word library, built on openWakeWord, generates data in over 30 languages, and its README says multilingual models "currently achieve lower accuracy than English models", partly because its multilingual TTS produces less diverse speech than the English one.
• Evaluation. openWakeWord measures its accuracy on recorded speech: the "alexa" test clips are crowd-sourced recordings from Picovoice's public benchmark, and the "hey mycroft" test clips were "manually collected from a male speaker with a relatively neutral American english accent". That is a long way from a test set covering your users.

A sensible split for many teams: synthetic positives to prototype and to add variety, recorded positives for the test set and for the accents, languages and devices where the prototype fails.

Negatives and false accepts

A false accept is the device waking when nobody said the wake word. Most come from speech that shares sounds with the phrase, so the confusable list deserves as much care as the phrase. Amazon's team built theirs with a "lexicon filter" that compares phoneme sequences by edit distance. For a six-phoneme wake word, words one or two phonemes away gave them "sufficient negative examples". A buyer's list for a phrase like "Hey Juniper" would cover:

• Phrases one or two sounds away, such as "Hey Jupiter".
• Each part of the phrase alone, and the first word followed by other names.
• The phrase running across word boundaries inside longer sentences.
• Names, brands and common words in your users' languages that rhyme with it.

Apple defines the false-accept rate as "the number of false activations per hour (or mean hours between activations)" in its Hey Siri article. To measure it, play hours of audio with no wake word through the detector, count activations and divide by hours. Papers then report the false reject rate at a fixed false accept rate: Hey Snips at 0.5 false alarms per hour "computed on the collected negative data", Apple's RepCNN at 3 per hour against about 2,000 hours of "dense general speech". Compare models only on the same negative audio.

False accepts are rare events, so a short test can't measure them. A 10-hour test that records 5 false accepts is consistent, at 95% confidence, with a true rate anywhere from about 0.16 to 1.17 per hour (exact Poisson interval). As a planning starting point, record enough negative hours to expect 10 to 20 false accepts at your target: 20 to 40 hours for 0.5 per hour, 100 to 200 hours for 0.1 per hour.

Apple says its negative set holds "thousands of hours of recordings" because it is "trying to estimate false-alarm rates as low as one per week". At that rate, 10 false accepts take about 1,680 hours.

Two details keep the count honest. The negative audio should sound like the deployment: Apple's includes podcasts and other speech, chosen to represent "the kinds of phrases that a user might say to another person". And any real occurrence of the wake word in it, say a podcast that mentions your product, should be labeled as such, as Apple does, so the detector is not penalized for it. For bulk negative speech in your users' languages, licensed conversational data works well: SpeechData.ai's dataset catalog holds spontaneous two-person conversations in 60 languages and dialects. Keep test negatives separate from the audio you train on.

A collection spec to paste into a brief

Fill in each row for your product. Where a note gives a number, it comes from the research above and is a planning reference, not a rule.

These rows cover what our wake word data collection service asks for in a brief: phrases, languages and accents, speaker counts, devices and environments.

Building the test set

The test set decides whether you ship, so build it before you train. Apple calls its own "quite expensive to collect and prepare, but essential", and device logs can't replace it, because the system "doesn't capture the attempts that failed to trigger".

• Hold out speakers. No test speaker should appear in training. The MSWC splits ensure "no known speakers appear in multiple data splits for the same keyword"; apply the same rule by speaker ID across positives, confusables and commands.
• Record in the target conditions. Apple's test recordings were made "in various conditions, such as in the kitchen (both close and far), car, bedroom, and restaurant, by native speakers of each language". The Amazon study trained on simulated far-field audio but evaluated on more than 300 hours from far-field, mid-field and near-field devices in real use. If you train on simulated distance, test on real distance.
• Break results down. Report the false reject rate per accent, age band, gender, device and distance, all at the same threshold. One overall number can hide a group the model serves badly.
• Size it by speakers. The rules for an ASR test set apply here: split by speaker, and count speakers per slice, not just utterances.
• Freeze it. Keep the test set fixed, so a change in the numbers means a change in the model.

Planning a wake word collection

SpeechData.ai records wake phrases, commands and confusable phrases with native speakers recruited to your quotas for age, gender, region and accent, on phone, headset, far-field or in-car audio, and you can send your brief through our wake word collection page for a feasibility assessment and a quote within one business day. For a detector in a car, the page on in-car speech data collection lists what a brief can say about seats, microphones and cabin noise.