Audio latency test
Your browser will happily tell you what it thinks its audio delay is, and the number leaves out the operating system, the speaker, the air and the microphone. This measures the whole path instead: it sends a short sweep out of your speakers, listens for it on your microphone, and times the gap.
Turn the volume up and let the sound out of the speakers you actually use. The microphone has to be able to hear them.
- Round trip—
- Verdict—
- Steadiness—
- Bursts heard—
- What the browser claims—
What did the round trip come out at?
What is actually being measured
The test schedules a ten-millisecond sweep from 1 kHz to 6 kHz at a known point on the browser’s audio clock, records the microphone on the audio thread so the recording carries timestamps from that same clock, and then looks for the sweep in what came back. The gap between the two is the round trip.
That figure contains, in order: the browser’s output buffer, the operating system mixer, whatever the audio device does before the sound leaves it, the travel through the air, the microphone, the capture buffer, and the browser’s input side. It is one number because it arrives as one experience — the delay between doing something and hearing it.
Five sweeps go out, half a second apart, and the result is their median. The steadiness figure is how far the individual readings sat from each other. A tight spread means a stable audio path; a wide one usually means something is resampling or the machine is busy enough to miss buffers, and that instability is audible as the occasional dropout rather than as delay.
Reading the number
Under 80 ms. Normal for a browser on wired equipment. Nothing to fix.
80 to 160 ms. High enough to be noticeable if you monitor your own voice or play along to anything. Wireless is the usual cause. On a wired setup, look at the sample-rate and exclusive-mode notes below.
Over 160 ms. Almost certainly Bluetooth. This is the range where you hear yourself as a distinct echo, where a video looks out of sync with its sound, and where playing an instrument along to a backing track stops being possible.
Bluetooth is usually the whole answer
Bluetooth headphones buffer aggressively, because a dropout sounds far worse than a delay for the thing they were designed to do, which is listening to music. For listening, 200 ms of delay is invisible. For anything where you are also making the sound, it is the entire problem.
There is a second effect that surprises people. The moment an application starts using a Bluetooth headset’s microphone, the link switches from the high-quality one-way profile to a two-way headset profile — the same one a phone call uses. The delay drops, and the sound quality collapses to something that is audibly telephone-grade in both directions. That is why your music sounds fine on the same headphones that make you sound terrible on a call, and it is not a fault.
Neither behaviour has a software fix. A wired headset removes both, and it is the only thing that does.
Windows 11
- Sample rate mismatch is the most common wired cause. Settings → System → Sound → your device → Format. If the microphone and the speakers are set to different rates, Windows resamples between them and adds buffering to do it. Setting both to 48000 Hz is usually the whole fix.
- Exclusive mode. In the same device properties, “Allow applications to take exclusive control” lets one application bypass the shared mixer. It lowers delay for that application and can lock every other one out of the device, which is worth knowing before you turn it on.
- Audio enhancements, on the same screen, insert processing on the path. Each effect costs a little delay. Turning them off is a reasonable thing to try and a reasonable thing to leave off.
- Bluetooth: Windows exposes a Bluetooth headset as two separate devices — one for stereo output, one for handsfree. If both appear in the sound settings, the one named “Hands-Free” is the low-delay, low-quality mode.
macOS
- Audio MIDI Setup, in Utilities, shows the real sample rate of every input and output. The same mismatch as on Windows applies, and the same fix: put both sides on 48000 Hz.
- AirPods behave exactly as described above. They are excellent headphones and a poor choice for anything where you need to hear yourself, and no setting changes that.
- Aggregate devices built in Audio MIDI Setup add their own buffering to keep two clocks together. If your input is an aggregate device you assembled, that is a plausible source of the extra delay.
- macOS does not expose a global buffer size the way Windows does. The delay you measure here is the one applications get.
If you record music or stream
Nothing in a browser is the right tool for tracking, and this measurement will confirm it rather than fix it. What it is useful for is answering two specific questions before you go looking any further: is the delay in the equipment or in the software, and does a change you just made help. Run it, change one thing, run it again. The number moves or it does not.
For monitoring while you record, the answer has not changed in twenty years: listen to the input directly through the interface’s own hardware monitoring, not through the computer. Then the round trip does not matter, because your voice never goes through it.
Common questions
Is this microphone latency or audio latency?
Both, and that is not a dodge — they cannot be separated from inside a browser. The sweep leaves your speakers and comes back through your microphone, so the single number contains the output side and the input side together, and nothing available to a web page can tell you how the total splits between them. Calling it microphone latency would credit the microphone with delay that mostly is not its fault. If you need the two apart, the way to get it is to change one thing at a time and run this again: the same microphone with different output, or the same output with a different microphone. The difference between two runs is real even though neither half is.
Why is this number so much bigger than the one my audio interface quotes?
Because they are measuring different things. An interface quotes its own driver buffer — the delay it is responsible for, often under 10 ms. This measures the entire round trip: the browser buffer, the operating system mixer, the speaker, the travel through the air, the microphone, the capture buffer, and the browser again. Every one of those is real and every one of them is in what you hear. A browser also buffers far more conservatively than a native audio application, so a healthy wired setup usually lands somewhere between 40 and 80 ms here and there is nothing wrong with it.
Can I use this to test my Bluetooth headphones?
Yes, and it is the single most useful thing it does. Select the headset as the microphone, wear it normally, and run the test — the sweep goes to its speaker and comes back through its own microphone, so the whole Bluetooth link is inside the measurement. Then run it again on the built-in speakers and microphone. The difference between the two numbers is what Bluetooth is costing you, and it is usually somewhere between 100 and 250 ms.
The test says it never heard the sound.
Either the volume is too low, or the sound is coming out of one device while a different device is being recorded. Headphones on your head with the laptop microphone selected is the common version of that: nothing reaches the microphone because the sound is sealed against your ears. Put the output and the input on the same device — both on the laptop, or both on the headset — and turn the volume up.
Why does the test send a sweep instead of a click?
Because a click has to be loud to be found in a room that has other noise in it, and a sweep does not. Correlating the recording against a sweep the test already knows collects all of its energy into one sharp peak, so a quiet sweep is located more precisely than a loud click. Radar uses the same trick for the same reason.
Why does the test turn echo cancellation off?
Because echo cancellation exists to remove sound that came out of your own speakers, and that is exactly the sound being timed. Leaving it on would ask the browser to delete the measurement.
Is the result comparable between browsers or machines?
Between runs on the same machine, yes, and that is the comparison worth making — wired against wireless, before a setting against after it. Between different browsers or different machines, treat it as a rough band rather than a figure. Buffer sizes differ, and a 12 ms gap between two machines means nothing while a 150 ms gap means Bluetooth.
People on Discord say I sound delayed. Will this find it?
It will tell you whether the delay is yours, which is the useful half. Discord adds a jitter buffer and a network trip on top of everything measured here, and that is usually where a conversational delay comes from. If this test reads under 80 ms and people still hear you late, the problem is between you and them rather than inside your machine, and changing microphone settings will not help.
Does the measurement include the distance to my speakers?
Yes, but barely. Sound covers a metre in about three milliseconds, so a normal desk adds one or two milliseconds to the total. That is inside the noise of the measurement and far below anything you could hear.