Latency, and why a speaker starts stumbling

Why a speaker starts stumbling over their words

Put headphones on somebody, feed their own voice back to them through a computer, and if the delay is more than a few milliseconds they begin to hesitate, slow down and repeat syllables. They will usually blame themselves.

This is delayed auditory feedback, and it is a well-documented effect rather than a matter of preference. Hearing your own voice late disrupts the feedback loop speech production relies on. The disruption is strongest around 150 to 200ms (where it is severe enough that it has been used as an experimental technique) and it is measurable well below that. For anyone speaking or performing on a headphone feed, the useful threshold is roughly 10ms round trip; above about 20ms most people notice something is wrong even if they cannot name it.

Where the milliseconds come from

Buffer size is the dominant term. Audio is processed in blocks, and the computer needs a block’s worth of samples before it can do anything.

buffer latency = buffer size / sample rate

• 128 samples at 48kHz = 2.7ms
• 256 samples at 48kHz = 5.3ms
• 512 samples at 48kHz = 10.7ms
• 1024 samples at 48kHz = 21.3ms

That figure is incurred on the way in and on the way out, so round-trip is roughly double. Add converter latency (the anti-aliasing and reconstruction filters, typically 1 to 2ms combined) and any plugin that looks ahead.

Note the useful consequence: at 96kHz, the same 256-sample buffer is 2.7ms instead of 5.3. This is the genuine low-latency argument for higher sample rates from the previous lesson.

The trade you are making

A smaller buffer gives lower latency and leaves the CPU less time to finish each block. Miss the deadline and you get a buffer underrun: a click, a pop, or a dropout. There is no way around the trade; it is the same CPU either way.

The working practice everyone converges on:

• Small buffer (128 or 256) while recording, with as few plugins as possible.
• Large buffer (1024 or more) while mixing, where latency does not matter and you want the processing power.

Most recording software has a one-click switch between the two.

Direct monitoring, which removes the problem entirely

Most audio interfaces can send the input signal straight to the headphone output in hardware, without it passing through the computer. Latency is then microseconds: effectively zero.

This is the correct arrangement for recording a voice. The speaker hears themselves instantly through the hardware path; the computer records in parallel and its latency is irrelevant because nobody is listening to its output.

The limitation is that you hear the raw signal, without any processing. For voiceover that is fine and usually preferable. For a singer who wants reverb to perform against, you need either an interface with built-in effects on the monitor path or a low enough buffer to monitor through the computer.

Bluetooth is not a monitoring option

Bluetooth audio latency is typically 100 to 300ms depending on the codec, and the protocol is not designed to be low. Even the low-latency codecs land in the 40 to 80ms range.

This makes Bluetooth headphones unusable for recording, for monitoring, and for editing to picture: lip sync will look wrong and you will “fix” it into being wrong. Wired headphones for anything you are making; Bluetooth for listening to things other people made.

Some playback software compensates by delaying the video to match, which works for playback and not for recording.

Latency inside the session

Plugins introduce their own delay. A linear-phase EQ, a look-ahead limiter or a convolution reverb may need dozens of milliseconds. Every modern host applies plugin delay compensation, delaying every other track to match the slowest, so the mix stays aligned.

Two things to know. It only works for plugins that report their latency honestly, and a few do not: the symptom is one track sounding slightly loose against the rest. And compensation cannot help live monitoring: if you are listening through a look-ahead limiter, that delay is real and unavoidable, which is another argument for direct monitoring while recording.

The monitoring path matters more than the numbers

Two practical points that are worth more than any buffer setting.

Closed-back headphones for recording. Open-back headphones leak, and the leak is picked up by the microphone. It will not be loud, but it produces a faint echo of the programme under the voice that is impossible to remove.

Someone must listen on headphones during the recording. Not watch the meters: listen. A meter shows level and says nothing about a cable crackle, a rustling sleeve, a phone buzzing on a desk, or a microphone that has drifted off axis. On a shoot this is a person’s job for a reason; on a one-person setup, wearing the headphones is the substitute.

The free path

Audacity, Ardour and Reaper all expose buffer size directly. On Linux, JACK and PipeWire handle low-latency routing well and let you set the period size explicitly. On macOS, Core Audio is low-latency by default. On Windows, ASIO4ALL is free and is often the difference between a usable and an unusable interface, since the default Windows driver path adds substantial latency.

Measure what you actually have rather than trusting a display: play a click out, loop the output back into an input with a cable, record it, and measure the gap in samples. Most hosts have a built-in routine that does exactly this.

The limitation

Latency cannot be reduced to zero through a computer. Block processing is how digital audio works, and the converters have filters with real group delay. Direct monitoring sidesteps it rather than solving it.

And reported latency is often wrong. Interfaces report a figure to the host that may omit the converter delay, and a host’s displayed round-trip number can be several milliseconds optimistic. If a musician says it feels late while the software claims 6ms, believe the musician: the loopback measurement is the only number that is not a claim.