Audio latency explained: why milliseconds matter

Audio latency is the time between sound entering one part of a chain and leaving another. The number sounds small — typical desktop latency is measured in milliseconds — but small numbers add up. By the time a voice has crossed a microphone, the operating system, the browser, the network, and another set of speakers, the total can be high enough to make a video call awkward or a recording impossible to monitor live. This guide explains where the milliseconds come from and what you can do about them.

What "latency" actually measures

There are at least four different latencies that get bundled under the same word:

• Buffer latency — the time it takes to fill the audio buffer before the next chunk is processed. Smaller buffers mean lower latency but more work for the CPU.
• Driver and system latency — the operating system's audio stack, kernel scheduling, and any vendor enhancements layered on top.
• Transducer latency — the microphone or speaker itself, plus any wireless link such as Bluetooth.
• Network latency — only when a remote system is involved, but it dominates the moment a call enters the picture.

Our test reads what the browser exposes through the Web Audio API: principally the buffer-related latencies. Everything below the browser is invisible to the page but still very much present in your experience.

How much latency is acceptable?

Tolerance depends on the task. Sitting silently and listening to a recorded podcast, hundreds of milliseconds go unnoticed. Speaking and hearing your own voice routed back, the brain begins to flinch around 30 ms.

Two important nuances. First, these are round-trip budgets — the perceived total, not just the browser figure. Second, latency rarely arrives as a single value: it jitters. A connection averaging 80 ms with occasional 300 ms spikes feels worse than a steady 150 ms.

Where the milliseconds come from

Bluetooth

Wireless headphones add a chunk of latency that varies with codec and connection profile. Streaming audio profiles (A2DP) tend to add roughly 100–250 ms; the moment the microphone is in use, headsets typically switch to a lower-quality profile that may add even more. If a recording sounds out of sync, Bluetooth is one of the first things to suspect.

USB audio devices

Cheap USB microphones often run at 16-bit, 44.1 or 48 kHz with relatively large buffers. Better interfaces use ASIO or Core Audio drivers that can run very small buffers, but only when the rest of the system is healthy enough to keep up.

Operating system audio stacks

On Windows, shared mode through WASAPI typically adds 10–30 ms; exclusive mode and ASIO can drop to a few. macOS Core Audio is generally lower-latency out of the box. On either platform, virtual cameras and meeting-app filters can insert their own buffers.

The browser

Browsers are not the worst place to do real-time audio anymore, but they are still bound by the same buffer-size trade-off. Tabs in the background often run at slower clocks, and a single misbehaving extension can pause the audio thread long enough to cause a glitch.

Networks

Once a remote endpoint is involved, latency starts at the round-trip time of the connection and grows with every codec and jitter buffer in between. Even on a fast connection, expect 50–150 ms of network-side delay on a typical video call.

How to reduce latency on a normal computer

1. Use a wired connection where it counts. Bluetooth alone can blow a 20 ms budget.
2. Plug audio devices directly. USB hubs add jitter and occasionally drop frames.
3. Close other apps that use audio. Each one wants its own buffer.
4. On Windows, enable exclusive mode for the device or use an ASIO driver if your interface supplies one.
5. Lower the buffer size in your DAW, meeting app, or driver utility — but watch for crackles, which mean you went too low.
6. Restart the browser tab between sessions. Audio contexts that have been alive for hours sometimes drift.

Worked example: video calls

Imagine you join a meeting from a laptop with built-in audio:

• Microphone capture and OS processing: ~10–20 ms.
• Meeting app encoding and packetisation: ~20–40 ms.
• Network round-trip to the meeting server: ~30–80 ms.
• The other participant's decoding and playback: ~20–40 ms.

The total commonly lands somewhere around 100–180 ms one-way, before either party adds Bluetooth headphones. That is why turning off Bluetooth alone often turns a sluggish call into a snappy one.

Common mistakes to avoid

• Mistaking lag for latency. If video freezes and audio continues, you have a network or CPU problem, not a high-latency device.
• Adding software effects "to fix the sound" while monitoring live. Each effect adds its own buffer.
• Trusting the browser number alone. Treat it as a baseline. Real perceived latency is always higher.
• Dropping the buffer below what the system can handle. You will get clicks, pops, and dropouts that sound worse than the latency you saved.

For day-to-day calls, latency under about 150 ms is hard to notice. For recording, aim for under 20 ms round-trip — anything higher will fight you. For live software-instrument playing, plan for an audio interface and a wired chain.

If a low number on the test is not matching your experience on calls, the chain outside the browser is almost always responsible. Run the latency test with and without your headphones connected to compare. Our microphone troubleshooting guide covers the related "the test looks fine but the call sounds bad" scenario.

A latency budget for a real setup

Individual figures are less useful than the sum. Here is roughly how the milliseconds stack up in two common configurations.

The table makes the point that no amount of buffer tuning competes with removing the wireless link. Everything else on the list is worth single-digit milliseconds; Bluetooth is worth a hundred or more. Measure your own baseline with the audio latency test, and see why Bluetooth microphones sound bad for the quality side of the same trade-off.

Which symptom is really a latency problem?

Note the tension in that table: latency and stability pull in opposite directions. Smaller buffers reduce delay but increase the chance of dropouts, so the right buffer size is the smallest one that stays glitch-free on your machine, not the smallest one available.

How to measure it properly

Browser-reported latency is a floor, not a total. To measure what you actually experience end to end:

1. Loopback test. Record the output of your speakers with your microphone while playing a sharp click, then measure the gap between the two in any audio editor. That gives true round-trip delay including every stage.
2. Video reference. Film your hands clapping while a screen shows the same clap, then step through frames. Crude, but it catches audio-to-video offsets that no software reports.
3. Compare configurations, not absolutes. The useful question is almost never "what is my latency" but "did this change reduce it" — and for that, a consistent method matters more than an accurate one.

Frequently asked questions