Please reduce plugin latency. If possible, optimize the algorithm to lower it—really needed.
Older plugins introduce too much latency to be usable in today’s workflows.
I don’t disagree, but it seems like most of the latency introduced by plugins are necessities of the algorithm (as in, it needs to collect enough audio to process before it can start outputting it), rather than because of poor development? If you want an EQ that does zero latency EQ, then use F6 and accept that you won’t get the saturation or dynamic effects of the analogue emulations.
Or maybe you just mean the CPU usage, in which case I 100% agree that this is a very good use of developer time. The recent updates have been great for me here, my LV1C is down to about 40% usage from 80%ish. But don’t stop working on it!
2 Likes
hoon8247, it would be helpful if you note which plugins you have latency issues with. As steve.dower pointed out, it’s not always possible to do something about.
Waves is usually “very good but not not always perfect” about this issue.
For the ‘good’, you’ll notice they have “live” versions of some of their products. One of my favorites is AR TG Mastering Chain. I use the “live” version because it’s zero latency! (I’m grateful for this.) It’s all I ever use, because the full version has ~8000 samples of PDC latency.
Many Waves plugins are “low-latency for how good they sound” … An example would be Kramer Master Tape, which requires 64 samples of PDC latency @ 48khz. That’s pretty low for a tape emulation plugin and it sounds amazing.
SSL EV2 is another. It has 59 samples of PDC latency @ 48khz. It sounds amazing, but if that latency comes from oversampling (which I think it does, based on my Plugin Doctor tests) – it would be nice to be able to turn off oversampling for reduced latency.
For this reason I use SSL 4K G instead, which runs at zero-latency when oversampling is turned off.
Scheps Omni Channel is actually my favorite channel strip, though, and it does run at zero latency! (If they can pull that off with S.O.C., I wish they’d offer that option for SSL EV2 & CLA Mixhub.)
H-Comp is another that requires some latency - perhaps due to the integrated limiter? But again, an option to turn that off would be appreciated.
At the heart of the matter is the belief that many developers have that “low latency is okay.” But the problem comes when you use it in series. A few plugins with 64 samples of latency on tracks, submixes, and master bus adds up to 576 samples of latency – and that’s enough to impact your playing.
Problem is, many electronic and independent artists sort of mix as they compose, so zero-latency plugins are critical for that.
There’s a sign that Waves is listening, though – notice Magma BB Tubes has adjustable oversampling, and it is indeed zero-latency when turned off! They also issued “live” versions of both Silk EQ and Curves Equator if I’m not mistaken… Waves AQ as well. So by no means are we ignored on this issue.
I suspect one day we’ll get a Waves version update where they add adjustable oversampling to most of their plugins as a feature, like it is in Magma BB Tubes. That would be awesome.
But Magma Tube Channel Strip doesn’t have the setting!! And being a channel strip, I could really use the zero latency for that.
Oversampling is great, I just need to be able to turn it off while composing.
PS. Some devs offer automatic oversampling when rendering. Not all DAWs support it, but that’s a cool feature, too.
PS #2. Kramer Pie is another really good compressor which is zero-latency…
PS #3. Waves has a helpful chart with all their products and how much latency they require: https://www.waves.com/support/tech-specs/plugin-latency
I’m not really talking about plugin latency in a studio context where you can just compensate for it later or live with a bit of delay. I’m talking about real live sound situations — especially monitor console work where everything has to feel immediate and natural.
In that environment, latency isn’t just a technical number anymore — it becomes a real operational limitation. There are plenty of times where I simply can’t use certain plugins I would otherwise want to use, not because they don’t sound good, but because the added latency makes them unusable for real-time monitoring.
Anyone who has spent time on monitors knows this — singers and players can be way more sensitive to latency than people expect. Some of them will pick up on even a small delay in their IEM mix, and once they do, it affects their timing, their confidence, and ultimately the performance.
At that point, it’s not about “sound quality vs CPU” anymore — it’s about whether the system disappears enough for the artist to forget it’s even there.
2 Likes
There are some functions that are capable or working with super low latency, such as amplitude/dynamic based processing, while others require a slice of “data over time” to make the necessary calculations.
Anything that works with frequencies for example, because that’s about cycles over time. But then there are processes that utilise a lookahead, or oversampling and even AI. All that requires “data over time” so that it’s able to perform the required calculations.
So asides from choosing plugins that avoid much of the above, or at least, least you deactivate those options, you can also reduce your IO Buffer Size and increase the sample rate of your session. That will indeed have a big impact on latency. Though, nothing comes for free because doing that will require more CPU power to keep up with the smaller buffer sizes and the faster rate of the incoming data.
Yeah, I also spend as much time doing live as post, including monitors, so I put a lot of effort into getting the latency down for monitors. That means I’m also familiar with how Waves’s latencies are, and overall, they’re pretty good (at least on the LV1C). My main request would be a warning before adding a plugin that’s going to affect latency compensation, so I can do it at a quiet moment and avoid the brief pause in all audio.
I wouldn’t say no to lower latencies here and there (PuigTech EQs and SSL EV2 as mentioned come to mind), but it’s certainly not bad enough for a two line “just do it” feature request. A specific list of “can we have ‘Live’ versions of X, Y, Z” or “can we disable oversampling on X, Y, Z” would be more likely to achieve something.
I’ve actually spent a lot of time (probably too much, hah) figuring out which parts of my signal chain can skip latency compensation for the sake of monitors, and double-patching inputs for certain parts (vocal in particular) so that they can get it in their ears more directly. It’s not too difficult to work around the plugins that introduce latency, and if we want to keep aliasing down, there isn’t really much choice.
Thanks, but I could really do without the unsolicited advice.
Actually, there is one thing you could try that might help a little with aliasing, but doesn’t involve oversampling or higher sample rates. That is to use something like a shelf to turn down all the high frequencies prior to certain processes that could potentially generate aliasing. At the end of the process add another shelf turning those frequencies back up again.
It should help a little.
I understand that some processes need to introduce a certain latency.
For the LV1 (Classic):
But please: let us A: filter plugins by latency (for example hide all plugins with more than 2ms of latency).
And B: please let use insert plugins in bypassed mode!
1 Like
When you say “filter” plugins, do you mean in StudioRack?? Because any DAW plugin filters need to be built into the DAWs themselves.
Ah, I meant for the LV1 (Classic) mixing system.
For live mixing latency can be a real problem. So (accidentally) inserting a plug-in with 50ms of latency should be avoided at all costs.
That’s why a: a filter and b: inserting a plug-in in bypass would be crucial.
2 Likes
Yeah it would be really good. And on the plus side Waves do make the software for this. So this is actually something they would potentially the ability to implement.
Whether they do remains to be seen.
1 Like
as I’m also a monitor engineer working with many different systems (like DiGiCo Quantums with Waves, LV1 classic, A&H dLive, Midas HD96, Yamaha Rivage etc.) in general I get the point.
Having that said, Waves isn’t that worse. F.e. using a Yamaha Rivage with their internal “Neve” PlugIns (which aren’t one of my favorite), you get latency numbers way beyond most thing you do in a LV1 classic.
Also: if you switch to 96kHz many Waves plugins (like SSL EV2) have way better latency numbers.
So in conclusion: with a well thought out session on a LV1 I never experienced more latency than on other digital consoles to be honest.
Regards Peter
2 Likes
It does depend on the type of plugin, but running sessions at 96kHz have the potential to roughly half the latency value. But not every type of plugin benefits that way.
… that’s what I said: “if you switch to 96kHz many Waves plugins (like SSL EV2) have way better latency numbers.”
But no: it’s not half the latency. Older PlugIns just use the double buffer in 96kHz which means they have exactly the same latency as in 48kHz not half!
But newer PlugIns (like the mentioned SSL EV2) are optimized for 96k
So SSL EVERY has 59 Samples@48k but only 20 Samples@96k which means 0.208ms at 96kHz, but 1.17ms at 48kHz which is almost times 6!
And for other (newer) PlugIns there are many live versions which may cut down details but therefore have way less latency.
So it is very obvious, that Waves is aware about latency and are constantly working on it.
Actually, that has not been my experience in. Logic. There is a good chance that frequency analysis dependant plugins do, because the require an element of “time” and that is the same irregardless of sample rate. But other plugins such as dynamics ones don’t, they may require a number of “sam pies” but the time, or latency aspect is relevant, because samples are dependent on sample rate. That’s where you are likely to half latency, or thereabouts, just by doubling the sample rate.
If you engage so thing like a lookahead or oversampling then all bets are off though. Something like the SSL channel strip could, in fact, have both, because it’s effectively several processors rolled into one. That’s where it gets complex.
Though, ineffectual, if you want to use it live, turning off the Analog feature would be advised. Leaving elements you aren’t using in Bypass, may also be beneficial as it MAY deactivate any latency compensation the might require.
Here are the official numbers for native system (where your Logic fits in).
Many PlugIn have way better latency number (less than just half of latency) in 96kHz than in 48kHz.
All infos are there, just read. If you experienced something else with Logic, this might more an issue of your Logic settings, as native systems have different points where they introduce latency (and way more than the plugins do), f.e. driver and driver structure.
So again: Locking at that table f.e. Abbey Road Chambers has 101 samples @48kHz, and just 33 samples @96kHz, which means 2.1ms @48kHz vs. 0.34ms @96kHz, that IS NOT JUST HALF!
It’s clearly optimized for 96kHz.
Next Abbey Road TGI 85 samples @48kHz and ZERO @96kHz, which AGAIN is way less than just HALF.
The list goes on and on.
So - “you’re experience” just can’t hold the reality at least if we’re talking Waves PlugIns.
I also measured it with my SuperRack SG and LV1 Classic with Smaart. That’s why I only go 96kHz in live - not because it “sounds” so much better, but for way better latency.
And “turning off any Analog features for live” is excactly what happens, if you use the “live” versions of Waves. That’s why they exist. In critical situation being a fracture more accurate to the real thing may be not so important than having less latency.
Sorry dude - do your homework before posting any false claims.
I think there’s some confusing as we seem to be making the same point.
I only suggested that latency is “roughly” halved at 96kHz in general, simply because of how digital audio works. If Waves manages to reduce the latency even more at 96kHz then that’s even better. At no point did I say that wasn’t the case or it wasn’t possible to achieve.
It still confirms my overarching statement of “running projects at higher sample rates tends to reduce latency”. We were actually on the same page this whole time. Then difference is I was just using a guesstimate.