Audio Latency Test: Measure the Bluetooth Delay Most Online Tests Miss

Pair your Bluetooth earbuds, open a typical online audio latency test, and the number on screen is usually the browser's guess at its own output delay. No microphone heard the sound reach your ear. Nobody measured anything.

The click test on this page actually listens. It plays a click, records it back through your device's mic and draws the waveform, so you see the gap instead of being told about it. Hold a second phone next to your earcup and you go one step further: you capture the delay you have been hearing on calls.

Our take: the latency figure on the box is written for gamers, and video apps mostly hide it anyway (more on that below). The delay you actually pay for is on live calls, where nothing can compensate, and ITU-T G.114 warns that interactive voice suffers at delays far below its 400 ms planning ceiling. So test your own headset on your own device, not a codec spec sheet.

How do I test my Bluetooth headphones' latency at home without special gear?

The delay you hear is a chain, not one number. Audio leaves the app's buffer, passes through the operating system's mixer, gets packed by the codec encoder, crosses the radio link, waits in the headphone's jitter buffer, and is finally decoded and turned back into sound by the DAC. A test only counts the links it can see.

Three methods work with what you already own. The in-browser click test takes about 30 seconds on the device you actually use, but it counts the microphone's input delay along with the output, so it needs a baseline run. Clap-and-record uses a second phone as an independent recorder, and subtracting a wired run isolates what Bluetooth adds. Slow-motion video means filming a screen flash next to the earcup and counting frames. At 240 frames per second each frame is about 4.2 ms, so it is coarse, but it shows exactly what your eyes and ears get together.

The site's view: run the browser test first, then confirm with clap-and-record before you blame or return a headset.

The most common mistake is testing once. Bluetooth delay drifts as the headphone's buffer adapts to radio conditions, so take five readings and use the median.

Can a website really measure my headphone latency, and what does the number include?

Partly, and only if it records. The Web Audio API hands a page two numbers. AudioContext.baseLatency is the browser's own processing buffer. outputLatency is the browser's estimate of the time from its audio graph to the output device, and it is only as good as what the operating system's driver reports. On many browser and OS combinations that estimate leaves out most of the Bluetooth transport and the headphone's own buffering, or returns a fixed figure. Some browsers don't expose it at all.

The test here measures instead of asking:

1. Allow microphone access and choose the device's built-in mic.
2. Hold the earcup flat against that mic.
3. Press play. The page sends one click and records what comes back.
4. It finds the first sharp rise on the waveform and times it.
5. Run it again on the device speaker or wired headphones for a baseline.
6. Read the measured round trip next to baseLatency and outputLatency.

The round trip catches everything from the browser to the earcup, plus the microphone input path. On its own it can't split output delay from input delay. Subtract the speaker baseline and the shared input path drops out, leaving roughly the extra delay of the Bluetooth link.

On the waveform, the first sharp spike is the click. The low fuzz before it is room noise. With the earcup pressed to the mic, the room adds almost nothing.

Even a careful reading can come out low, though. The reason sits inside the headphones.

Why does an online latency test show a lower number than the delay I actually notice?

Because most simple tests print only outputLatency. Your headphones buffer audio on their side, and the phone or laptop often has no idea how big that buffer is.

That buffer also grows when the radio gets crowded. Adaptive codecs and smart buffers stretch in a busy office, on a packed train, or with the phone in a back pocket and your body between it and the earbuds. A quiet-room reading understates the delay you get on your commute.

Round-trip tests err the other way, because the mic input adds time. That is why the baseline run matters.

Then there is perception. You notice delay most against something you see or touch: a key press, a drum hit, someone's lips. A small reported figure can still feel wrong in a game. Treat any number that was not recorded from the earcup as a lower bound.

How does the clap-and-record method work, and how accurate is it?

You need two phones and about five minutes.

Setup. Phone A is paired with the Bluetooth headphones and runs live mic monitoring (a hearing or karaoke-style feature that plays its own mic into the headphones). Make sure it uses phone A's built-in mic, not the headset's. Phone B runs any voice recorder that shows a waveform. Place phone B's mic between phone A's mic and the earcup, all within a few centimeters.

Steps.

1. Clap once, sharply.
2. Phone B records the real clap, then the copy coming out of the earcup.
3. Zoom into the waveform and note the time of each peak in milliseconds.
4. Repeat with wired headphones (or phone A's speaker held at the same spot) and note that gap too.
5. Subtract the wired gap from the Bluetooth gap.

The wired run captures phone A's own input and processing delay. Take it away and what's left is the extra delay Bluetooth adds over a cable.

Accuracy. Reading peaks on a zoomed waveform is good to a few milliseconds. Sound covers about 3.4 cm in 0.1 ms, so placement barely matters at this distance. The real error is drift between runs, which is why five claps beat one.

Say the clap peak sits at 1,000 ms and the earcup peak at 1,262 ms. That gap is 262 ms. Your wired baseline was 42 ms, so Bluetooth adds 220 ms.

How to read your result:

As of November 2026, ITU-R BT.1359-1 is commonly cited as putting the detectability threshold for sound arriving late relative to video at roughly 125 ms. As of November 2026, delays of roughly 125 to 185 ms are commonly cited as noticeable but still within the broadcast acceptability limit set by ITU-R BT.1359-1. As of November 2026, sound delayed by more than roughly 185 ms is commonly cited as beyond the ITU-R BT.1359-1 acceptability limit. On calls, it piles on top of the network delay.

The 220 ms example lands in the last band. Whether that's the codec's fault or the phone's is the next question.

Does your codec decide the delay: SBC, AAC, aptX, LDAC or LC3?

The codec sets the floor. The headphone's buffer and the phone's Bluetooth stack set the real number. The same AAC earbuds can measure differently on an iPhone and on an Android phone.

The trap is the label. aptX Low Latency works only when both ends support it, and most phones never shipped it. "aptX" on the box does not mean you get the low-latency mode.

LDAC at its highest bitrate trades delay for quality. It's a music codec, not a gaming one. Find the row your setup uses below, then let the calculator give you the number your headphones actually produce.

How much audio latency is acceptable, and is 45 ms or 100 ms noticeable?

Viewers forgive late sound more than early sound. That is the core finding behind ITU-R BT.1359-1 (November 1998), the broadcast reference for sound and picture timing, which replaced BT.1359-0 from February 1998 and is still in force.

Its numbers:

• As of November 2026, ITU-R BT.1359 is generally cited as putting detectability of sound leading the picture at about 45 ms and unacceptability at about 90 ms.
• As of November 2026, ITU-R BT.1359 is generally cited as putting detectability of sound lagging the picture at about 125 ms and unacceptability at about 185 ms.

Bluetooth delay always makes sound late, so the lag figures are the ones that apply.

Is 45 ms good? Yes. It's well under the lag threshold for video and fine for most games. Rhythm games and playing an instrument live are the exceptions.

Is 100 ms noticeable? Rarely in video. Often in fast games, where a shot or footstep lands after the flash. Always when you play along to music.

Music on its own is the easy case. With no picture and no input to compare against, no delay is audible. Calls are where it stops being easy.

When does headset delay actually matter on a phone or video call?

ITU-T G.114, current edition May 2003, sets the reference for one-way delay in voice. Amendment 1 (September 2003) added guidance on one-way delay for VoIP, and Amendment 2 (November 2009) added an appendix on delay variation over unshared access lines.

It deals with end-to-end one-way delay, mouth to ear, and gives an upper bound for network delay. For general network planning, G.114 recommends staying under 400 ms one way. It also says highly interactive tasks, including many voice calls and video conferencing, can suffer at much lower delays. For anything under 500 ms it estimates the effect on conversation with a curve derived from the E-model in ITU-T G.107.

Your headset's delay is not separate from that budget. It stacks on top of the network and the call app's own jitter buffer, on your end and on theirs.

Say a video call already runs at 200 ms one way. Add a headset that delays playback by 150 ms and the other person's voice reaches you at about 350 ms, close to the planning ceiling. That is the point where people start talking over each other.

Why does my headset sound worse on calls than with music?

Music travels over A2DP, a one-way, high-quality link. The moment the mic opens, the headset switches to HFP (or the older HSP), a two-way link carried over a SCO connection.

HFP's codecs are modest:

• CVSD: narrowband, 8 kHz sampling, old phone-line quality.
• mSBC: wideband, 16 kHz sampling.
• LC3-SWB: super-wideband in the newest HFP versions.

LE Audio drops the split entirely and runs both directions on LC3.

The uncomfortable truth: the call link often has smaller buffers and less delay than music playback. What you lose is fidelity, because the same radio time now has to carry your voice up as well.

The usual fix is to talk into the laptop's built-in mic so the headphones stay on A2DP. You get music-grade sound, and you also get music-grade delay back in your conversation. A headset and OS with LE Audio or wideband speech avoid that trade.

Does your phone or laptop add delay, and how can you cut Bluetooth latency?

Every operating system adds its own layer. On Android the path varies by maker and by the audio API an app uses; AAudio and the low-latency paths are faster. Windows adds its audio engine's shared buffer. macOS and iOS are consistent but use AAC for most headphones.

What works, roughly in order of payoff:

1. Turn on the headphones' game or low-latency mode.
2. Pick a faster codec in Android's developer options when both ends support it.
3. Switch off multipoint while gaming.
4. Keep the phone in line of sight of the earbuds.
5. Close other apps that play audio.

What doesn't: "boost" apps, fancier cables on a USB dongle, or turning the volume up.

For rhythm games, recording or playing an instrument, wired headphones or a 2.4 GHz dongle beat any Bluetooth codec. The site's view: if the delay matters enough to measure, it matters enough to plug in.