Zero Latency Limiter plugin?

[pchase]

Maybe I don’t understand clearly enough, but turning off lookahead to reduce latency (all the way down to 0 ms) means your limiter will miss incoming peaks above the threshold. Unless you have a limiter that allows you to set the attack to instant. Which, at that point, you’ve turned your limiter into a hard clipper, and you get wave shaping distortion. Tell me how I’m wrong.

It could be acting similar to a hard clipper, but only for the few samples where the peak first hits -0dB. After that it'd act like a limiter. So the distortion would be very short. It's a compromise.

[dblock]

I have Smart Limit and don't remember any problem using it in real time.

[@l3x!5]

X limit from SSL is zero latency and very good

Don't know about earlier versions, but SSL X-Limit v1.2.2 reports 46 samples of latency at 48 kHz on Cubase Pro 15.

My bad, for some reason that's what it shows in the plug-in manager, while it is indeed zero latency on track when TP and look-ahead are disabled.

Bumping the edit since it's still on sale at the time of writing and it is a valid choice for non committing operations -- VSTi playing, perusing samples etc. Imagine you were launching Stylus! Peak PTSD! Lol.

Not yet mentioned alternatives that will do the job with a little more safety at the cost of a few samples:

• Waves L4 (no OS, no TP, 'Aggressive' mode) = 34 samples @48 kHz
• Cubase Brickwall Limiter (default) = 48 samples @48kHz

[oobesan]

Maybe I don’t understand clearly enough, but turning off lookahead to reduce latency (all the way down to 0 ms) means your limiter will miss incoming peaks above the threshold. Unless you have a limiter that allows you to set the attack to instant. Which, at that point, you’ve turned your limiter into a hard clipper, and you get wave shaping distortion. Tell me how I’m wrong.

It could be acting similar to a hard clipper, but only for the few samples where the peak first hits -0dB. After that it'd act like a limiter. So the distortion would be very short. It's a compromise.

No, I don't think so. First of all, a limiter is just a compressor with a lookahead function and infinite ratio. If it isn't using lookahead, it isn't limiting. A compressor waits until the threshold is reached before it starts compressing (per its compression curve, the attack setting, and the selected ratio). With a compressor, your audio signal will always go above the threshold, because it doesn't even start to do anything until the threshold is reached. A limiter, on the other hand, starts compressing BEFORE the threshold is reached. A limiter uses lookahead to determine when an audio signal is going to breach the threshold, and calculates when to start applying a compression curve to the signal so that it rounds off the peak exactly at the threshold. This is why a limiter is a brick wall. A "limiter" with zero latency = no lookahead = samples going above the threshold = not limiting. If a limiter doesn't start applying gain reduction until after the threshold is breached, and then it immediately brick walls it back to the threshold, that is just delayed clipping. You wouldn't be brick walling anything, and you would get clipping distortion. This is the worst of both worlds. So, just use a soft or hard clipper.

[vitocorleone123]

Im using Blue Cat Protector and set it to .1 ms latency instead of 0.

[pchase]

If a limiter doesn't start applying gain reduction until after the threshold is breached, and then it immediately brick walls it back to the threshold, that is just delayed clipping. You wouldn't be brick walling anything, and you would get clipping distortion. This is the worst of both worlds. So, just use a soft or hard clipper.

How is it equivalent to using a clipper? It'd sound nothing like it. A clipper doesn't have release. If you had a signal that was slience, followed by a minute of loud music that was entirely above the threshold, a clipper would distort continously and totally change the sound of the whole song. A limiter, even with zero latency and no lookahead, would distort similarly. But only for a period of time on the order of ~1 sample, after which depending on the behaviour of the release, the whole shape of the song including all dynamics could be perfectly preserved.

So how are they comparable at all?

Try using fircomp2 in limiter mode with no lookahead. It quite obviously sounds nothing like a clipper and everything like a limiter.

[oobesan]

If a limiter doesn't start applying gain reduction until after the threshold is breached, and then it immediately brick walls it back to the threshold, that is just delayed clipping. You wouldn't be brick walling anything, and you would get clipping distortion. This is the worst of both worlds. So, just use a soft or hard clipper.

How is it equivalent to using a clipper? It'd sound nothing like it. A clipper doesn't have release. If you had a signal that was slience, followed by a minute of loud music that was entirely above the threshold, a clipper would distort continously and totally change the sound of the whole song. A limiter, even with zero latency and no lookahead, would distort similarly. But only for a period of time on the order of ~1 sample, after which depending on the behaviour of the release, the whole shape of the song including all dynamics could be perfectly preserved.

So how are they comparable at all?

Try using fircomp2 in limiter mode with no lookahead. It quite obviously sounds nothing like a clipper and everything like a limiter.

Yes the release phase would look weird, because it would apply the mirror image of the compression curve to gain reduction after the audio signal goes below then threshold. But while the signal is above the threshold, the signal will be clipped to the threshold, hence clipping distortion. This is why TBproAudio, who makes limiters and compressor plugins, wrote early in this thread that a limiter with no lookahead is a clipper.

[mystran]

How is it equivalent to using a clipper? It'd sound nothing like it. A clipper doesn't have release.

You're correct and anyone can convince themselves that a clipper and a zero-attack brickwall limiter with finite non-zero release time are quite different, simply by working out the resulting distortion spectrum.

I suggest starting from the "single peak over" case as that one's quite trackable mathematically, which is not necessarily the case in more complex situations (roughly the same principle applies, except the limiter gains some additional advantages due to not always having to act as strongly on every peak separately).

If we think of these as time-domain products of signal and sidechain gain curve, then in a clipper the gain curve is a bunch of impulses. If we add release, that is effectively a low-pass (in the infinite release case we have a step that's 6dB/octave spectral decay relative to an impulse, but as we make the release finite and faster, this moves the "cutoff" higher up) but the low-frequency response is also higher.

Once we convolve the spectra (which what multiplying the two together does), we'll observe that the flat spectrums from the clippers impulsive action generates broadband distortion products pretty much across the entire spectrum, where as with a longer release we get stronger sidebands up close, but then the distortion products decay faster as we move further away from the frequencies being distorted. Once we've mathematically worked things this far, we should be quite convinced that the two things are distinct (ie. a limiter is not a clipper even if you set zero attack and brickwall response without lookahead), even without listening to how they sound.

For what it's worth, I'd also call a "limiter" a combined design where there's a sloppy limiter (perhaps with a longer attack, so that it doesn't apply full gain reduction) together with a clipper to clean up any remaining overs. In fact this type of limiter is sometimes my favorite for a master bus as it can be a sort of "best of both worlds" if most of the overs are at noisy transients (so clipping gets mostly masked) and a straight limiter pumps too much.

As far as lookahead, it seems great the first you try it, but then as you start to listen more critically you'll eventually notice that it's not without downsides: where intentionally causing a bit of distortion by using clipping as a "last resort" for things like drum transients can actually enhance those transients, too much lookahead tends to do the opposite and smear them losing impact. A little bit of lookahead is nice, so that you can start thinking about about things like true peaks or whatever, but what we see is that older limiters tended to have lookahead in the maybe 10ms range, but then many modern designs actually have much less than this and it's not due to some crazy advance in mathematics that allows us to break physics, but rather because too much lookahead just doesn't sound good once you start to notice the problems it creates.

[Kai Enaki]

How is it equivalent to using a clipper? It'd sound nothing like it. A clipper doesn't have release.

For what it's worth, I'd also call a "limiter" a combined design where there's a sloppy limiter (perhaps with a longer attack, so that it doesn't apply full gain reduction) together with a clipper to clean up any remaining overs. In fact this type of limiter is sometimes my favorite for a master bus as it can be a sort of "best of both worlds" if most of the overs are at noisy transients (so clipping gets mostly masked) and a straight limiter pumps too much.

I don't use Flatline 2 for the clipper/limiter hybrid, but it's nice to have the feature available so I can test and decide if I should proceed with building my own clipper/limiter stack.

[strovoknights]

Boz The Wall 1 has a latency of 0.7 ms. With the upgrade to The Wall 2, the plugin has become more convenient to use, but the 0.7 ms latency is now available only in the Aggressive mode. In Smooth mode, the latency is 1.5 ms.

[simon.a.billington]

X limit from SSL is zero latency and very good

Don't know about earlier versions, but SSL X-Limit v1.2.2 reports 46 samples of latency at 48 kHz on Cubase Pro 15.

My bad, for some reason that's what it shows in the plug-in manager, while it is indeed zero latency on track when TP and look-ahead are disabled.

Bumping the edit since it's still on sale at the time of writing and it is a valid choice for non committing operations -- VSTi playing, perusing samples etc. Imagine you were launching Stylus! Peak PTSD! Lol.

Not yet mentioned alternatives that will do the job with a little more safety at the cost of a few samples:

• Waves L4 (no OS, no TP, 'Aggressive' mode) = 34 samples @48 kHz
• Cubase Brickwall Limiter (default) = 48 samples @48kHz

Interestingly, at twice the sample rate (96k),while the sample count generally stays the same, the time to process them as halved.

So, while the buffer time for L4 is 1.4ms (34 samples), for example, at a sample rate of 96k it becomes 0.7ms. But your computer is generally working twice as hard to achieve the necessary calculations in half the time.

This is not an option for everyone, but if latency was the primary concern it might be worth considering.

[osiris]

I don't think there will ever be a 0 latency limiter because they all have to do look ahead, otherwise they can't do their job.

[pekbro]

McDSP ML8000 measures at 0 latency, input, output and process...

The same DAW reports 64 samples, process and output for Boz's the wall 2 for example.

[simon.a.billington]

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.

It's possible for limiters to work within this time constraint, but not the type that either lookahead or oversample. So you could argue that they're not as good quality, but you don't always need them to be. Sometimes practicality is more important, at other times a "grungier" quality is also appreciated within the give context.

[mystran]

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.