Mic monitor

The path is long. Your voice is captured by the mic, buffered by the OS, handed to the browser, pushed through the Web Audio graph, buffered again on the way out, and finally played by your headphones. Every one of those hops adds a few milliseconds, and a browser page has almost no control over any of them. The result is a delay of tens of milliseconds at best, and often well beyond that, between speaking and hearing it.

Why the delay matters. Roughly 10 ms and under reads as immediate to most people. Once monitoring lags noticeably behind your own voice, it stops feeling like monitoring and starts feeling like an echo, which is distracting enough that many people would rather not hear themselves at all. If your monitor sounds like a slapback, the monitor is the problem, not your voice.

Bluetooth makes it worse. Wireless headphones add roughly 100 to 300 ms on top of everything above. For any kind of self-monitoring, wired beats wireless, every time.

What a real path looks like. Low-latency monitoring means skipping the browser entirely: either your audio interface's direct monitor knob (analog, effectively instant, but with no effects) or a native mixer running on a fast driver. patchd monitors at about 10.7 ms through the bus at a 512 buffer, and smaller ASIO buffers take it lower, with the full effects rack in the path. The complete setup, including where the buffer size actually gets set, is in how to monitor your mic with low latency.

Input level is the peak of your raw mic signal, measured before the level slider, so it keeps moving while you are muted. If it pins to the right and turns red you are near clipping: back off your mic gain in the OS or on your interface, not just the monitor slider.

Monitor level is how loud the mic plays back to you, capped at unity (0 dB). The cap means this tool can attenuate but never amplify, so it cannot push a feedback loop harder than your mic and system gain already allow. That is also why the headphone confirmation is not optional: with echo cancellation off, mic into speakers howls within about a second.

Reported output-side latency is the sum of two numbers the Web Audio API exposes: baseLatency (the browser's own processing buffer) and outputLatency (the delay the OS reports for your output device). Not every browser reports outputLatency, and no browser reports the input side, the time your voice spends being captured and buffered before the page ever sees it. So treat the figure as a floor: your true mouth to ear delay is always larger, typically by tens of milliseconds. To measure a real round trip instead of trusting reported numbers, run the audio latency test, which claps a signal out of your speaker and times its return through the mic.

One caveat on processing. Echo cancellation, noise suppression, and auto gain control are all disabled here, so what you hear is your actual mic signal, the same raw feed a mixer would receive. If it sounds noisier or boomier than you expected, that is real information about your mic and room, and it is fixable with a gate, suppression, and EQ in the monitoring path.