A/V Sync (Lip-Sync) Test
Measure how far your sound is ahead of or behind the picture, in milliseconds.
Volume warning
This test plays tones that can be loud and may damage hearing or speakers. Turn your volume down before starting, then raise it gradually.
How this test works
Most pages claiming to test A/V sync play a clip and ask you to judge it, which measures nothing. This measures the offset. You run two rounds: in the first you press the moment a panel flashes, in the second you press the moment you hear a beep. Your reaction time is large and personal, but it is the same in both rounds, so subtracting one median from the other cancels it and leaves the difference between the two paths — which is exactly what you perceive as sound being out of step with the picture. Six cues per round, medians rather than averages, randomised gaps so the rhythm cannot be learned, and presses faster than 90 milliseconds discarded as anticipation. The result is cross-checked against the output latency your browser reports for the current audio device, and the page shows how consistent your taps were so you know whether to trust the figure.
What the results mean
- Audio offset
- The headline number. Positive means sound arrives after the picture, which is the common direction. Negative means sound arrives first, which is rarer and far more noticeable — the ear tolerates late sound much better than early sound.
- Reaction to the flash / to the beep
- Your median response in each round. These values are mostly your own reaction time, typically 200 to 300 milliseconds, and are not interesting on their own. Only the difference between them carries the measurement.
- Tap consistency
- How much your presses varied, as a median absolute deviation. Above about ±90 milliseconds the spread is wider than the offset being measured, and the result is reported as unusable rather than dressed up as a reading.
- Output latency the browser reports
- The audio stack's own estimate of the delay to your current output device — an independent cross-check on the measured offset. Firefox and Safari report zero here, which means unavailable rather than instant.
Common problems and fixes
- The offset is 150 to 250 milliseconds and you are on wireless headphones
- That is the Bluetooth codec, not a fault. SBC and AAC both add delay in this range. The fix is a low-latency codec supported at both ends, or a wired connection for anything with a picture. Music is unaffected — a constant delay is inaudible when nothing has to line up with it.
- Sound is fine on the computer but out of step on the television
- Picture processing is the usual cause. Modes named Cinema, Smooth Motion or Motion Interpolation hold several frames back to do their work while the sound goes straight through. Turn them off, or use the audio delay setting in the television's sound menu to put the offset back.
- It is only wrong in one app or on one site
- Then the offset belongs to that app's playback or to the stream itself, and this test will come back in sync. Streaming platforms drift on individual titles, and the same file often plays correctly in a different player.
- The result says your taps were too scattered
- Run it somewhere quiet with the volume high enough that the beep is unmistakable, and react to each cue rather than predicting the rhythm. The gaps are randomised specifically to prevent anticipation, and anticipated presses are discarded.
Frequently asked questions
Why not just play a video with a clapperboard?
Because you cannot read a number off a clapperboard. Watching a synchronised clip tells you whether something feels wrong, not by how much, and it cannot separate your display's delay from your audio device's. Two rounds of reaction times give a figure in milliseconds, which is what you need to set an audio delay or to decide whether the headphones are the problem.
How can it measure anything when my reaction time is larger than the offset?
Because reaction time appears in both rounds and cancels in the subtraction. If you react in 250 milliseconds to a flash and 310 to a beep, the 60 millisecond difference is the audio path being slower — your 250 is in both numbers and drops out. It is the same reason a differential measurement works where an absolute one would not.
What offset counts as acceptable?
ITU-R BT.1359-1 puts detectability at about 125 milliseconds for sound arriving late and 45 milliseconds for sound arriving early, with the objectionable limits at 185 and 90. This page uses those bands, which is why the tolerance is asymmetric — early sound is much more obvious than late sound.
Does the result depend on which browser I use?
Somewhat, because the browser's own audio and video paths are part of what you are measuring. If you want to know whether a device or a codec is responsible, run the test twice on the same browser with only the output changed. The comparison stays reliable even where the absolute figure carries a browser's own contribution.