What is happening? I thought that this infamous problem was solved
TL;DR
DAWBench removes Cubase/Nuendo from all tests soon because “their engine being essentially broken with AG Off , on any system above 6 Cores.”
So I’m testing Cubase 10.0.50 with AMD Ryzen 7 1700 (8/16) on Windows 1909.
Testing conditions: 44.1 kHz, ASIO buffer size 128. With ASIO Guard turned OFF Cubase can load something like 90 copies of SGA1566, with ASIO Guard turned ON it can load 160 copies of SGA1566, resulting in 83% CPU load, but somehow someway this result is the same for 128 and 1024 buffer - new Cubase versions cannot use 100% of CPU’s power for some reason (am I doing something wrong??). I was able to hit 100% CPU usage with Cubase 9.0 and ASIO Guard turned on old Windows 10 in this exact test with SGA1566, but today I can’t reach that number.
Looks like I’m facing the exact problem DAWBench described.
Help, please. I want to use 100% of my CPU power, not like 83%.
So to summarize, if you have more than (>) 6 physical cores and want to use all available threads, the options are:
Keep ASIO Guard on at all times (I suspect most users do this) or
Turn off ASIO Guard and experience a max of 6 cores/12 threads
Is that right?
I agree it’s lame, but most users are going to keep ASIO Guard on all the time. Though, with some of these monster core systems coming out, you’d think there’d be less of a need for ASIO Guard and you’d be able to run at lower latencies with it off. Totally valid workflow IMO.
I don’t know mind using ASIO Guard all the time, furthermore, I always use C10 with 128 buffer settings and ASIO Guard turned, and everything runs pretty smoothly on average projects and even on projects that are a little bit heavier.
My main concern is that I can’t hit 100% CPU load with even higher buffer settings and ASIO Guard turned ON for some reason. I was definitely able to hit 100% CPU with previous combo in DAWBench DSP (Cubase 9.0 Pro, ASIO Guard turned ON and old Windows build), even the graphics and mouse were lagging and Cubase was loading CPU at 99%-100%, but today it can’t pass even 83%. I am thinking about upgrade to Ryzen 7 3700x, but I need to be sure that I will be able to use its full power. Another concern is that 3700X and 3900X doesn’t seem to benefit greatly from ASIO Guard and they are higher-than-14-thread CPUs and buying some of those would be a huge waste of money.
How do I achieve total usage of CPU in some really heavy projects and in DAWBench DSP test? What kind of settings should I apply? Am I doing something extremely wrong?
I have a Threadripper 1920x (24 cores) and it is certainly POSSIBLE to fully load all cores with Cubase. It’s quite unlikely that you would achieve this in a real world Cubase session but it can be done given the right combination of tracks/plugins.
Yeah I think there are different things to keep track of here. It’s easy to get the impression that there’s like one thing that’s a problem.
I can confirm that Vin (“TAFKAT”) who tested this and set up DAWbench is right, and I found the same thing. Basically for 8 cores and above Cubendo will use physical cores only, and all cores minus 1. So an 8 core CPU will load 7 cores with a max of 7 threads - with AG off.
It is a solution I suppose but it’s also pretty annoying that Steinberg isn’t upfront about this. It’s also not necessarily the best solution.
As for loading the CPU and so on I think it’s maybe a bit hard to judge exactly what it is that bottlenecks the system. Certainly if you reach 80-85% load it seems like it’s something other than the CPU, but I suppose it also depends on what you’re measuring, and where, specifically. We should remember that we get different results depending on how we load our systems. What I found when I tested this was that:
“There’s a difference between having AsioGuard on and off. With it on CPU usage in the performance meter (in DAW) goes up and the spikes go down and cores are balanced throughout. With it off CPU usage goes down, spikes go up, and Cubendo takes all cores, subtracts one, and assigns one thread per remaining core - physical cores.”
Also, instantiating plugins in series hits the CPU much harder than in parallel. So loading up 16 plugins per channel and all channels go straight to an output will give a different result than loading 16 in a channel, sending that to a group and loading the group with another 16, then repeat.
Anyway, I think Steinberg should comment and I have a feeling there’s a better way to deal with this…
— Actually, if I remember correctly I think there was a fix that’s semi-official, but it doesn’t “stick” when Windows gets updated so it needs to be reapplied.
Regarding the 100% CPU load - I’ve tried multiple instances of Dune 2 and looks like it’s possible to achieve full load of CPU using ASIO Guard - Cubase just hit 90% mark. Seems like it depends on a concrete plugin and its ability to utilize multi-core and multi-thread.
AFAIR there was an article published by ScanProAudio and there was some kind of weird conclusion about Ryzen 3000 generation not benefitting from ASIO Guard ON at all. I mean, I’m kinda okay if ASIO Guard just lets CPU work with all cores and doesn’t give too much of “additional” power to CPU, but what is the situation when it comes to real life? I would like to see an opinion from an actual 3rd gen Ryzen and Cubase user if there is one, of course.
By the way, ScanProAudio’s article was deleted for unknown reason (probably because Pete discovered the whole problem with AG off).
If the article was deleted then it was probably for a good reason and I wouldn’t really rely on anything in it. I think it’s possible that Pete (at Scan) ran into the “fix” Steinberg made and didn’t realize it, and then pulled the article while trying to figure things out.
As for Ryzen gen3 specifically I’m not sure I see why AG would be any less of a benefit compared to the previous generation. The Zen 2 architecture in Ryzen 3 is basically just offloading I/o to the I/o die inside the CPU. That should give benefits to that generation at least as far as each core or core complex having the same latency is concerned, and I don’t see why an overall AG buffer wouldn’t help once you max out the capacity of the CPU in general.
I’m not saying “all clear” by the way, I just don’t see why this would be a potential issue.
I bought a new Ryzen 3950x system, its coming next week. I am a bit worried now reading about these issues. I will try to do the same benchmark tests as Scan does.
(The below is all from memory and my understanding)
The problem with having many cores/threads and Windows 10 resulted in drop-outs etc. Having a larger buffer helped with that since the system had more time to “recover” if a shorter buffer emptied. Steinberg’s AG in a sense is a buffer that pre-processes some data and increases total latency. So AG “hides” the fundamental problem.
When you turn ASIO off though we’re left with just the normal hardware driver buffer. So I’m guessing Steinberg decided that since this is where you can run into these problems they’d need another default solution that didn’t require you to do anything. And so by default with AG OFF multi-threading is turned off, and you can only use all cores minus one in your CPU (as assigned by Cubase/Nuendo).
There seems to be a solution to this for at least earlier versions of Cubase/Nuendo (before v10) but it’s not a fix that’s easy to find unless you know where to look or whom to contact.
If you want to learn more then you can start by reading from post number 199 in this thread:
Read the posts by TAFKAT (Vin). There are about three total that explains a large part of the problem.
Again: If people want better performance then there probably needs to be a large demand from users for all of this to be explained and fixed by Steinberg.
As you can see Cubase balances the cores perfectly with AG on.
The caveat, as I understand it, is that when you arm a track that track gets processed as if AG is off. So if you arm many tracks processor balancing gets worse. So to be safe from dropouts, don’t put your heaviest plugins on tracks you want to record to. Or on the master track, for that matter.
