Zero Latency Limiter plugin?

VST, AU, AAX, CLAP, etc. Plugin Virtual Effects Discussion
RELATED
PRODUCTS

Post

simon.a.billington wrote: Mon Feb 09, 2026 3:46 am What 0 latency actually means is it can do all the necessary calculations within the time allocated by the buffer, 64 samples, going by the above example. So its note truly 0 latency, it just doesn't add anything extra on top of the buffer.
You can implement it like this, but it doesn't lead to optimal results:
the first sample in the buffer would be calculated based on no previous sample information, the second sample would be calculated with one previous sample information, the third sample would be calculated with two previous sample information. And so forth. This would create uneven and unnecessary distortion depending on the buffer size.
Therefore, a consistent look-ahead (even if very small) is preferable.
Last edited by TB-ProAudio on Tue Feb 17, 2026 2:13 pm, edited 1 time in total.

Post

TB-ProAudio wrote: Tue Feb 10, 2026 7:28 am
simon.a.billington wrote: Mon Feb 09, 2026 3:46 am What 0 latency actually means is it can do all the necessary calculations within the time allocated by the buffer, 64 samples, going by the above example. So its note truly 0 latency, it just doesn't add anything extra on top of the buffer.
You can implement it like this, but it doesn't lead to optimal results:
the first sample in the buffer would be calculated based on no previous sample information, the second sample would be calculated with two previous sample information, the third sample would be calculated with three previous sample information. And so forth. This would create uneven and unnecessary distortion depending on the buffer size.
Therefore, a consistent look-ahead (even if very small) is preferable.
Yes that is ultimately why most limiters cause additional latency. So they can make calculations in context of the rest of the audio. Which is why zero latency means poorer quality.

Post

mystran wrote: Mon Feb 09, 2026 10:54 am
simon.a.billington wrote: Mon Feb 09, 2026 3:46 am What 0 latency actually means is it can do all the necessary calculations within the time allocated by the buffer, 64 samples, going by the above example.
This statement is wrong.

Latency itself is just "unwanted delay" but I think you're confusing two different sources of latency here.

Buffer latency happens because while the DAW is processing one block, the ADC is collecting samples to the next block and the DAC is converting the previous block to analog. It's a pipeline of three blocks, so there is a minimum delay of two blocks for the signal to propagate from the ADC to the DAC. In practice, this is optimistic because there's likely more delays, but that's the minimum.

Plugin processing latency is different though. The DAW does not wait for a full block for plugins to do their processing. It hands the plugin the current block and it expects to also get the results during the current block. So plugin processing does not intrinsically add any "buffer latency" the same way as the whole blockwise ADC/DAC procedure does.

The common case of plugin "processing latency" (as opposed to the buffer latencies) is because a plugin is doing processing that isn't causal without additional delay. For example, if we want to use a 32 sample (which is perhaps close to the minimum you can get away with) linear-phase oversampling filter, then the "zero-phase" point of such a filter is at 16 samples and we are effectively adding 16 samples of "unwanted delay" (ie. latency) to the signal. In a properly written plugin, this will be the same 16 samples whatever the blocksize.

Now, the whole idea of "zero latency" plugins sounds great, but in practice it's not always a worthy goal, because we're going to have some latency due to the buffer latencies anyway, so "zero latency" isn't going to get our inputs and outputs into perfect time-alignment in any case and what we should be worried about is the overall total latency (since latency adds up): is it high enough to become an issue?

If we're running 64 samples blocks and we assume we'll get about 3 blocks worth of round trip latency (more realistic than the theoretical minimum of 2) then we're at about 192 samples which is about 4ms at 44.1kHz which is about the time it takes for sound in air to propagate 1.4 meters. If we were to add 16 of plugin procesing latency on top of that, it would be equivalent to adding about 12cm to the distance from the speakers to the ears of the listener (ie. about 1.5 meters now, on top of the actual physical distance, assuming you're not using headphones).

Because latencies add up, if we run the signal through say 10 plugins all of which add that 12cm of latency to the signal, now we've added a full meter and at some point as we keep doing this it'll start to become difficult to play in sync, but it's not a binary thing where you either have zero latency or you don't because zero latency in terms of the entire chain just isn't a thing unless you go all analog.

So look at the actual numbers. A plugin adding a couple of samples for linear-phase oversampling is entirely different from another plugin that adds 10ms (=3.4 meters in terms of sound propagation) for lookahead.

ps. I actually feel like thinking about the distances of sound propagation is probably more helpful than staring at the sample values or the millisecond values, because it gives you direct real world perspective on exactly what is going on.
Actually, I think you more misunderstood what I was saying. I was essentially saying that there will always be a latency anyway. This is dictated by the IO Buffer size which directly relates to a subsection of time depending heavily on your project's sample rate.

So at the barest minimum there is still always a small audio latency/delay. It can never be instant.

Post

simon.a.billington wrote: Tue Feb 17, 2026 9:17 am Actually, I think you more misunderstood what I was saying. I was essentially saying that there will always be a latency anyway. This is dictated by the IO Buffer size which directly relates to a subsection of time depending heavily on your project's sample rate.

So at the barest minimum there is still always a small audio latency/delay. It can never be instant.
Yes, but latencies (=delays) also add up. A plugin does not get anything "for free" simply because you're using a certain blocksize. If a plugin wants to look one sample "into the future" then it needs to add one sample of latency, but the minimum latency that a plugin can have is still zero.

Post

We need a quantum limiter maybe.

Post

"Our new quantum limiter has zero latency and zero distortion."
"How is that possible?"
"We don't apply any gain reduction until someone complains about the mix."

Post

mystran wrote: Tue Feb 17, 2026 3:29 pm
simon.a.billington wrote: Tue Feb 17, 2026 9:17 am Actually, I think you more misunderstood what I was saying. I was essentially saying that there will always be a latency anyway. This is dictated by the IO Buffer size which directly relates to a subsection of time depending heavily on your project's sample rate.

So at the barest minimum there is still always a small audio latency/delay. It can never be instant.
Yes, but latencies (=delays) also add up. A plugin does not get anything "for free" simply because you're using a certain blocksize. If a plugin wants to look one sample "into the future" then it needs to add one sample of latency, but the minimum latency that a plugin can have is still zero.
There are plugins that, for all intents and purposes, say they have 0 latency. The only way they could claim that really is if the processing was done in the time and information afforded by the buffer block.

Granted, there plugins that do need more data/time than what the block is offering so they will incur extra latency on top. That's what is usually mentioned by plugin devs, that additional latency.

It is also the kind of thing you'd expect to see in a limiter as it is basically impossible to design anything decent without having a look at the incoming data ahead of time so it can make better decisions/transfomation.

Post

pekbro wrote: Tue Feb 17, 2026 6:56 pm We need a quantum limiter maybe.
Morphulus wrote: Thu Feb 19, 2026 5:50 pm "Our new quantum limiter has zero latency and zero distortion."
"How is that possible?"
"We don't apply any gain reduction until someone complains about the mix."
I figured one day with quantum computing made accessible for everyone this kind of thing would be possible. But it won't be for at least another 10 years I reckon, even then, they'd be bloody expensive for quite some time.

Post

Quantum Cortex.
ABX is enemy to GAS

Post

One of the DDMF limiters might be 0 latency
Intel Core2 Quad CPU + 4 GIG RAM

Post Reply

Return to “Effects”