Another Webnevisan task on the same laptop-testing app as the port-detection work — this time the requirement was to confirm a laptop's microphone and both speakers actually worked, automatically, with no person plugging in headphones or talking into the mic to check.
The challenge: prove, unattended, that the microphone captures real audio and that each of the two speakers — left and right, individually — actually produces sound. No person is present to say "yes, I heard that" or "yes, it heard me."
One test that proves two things at once
The insight that shaped everything else: don't test the microphone and the speakers as two separate probes. Have the laptop's own speaker say something specific, and have the laptop's own microphone try to hear it. If the mic transcribes back something close to what was actually said, that single round trip proves both halves at once — the speaker produced audible sound, and the microphone captured usable audio. Neither result means anything without the other, so one test verifies both instead of two weaker ones verifying nothing.
Building a phrase nothing else could have said
The phrase itself is derived from the machine's own serial number, so it's tied to that exact physical device rather than being a fixed string every unit repeats. The app takes the serial, strips anything that isn't a letter or digit, keeps the last 3 characters, uppercases them, and repeats that 3-character fragment three times — a 9-character passphrase built from a 3-character core, giving the recognizer more signal to latch onto than a single short burst would.
Making letters sound like letters, not homophones
Handing a bare letter to a speech engine is asking for trouble — say "C" out loud and a listener (human or machine) hears "see," not the letter. So each character in the passphrase is translated before it's ever spoken: digits are left as digits, since a TTS engine pronounces those cleanly, but every letter is swapped for a whole word that starts with it, pulled from a fixed 26-word list — C becomes cat, K becomes key, and so on. The client app and the recognizer both work from the same word list, so a letter that goes out as a word comes back meaning the same letter on the other end.
Speaking through one speaker at a time
Turning the passphrase into sound is platform-specific: on Windows, the say package drives the built-in SAPI voice; on Linux, espeak-ng is called directly, deliberately slowed down with extra gaps between words for clarity. Either way the result is a WAV file, decoded through the Web Audio API and routed through a StereoPannerNode panned hard left (-1) or hard right (+1) — so it plays out of essentially one physical speaker at a time. The whole sequence runs twice, once per channel, each with its own independent microphone recording, so a failing right speaker doesn't get hidden behind a passing left one.
An offline, constrained speech recognizer
The recorded clip for each channel is uploaded to a small Flask API, converted to 16kHz mono 16-bit PCM with pydub/ffmpeg, and fed to Vosk — an offline speech recognizer built on Kaldi's C++ recognition engine, exposed through a Python wrapper. Offline matters here: this runs unattended against real laptop hardware and ambient noise, with no round trip to a cloud speech API to depend on. Vosk's grammar is also constrained to only the vocabulary that could ever legitimately appear — the 26 letter-words plus the spoken number words — instead of decoding against an open vocabulary, which meaningfully improves accuracy for a phrase this short and this fixed in shape.
Comparing what was said to what was heard
Both the expected phrase and Vosk's transcript are run through the same normalizer before they're compared — folding spoken number words back to digits, folding common mishearings ("TOO"/"TO" back to 2, "FOR"/"FUR" back to 4, "ATE" back to 8), and folding each letter-word's transcribed form back to its single letter, so "key" coming back out of the recognizer becomes "K" again — directly comparable to the expected serial fragment. The two normalized strings are then scored with a Levenshtein-based similarity ratio (fuzzywuzzy, backed by the compiled python-Levenshtein extension for speed), with the match threshold set deliberately generous — real hardware, ambient noise, and a synthesized voice make an exact transcript unrealistic, so the bar is "clearly this phrase," not "character-perfect."
Where it landed
The laptop-testing app gets a result per channel — left speaker pass or fail, right speaker pass or fail, microphone confirmed working — instead of one vague "audio: OK" checkbox, entirely without a person listening or speaking. It shipped alongside the port-detection work as part of the same broader push to test hardware the OS itself couldn't be trusted to report on truthfully.
What I'd take from this
- When two things can only be verified together, design one test to prove both — a mic result only means something if you also know a real sound was actually produced to hear.
- A constrained grammar beats a general-purpose speech model for a phrase whose shape you already know in full — don't pay for open vocabulary a fixed-format passphrase will never need.
- When a machine has to say something meant to be understood exactly, don't trust the literal spelling — design the phrase around what a listener will actually hear, not what's technically written.