A debugging case study · real audio evidence
The same app, the same person, the same one-word answers — through two microphones. One session worked almost perfectly. One produced garbage. The recordings explain everything.
Waveform: almost entirely silence, with one very short 0.35 second spike of audio.
Waveform: a full, wide word-shaped envelope with a clear beginning and end.
All waveforms on this page are drawn at the same absolute scale. Press play — hear exactly what the app heard.
A flashcard web app drills mental math. You see a card, you say the answer (“seven”, “twelve”), and an on-device speech model — Moonshine — checks you. A silence gate decides when an answer starts and stops; the browser hands the app whichever microphone is the system default.
On a Mac with AirPods connected, recognition fell apart: 44 seconds, four rounds, zero usable answers. Same app, same person, same drill with a USB desk mic (an OBSBOT Tiny2): nearly flawless.
Bad model? Bad app? Bad luck? The app exports its real recordings in a debug bundle, so every capture could be re-transcribed by an independent, much larger ASR model — NVIDIA Parakeet — acting as the referee. The referee’s verdict: the recognizer wasn’t the problem. The audio itself was.
Waveform: bursts of audio slammed flat against the top and bottom of the scale; clipped regions highlighted in red.
Waveform: a single brief spike of audio, roughly a third of a second, surrounded by silence.
The other rounds went the same way. “Eight”, said twice, came through as 0.24–0.26 s blips — Moonshine guessed “A” and “E”; Parakeet found the clips effectively empty. Run the entire 44-second session through Parakeet and the sum of everything that survived the Bluetooth trip is four faint words:
“Of of eight six”
An obvious suspect: maybe the app just listened at the wrong moments. The debug log rules that out. Here are the seven listen windows against the seven speech bursts the session recording actually contains:
Every speech burst landed inside an open window — the silence gate opened on time. The problem is the bursts themselves: 0.2–0.7 s slivers where half-second words should be. The mic was listening; the audio it delivered was fragments.
Same person, same app, same silence gate — the only change is the microphone. “Five”, “four”, “ten”, “three”, “one”, “seven” all recognized cleanly. When he talked over the drill in full sentences, those transcribed too. And the two “errors”? The referee proved they weren’t the app’s.
Waveform: two complete word envelopes, a short one for uh and a longer one for five, with natural pauses.
Waveform: one complete word envelope with a rising tail.
When AirPods play audio, they are a high-quality speaker. The moment an app opens their microphone, everything changes: the link drops into the Bluetooth hands-free profile, and the signal runs through the AirPods’ own DSP noise suppression — and then through the browser’s noise suppression and auto gain on top. Two noise reducers in series, both tuned for continuous conversation.
A flashcard drill is that stack’s worst case: short, isolated words surrounded by silence. To a suppressor tuned for speech-in-conversation, a lone “six” popping out of dead air looks like a noise transient. By the time the gate ramps open, the word’s onset is gone — “twelve” becomes “of”, “six” becomes something ruder. And the very first capture after the Bluetooth mic path wakes arrives digitally clipped while the gain stages scramble to converge.
The fix
Use a wired or USB microphone for speech recognition. Keep the AirPods for output only — they are a lovely speaker and a hostile mic.