Concept renderA voice command interface on a device rests on five decisions. How listening starts: wake word, push-to-talk or both. Where commands are recognized: on the device for a fixed list, or cloud ASR for open speech. Which light and tone marks each state. How misses recover. How every function works without speech.
Most voice design guides assume an app or a smart speaker that already exists. A hardware team decides more: the microphones, the chip, the button, the light and the speaker. Those parts set what the voice interface can do. This guide takes the choices in the order a device team meets them. Figures come from chip vendor documentation and US government pages, with the date we read them. It contains no Duobay test results and no prices.
What is a voice command interface on a device?
A voice command interface lets a user control a device by speaking. On a phone, the operating system does most of the work. On your own hardware, your team builds each step:
- Activation. Something tells the device to start listening: a wake word or a button.
- Audio front end. Echo cancellation, noise reduction and voice activity detection clean the microphone signal.
- Recognition. A model turns speech into a command or into text, on the device or in the cloud.
- Action. Firmware or a server carries out the command.
- Feedback. Lights, tones and speech tell the user what happened.
Each step has a hardware cost. An always-on wake word needs a detector running all day. Echo cancellation needs a reference signal from the speaker output. A cloud recognizer needs a radio. Decide the interface early, because it drives the board.
Wake word or push-to-talk: how should listening start?
This is the first decision, and it shapes power, privacy and testing. The table compares the two and a hybrid of both.
| Factor | Wake word | Push-to-talk | Both |
|---|---|---|---|
| How listening starts | The device hears a set phrase and opens the microphone stream to the recognizer. | The user holds or presses a button. Listening lasts while it is held, or until silence. | Wake word for hands-busy use, plus a button that always works. |
| Always-on load | A detector runs on every audio frame, all day. That sets your standby power. | The microphone path can sleep until the press. | Detector load stays, and the button gives a low-power fallback. |
| Wrong starts | False accepts when speech or media sounds like the phrase. Testing takes many hours of audio. | Accidental presses in a bag or pocket. A recessed button or a hold time helps. | Both, so test both. |
| Missed starts | False rejects in noise, at distance, or with accents the model saw less often. | Rare, because the press is explicit. | The button covers what the wake word misses. |
| Privacy story | The microphone is always powered. You need a clear indicator and a mute. | Easy to explain: the device listens only while you press. | Explain both modes in the setup flow. |
What a published wake word engine looks like
Espressif publishes figures for its WakeNet engine on the ESP32-S3, as of November 2026. WakeNet supports up to 5 wake words and takes 16 kHz, mono, 16-bit audio (WakeNet docs). The quantized WakeNet9 model with 2 channels uses 16 KB of RAM and 324 KB of PSRAM, at 3.0 ms per 32 ms frame (ESP-SR benchmark). On the vendor's ESP32-S3-Korvo V4.0 board with the WakeNet9 model, the benchmark lists a 98% wake rate in quiet at 1 m and 3 m, 94% with speech noise at 4 dB SNR, and a false trigger rate of once in 12 hours.
These are one vendor's results on its own board and test set. Your enclosure, microphone ports and users differ. Set your own false accept target per hour and plan enough hours of background audio to show it on your board.
Should commands run on the device or in cloud ASR?
On-device command recognition matches speech against a fixed list. Cloud automatic speech recognition (ASR) turns open speech into text on a server. They solve different problems, and one product can use both: local commands for control, cloud ASR for questions.
| Factor | On-device commands | Cloud ASR |
|---|---|---|
| What it recognizes | A fixed list of commands you define at build time. | Open speech, long sentences, names and numbers. |
| Network needed | No. It works offline. | Yes. No network means no recognition, so plan a local fallback. |
| Response time | Set by the model on your chip. Espressif states its MultiNet command model responds within 500 ms, as of November 2026. | Uplink, server and downlink time add up. See the latency budget article linked below. |
| Memory and compute | Fits on some microcontrollers with external PSRAM. Check the vendor benchmark. | Small on the device: audio capture, encoding and a network stack. |
| Audio leaves the device | No, unless you add logging. | Yes. You need a data retention policy and a deletion path. |
| Best fit | Lights, volume, timers, modes, stop, mute. | Questions, dictation, search, LLM conversation. |
Espressif's MultiNet is one published example of on-device commands, as of November 2026. It recognizes up to 200 commands offline in Chinese and English on the ESP32-S3, and MultiNet7 defines English commands by phonemes (MultiNet docs). The benchmark lists MultiNet7 at 18 KB of internal RAM and 2,920 KB of PSRAM. For English commands at 3 m, it lists 97.2% recognition in quiet, 92.3% with stationary noise and 90.6% with speech noise, both at 5 to 10 dB SNR (ESP-SR benchmark).
Notice the drop from quiet to noise. Test your command set at the distance and noise your users will have. If you need open speech on the device, the memory math changes a lot. Our on-device ASR memory budget works through it. If you send audio to the cloud, read the voice latency budget before you promise a response time.
Keep a short command list
Commands that sound alike get confused. "Lights on" and "lights off" differ by one short sound. Give each command a distinct shape and test the pairs a user might mix up. A short list is also easier to remember.
How should lights and tones show what the device is doing?
A voice device often has no screen, so the light and the tones are the whole interface. The user needs to know at a glance whether the device is listening, thinking, done or confused. Write a state map before the industrial design is frozen. It decides how many LEDs you need and where they sit.
| State | Light | Tone | What the user should do |
|---|---|---|---|
| Idle, wake word on | Off, or a dim steady color you document | None | Nothing. The device waits for the wake word or a press. |
| Listening | A distinct color or pattern, the same every time | Short rising tone | Speak the command now. |
| Processing | A second pattern, different from listening | None, or a soft tick if it runs long | Wait. The device heard you. |
| Success | Brief confirm pattern, then back to idle | Short confirm tone, or the result itself | Nothing. The action is done. |
| Did not understand | Short error pattern | Short falling tone, then an optional spoken hint | Try again, or use the button. |
| No network | A pattern reserved for offline | A tone or short phrase that names the problem | Local commands still work. Cloud requests will not. |
| Microphone muted | Dedicated indicator, separate from the status light if you can | One tone on mute and a different one on unmute | Unmute to use voice. Buttons still work. |
Some rules that keep the map usable:
- Use one pattern per state, and never reuse it for another state.
- Do not tell states apart by color alone. Use pattern or position too, for users who cannot see color differences.
- Put the light where the user looks when speaking. On a wearable, check that it stays visible while worn.
How do you design error recovery in a voice user interface?
Recognition fails some of the time, as the benchmarks above show. Good voice user interface design plans what happens next, for each type of failure.
| Failure | What the device should do |
|---|---|
| No speech after the listening tone | Close the session after a timeout you set, play the error tone and go back to idle. Espressif documents a timeout state in MultiNet: when no command is detected for a long time, it exits and waits for the wake word again, as of November 2026. |
| Speech heard, no command matched | Say what the device can do in one short line, or give two example commands. Vary the prompt on the second miss. |
| Low-confidence match on a risky action | Ask for a yes or no before purchases, deletes, calls and unlocks. Act at once on low-risk commands such as volume. |
| Wrong action taken | Offer an undo command and a button undo. Make stop and cancel work in every state, including during playback. |
| Device talking while the user speaks | Use echo cancellation with a playback reference channel so the recognizer hears the user over the speaker. |
| Repeated failures | After two or three misses in a row, suggest the button or the app. Log the miss count for your test team. |
Echo cancellation needs hardware support. Espressif's audio front end takes a playback reference channel next to the microphone channels, and its echo cancellation supports up to two microphones, as of November 2026 (AFE docs). If the speaker signal is not routed back to the processor, barge-in will be poor. That is a schematic decision, so make it before layout.
How do accessibility and privacy indicators fit the design?
Accessibility
A voice interface helps users with limited vision or limited hand use. It shuts out users who cannot speak or whose speech the model handles poorly. The US Access Board's Section 508 functional performance criteria include these lines, as of November 2026 (ICT standards):
- 302.6 Without Speech: where speech is used for input, control or operation, at least one mode of operation that does not require user speech.
- 302.4 Without Hearing: where an audible mode of operation is provided, at least one mode of operation that does not require user hearing.
- 302.1 Without Vision: where a visual mode of operation is provided, at least one mode of operation that does not require user vision.
Section 508 applies to ICT that federal agencies procure, develop, maintain or use. The Section 255 guidelines on the same page apply to telecommunications equipment makers. This is an engineering summary and is not legal advice. Either way, the three lines make a good test: every core function works by button or app, every tone has a light, and every light has a tone or a haptic.
Privacy indicator
Users want to know when the microphone is live. A reliable indicator follows the microphone itself. If firmware drives the light, a firmware bug can show "off" while audio flows. Driving the indicator from the microphone power or clock line is harder to get wrong. A hardware mute switch makes a stronger claim than a software mute. Our mic mute switch guide covers which claim each design supports.
Cloud audio raises a second question: what happens to the recordings. In a 2023 case about children's voice recordings, the FTC alleged that transcripts stayed in some databases after parents asked for deletion (FTC press release, May 31, 2023). If your device offers deletion, make it remove the audio, the transcripts and any copies, and test that it does.
What should you ask your hardware team?
Take this list into your next design review.
- Which activation modes do we ship: wake word, push-to-talk, or both? What is the fallback when the wake word misses?
- Which commands run on the device, and which need the cloud? What happens to each one with no network?
- What false accept rate per hour did we set as a target, and how many hours of audio will we test to show it?
- What command accuracy did we set at our real distance and noise level?
- Does the light and tone map cover every state, including offline, muted and low battery?
- Is there a way to use every core function without speech, and without hearing the tones?
- What drives the privacy indicator: firmware, or the microphone power or clock line itself?
- Where does cloud audio go, how long is it kept, and does a deletion request remove the transcripts too?
Questions about voice command interfaces
Is a wake word required for a voice product?
No. Push-to-talk is a complete activation method. It is easy to explain, and it lets the microphone path sleep between presses. A wake word adds hands-free use at the cost of an always-on detector and false accept testing. You can also ship both.
Do accessibility rules require a non-voice mode?
Where speech is used for input, control or operation, the Section 508 functional performance criteria ask for at least one mode of operation that does not require user speech, as of November 2026 (US Access Board ICT standards). Section 508 covers ICT that federal agencies procure or use, and the Section 255 guidelines cover telecommunications equipment makers. Ask a lawyer whether either applies to your product. Even when neither applies, a button path for every core function is a sound design rule.
Can Duobay help design a voice command interface for my device?
Duobay develops custom audio and voice hardware for US companies, with a Shenzhen engineering team covering electrical, firmware, app and test work. A Gate 0 Feasibility study can set the activation modes, the on-device and cloud split and the test plan for your product. We do not publish prices. Tell us about your device and we will explain how it works.
For the category background, see audio and voice hardware development. If you are planning a voice product and want the activation, recognition and feedback choices settled before layout, tell us about your device.
Sources
All pages accessed November 5, 2026. Vendor figures describe the vendor's own boards and test sets. Re-read the pages before you rely on any figure.
- Espressif, ESP-SR speech command recognition (MultiNet): https://docs.espressif.com/projects/esp-sr/en/latest/esp32s3/speech_command_recognition/README.html (accessed 2026-11-05)
- Espressif, ESP-SR wake word engine (WakeNet): https://docs.espressif.com/projects/esp-sr/en/latest/esp32s3/wake_word_engine/README.html (accessed 2026-11-05)
- Espressif, ESP-SR benchmark: https://docs.espressif.com/projects/esp-sr/en/latest/esp32s3/benchmark/README.html (accessed 2026-11-05)
- Espressif, ESP-SR audio front end: https://docs.espressif.com/projects/esp-sr/en/latest/esp32s3/audio_front_end/README.html (accessed 2026-11-05)
- US Access Board, ICT standards and guidelines (Section 508 and 255): https://www.access-board.gov/ict/ (accessed 2026-11-05)
- Federal Trade Commission, press release of May 31, 2023: https://www.ftc.gov/news-events/news/press-releases/2023/05/ftc-doj-charge-amazon-violating-childrens-privacy-law-keeping-kids-alexa-voice-recordings-forever (accessed 2026-11-05)
Planning a voice or audio device? Tell us what it needs to do. A Duobay engineer replies within 1 business day. Send a project brief →