Diagnose your microphone before the call

The idea

A small tray app that runs a ten-second mic check and gives you a verdict, not a waveform. You read a sentence off the screen; it measures your level, clipping, noise floor, and whether the operating system quietly handed your voice to a band-limited Bluetooth headset. The output is a card with four pass/fail rows and one concrete instruction: "your input is 14 dB too quiet — raise input gain on the Yeti to 60%" or "macOS is using the AirPods mic at 16 kHz; switch input to the built-in mic and keep the AirPods for output."

Why build this

Every remote worker has sat through "you sound like you're in a tunnel" and had no idea what to change. The built-in meters in Zoom, Meet, and Slack show a bouncing green bar, which confirms sound is arriving and tells you nothing about why it's bad. The common failures are a short list — gain too low so the platform's AGC amplifies room noise, gain too high so consonants clip, a 50/60 Hz hum from a laptop charger, a laptop fan sitting under an omnidirectional mic, and the Bluetooth headset that silently halves your bandwidth — and all of them are measurable from a few seconds of audio.

Nobody ships this because it's an unglamorous diagnostic rather than a product category. That's exactly why a solo developer can own it: the DSP is textbook, the libraries are mature, and the value is in the translation layer from measurement to a sentence a non-engineer can act on.

Stack sketch

• Tauri shell with a Svelte UI — a tray app that stays out of the way and ships as a signed .app and .msi
• cpal for device enumeration and capture at 48 kHz mono; keep capture in Rust rather than the webview so you can see every host device the OS exposes
• ebur128 for loudness (target roughly -18 LUFS short-term for speech), plus straight peak and RMS for clipping and headroom
• rustfft for the spectrum: hum detection as energy spikes at 50/60 Hz and their harmonics, band-limiting as the ratio of energy above 7 kHz to total, noise floor from the quietest 10% of frames
• nnnoiseless (RNNoise port) to render a cleaned-up A/B preview so the user hears what a fix buys them
• rusqlite for a local history of checks, so "it was fine last week" becomes a verifiable claim
• No backend, no account, no upload — the recording never leaves the machine, which is also the privacy pitch

Scope for v1

• One button, one ten-second read-aloud prompt, one verdict card
• Four checks: level, clipping, noise floor, bandwidth
• Device picker with the OS's current input highlighted and a recommended alternative
• A "copy summary" button producing plain text to paste to whoever said you sounded bad
• macOS first; Windows second
• Deliberately out: echo and room reverb measurement, calendar integration, video or lighting checks, any team dashboard, and anything that changes OS settings on the user's behalf

Where it could go

The obvious next step is making the check automatic: read the local calendar and run silently five minutes before any meeting with a conferencing link, surfacing a notification only when something is wrong. That turns a tool you remember to open into one that catches the bad headset before the call rather than during it.

After that, two directions open up. A team edition where IT sees an aggregate — eleven people on Bluetooth mics, three with chronic hum — is a genuine B2B wedge, because support tickets about call quality are currently unfalsifiable. The other is a virtual input device that applies the fix system-wide: a high-pass filter, gain staging to a sane target, and RNNoise, exposed as a selectable microphone in every app. That's a much larger engineering commitment (a kernel-adjacent audio driver on both platforms) but it's what people will ask for the moment the diagnosis lands.

Watch out for

Bandwidth detection is the easy false positive: quiet speech, a soft-spoken user, or a codec that upsamples will all look band-limited, so gate the check on having enough signal and compare against the device's claimed capabilities before accusing it. Microphone permission on macOS also means the app can't check anything until the user grants access, so the first run has to explain itself well or it reads as an app that does nothing.