⏱️

Mic Latency Tester

This free mic latency tester measures your real round-trip audio latency in milliseconds. The tool plays a short click through your speakers, your microphone hears it, and the delay between sending and detecting is timed — repeated over several trials for a stable average with min / max and a quality rating. It is the most direct way to run an audio latency test in your browser without any extra software, giving you a concrete microphone latency figure for your current hardware and OS setup.

🔊 Use speakers, not headphones — the mic must be able to hear the click acoustically. Put the mic near the speaker and keep the room quiet for the cleanest result.

🔒 Everything runs locally in your browser. No audio is recorded, uploaded, or stored.

Microphone

Device names appear after you grant permission once.

Test settings

Loud enough that the mic clearly hears each click, but not so loud it distorts. Increase this if you get "no echo detected".
Idle — press Start measurement.

Reported by browser

Base latency
Output latency
Sample rate
Buffer (process)

Round-trip latency

ms
average of valid trials
Min
Max
Valid
Rating (round-trip): under 30 ms = excellent, 30–70 ms = usable, over 70 ms = high (noticeable for live monitoring). This is the full loop: output + acoustic travel + input + processing.
Per-trial latency (ms) — each bar is one click→echo measurement
Live microphone level — watch the click echoes arrive

Share or embed this tool

Free to use on your own website — WordPress, Wix, or any platform. Paste one line and it works instantly, resizing to fit.


How the Mic Latency Test Works

"Round-trip latency" is the total time from when your computer sends a sound to when it hears that sound back through the microphone. This tool measures it directly: it schedules a short, sharp click to play through your speakers at a precisely known moment, then watches the raw microphone signal sample-by-sample for the click to arrive. The gap between the two is one latency measurement. It repeats this several times and reports the average, because any single measurement has some jitter.

That round-trip number is the sum of several parts: the output latency (how long the browser + OS + audio hardware buffer before sound actually leaves the speaker), the acoustic travel time (sound covers about 34 cm per millisecond through air), the input latency (buffering on the way back in), and a little processing time. Placing the mic close to the speaker minimizes the acoustic part so you mostly measure the electronic round trip.

Why buffer size matters

Most audio latency comes from buffering. Larger audio buffers are safer against dropouts but add delay; smaller buffers are snappier but risk glitches. The browser exposes two hints — base latency and output latency — shown in the readouts above. They reflect the buffering the browser has chosen and are a useful lower bound; the measured round-trip will always be somewhat larger because it also includes the input path and the air.

Getting an accurate result

  • Use speakers and place the microphone close to them. Headphones won't work — the mic can't hear them.
  • Quiet room. The tool calibrates to your background noise first; loud rooms can mask the click or cause misfires.
  • Enough volume. If you get "no echo detected", raise the Click volume so the mic clearly registers each click.
  • Expect ±a few ms of jitter. Browser audio timing isn't perfectly deterministic, which is exactly why this tool averages many trials.

What the number tells you — and what you can do about it

A high round-trip figure (above 70 ms) usually points to large audio buffer sizes in your operating system or browser. The buffer size — sometimes exposed as "audio buffer" or "samples" in a DAW or audio driver settings — is the primary knob for trading latency against stability. Cutting the buffer from 512 to 128 samples at 48 kHz cuts about 8 ms of buffering per direction. The trade-off is that smaller buffers demand more from your CPU; if the CPU can't keep up, you'll hear crackles and dropouts instead of clean audio. A dedicated audio interface with its own driver stack — particularly one that supports ASIO (on Windows) or Core Audio (on macOS) — bypasses the standard OS audio path entirely and can achieve round-trip latencies below 10 ms that a browser-based test cannot reach. This tool measures your current system as the browser sees it; if your results are consistently above 50 ms and you need low-latency monitoring for singing or playing an instrument, an audio interface with direct hardware monitoring is the reliable solution. Note that recording latency — the one-way input delay that a DAW compensates for automatically — comes from the same buffers, but the round-trip figure you see here is what matters for live monitoring comfort. For a deeper look at exactly where your system's delays accumulate, see the Audio Latency Measurement Tool. If you want to verify that a physical loopback cable is working cleanly after reducing your buffer, the Audio Loopback Tester provides a controlled signal path for that check.

Frequently Asked Questions

What counts as good latency?
For this round-trip measurement, under ~30 ms is excellent, 30–70 ms is usable for most purposes, and over ~70 ms becomes noticeable — especially for live monitoring while recording or singing, where you hear yourself delayed. Note that round-trip is roughly double the one-way latency a DAW might report, since it includes both the output and input paths.
Why do I need to use speakers instead of headphones?
The test works acoustically: it plays a click and the microphone must physically hear it to time the round trip. With headphones the sound goes into your ears, not the mic, so nothing comes back to measure. Use your speakers and put the mic near them.
Why does it disable echo cancellation?
Echo cancellation is specifically designed to remove exactly the kind of speaker-to-mic feedback this test relies on. The tool requests the raw signal with echo cancellation, noise suppression, and auto-gain all off so the click comes through cleanly. Some systems may still apply processing the page can't override, which can reduce accuracy.
It says "no echo detected" — what's wrong?
Usually one of: you're on headphones (switch to speakers), the click volume is too low (raise it), the mic is too far from the speaker (move it closer), or the room is too noisy (the calibrated threshold is high). Echo cancellation that can't be disabled can also remove the click entirely.
How accurate is this?
It's a good ballpark — typically within a handful of milliseconds. Browser audio scheduling isn't perfectly sample-deterministic across the output/input boundary, so each trial has some jitter; averaging many trials and reporting min/max gives you a reliable range rather than a single fragile number. For sample-exact figures, a dedicated audio interface and DAW loopback test is the gold standard.
Does the acoustic distance affect the number?
Yes, but only a little. Sound travels about 34 cm per millisecond, so a mic 34 cm from the speaker adds ~1 ms each way. Keep the mic close to the speaker to minimize this and measure mostly the electronic round trip.
Is any audio recorded or sent anywhere?
No. The microphone signal is analyzed locally in your browser purely to detect the click's arrival time, and is never recorded, saved, or transmitted. The microphone is released as soon as the measurement finishes or you press Stop.
How is this different from the browser's reported latency?
The "base latency" and "output latency" values are the browser's own estimates of its output buffering — a lower bound for one direction only. The measured round-trip number is an actual end-to-end measurement that also includes the input path, the air gap, and real-world timing, so it's larger and more representative of what you'd actually experience.
How do I reduce my mic latency after seeing a high number?
The main lever is buffer size: reduce it in your DAW or audio driver settings (ASIO on Windows, Core Audio on macOS). Halving the buffer roughly halves the buffering latency per direction. A dedicated audio interface with ASIO/Core Audio drivers bypasses the OS audio stack entirely and can hit round-trip latencies below 10 ms. For live monitoring — hearing yourself while singing or playing — look for a hardware direct-monitoring switch on your interface, which adds zero latency because it bypasses the computer entirely.
Does the type of microphone — USB vs XLR — affect latency?
Yes. A USB microphone routes audio through the browser's OS audio stack, which typically adds 20–80 ms of buffering. An XLR microphone connected to an audio interface can use low-latency ASIO or Core Audio drivers with much smaller buffers, and most interfaces include direct hardware monitoring that bypasses the computer entirely for zero-latency playback. This browser test measures the USB/OS path; ASIO latency requires a dedicated DAW test to measure accurately.
What is monitoring latency, and is it the same as recording latency?
Monitoring latency is what you hear in your headphones when you sing or play through the computer in real time — it's the full round-trip delay this tool measures. Recording latency is a one-way input delay; your DAW compensates for it automatically so recorded tracks line up with the project timeline. Both come from the same buffering, but monitoring latency is what singers and instrumentalists feel most acutely. If monitoring latency feels uncomfortable (above ~20–30 ms), use your interface's hardware direct-monitoring path instead.
My latency result varies a lot between runs — is something wrong?
Some jitter is normal: browser audio scheduling is not perfectly sample-deterministic, and acoustic reflections in the room can create secondary arrivals that the tool occasionally mistakes for the click. Run 20 trials rather than 5 to get a more stable average. If the min–max spread is more than ~20 ms, try a quieter room, move the mic closer to the speaker, or reduce CPU load (close other browser tabs and background apps) so the browser audio thread has more consistent timing.