Audio Latency

Every digital audio system delivers the past. Between the moment a sound hits your microphone and the moment it leaves for the network, it queues in buffers, waits for analysis frames to fill, and sits in deliberate look-ahead delays. None of this is sloppiness — most of it is physics and arithmetic. Here's where the milliseconds actually come from, and how many of them matter on a call.

Where the milliseconds come from

Digital audio doesn't flow; it moves in blocks. A capture driver doesn't hand software one sample at a time — it fills a buffer of, say, 512 samples and delivers the whole thing. At a 48 kHz sample rate, a 512-sample buffer is about 10.7 ms of sound, and the last sample in it is brand new while the first is already 10.7 ms old. Smaller buffers mean less waiting but more frequent wake-ups, and because a general-purpose operating system schedules audio threads alongside everything else, every real system pads its buffers with safety margin so a late wake-up doesn't cause an audible glitch. That's the first tier of latency: buffering, the tax on reliable delivery.

The second tier is block processing. Much of modern audio analysis happens in the frequency domain, and a Fourier transform needs a full frame of samples before it can say anything about them. An algorithm built on 1024-sample FFT frames cannot produce its first output until 1024 samples — over 21 ms at 48 kHz — have arrived, and overlapped processing adds partial frames on top: if frames advance in 512-sample hops, each output region isn't final until every frame that overlaps it has been computed. The third tier is look-ahead, which deserves its own section.

Crucially, these delays don't average out — they accumulate. A signal that passes through a capture buffer, a ring buffer into the processing thread, an FFT frame, a look-ahead delay, another ring buffer, and an output buffer carries the sum of all of them, every time. This is also why quoted figures deserve skepticism unless they were measured end to end: the honest method is a loopback test, where you play an impulse out one path, record it back through the whole chain, and count the samples between the two. Arithmetic tells you the floor; measurement tells you the truth.

Why look-ahead must add delay

Some processing decisions are impossible to make causally. Consider a click suppressor that must distinguish a trackpad click from the sharp onset of a consonant like "t" or "k". At the moment of the transient, the two are nearly identical; the difference reveals itself in what follows. A click decays into silence in a few tens of milliseconds. A consonant decays into a vowel. Any algorithm that acts at the instant of the transient is guessing; one that waits to watch the decay knows — but by then, the transient has already gone out the door.

The only fix is to delay the main signal by exactly the amount of future the detector needs to see. The detector runs on the live input, the audience hears the delayed copy, and the algorithm effectively operates on the past with knowledge of the "future." This is why look-ahead limiters, de-clickers and gates all quote a fixed latency: you cannot duck a click you haven't seen finish. The delay isn't an implementation weakness to be optimised away — it is the algorithm.

How much latency matters on a call

For conversation, the number that matters is one-way, mouth-to-ear delay. ITU-T guidance for telephony (Recommendation G.114) holds that one-way delay below roughly 150 ms feels natural to most users; as delay grows beyond that, the damage isn't echo or artifacts but broken turn-taking — the pauses that signal "your turn" stretch, people start talking over each other, and conversation develops that unmistakable satellite-link awkwardness.

Against that budget, local processing is a minor line item. A typical call already spends its milliseconds on the codec's own framing, the network path, and the receiver's jitter buffer — the queue that deliberately holds packets back so that unevenly arriving audio can play out smoothly — before anyone's DSP gets involved. Network conditions routinely swing a call's delay by more than an entire processing chain costs, and the jitter buffer grows and shrinks with them. Forty milliseconds of cleanup at the source is imperceptible to the person on the other end, and it buys a signal the platform's own processing no longer has to fight.

It's also worth being precise about which direction you're counting. Conversational comfort depends on one-way delay, but what you subjectively notice on a bad call is the round trip: you finish a sentence, and the other person's reaction arrives two full traversals later. That's why a link that measures fine on paper can still feel laggy in practice — every hesitation you perceive includes their delay as well as yours.

Throughput latency versus monitoring latency

There is one situation where tens of milliseconds are not fine, and it's worth naming precisely. Throughput latency — mic to the far end — is delay you never hear. Your listener experiences your voice slightly later; neither of you can perceive the offset, because there's nothing to compare it against. Monitoring latency — mic to your own ears — is different in kind, because your brain compares the returned sound against the act of speaking in real time. Musicians tracking through headphones notice this above roughly 10 ms and demand direct hardware monitoring; for speech, a delayed return of your own voice actively disrupts fluency, a phenomenon strange enough to have its own literature — see delayed auditory feedback. The same 40 ms that is invisible in throughput is uncomfortable in a monitor path, and monitor paths are usually slower than throughput paths, not faster.

In DeskBroadcast

DeskBroadcast's processing chain adds about 40–43 ms of throughput latency, and the arithmetic is exactly the kind described above. The classical spectral stage needs one 1024-sample FFT frame plus two 512-sample look-ahead hops — 43 ms at 48 kHz. That look-ahead exists for a specific reason: it lets the click suppressor watch a transient decay before deciding it wasn't speech. The AI voice isolation stage measures about 40 ms (1922 samples at 48 kHz), and the two stages replace each other rather than stack, so enabling the model doesn't add its delay on top of the classical chain's. Capture and output contribute small ring-buffer amounts on either side. The separate Monitor playback path is another story: fed by an audio tap and routed through its own output, it adds far more — roughly 125–250 ms — which is one reason live self-monitoring feels wrong, and why the app offers a record-and-replay check instead.