Skip to main content

Audio latency test

Measure your audio round-trip latency using your speakers and microphone.

Free & unlimitedWorks offline

Microphone access needed

This tool plays a short tone and listens through your microphone to measure round-trip latency. Audio stays on your device.

5 rounds by default · Configurable before starting

All processing happens in your browser. No data is sent to any server.

This audio latency test measures the real loop: a Web Audio oscillator plays a short tone through your speakers, the microphone picks it up, and an analyser watches the time-domain buffer until the amplitude crosses your threshold. The gap, timed with performance.now, is the round trip through the output stack, the air, the input stack and the browser. It runs several rounds and averages them. Alongside that it prints the two figures the browser reports itself, AudioContext.outputLatency and baseLatency, so you can see how much of the total the browser admits to. If microphone access is refused there is a manual tap mode instead.

Key facts about Audio latency test

Key facts about Audio latency test
What is measuredspeaker output plus air travel plus microphone input plus browser processing, end to end
Test tonean OscillatorNode, square by default, also sine or sawtooth
Tone frequency500, 1000, 2000 or 4000 Hz — 1000 Hz is the default
Tone lengthabout 30 ms in automatic mode, with an exponential gain ramp to near silence
DetectiongetByteTimeDomainData scanned for a sample whose amplitude exceeds the threshold
Analyser settingsfftSize 2048 with smoothingTimeConstant 0.3, so the attack is not smeared
Timing sourceperformance.now() taken immediately before the beep and again on detection
Rounds3, 5, 10 or 15 per run, averaged; 5 is the default
PresetsSensitive 0.30 volume and 0.05 threshold, Balanced 0.50 and 0.15, Loud room 0.80 and 0.30, Max volume 1.00 and 0.20
Browser figuresAudioContext.outputLatency and baseLatency, both in milliseconds, plus sample rate
False-start guardthe first five analyser checks after the beep are ignored so the tone's own onset cannot trigger early
Manual fallbacka beep after a random 1.5 to 4 second delay that you tap — human reaction time is included

What happens to your file

The microphone is opened with getUserMedia and connected to an AnalyserNode inside a local AudioContext. Only the amplitude values in the analyser buffer are read, and only to find the moment the tone arrives; nothing is recorded, saved or transmitted. The tone itself is synthesised in your browser rather than fetched, so the test needs no network at all once the page has loaded. Results live in memory for the session and are lost on reload. When you leave, the stream is stopped and the AudioContext is closed, which releases the microphone and clears the recording indicator.

About this tool

  1. 1

    Use speakers, not headphones

    The measurement depends on the microphone hearing the tone through the air. With headphones on, nothing reaches the microphone and every round times out. Built-in laptop speakers and the built-in microphone work fine.

  2. 2

    Allow the microphone

    Accept the browser prompt. If you decline, the tool switches to the manual tap mode, which measures your reaction time plus the latency rather than the latency alone.

  3. 3

    Pick a preset for your room

    Balanced suits a normal quiet desk. Sensitive lowers both volume and threshold for a very quiet room. Loud room raises both so background noise does not trigger detection early. Max volume is for speakers that are simply quiet.

  4. 4

    Set the number of rounds

    Five rounds is enough for a stable average on most systems. Use ten or fifteen when results scatter, which usually means the threshold is close to the room's noise floor.

  5. 5

    Sit still and stay quiet

    Any sound above the threshold can be mistaken for the tone. Do not type, move the mouse on a hard desk, or talk while the rounds are running.

  6. 6

    Read the average, not one round

    Individual rounds vary with buffer alignment. The average across the run is the figure to record, and the spread between rounds tells you how stable the audio stack is.

  7. 7

    Compare against the browser's own numbers

    outputLatency is the browser's estimate of its output path alone, and baseLatency is only its internal buffer. The difference between those and your measured round trip is everything the browser cannot see: the OS mixer, the driver, the DAC, the speaker and the microphone path.

Specs & compatibility
Browser supportany browser with Web Audio and getUserMedia — Chrome, Edge, Firefox, Safari, Opera
outputLatencyreported by Chromium and Firefox; Safari commonly returns nothing and the field shows Not supported
baseLatencythe AudioContext buffer only; it is always far smaller than the true round trip
Secure contextmicrophone access requires HTTPS, which this page uses
Autoplay policythe AudioContext starts suspended and is resumed on your click, so the test cannot begin on its own
Air travelroughly 0.3 ms per 10 cm between speaker and microphone, which is negligible at desk distance
Headphonesthe loop cannot close acoustically — use speakers, or the manual mode
Account or installnone — no signup, no ASIO driver, no loopback cable
  • Place the microphone within about 30 cm of the speaker. Distance adds roughly 0.3 ms per 10 cm, which is small, but a distant microphone also needs a much higher volume to trigger detection.
  • A Bluetooth speaker or headset adds 100 to 300 ms of codec and transmission delay, and it will dominate the result; test wired hardware if you want to know what the computer is doing.
  • If every round times out, raise the volume first and lower the threshold second — a threshold set below the room noise floor causes the opposite failure, with impossibly fast results.
  • Results under about 10 ms almost always mean the threshold is triggering on noise rather than the tone; raise it and run again.
  • The square wave is the default because its sharp onset is the easiest edge to detect. Switch to sine only if the square tone is unpleasantly harsh, and expect slightly noisier detection.
  • Windows exclusive-mode and low-latency driver settings change this number measurably; run the test before and after to see whether a change actually helped.
  • Browsers differ: the same machine can report noticeably different round trips in Chrome and Firefox because their audio output paths differ.
  • Manual mode includes your own reaction time, typically 200 to 300 ms, so treat it as a rough comparison between setups rather than a latency figure.
  • Automatic loopback rounds with averaging
  • Adjustable tone type, frequency, volume and detection threshold
  • Four room presets from Sensitive to Loud room
  • Live waveform with the threshold drawn on it
  • AudioContext outputLatency, baseLatency and sample rate readout
  • Manual tap fallback when the microphone is unavailable
  • Session history of previous runs
  • Checking whether a new audio interface or driver mode actually reduced latency.
  • Finding out how much delay a Bluetooth speaker adds compared to a wired one.
  • Diagnosing lip-sync complaints in video calls by separating audio delay from video delay.
  • Comparing browsers on the same machine before choosing one for a browser-based DAW or a rhythm game.
  • Establishing a baseline before changing buffer sizes in a music production setup.
  • Confirming that a laptop's built-in audio path is not the cause of a monitoring delay.
It is the total time from a program deciding to make a sound to that sound coming back in through the microphone. On this page it covers the browser's output buffer, the operating system mixer, the audio driver, the digital-to-analogue converter, the speaker, the air between the speaker and the microphone, the microphone's own path back through driver and mixer, and the browser's input buffer. Software that reports only its own buffer size, including the browser's baseLatency, is describing one small slice of that chain.
Because the measurement is acoustic. The tone has to physically reach the microphone for the analyser to detect it, and headphones send it into your ears instead. Use your computer's built-in speakers and microphone, or external speakers with any microphone pointed at them. If you have no speakers at all, the manual mode gives a rough comparison, but it includes your reaction time and cannot substitute for the loopback measurement.
On a wired desktop setup, 20 to 60 ms round trip is typical for a browser, and under 20 ms is very good. Laptops with shared audio drivers often land between 50 and 120 ms. Anything above roughly 150 ms usually means Bluetooth, a large driver buffer, or a virtual audio device in the chain. Because this measures the whole acoustic loop rather than a driver buffer, do not compare the number directly to a DAW's reported buffer latency, which is a different and much smaller quantity.
Audio buffers are discrete. A tone that starts just after a buffer boundary waits for the next one, so the measured latency quantises to the buffer size, and with a 512-sample buffer at 48 kHz that is about 10.7 ms of legitimate variation. Background CPU load, power-saving states and other applications holding the audio device add more. That is why the tool averages several rounds: the average is stable even when individual rounds scatter across one buffer period.
AudioContext.outputLatency is optional in the specification and Safari in particular does not implement it. When the browser does not provide a number, the tool prints Not supported rather than inventing one. The measured round trip does not depend on that field at all, so the test still works; you simply lose the ability to compare the browser's own estimate against the real measurement. baseLatency is more widely available, but it only describes the AudioContext's internal buffer.
In order of likelihood: headphones are plugged in, so the tone never reaches the microphone; system volume is muted or very low; the microphone is muted at hardware level or set to a device pointing away from the speakers; or the threshold is too high for how loud the tone is. Raise system volume, switch to the Max volume preset, confirm the microphone is live on the microphone tester page, then lower the threshold one step at a time. Each round gives up after about 500 checks, which is why a failed run ends rather than hanging.

Related tools

View all

Part of Hardware testers that run in your browser

Related categories2

Updated

We use anonymous analytics to improve ToolChamp. No personal data is stored or sold. Privacy Policy