Where audio delay actually comes from
Digital audio is not processed sample by sample. It is processed in blocks, and a block cannot be worked on until it is full — so every buffer in the chain costs you the time it takes to fill. That single fact explains almost all latency you will ever meet, and it makes the arithmetic unusually clean: a buffer of n frames at r samples per second holds n ÷ r seconds of sound, and adds that much delay.
The Web Audio API sets the smallest unit — the render quantum — at 128 sample frames by default, and 1.1 lets a context ask for a hardware-chosen size instead of that default. Take the default, which is what you almost certainly have, and the figures come out as whole numbers of those blocks. The specification even works the example itself: an audio context at 44.1 kHz with the default render quantum, whose destination node double-buffers internally, has a processing latency of (2 × 128) ÷ 44100, which is approximately 5.805 ms. That is the specification’s own arithmetic, and you can check it on a calculator.
Buffer size to milliseconds, exhaustively
| Buffer | Render quanta | At 44 100 Hz | At 48 000 Hz | Round trip at 48 kHz |
|---|---|---|---|---|
| 128 frames | 1 | 2.902 ms | 2.667 ms | 5.333 ms |
| 256 frames | 2 | 5.805 ms | 5.333 ms | 10.667 ms |
| 512 frames | 4 | 11.610 ms | 10.667 ms | 21.333 ms |
| 1024 frames | 8 | 23.220 ms | 21.333 ms | 42.667 ms |
| 2048 frames | 16 | 46.440 ms | 42.667 ms | 85.333 ms |
Two things fall out of that table. First, doubling the buffer doubles the delay exactly — there is no diminishing return and no clever scheduling that escapes it. Second, the sample rate matters less than people expect: moving from 44.1 to 48 kHz shaves about 8% off every figure — the ratio 44100 ÷ 48000 — while halving the buffer removes 50%. If you are chasing latency, the buffer is the lever.
What your browser will and will not tell you
The Timing panel above reads three values live. AudioContext.baseLatency is defined by
the Web Audio specification as the seconds of processing latency incurred passing audio from the
destination node to the audio subsystem — and the specification is careful to say it excludes the
audio graph’s own latency and anything between the destination and the hardware.
AudioContext.outputLatency is defined as an estimate of the interval between the
browser asking the host system to play a buffer and the first sample actually being produced by the
output device; the specification notes it depends on the platform and the connected hardware and can
change while the context is running. The sample rate is what your context actually opened at.
What this page does not claim. Those are your browser’s estimates for your machine, read at the moment you look. They are not a MicTester measurement, they are not comparable across machines, and a browser that has not implemented a property shows “not reported” rather than a plausible-looking number. We have no microphone array, no second operating system and no way to benchmark hardware, so this site publishes no latency league table — only your own reading and the arithmetic that explains it.
Asking for lower latency, and why it may not arrive
There is a constraint for this. The specification defines latency as a
ConstrainDouble measured in seconds, described as the
time between the start of processing — for instance, when a sound occurs in the real world — and the
data being available to the next step. It then adds the sentence that matters: the number is
expected to be the target latency of the configuration, and the actual latency may show
some variation from it.
So a page can ask, and a browser can agree to the request while delivering something else. That is
the reason this page shows you what you got, and the reason the
Timing panel sits next to the track readout: getSettings() reports what the track
actually holds, which is the only figure worth acting on.
Reducing the delay you can control
- Turn processing off when you do not need it. Echo cancellation, noise suppression and gain control are each a stage with a buffer. This page starts with all three off for that reason.
- Prefer wired. A radio link adds an encode, a transmit and a decode that no buffer arithmetic on this page covers.
- Use the device’s own driver. Interfaces that ship a dedicated driver usually allow smaller buffers than a generic class driver will.
- Do not monitor through the computer. If your interface has direct hardware monitoring, it bypasses every millisecond in the table above — the delay becomes zero because the signal never enters the computer.
- Stop chasing it for calls. On a conference call the network dominates completely, and shaving five milliseconds locally changes nothing anybody can hear.
Latency you can hear, and what causes it
- Hearing yourself echo while wearing headphones on a call — the far end’s return path, not your capture. Nothing on this page affects it.
- Your voice arriving late in a recording alongside a backing track — capture buffer plus output buffer, which is the round-trip column above. Most recording software can compensate for a fixed offset if you tell it the number.
- A wireless headset feeling laggy — the radio link. Try the same test on a wired device and compare the reported figures.
- Everything fine until you share your screen — that is CPU contention forcing larger buffers, not a microphone fault. Check whether the reported figures change while sharing.
If the delay arrives with dropouts instead of as a clean offset, the problem is usually level or device selection, and timing is a red herring — the quiet-microphone page and the headset test cover those.