What Is an Audio Latency Test?
This tool measures two genuinely different things. First, it reads your browser's own reported audio latency values directly from the Web Audio API - real numbers your browser calculates based on your audio hardware and driver setup, where supported. Second, it runs a round-trip trial where you click a button, wait for a randomly-timed tone, and click again the instant you hear it - this captures the combined delay of your audio output hardware plus your own reaction time.
These two numbers answer different questions: the system-reported figures tell you about your audio pipeline's technical latency, while the round-trip trials give you a practical, real-world sense of total delay including the human element.
How to Use the Audio Latency Test
- Set your device or headphone volume low. Select Enable Audio / Refresh Readings so the browser can start its Web Audio context and show Base Latency, Output Latency and Sample Rate when supported. “Not reported” means the browser does not expose that figure, not that latency is zero.
- Use the optional short Test Tone to check audibility. Choose your current connection label (Wired, Bluetooth or Other) and a comfortable digital tone level. The label is for your records; it does not switch the output device.
- Click Start Trial. Wait without guessing: an 880 Hz beep plays after a randomized pause. As soon as you actually hear it, click I HEARD THE TONE. If you cannot hear it, choose Did Not Hear It instead of making up a result.
- Complete at least 5–10 trials. The dashboard displays your latest, median, average, P95 and minimum–maximum response intervals, with a chart and per-trial session history. Early guesses, cancellations, background-tab interruptions and timeouts are excluded.
- For a wired-versus-wireless comparison, switch your actual listening device, enable/refresh the audio context if necessary, update the connection label and repeat multiple trials in similar conditions. Use Export CSV to keep separate browser-reported values and human-included responses, or Reset Results to clear this tab's history.
How It Works
The system latency readouts come from AudioContext.baseLatency and
AudioContext.outputLatency, standard Web Audio API properties that report the processing
delay your browser calculates for its audio pipeline - support and accuracy vary by browser and operating
system. The round-trip trial plays a short tone through the Web Audio API at a randomized delay after you
click Start, records the precise timestamp the tone began, and calculates the difference against when you
click again after hearing it. Randomizing the delay before each tone prevents you from timing your click to
a predictable rhythm instead of your actual hearing.
Understanding Your Results
- Output Latency reads a small, stable number (roughly 5–20ms) - typical of a well-configured desktop audio setup with low-latency drivers.
- Round-trip average lands around 150–250ms - this is normal and mostly reflects human auditory reaction time, not a hardware problem; average human reaction time to sound is itself typically in this range.
- "Not reported" for Base or Output Latency - some browsers, particularly Firefox and Safari, don't currently expose these specific values; the round-trip trial still works regardless.
- Round-trip results vary widely between trials - normal; human reaction time is naturally inconsistent trial to trial, which is exactly why running several trials and averaging matters.
Browser Limitations
The baseLatency and outputLatency properties are currently best supported in
Chromium-based browsers; Firefox and Safari may not report meaningful values for one or both. The round-trip
trial inherently measures human reaction time layered on top of actual audio latency - there's no way for a
browser-based test to isolate pure hardware latency from your own perception and click speed, so this figure
should be read as a practical combined delay, not a lab-grade hardware measurement.
Common Mistakes to Avoid
- Anticipating the tone instead of reacting to it - the randomized delay is there specifically to prevent this; try to genuinely wait for the sound each time.
- Running only one trial - a single result can be skewed by a slow or fast reaction; average several trials for a fair reading.
- Testing with Bluetooth headphones and expecting low latency - wireless audio commonly adds noticeable extra delay compared to wired output, which is expected, not a fault.
Frequently Asked Questions
Why does my round-trip time seem much higher than the reported system latency?
The round-trip trial includes your own reaction time to hearing the tone, which is typically 150–250 milliseconds on its own - that's added on top of any actual hardware or software latency.
Why do Base Latency and Output Latency show "Not reported"?
These specific Web Audio API properties currently have limited support outside Chromium-based browsers; this doesn't affect the round-trip trial, which works independently of those values.
Can this test detect Bluetooth audio delay specifically?
Indirectly - Bluetooth headphones typically add real, measurable delay compared to wired output, which would show up as a higher round-trip average when comparing the same test with wired versus wireless audio.
Is my audio or click timing data stored anywhere?
No. All timing happens locally in your browser for the current session and is discarded when you refresh or leave the page.
Does this measure microphone input latency too?
No, this test focuses on audio output. For a microphone input check, use the dedicated Microphone Tester.
Conclusion
Between the system-reported latency values and your own round-trip average, you get both a technical snapshot and a practical, real-world feel for your audio delay. If you're specifically comparing wired versus wireless output, run the round-trip trial with each and compare the averages directly.