LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Audio Latency Honestly

16 min read Audio Engineering
audio-latencylow-latencylive-soundin-ear-monitorsdigital-audioaudio-engineering
Contents

Latency is the one audio number that everybody quotes and almost nobody adds up correctly. A converter’s spec sheet brags about “1.2 ms round-trip,” a plugin developer reports “0 samples latency,” a wireless in-ear system claims “less than 4 ms” — and a guitarist still complains that monitoring through the desk feels like playing underwater. The reason is that latency is not a property of any single box. It is the sum of every conversion, buffer, transport hop, DSP block, and meter of air the signal crosses on its way from the source to an ear, and the human nervous system reacts to the total, not to the most flattering line item. The honest way to think about audio latency is as a budget you spend down a chain, with a hard perceptual ceiling at the end of it, and the engineering job is knowing which links cost what so you can cut the expensive ones without breaking everything else.

This matters because the two people who care about latency — the performer and the audience — experience completely different chains, and conflating them is the source of most confused advice. A musician monitoring themselves cares about the closed loop: their finger hits a string, and how long until they hear it back. The audience cares about an open path: sound leaves a speaker and arrives at their seat, with no reference signal to compare against, so they tolerate far more delay before anything seems wrong. Most “low latency” engineering effort goes into the performer’s loop, where the ceiling is brutally low, while the audience’s path is dominated by something no DSP can fix: the speed of sound in air.

The perceptual thresholds: what actually matters

Before counting milliseconds it is worth knowing what the milliseconds buy. Human latency tolerance is not a single threshold; it depends entirely on what cue the brain is using.

For a performer monitoring their own playing, the tight number is around 10 ms of round-trip delay before the feel starts to degrade, with many players noticing softening above roughly 6–7 ms and most agreeing that anything past 12–15 ms is unusable for fast, percussive playing. Drummers and percussionists are the most sensitive because the attack transient is the timing cue; a pad-and-sustain synth player can tolerate much more. The mechanism is not “hearing an echo” — at these delays you do not perceive two events, you perceive one slightly wrong event, a smearing of attack and a subtle disconnect between the physical action and the sound.

A second, lower threshold matters when the delayed sound mixes with an undelayed acoustic version of itself: comb filtering. If a singer hears their own voice both acoustically through bone and air and delayed through in-ear monitors, the two combine and notch out frequencies wherever they are out of phase. This becomes audible as a hollow, phasey coloration at delays as small as 1–3 ms, far below the timing threshold. It is why monitoring problems often sound like a tone problem rather than a timing problem.

The third threshold is the echo threshold (the Haas or precedence window), around 30–40 ms, beyond which the brain stops fusing the delayed copy with the original and starts hearing a distinct second event — a slap. This is the audience-side ceiling, and it is enormous compared to the performer’s. Sound travels roughly 1 foot per millisecond (343 m/s, about 1.13 ft/ms), so 30 ms is about 34 feet of air. An audience member 60 feet from the stage is already 53 ms behind a front-row listener and does not care, because there is no reference to compare against.

Scenario Cue used Trouble threshold Why
Musician monitoring own attack Action-to-sound timing ~6–12 ms Smearing of transient feel
Voice mixed with own acoustic sound Comb filtering ~1–3 ms Phase notches color the tone
Audience hearing PA vs. another source Echo / precedence ~30–40 ms Brain splits into two events
Lip-sync to video Audiovisual fusion ~ -125 ms to +45 ms Audio-after-video tolerated more

The asymmetry in that last row is worth keeping in mind: ITU-R BT.1359 finds people detect audio leading video at about 45 ms but tolerate audio lagging by up to about 125 ms, because in nature sound always arrives after the sight of the event. The same neural bias makes a late monitor feel worse than its raw number suggests when there is a visual reference.

Where the milliseconds come from: the digital chain

In a computer-based studio, round-trip latency is dominated by one tunable parameter and a handful of fixed costs. The tunable one is the buffer size. Audio hardware does not hand the CPU one sample at a time; it fills a buffer of N samples and interrupts the host once per buffer. The time that buffer represents is simple arithmetic:

buffer_latency_ms = (buffer_size_samples / sample_rate_hz) * 1000

at 48 kHz:
   64 samples  -> 1.333 ms
  128 samples  -> 2.667 ms
  256 samples  -> 5.333 ms
  512 samples  -> 10.667 ms
 1024 samples  -> 21.333 ms

But that is the one-way cost of a single buffer, and the real round trip pays for it more than once. The signal is buffered on the way in (capture), the host typically needs a full buffer period to process and hand back the output, and it is buffered again on the way out (playback). A useful rule of thumb is that round-trip latency is roughly two to three buffer periods plus the converter overhead, which is why a “128 sample” project at 48 kHz reports something like 7–9 ms round-trip rather than 2.7 ms.

The fixed costs are the parts you cannot turn down with a slider:

  • Converter latency. ADCs and DACs use oversampling sigma-delta designs whose digital decimation and reconstruction filters impose a fixed group delay, typically 0.3–1.0 ms each. Linear-phase converter filters cost more delay than minimum-phase ones; some interfaces offer a “low latency” converter mode that trades a gentler anti-alias slope for less delay.
  • Transport. USB, Thunderbolt, and PCIe differ. PCIe and Thunderbolt can sustain tiny buffers reliably; USB adds its own microframe scheduling and is more sensitive to small buffers. The interface’s USB stack often adds a “safety offset” buffer the host cannot see directly.
  • Driver model. On Windows, ASIO bypasses the shared WASAPI mixer and is what every DAW uses for tracking; the generic shared path adds tens of milliseconds. On macOS, Core Audio is low-latency natively. On Linux, PipeWire (or JACK) plays the same role.
  • Plugin / DSP latency. This is the sneaky one and the subject of its own section below.

A practical tracking session lives at 64 or 128 samples to keep the performer’s loop under 10 ms, then the engineer raises the buffer to 512 or 1024 for mixing, where round-trip feel no longer matters and CPU headroom does. Knowing the budget is what makes that trade deliberate instead of superstitious — the same kind of signal-flow accounting covered in the broader DSP for audio discussion.

The round-trip budget, drawn out

It helps to see the whole performer loop as a pipeline with a running total. Here is a representative monitoring round trip for a singer tracking through a DAW at 48 kHz, 128-sample buffer, with one software effect inserted:

   SOURCE (voice)
       |
       v
  [ Mic + preamp ]                 ~0.00 ms   (analog, negligible)
       |
       v
  [ ADC convert ]                  +0.50 ms   converter group delay
       |
       v
  [ Capture buffer ]              +2.67 ms   128 smp in
       |
       v
  [ Host + plugin DSP ]           +2.67 ms   one buffer period
       |          (+ plugin PDC if any, e.g. linear-phase EQ +X ms)
       v
  [ Playback buffer ]             +2.67 ms   128 smp out
       |
       v
  [ DAC convert ]                 +0.50 ms   converter group delay
       |
       v
  [ Headphone -> ear ]            ~0.00 ms
       |
       v
   PERCEIVED                       = ~9.0 ms round trip

About 9 ms — under the threshold, just. Now insert a mastering-style linear-phase EQ or a lookahead limiter on the monitor path and watch the budget blow: a linear-phase EQ can report 5–20 ms of its own latency, and a lookahead limiter another 1–5 ms, instantly pushing the loop past usable. This is why the universal tracking advice is to monitor dry or through the interface’s zero-latency hardware path and save the heavy plugins for mixdown. The numbers below show how little room the buffer alone leaves once converters and double-buffering are counted.

Buffer @ 48 kHz One buffer Typical RTL (2.5×) + converters Verdict for tracking
32 smp 0.67 ms ~2.5 ms Ideal, needs strong CPU/IO
64 smp 1.33 ms ~4.3 ms Comfortable for most
128 smp 2.67 ms ~7.7 ms Safe default
256 smp 5.33 ms ~14.3 ms Drummers will feel it
512 smp 10.67 ms ~27.7 ms Mix-only, not tracking

Live sound: the acoustic chain dominates

Move from the studio to the stage and the whole accounting flips. Digital consoles, stageboxes, and networked audio add latency, but it is dwarfed by the physics of air. A modern digital mixing console — a DiGiCo, an Avid S6L, an Allen & Heath dLive — has a fixed input-to-output latency on the order of 0.7–2.5 ms, including its converters and internal DSP. A digital snake over an audio network adds a small, deterministic amount on top. That entire electronic budget is smaller than the delay introduced by standing two feet further from a wedge.

The dominant live numbers are acoustic:

  • Throw distance. At ~1.13 ft/ms, a listener 100 feet back hears the main PA about 88 ms after it leaves the box. That is why large systems use delay towers — secondary speaker positions downstream that are electronically delayed so their output arrives in time-alignment with the main PA’s wavefront as it sweeps past, rather than ahead of it.
  • Monitor wedges vs. IEMs. A floor wedge is close, so its air delay is a millisecond or two, but it bleeds into mics and combs with the PA. In-ear monitors remove the wedge but introduce the comb-filter problem against the performer’s own bone-conducted sound.
  • Wireless IEM RF latency. Analog FM in-ear systems are effectively instantaneous (RF travels at light speed; the only delay is the companding circuit, microseconds). Digital wireless IEM systems encode and packetize, adding a real, fixed 1.4–4 ms. That sounds trivial until you stack it on a digital console’s 2 ms and a digital wireless mic on the input — suddenly a singer is monitoring their own voice 6–8 ms late through the ears while hearing it ~0 ms through their own skull, and the comb filtering and timing smear are both in play.
  STAGE                                        AUDIENCE
  -----                                        --------
  Vocal mic --> [digital wireless RX +3ms]
                      |
                      v
               [digital console  +2ms] --> [main PA] ))) air )))  Row 1   ~5 ms
                      |                                  \
                      +--> [IEM TX digital +2.5ms]        ))) air )))  Row 30  ~35 ms
                              |
                              v
                       singer's ears  ~7.5 ms  (vs. bone-conduction ~0 ms)

The console operator can solve the audience side with delay alignment, but the performer side has no clean fix: you cannot delay bone conduction. This is the central, unglamorous truth of live monitoring engineering, and it is covered from the mixing side in the live sound engineering deep dive.

In-ear monitors and the comb-filter problem

The in-ear case deserves its own dissection because it is where “low latency” hardware can still produce a bad result. When a vocalist sings, the sound reaches their cochlea by two routes: through the air and skull (bone and tissue conduction, essentially instantaneous and unavoidable while the mouth is producing sound) and through the monitor chain (mic, wireless, console, IEM transmitter, earpiece — several milliseconds late). The two copies sum at the eardrum, and wherever they are a half-wavelength out of step they cancel.

A 4 ms delay puts a first cancellation notch at 125 Hz (the frequency whose half-period is 4 ms), with a comb of further notches above it. The singer perceives this not as latency but as a thin, hollow, “phasey” voice in their ears, and the instinctive response — push more vocal into the mix — makes it worse. Sealing the ear more tightly (deeper insertion, custom molds) attenuates the acoustic path and reduces the comb, which is part of why custom IEMs are valued beyond comfort. The other levers are choosing analog or lowest-latency digital IEM systems, minimizing the number of digital hops in series, and accepting that some bleed is unavoidable. The same delay-versus-quality trade shows up in consumer gear, where Bluetooth codecs impose tens of milliseconds — see Bluetooth audio explained for why wireless earbuds are categorically unusable for live monitoring.

Networked audio and remote collaboration

Audio-over-IP splits cleanly into two worlds with wildly different latency stories, and confusing them is a common error.

Deterministic local networks — Dante, AES67, AVB/Milan — run on managed Ethernet with tight clock synchronization (PTP, IEEE 1588) and configurable, bounded latency. Dante exposes selectable latency settings of 0.25, 0.5, 1, 2, or 5 ms depending on network size and switch count; a typical stage runs at 0.5 or 1 ms. These are deterministic because the network is engineered: known switches, known hop count, priority queuing for audio. The point of the latency setting is to provide enough buffer to absorb switch jitter without overrunning — bigger networks need a bigger setting.

# Conceptual Dante device latency budget
# (set per-device in Dante Controller)
#
#   latency_setting >= max_path_jitter + transmit_window
#
#   1 switch hop   -> 0.25 ms often safe
#   3-5 hops       -> 1 ms typical
#   large/WAN-ish  -> 5 ms

The public internet is the other world, and here the floor is physics, not buffering. Light in fiber travels at about two-thirds of c, so the one-way propagation delay is roughly 1 ms per 200 km of cable, before any router queuing. New York to London is about 5,500 km, giving a theoretical one-way minimum near 28 ms and a real round trip, with routing and jitter buffers, of 70–100+ ms. That is why remote real-time jamming is fundamentally hard: tools like JackTrip strip the chain to the bone (no codec, tiny buffers, raw PCM over UDP) and can hit usable numbers only over short distances or dedicated research networks like Internet2. WebRTC-based collaboration tools add Opus encoding and adaptive jitter buffers that push latency to 100–200 ms — fine for conversation, useless for playing in time together. The honest position is that low-latency local networked audio is a solved, deterministic engineering problem, and low-latency internet audio is bounded by the speed of light and the chaos of best-effort routing, and no amount of clever buffering changes that floor.

The limits of the tooling

The studio’s best tool for latency is plugin delay compensation (PDC), and understanding what it can and cannot do separates engineers who trust their meters from those who get surprised. PDC works by reading each plugin’s reported latency, finding the most-delayed path through the project, and delaying every other track to match, so everything lines up at the master bus. It is the reason you can put a 20 ms linear-phase EQ on the mix bus and not hear the drums smear against the bass.

PDC has three hard limits:

  1. It only compensates for reported latency. A plugin that introduces delay but reports zero — older or sloppily written ones do exist — will not be compensated, and the host has no way to know. The fix is measurement, not trust.
  2. It cannot compensate a live input. PDC delays other tracks to match the slow one, but you cannot delay reality. While you are tracking through a latency-inducing plugin, that plugin’s delay is added to your monitoring round trip with no remedy except removing it from the monitor path. This is why PDC, the studio’s great latency equalizer, is useless on stage.
  3. It interacts badly with feedback and live re-amping. Any loop that leaves the computer and comes back (hardware inserts, external re-amping) accumulates the round-trip latency that PDC cannot see across the analog gap, so DAWs provide a separate manual “hardware insert delay” ping to measure and offset it.

For numbers PDC cannot give you, the tooling is a loopback measurement: physically patch an output back to an input and play a click, then measure the sample offset between what you sent and what came back. That is the only way to learn your true round-trip latency including the converter and driver costs the spec sheet rounds off. On Linux with JACK or PipeWire the canonical tool is jack_iodelay:

# Measure true round-trip latency, Linux/JACK or pw-jack
# Physically connect an output to an input first.

$ pw-jack jack_iodelay
# then in another terminal, wire it up:
$ pw-jack jack_connect jack_delay:out system:playback_1
$ pw-jack jack_connect system:capture_1 jack_delay:in

# jack_iodelay prints, e.g.:
#   roundtrip latency: 312 frames  6.500 ms  (incl. -64 frames extra)

On macOS and Windows the equivalent are utilities like Oblique Audio’s RTL Utility, which do the same loopback timing through a hardware cable. The number they return — not the one on the box — is your real budget. Every interface vendor’s quoted figure omits something (the USB safety offset, the host buffer, or both), and the gap between the spec and the loopback result is often 2–4 ms, which is exactly the margin that decides whether a drummer can track comfortably. The discipline that separates reliable low-latency work from cargo-culting buffer sizes is the same one behind honest audio codec comparisons: measure the whole chain, distrust the single advertised number, and account for every hop.

Verdict

Audio latency is not a spec, it is an accounting problem, and almost every frustration with it comes from adding up the wrong column. The performer’s monitoring loop has a brutal ceiling — roughly 10 ms of round trip, with comb filtering biting far below that whenever a delayed signal meets an undelayed acoustic one — and you protect it by minimizing buffers, monitoring dry through hardware paths, and keeping lookahead and linear-phase DSP off the live signal. The audience’s path, by contrast, is governed almost entirely by the speed of sound, tolerates 30 ms and more before anything seems wrong, and is corrected with delay alignment rather than faster electronics. The two budgets are different by an order of magnitude, and good engineering means knowing which one you are spending.

The tooling is genuinely good but bounded in honest, predictable ways: plugin delay compensation cleans up the mix bus but cannot help a live input or a plugin that lies about its latency; deterministic networks like Dante make local audio-over-IP a solved, sub-millisecond problem; and nothing — no codec, no buffer trick, no marketing — beats the speed of light, which is why internet jamming stays hard and probably always will. Trust the loopback measurement over the spec sheet, keep the performer’s loop short and dry, and align the room for the audience. Do that and latency stops being a mystery and becomes what it actually is: a budget you can read off, line by line.

Sources

Comments