Where the Milliamps Go: What We Learned Building an Always-On Voice Recorder
Battery-side measurements of an always-on voice recorder: where the current goes while nobody is talking, and how listening mode went from about 6 to about 10 days.
On an always-on voice device, the battery doesn’t die recording. It dies waiting.
The teams who build meeting recorders, clip-on recorders, AI pendants and badges for care and service quality all ask for the same thing: capture the sentence that mattered, whenever it was said. They also hand us a battery small enough to wear all day.
Those two requests collide in a quiet way. For most of a typical day, nobody near the device is talking. A product designed to “record when someone speaks” still pays for every silent minute it spends waiting.
So we stopped asking how to make recording cheaper, and started asking where the current goes when nothing is happening. The answer took our listening mode from about 6 days to about 10 on the same 1,000 mAh cell.
How we measured: at the battery, one load at a time
We measure at the battery terminals, not at USB. USB-side readings include the charging circuit and indicator lights, which can make a device look better or worse than it is. What matters is what leaves the cell.
We switch off one path at a time. Turn one load off, wait for the current to settle, sample, record, then move to the next. Every milliamp gets assigned to a specific source instead of a guess.
The waiting step matters more than it sounds. Low-power designs drift between states for a while after a change, and a reading taken too early credits the saving to the wrong load. A slow, boring bench produces a ledger you can defend in a design review.
We run long, in real rooms. Short bench runs flatter a design. We ran the listening pipeline for hours, including in a household with several people talking over each other.
Test conditions for every number in this article: 1,000 mAh / 3.7 V lithium cell, current measured at the battery, engineering platform (not production hardware). Battery-life figures are rounded and stated as “about”.
Three findings that surprised us
1. The biggest losses came from things nobody was using.
One culprit was a wireless subsystem that stayed awake when nothing needed it. Once we found it and put it to sleep, the device could reach a true deep standby: about seven weeks on a 1,000 mAh cell.
The other was a bias supply still feeding microphones that weren’t in use. Nothing in the design asked for it. Nothing in a datasheet warns you about it.
Our firmware now powers just the microphones in use. Measured at the battery, that one change cut listening-mode power by about 40% and continuous-recording power by about a third.
Neither load shows up when you measure recording. Both show up in every hour the device spends waiting.
That is the practical lesson for anyone writing a spec. A datasheet sleep current and a battery-side listening current are different numbers, and the gap between them is where days of battery life disappear. Ask for the second one.
2. Storage writes barely matter. Neither does a second microphone.
Writing audio to local storage costs about 1% of recording power. We tried buffering audio in memory and writing in larger batches. It didn’t save power; in our tests it came out slightly worse.
Adding a second microphone barely moved the needle either, once the idle-mic supply was under control. Even with all six microphones on, continuous recording still runs about 5 days.
The intuition that “flash is expensive, so write less often” comes from older designs. On this platform the cost sits in keeping the compute side awake, not in the write itself, so that’s where tuning pays.
3. A generic voice detector turns “record on speech” into “record always”.
A general-purpose voice activity model, on its own, flagged far more of the day as speech than anyone was actually saying. On our board, much of what it reacted to was board-level noise, not people.
If the trigger fires most of the time, an “on-demand” recorder is just a recorder. We added multi-stage gating in front of the record decision, and we keep the opening words of each sentence, so a stricter trigger doesn’t cost you the start of what someone said.
The architecture this points to
Every milliamp in the findings above is spent because the main SoC is awake in order to listen.
The next step is to stop asking it to. In a two-tier design, an ultra-low-power always-on AI chip does the listening and the deciding. The main SoC, which handles recording, encoding, storage and wireless, sleeps until there is something worth waking for:
- human speech
- a wake word
- a specific speaker
- a sound event that matters to the product
Keeping the opening words still matters here: the wake-up has to happen without losing the start of the sentence that caused it.
The design also changes what “always-on” costs as a product decision. In a single-chip device, every extra listening feature is paid for by the main SoC’s awake current. In a two-tier device, listening features live on the small chip, and the expensive side of the system pays just when there is something to record.
We are evaluating this design now. When we publish its numbers, they will be whole-device measurements at the battery, not projections.
Results on our engineering platform
| Mode (1,000 mAh / 3.7 V, measured at the battery) | Battery life | Status |
|---|---|---|
| Listening mode, records when someone speaks (single-chip) | About 10 days | Measured |
| Continuous recording: single mic, low-bitrate speech codec, written to local storage | About 8 days | Measured |
| Continuous recording: all six mics on | About 5 days | Measured |
| Bluetooth connectable standby | About 2–3 weeks | Measured |
| Deep standby | About 7 weeks | Measured |
Two reliability results matter as much as the battery table:
- Capture. After fixing a race in the audio capture path, our validation runs recorded zero dropped frames in single- and dual-mic recording.
- Power loss. Recordings are written to storage at regular intervals, so a sudden power cut loses at most a dozen or so seconds of audio.
Engineering platform, not production hardware. Production battery life depends on the final design, battery, microphone configuration and usage, and is confirmed per project.
Where this approach stops helping
Listening mode saves power when the room is quiet. The more of the day people spend talking, the smaller the gain. In a day of near-constant conversation, a listening device behaves much like a recording device, and the battery numbers converge.
Noise reduction is not in these numbers. We’re still validating it and will publish once it meets the same bar as everything above.
And one note for anyone deploying always-on audio: the deploying organisation must follow local recording-consent and personal-data laws, such as all-party consent rules in some US states, the EU GDPR and China’s Personal Information Protection Law.
What’s next
We’re now evaluating an ultra-low-power always-on AI chip as the listening tier, and we’re opening that work to ODM and brand partners who want to test it against their own use case. Next on the same battery-side bench: whole-device measurement of the two-tier design, and dual-mic noise reduction.
GMIC AI focuses on low-power AI voice wearable hardware, edge audio algorithm integration and volume product delivery, connecting chips, algorithms and end-customer requirements.
If you’re building an always-on voice product and want to see these numbers on your own use case, ask us for an evaluation sample or a reference-design discussion: [email protected].
The quiet hours are where the battery goes. That’s where the engineering has to go too.