{"course":{"slug":"motion-and-audio","title":"Motion, Sound and Music","url":"https://addaly.com/learn/motion-and-audio","level":"intermediate","track":"create"},"lesson":{"slug":"latency-and-monitoring","title":"Latency, and why a speaker starts stumbling","url":"https://addaly.com/learn/motion-and-audio/latency-and-monitoring","position":53,"of":72,"minutes":9,"answer":"Buffer latency is buffer size divided by sample rate and is paid both ways.","keyIdea":"Buffer latency is buffer size divided by sample rate and is paid both ways, so a 512-sample buffer at 48kHz is over 20ms round trip (past the point where hearing your own voice late disrupts speech) and direct monitoring in hardware sidesteps the whole chain."},"body":{"format":"markdown","text":"## Why a speaker starts stumbling over their words\n\nPut 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.\n\nThis 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.\n\n## Where the milliseconds come from\n\n**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.\n\n```\nbuffer latency = buffer size / sample rate\n```\n\n- 128 samples at 48kHz = 2.7ms\n- 256 samples at 48kHz = 5.3ms\n- 512 samples at 48kHz = 10.7ms\n- 1024 samples at 48kHz = 21.3ms\n\nThat 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.\n\nNote 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.\n\n## The trade you are making\n\nA 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.\n\nThe working practice everyone converges on:\n\n- **Small buffer (128 or 256) while recording**, with as few plugins as possible.\n- **Large buffer (1024 or more) while mixing**, where latency does not matter and you want the processing power.\n\nMost recording software has a one-click switch between the two.\n\n## Direct monitoring, which removes the problem entirely\n\nMost 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.\n\nThis 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.\n\nThe 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.\n\n## Bluetooth is not a monitoring option\n\nBluetooth 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.\n\nThis 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.\n\nSome playback software compensates by delaying the video to match, which works for playback and not for recording.\n\n## Latency inside the session\n\nPlugins 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.\n\nTwo 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.\n\n## The monitoring path matters more than the numbers\n\nTwo practical points that are worth more than any buffer setting.\n\n**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.\n\n**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.\n\n## The free path\n\n**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.\n\nMeasure 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.\n\n## The limitation\n\nLatency 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.\n\nAnd 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."},"check":{"question":"A voiceover artist monitoring through the computer keeps hesitating. The engineer halves the buffer from 512 to 256 samples and the session starts producing clicks. What is the better fix?","options":[{"text":"Raise the sample rate to 96kHz, which halves the latency at any given buffer size and gives the CPU the same time per block.","correct":false,"tempting":"Halving the block's duration also halves the time available to process it, so the dropouts return."},{"text":"Switch to direct hardware monitoring, so the artist hears the input before it reaches the computer and the buffer can be set for stability instead.","correct":true},{"text":"Enable plugin delay compensation, which aligns the monitored signal with the recorded one and removes the perceived delay.","correct":false,"tempting":"Compensation aligns tracks in the recorded timeline; it cannot make a live monitor path arrive earlier."},{"text":"Move the monitoring chain to a lighter set of plugins and raise the buffer back to 512, accepting the 21ms round trip on the grounds that it is well below the 150 to 200ms range where delayed auditory feedback has its strongest disruptive effect on speech production.","correct":false,"tempting":"Cites the range of maximal disruption as though it were the threshold; speakers notice and stumble well below it."}]},"prev":{"slug":"phase-and-two-microphones","title":"Two microphones and a comb filter","url":"https://addaly.com/learn/motion-and-audio/phase-and-two-microphones"},"next":{"slug":"double-system-and-sync","title":"Two devices, one event","url":"https://addaly.com/learn/motion-and-audio/double-system-and-sync"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Latency, and why a speaker starts stumbling', in Motion, Sound and Music. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/motion-and-audio/latency-and-monitoring (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Latency, and why a speaker starts stumbling","courseTitle":"Motion, Sound and Music","module":{"index":6,"slug":"capturing-sound","title":"Capturing sound"},"answer":null,"keyIdea":"Buffer latency is buffer size divided by sample rate and is paid both ways, so a 512-sample buffer at 48kHz is over 20ms round trip (past the point where hearing your own voice late disrupts speech) and direct monitoring in hardware sidesteps the whole chain.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"why-a-speaker-starts-stumbling-over-their-words","runs":[{"text":"Why a speaker starts stumbling over their words"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"This is "},{"text":"delayed auditory feedback","b":true},{"text":", 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 "},{"text":"10ms round trip","b":true},{"text":"; above about 20ms most people notice something is wrong even if they cannot name it."}]},{"t":"h2","id":"where-the-milliseconds-come-from","runs":[{"text":"Where the milliseconds come from"}]},{"t":"p","runs":[{"text":"Buffer size","b":true},{"text":" is the dominant term. Audio is processed in blocks, and the computer needs a block’s worth of samples before it can do anything."}]},{"t":"code","lang":"","label":"Text","text":"buffer latency = buffer size / sample rate"},{"t":"ul","items":[[{"text":"128 samples at 48kHz = 2.7ms"}],[{"text":"256 samples at 48kHz = 5.3ms"}],[{"text":"512 samples at 48kHz = 10.7ms"}],[{"text":"1024 samples at 48kHz = 21.3ms"}]]},{"t":"p","runs":[{"text":"That figure is incurred on the way in "},{"text":"and","i":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-trade-you-are-making","runs":[{"text":"The trade you are making"}]},{"t":"p","runs":[{"text":"A smaller buffer gives lower latency and leaves the CPU less time to finish each block. Miss the deadline and you get a "},{"text":"buffer underrun","b":true},{"text":": a click, a pop, or a dropout. There is no way around the trade; it is the same CPU either way."}]},{"t":"p","runs":[{"text":"The working practice everyone converges on:"}]},{"t":"ul","items":[[{"text":"Small buffer (128 or 256) while recording","b":true},{"text":", with as few plugins as possible."}],[{"text":"Large buffer (1024 or more) while mixing","b":true},{"text":", where latency does not matter and you want the processing power."}]]},{"t":"p","runs":[{"text":"Most recording software has a one-click switch between the two."}]},{"t":"h2","id":"direct-monitoring-which-removes-the-problem-entirely","runs":[{"text":"Direct monitoring, which removes the problem entirely"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"bluetooth-is-not-a-monitoring-option","runs":[{"text":"Bluetooth is not a monitoring option"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"Some playback software compensates by delaying the video to match, which works for playback and not for recording."}]},{"t":"h2","id":"latency-inside-the-session","runs":[{"text":"Latency inside the session"}]},{"t":"p","runs":[{"text":"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 "},{"text":"plugin delay compensation","b":true},{"text":", delaying every other track to match the slowest, so the mix stays aligned."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-monitoring-path-matters-more-than-the-numbers","runs":[{"text":"The monitoring path matters more than the numbers"}]},{"t":"p","runs":[{"text":"Two practical points that are worth more than any buffer setting."}]},{"t":"p","runs":[{"text":"Closed-back headphones for recording.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Someone must listen on headphones during the recording.","b":true},{"text":" 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."}]},{"t":"h2","id":"the-free-path","runs":[{"text":"The free path"}],"role":"free"},{"t":"p","runs":[{"text":"Audacity","b":true},{"text":", "},{"text":"Ardour","b":true},{"text":" and "},{"text":"Reaper","b":true},{"text":" all expose buffer size directly. On Linux, "},{"text":"JACK","b":true},{"text":" and "},{"text":"PipeWire","b":true},{"text":" handle low-latency routing well and let you set the period size explicitly. On macOS, Core Audio is low-latency by default. On Windows, "},{"text":"ASIO4ALL","b":true},{"text":" is free and is often the difference between a usable and an unusable interface, since the default Windows driver path adds substantial latency."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-limitation","runs":[{"text":"The limitation"}],"role":"limit"},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A voiceover artist monitoring through the computer keeps hesitating. The engineer halves the buffer from 512 to 256 samples and the session starts producing clicks. What is the better fix?"}],"options":[{"text":[{"text":"Raise the sample rate to 96kHz, which halves the latency at any given buffer size and gives the CPU the same time per block."}],"correct":false,"tempting":[{"text":"Halving the block’s duration also halves the time available to process it, so the dropouts return."}]},{"text":[{"text":"Switch to direct hardware monitoring, so the artist hears the input before it reaches the computer and the buffer can be set for stability instead."}],"correct":true,"tempting":null},{"text":[{"text":"Enable plugin delay compensation, which aligns the monitored signal with the recorded one and removes the perceived delay."}],"correct":false,"tempting":[{"text":"Compensation aligns tracks in the recorded timeline; it cannot make a live monitor path arrive earlier."}]},{"text":[{"text":"Move the monitoring chain to a lighter set of plugins and raise the buffer back to 512, accepting the 21ms round trip on the grounds that it is well below the 150 to 200ms range where delayed auditory feedback has its strongest disruptive effect on speech production."}],"correct":false,"tempting":[{"text":"Cites the range of maximal disruption as though it were the threshold; speakers notice and stumble well below it."}]}],"order":[2,1,0,3],"why":null},"prev":{"slug":"phase-and-two-microphones","title":"Two microphones and a comb filter","minutes":10},"next":{"slug":"double-system-and-sync","title":"Two devices, one event","minutes":10}}}