C14 - Plugins (still) better performance via AudioGridder

I am generally very satisfied with C14 upgrade from C13. However I still do not understand why audio performance of plugins is much better when using AudioGridder (local) than when using them direct on channel. See attached - I tested two plugins (SSL Native Bus Compressor and Ozone 9) on the same mix bus channel, on the same part of music. See attached - on the left performance using AudioGridder and on the left performance with plugins direct on channel without AG. The difference is significant. Why? Why 3rd party tool can improve the performance and Steinberg itself cannot?
I don’t say I am disappointed with C14 performance - opposite - I am very satisfied, it is much better than C13 - but still - that makes me wonder.

1 Like

It would be really weird if performance wasn’t ‘better’ within Cubase while using Audiogridder.
You’re taking a piece of Cubase workload and offloading it to another process (Audiogridder), which will then be dispatched on other cores. As a result, the Cubase meters will show an improvement within the Cubase process (because the workload just reduced), but if you look at your overall CPU consumption using Task Manager (or equivalent), you’ll see about the same load with Audiogridder vs. without.
You’re just moving workloads around, basically.
This logic, by the way, will apply to any DAW that Audiogridder works with.

1 Like

That’s not how DAW performance meters work. The “workload” is computed as the percentage of the time slice required to perform the processing task. Whether that processing happens within Cubase or in another process is irrelevant to the performance meter.

It’s a bit of a mystery why some people have reported that performance improves with audiogridder. It might be due to a different policy regarding cpu core scheduling. Or perhaps a different buffer size policy.

Well, given that I’ve seen the Cubase meter response to offloading workload myself (it’s pretty obvious with a heavy plugin), I suspect there’s more to it than that.

Got you point. In my case not the CPU consumption is the problem (which by the way is rather low) , but too high average Asio guard load - that is why I use AG to reduce it. Just wondering why Cubase cannot implement their own tool to redistribute the load to other cores, as you wrote, to reduce the ASIO guard load a which would be more convieniet that using 3rd party plugin.

Cubase, like all DAWs these days, distributes the load to as many cores as possible. However, with hybrid architectures, efficient distribution can be complicated.

You haven’t provided enough information to permit an analysis of what is happening in your case, but other people have reported audiogridder helps avoid cpu overload dropouts. However, AFAIK, nobody has done an investigation to explain why audiogridder improves performance in those cases.

1 Like

It gets even weirder. I tried to use AudioGridder on my laptop (server) while networked with my desktop (as client). My laptop has a Ryzen 4570U (8 cores, no HT), my desktop has an i9 10900 (10 cores, faster cores, no P-E, previous all equals architecture, HT). Now, if I launch some heavy plugins on my desktop they sometimes overload (note that most cores are not overloaded at all watching the Task Manager!). If I launch the same plugins on my laptop alone, it just can’t handle the load and overloads. But, if I share the load to the laptop, it flies! I mean, from continuous dropouts, to 10% load and flawless! Same machine, same plugins, just the DAW on the desktop. This is absolutely nonsense!
Something is wrong in multi-core optimization, here…
In the end I bought an additional mini-PC to use exclusively with AudioGridder, as a DIY sort-of DSP box!

2 Likes