Which Wake Word Is Better? microWakeWord vs Google vs Alexa

If you are building anything with a microphone, you eventually ask the same question: should the wake word be microWakeWord, Google, or Alexa?

The names make them sound like equivalent choices. They are not. microWakeWord is a framework and model path for small devices; Google controls its hotword stack inside its ecosystem; Alexa is usually a voice service paired with an integratable wake-word engine.

For a focused look at building a local wake-word path on the ESP32-S3, see Wake-word detection for always-listening devices.

I am not going to rank them with one “accuracy” number. That number only means something when the microphone, distance, noise, and test set are identical. The useful comparison is architectural: what you control, where audio goes, and which hardware each approach actually fits.

The short version

The three names sound similar, but model control and audio boundaries are very different.

Criteria	microWakeWord	Google	Alexa
What it is	Framework and models for constrained devices	Hotword stack inside Google's ecosystem	Voice service plus wake-word engine/client
Detection location	Local on the MCU when deployed that way	Usually local on supported devices	Engine is usually on-device; AVS handles the voice session
Custom wake words	Yes, but you train and test them	Not an open path for arbitrary hardware	Depends on the engine and integration program
Data control	High	Depends on the device and service	Depends on the client, engine, and AVS
ESP32-S3 fit	Excellent	Not practical for custom firmware	Too large if all you need is a small local detector
Main trade-off	You own the model and tuning work	Less control, more finished UX	Strong ecosystem, more integration complexity

1. microWakeWord: the practical ESP32-S3 choice

The microWakeWord repository describes an open-source library for detecting wake words on low-power devices and producing models suitable for TensorFlow Lite for Microcontrollers. The model does not need a Linux computer or a cloud API to run.

The pipeline is straightforward:

1. The microphone feeds an audio stream into firmware.
2. Audio becomes compact spectral features; the repository describes 40 spectrogram features every 10 ms.
3. A streaming model returns a probability for each window.
4. Several consecutive windows decide whether the wake word was actually heard.

ESPHome provides a Micro Wake Word component for running this locally. You can configure `probability_cutoff`, `sliding_window_size`, VAD, and models from the official model repository.

```yaml micro_wake_word: microphone: microphone: i2s_mic channels: 0 gain_factor: 4 vad: models:

• model: okay_nabu id: wake_model probability_cutoff: 97% sliding_window_size: 5 ```

What I like is the clear data boundary: before detection, audio can be processed and overwritten directly on the ESP32-S3. But open source does not mean “accurate out of the box.” The repository also warns that good model training is difficult; you need varied positive samples, negative data, noise/reverberation augmentation, and speakers outside the training set.

microWakeWord fits on the MCU; Google keeps the stack inside its platform; Alexa separates the engine from the AVS session.

2. Google: good hotword experience, not a library to drop into an ESP32

Google Assistant uses “Hey Google” and “OK Google.” Hotword detection is deeply optimized inside Android, phones, and supported Google devices. It normally sits locally before an Assistant session begins, but the model, training data, and tuning stack are not an open package that I can download and compile for an ESP32-S3.

Google does have open repositories and research around keyword spotting, including Google Coral's project-keyword-spotter, but a research/demo repository is not the official “Hey Google” model. Google's keyword-spotting research for Assistant also shows why real deployments need multiple layers to manage false accepts and false rejects.

If you are building an Android app or a supported Google device, Google makes sense: the wake word, UX, and Assistant belong to one ecosystem. If you are writing ESP-IDF firmware for an ESP32-S3, Google is not a “just install the package” option. I would use push-to-talk or a separate local detector for input, then connect a service later if the product really needs it.

3. Alexa: do not confuse AVS with the wake-word engine

The Alexa Voice Service Device SDK is a client SDK for connecting a device to Alexa Voice Service. Wake-word detection has a separate boundary. In the AVS ecosystem, the wake-word engine is integrated through interfaces; older Raspberry Pi examples used third-party engines such as Sensory.

In plain terms: Alexa/AVS helps you build a device connected to Alexa, but it does not turn “Alexa” into an open-source model that runs freely on every microcontroller. The wake-word engine remains a dependency with its own platform, licensing, and resource requirements.

Amazon also explains in the Alexa Auto SDK that the SDK provides hooks for connecting a wake-word engine. When evaluating Alexa, I would ask:

• Who owns the wake-word engine, and what is its license?
• How does audio move to AVS after detection?
• Does the device have enough RAM, storage, TLS, networking, and audio front-end support for the client?

For an Alexa Built-in product, this ecosystem can be the right one. For a small ESP32-S3 device speaking locally to Home Assistant, it is a fairly large dependency chain.

Compare them against the job you actually have

When privacy and local processing matter

microWakeWord wins on control. You know which model runs, which threshold is used, and can design the system so audio before the wake word never leaves the device. Google and Alexa may have local hotword stages, but their complete voice experiences remain tied to their platforms and services.

I would still add a visible status LED and a physical microphone power switch. “Local” is a property of the circuit, firmware, logs, and network policy together, not just a README sentence.

When you need a finished voice experience

Google and Alexa have a major advantage in wake phrases, UX, accounts, intents, and back-end services. You trade for less model control, more platform dependency, and a larger integration surface.

microWakeWord gives you a small detector, not a complete assistant. You still own command capture, STT, intent handling, and TTS — for example, a local Home Assistant Assist pipeline.

When you need a custom wake word

microWakeWord is the most direct path of the three, but “custom” does not mean “easy.” A good phrase should be distinctive, comfortable to repeat, uncommon on television and in conversation, and robust across voices. For Vietnamese, I would test regional accents and different emphasis patterns instead of relying on one synthetic dataset.

Test the room, not one clean file

Wake-word performance belongs to the room as much as to the model. My minimum test sheet would include:

• The phrase at 0.5, 2, and 4 meters.
• Quiet speech, normal speech, and calling from another room.
• Several hours of TV, podcasts, music, fans, and kitchen noise.
• Multiple speakers, accents, and pronunciations.
• The device playing its own response, to check echo re-triggering.

Wake-word performance belongs to the room, so test distance, TV speech, music, fans, and real voices.

Record detected attempts, false rejects, false accepts per hour, latency, and environmental conditions. Do not conclude with “accuracy = 95%”; a device that falsely activates twice every night can be more frustrating than one that occasionally misses a phrase.

What would I choose?

For an ESP32-S3 and a local voice product, I would choose microWakeWord for the wake-word layer and keep push-to-talk as a fallback. It is the best balance of resource use, privacy, and debuggability.

I would choose Google when the product already belongs inside a supported Google device ecosystem and the finished UX matters more than model control. I would choose Alexa when the product needs Alexa Built-in/AVS and the team accepts the SDK, cloud, account, and wake-engine requirements.

A threshold only means something when tuned with the final microphone, enclosure, speaker, and mounting position.

The short conclusion: microWakeWord is the choice when you want to build and control the detector; Google is the platform choice; Alexa is the voice ecosystem choice with a wake engine integrated around it. Comparing them this way helps you avoid choosing the wrong hardware or making promises about privacy that the whole system cannot keep.

References

• GitHub - OHF-Voice/micro-wake-word
• ESPHome - Micro Wake Word
• GitHub - ESPHome micro-wake-word-models
• GitHub - Google Coral project-keyword-spotter
• Google Research - Keyword Spotting for Google Assistant
• GitHub - Alexa AVS Device SDK
• Amazon - Alexa Auto SDK