What This Page Explains
This page documents the exact technical mechanism behind the Sound Latency Test on SoundLatencyTest.com. It explains what the tool measures, how the measurement is made step by step, what each stage of the pipeline does, what accuracy the result achieves, and what the tool cannot determine. If you want a plain-language explanation of what your result means and how to act on it, see the FAQ.
What Round-Trip Audio Latency Actually Is
Audio latency is the delay between an audio event being initiated and that event being perceived or captured. Round-trip audio latency — the figure this tool measures — is the total elapsed time between a sound being output by your system and that same sound being captured back by your microphone.
This figure is the sum of several independent latency sources stacked in sequence:
| Latency Source | Typical Range | Notes |
|---|---|---|
| AudioContext output scheduling | 1–10 ms | baseLatency property; browser and OS dependent |
| OS audio output buffer | 2–20 ms | WASAPI/Core Audio/ALSA dependent |
| Hardware DAC and speaker output | 1–5 ms | Negligible on wired headphones |
| Acoustic travel time (speaker to mic) | ~0.3 ms per 10 cm | Physical distance between speaker and mic |
| Microphone input latency | 2–15 ms | Hardware and driver dependent |
| OS audio input buffer | 2–20 ms | Symmetric with output buffer in most systems |
| AudioContext input scheduling | 1–5 ms | Browser capture pipeline overhead |
A typical consumer laptop using built-in audio will produce a round-trip latency of 30–80 ms. An external USB audio interface with low-latency drivers typically produces 5–15 ms. Bluetooth audio adds 40–200 ms of codec processing overhead on top of all of the above.
The Measurement Pipeline — Step by Step
Step 1 — AudioContext Initialisation
When the test begins, the browser creates an AudioContext instance. This is the Web Audio API’s core processing environment. The AudioContext operates at the device’s native sample rate — typically 44,100 Hz or 48,000 Hz — and all subsequent audio processing occurs within this context.
At this point the tool reads and logs two latency properties exposed by the AudioContext:
AudioContext.baseLatency— the estimated latency introduced by the AudioContext’s output processing pipeline, in secondsAudioContext.outputLatency— the estimated latency from the AudioContext to the audio output device, in seconds
These values are used as reference data. They do not constitute the final latency measurement — they are one component of it.
Step 2 — Microphone Permission and MediaStream Capture
The browser requests microphone permission via the getUserMedia() API. The user must grant this permission for the test to proceed. Once granted, the browser opens a MediaStream capturing the microphone input at the current sample rate.
This audio stream is connected to a MediaStreamAudioSourceNode, which feeds the captured audio into the AudioContext for analysis. The microphone stream is never recorded, never stored in any persistent form, and never transmitted over the network. It exists only as a live audio buffer in the browser’s memory for the duration of the test. For full details on how microphone data is handled, see the Data Security page.
Step 3 — Tone Burst Generation
The tool generates a short tone burst — a brief, spectrally distinct audio signal — using an OscillatorNode connected to the AudioContext destination (your speakers or headphones). The tone burst is designed to be:
- Short in duration (typically 20–50 ms) — to produce a clearly defined onset and offset in the captured signal
- Spectrally distinct — to be identifiable against background noise in the cross-correlation analysis
- Timed precisely — the exact AudioContext timestamp at which the tone burst is scheduled to begin is recorded
The AudioContext.currentTime property, which operates on a high-resolution clock independent of JavaScript’s standard timing, is used to timestamp the output event. This is critical to measurement accuracy: JavaScript’s Date.now() and performance.now() are subject to resolution limits in some browsers; AudioContext.currentTime is not.
Step 4 — Continuous Microphone Buffer Capture
While the tone burst plays, the MediaStreamAudioSourceNode feeds the microphone input into a ScriptProcessorNode or AudioWorkletNode (depending on browser support), which captures the incoming audio in short overlapping frames. Each frame is timestamped using AudioContext.currentTime.
The captured frames are assembled into a buffer that spans the expected round-trip window — from just before the tone burst is emitted to a maximum of approximately 500 ms after, which covers the full range of latency values expected in real-world browser environments.
Step 5 — Cross-Correlation Analysis
Once the capture window closes, the tool performs cross-correlation between two signals:
- The reference signal — the known waveform of the tone burst as generated
- The captured signal — the microphone buffer recorded during and after output
Cross-correlation computes the similarity between these two signals as a function of time offset. The time offset at which the correlation peaks — the point at which the captured signal most closely matches the reference signal — is the measured round-trip latency.
The formula applied:
Round-trip latency (ms) = (Peak correlation offset in samples ÷ Sample rate in Hz) × 1,000
Worked example: If the peak correlation offset is found at sample 2,205 and the sample rate is 44,100 Hz:
(2,205 ÷ 44,100) × 1,000 = 50 ms round-trip latency
The result is expressed in milliseconds and displayed alongside the hardware category benchmark for the user’s expected setup type.
Step 6 — Result Display and Interpretation
The measured latency in milliseconds is displayed with contextual benchmarks:
| Hardware Category | Typical Round-Trip Latency | Notes |
|---|---|---|
| External audio interface (ASIO/Core Audio) | 5–15 ms | Professional low-latency drivers |
| Built-in wired audio (laptop/desktop) | 30–80 ms | OS audio stack dependent |
| USB audio (class-compliant, no ASIO) | 20–50 ms | Better than built-in, not as low as ASIO |
| Bluetooth headphones/speakers | 70–250 ms | Codec and hardware dependent |
Results that fall significantly outside these ranges are flagged with a note directing users to the Troubleshooting page.
Accuracy
The cross-correlation method achieves sample-level precision in identifying the peak offset — meaning the theoretical resolution of the measurement is 1 ÷ sample rate. At 44,100 Hz, this is approximately 0.023 ms per sample.
In practice, the real-world accuracy of the measurement is limited by:
- Microphone frequency response — consumer microphones have uneven frequency response, which slightly distorts the captured waveform and can shift the correlation peak by 1–3 samples
- OS audio processing — automatic gain control (AGC), noise suppression, and echo cancellation applied by the OS can modify the captured signal before it reaches the browser
- Background noise — ambient noise creates a noise floor that slightly reduces cross-correlation peak clarity
- Single-measurement variance — a single test run may vary by ±2–5 ms from the true mean; running multiple tests and averaging the results improves accuracy
Practical accuracy: ±3–5 ms for a single run on a typical consumer setup. ±1–2 ms when averaged across three or more runs.
What This Tool Cannot Determine
Hardware-only latency in isolation The round-trip figure includes both hardware and software latency combined. The tool cannot isolate the contribution of the audio interface DAC from the contribution of the OS audio buffer or the browser’s AudioContext pipeline separately.
One-way latency (output or input independently) The measurement captures the full round-trip. Output-only latency and input-only latency cannot be separated from this figure without additional hardware reference measurement.
Zero-latency hardware monitoring latency Some audio interfaces offer hardware-level zero-latency monitoring that routes the input signal directly to the output without passing through the software stack. This bypass route is invisible to the browser and cannot be measured by any Web Audio API-based tool.
Latency under DAW load The measured latency reflects the browser environment at the time of the test. DAW buffer settings, plugin processing load, and system resource usage under production conditions will produce different figures than a standalone browser test.
Absolute hardware specifications The result is a measurement of your specific system at the time of testing, not a published hardware specification. Two identical machines may produce slightly different results depending on driver versions, OS configuration, and background processes.
Related Pages
- FAQ — plain-language answers to the most common questions about latency measurement results
- Troubleshooting — what to do if your result is unexpectedly high, zero, or fails to complete
- Data Security — how microphone audio is processed and why it never leaves your device
- About SoundLatencyTest.com — who runs this site and why it was built
Written by Jackson Cooper, founder of SoundLatencyTest.com. Last updated: June 2026.