I’ve noticed Cubase 14 is only actively using 4 cores, according to Windows taskmanager.
And the meter inside Cubase pegs to over maximum then stops audio playback when it gets overwhelmed. Yet I can see, in task manager, its only using about 13% of total cpu threading available (on a 12 core / 24 thread processor). And of those 4 cores in use, they’re only showing around half use each.
So I’m wondering what is going on and if there is a way to get Cubase to use more than 4 cores. I have multithreading ticked. I’ve tried all 3 different options on ASIO Guard (as well as disabling it).
Are you testing with a big project that has a lot of tracks with inserts? Because Cubase distributes the load across cores on a per-track basis. But basically, if you have more cores than tracks, you’re not going to see distribution across all cores.
The thing is, if even one track/core has a lot of high-CPU-utilization plugins on it, that will cause your VST performance meter in Cubase to max out.
What’s the make/model of your CPU? (Some modern processors have a mixture of performance vs efficiency cores.)
Yes big project with lots of tracks containing with lots of inserts. I only see considerable activity on the first 4 cores.
And I’m testing the new Relab 176 compressor on top of that. It’s a cpu pig that is what is maxing out the CPU in Cubase. But I’d expect, even with a single core maxed out, one of the 4 cores in use would be near maxing out in task manager too. But that is not the case. So I think you can agree that logically something is not right.
I’ve tested this by installing audiogridder, both the server and the client, on my computer. I’m then routing the Relab 176 compressor through audiogridder and see these plugins are being assigned to another core, beyond what Cubase wants to use normally. The result is smooth playback with many more instances of this demanding plugin.
Then I disabled audiogridder, loaded the plugin back, checked cpu (both in Cubase and TM) and it has reverted back to overloaded. Only using first 4 cores (0, 1, 2, 3).
Then I simply saved the project with the plugin (no audiogridder) directly in the insert. Closed Cubase fully. Reopened Cubase and the project. It’s still back to using the first 4 cores.
Then I add audiogridder, it goes back to using an extra core (core 7 in this case) and performance is smoothed on playback.
Ugh. Cubase. Please sort your threading out on Windows.
You speak of logic, so it’s worth pointing out since Audiogridder is just another plugin running within the Cubase user application space, your finding of it using additional cores is empirical evidence to the contrary of your original claim.
Yeah that’s what they say, but I’m not sure how effective the multi-processing function really is. Cubase for me can reach almost full usage peak and get drops outs - yet when I check the actual CPU usage, it’s only around 20-25%.
For testing purposes, I would probably break “number of cores utilized” and “utilization per core” into two different metrics. Seeing 20-25% utilization per core isn’t the same architectural issue as “thread/core scheduling.”
Depending on your chain, you can increase the core CPU utilization by putting a heavy-CPU effect (convolution reverb, dynamic linear EQs, etc) and you’ll see higher core utilization.
I wouldn’t call it a “myth” necessarily, but in my opinion, a potential misconception is that “effective thread management” is manifested by an effects chain being spread between multiple cores by the scheduler - I don’t think this is true. While a generalization, I tend to work in the constraints of “one thread per track,” which is really “one thread per real-time audio processing chain.” While there are obviously many different elements involved, serialized real-time audio processing should have constrained thread scheduling to obviate timing issues. Trying to fork a thread in the middle of RT DSP is quite challenging, and it really doesn’t buy you anything because at some point you’re going to just converge the parallel data back into a single stream. Personally, I think that would be worse.
It’s dependent upon multiple factors all throughout the chain/project/platform/OS. Cubase doesn’t manage threads, of course. It can ask for priority, but the OS scheduler does that bit. This is even true of Reaper, though you’ll see any number of claims that “Reaper’s thread management is superior.” Reaper has different priority options, but the scheduling is still handled by the OS.
I anticipate that it’s more likely that your testing mechanisms may not fully suit the metrics you’re trying to analyze than SB just “lying” about the mechanics. But if you actually think they’re lying in general, then that’s a different problem in my opinion.
On the contrary, audiogridder seems to have forced (or maybe ‘convinced’) Cubase to use another core when Cubase didn’t want to on it’s own. So it is clear there is an issue with Cubase, CPU core usage, and when it decides it needs to map a plugin to another open core. Which it is clearly having great difficulty at doing in it’s current form, from the example above.
I should probably point out I’m inserting the same plugin in the same track, in the same location on the inserts, between audiogridder hosting the plugin and simply using the plugin without audiogridder. Without audiogridder, cubase doesn’t want to use another core and the project begins to stutter - overload. With audiogridder ‘forcing’ Cubase to use another open core, I don’t get any stutters and can insert even more of this demanding plugin on other tracks no problem.
Incorrect, sir. Audiogridder is just another plugin. For purposes of application thread scheduling, it is no different than some EQ on some track running within the Cubase process space and Cubase asking the OS to schedule CPU resources accordingly.
The fact that you replace some other insert simply shows that Audiogridder is “a different plugin that has different requirements.” Audigridder doesn’t “force” Cubase to do anything. Audogridder is setting up another core to pass audio to so that the client component can offload DSP to the server component at the expense of latency.
You’re conflating multiple different DSP requirements, processes, and CPU scheduling paradigms into “one thing” that you’ve said is “a Cubase issue.” And that’s fine, but I think you’re doing yourself a disservice - you’re clearly interested in all this, so you may want to break these concepts up into smaller pieces and test more so that “the big picture” may come into view.
Well clearly it is correct what I’m saying. And you can tell me I’m wrong as many times as you like, but that doesn’t make me wrong.
One instance of this Relab 176 causes Cubase to jump from 25% on the Cubase performance meter to 85% with peaks above 90%. So, clearly, Cubase should see it is running out of runway, and load this newly assigned plugin to another open core (which it has many from which to chose).
But Cubase doesn’t.
Cubase instead keeps using 4 cores when it has 12 cores available to pick from and overloads those 4 cores causing dropouts in playback.
Until audiogridder is involved. Then and ONLY then does Cubase realize maybe this plugin (176) need to be sorted on another available core.
Otherwise Cubase overloads and stops playback. But with Audiogridder, Cubase now knows to use another open core and I can open multiple instances of this demanding 176 compressor plugin.
So, clearly, there is an issue inside Cubase with how it senses performance demands and assignment of cores to plugins.
Except that the APM doesn’t even have a metric for CPU usage. You’re not even comparing the same metrics, so there’s really no need to participate in this anymore. I was just trying to point you in the right direction if you actually wanted to have more information on how it worked.
Thank you but frankly I don’t really care how it works on the geek side, just that my production plays back without stuttering. Especially when I can plainly see there are many available cores for Cubase to pick from and it doesn’t.
There needs to be more done within Cubase to use more that 4 cores when there is a load that demands more than 4. Otherwise what is the point of buying a processor with more and more cores when Cubase refuses to use them on it’s own?
And I have clearly shown Cubase can use (at least one) of those extra cores, when I enabled audiogridder as server and client on this very same machine. Whatever is happening internally is causing another CPU core to be used which smooths out playback. And Cubase should just automatically realize it has a processing demand that necessitates it to move this processing need to another available core.
Sadly, things aren’t that simple in programming world as the layman thinks they would be… if you have several high cpu plugins on one track, you cannot simple move one of them to another core, as @Thor.HOG rightly wrote (the OS handles the scheduling). Well, maybe you can, if you create a separate thread for that plugin, but then you are in a world of pain with thread synchronization and more.
Cakewalk Sonar can actually split the plugins of a track over multiple threads, they use a pipelining approach, but the manual states that it is not always beneficial, only in certain cases, so it is optionally.
Audio gridder has the big advantage that it is a simple plugin host and it doesn’t need to synchronize a whole playback of dozens of tracks to an audio device, and it adds additional safety buffer, which means added latency.
(Also, as an aside, be aware that if you have a track with many high cpu plugins, if you out that track in record enable or monitor, the track will be moved from ASIOGuard to the realtime path, which usually has a way lower buffer size and thus consumes more CPU. This is important and often overlooked in many “performance tests”)
That being said, there are of course scenarios where it is known that Cubase has some issues, especially with long plugin chains and stacked group tracks. In other scenarios, it scales perfectly well.
True or not I think we can see that Cubase can use more cores than it wants and can manage extra software allowing that (audiogridder). So functionally, there is nothing stopping this from occurring.
If Steinberg can’t devise a means to force Windows to use more cores, then I guess we should all just start using 4 or 6 core CPUs. But I don’t really think apologizing for Cubase and accepting poor experience should be done.
I would think more could be done with affinity and core usage, even if it means Steinberg has to ‘trick’ the OS into doing so..
That just seems like core use is very inconsistent when it shouldn’t be this bad. Call it an OS issue or not but I think Cubase could work to address this more.
I see if I layer a ton of tracks with less demanding plugins, Cubase does use more a few more cores.
But if I drop in a plugin that eats 30% of the available performance (according to the Cubase meter), another core isn’t used. Even when the total project was already using 30% combined. Which means when you drop a 2nd instance of this plugin into the project on a different channel, the whole playback drops out.
So it seems Cubase (in relation to Windows) is sufficient at handling/mapping many lower demanding plugins but not figuring out it needs to assign another core once a processing bomb is dropped on the project.
And we can see another core can, in theory, be assigned.. because through audiogridder this has been done. I can also see the playback is smooth and responsive with this scenario meaning there is nothing inherently problematic about another core being used.
OK… Cubase has issues with core loading threading in windows.
As the OP has seen, using audio gridder shows this up very clearly.
Another easy way to show this is to duplicate a Cubase project n Reaper and then look at the task manager /application performance meter.
I’ve been working with Vin at DAWbench to make a new mix test for DAW becnh along with the traditional Vi and DSP test.
This came about because my 16 core machine would max out with only 25% od my actual CPU use, whereas in Reaper I could load 70 more plugins on the buses.
using audio gridder in Cubase I could do the same and add those same extra 70 plugins to similarly match reapers performance.
I posted all this info on Gearspace and also in a thread here along with the screen shots etc. If i can find them I’ll reference them here again.
Now, someone mentioned that the OS handles the core threading. well in Reaper it does… however part of the problem with Cubase is they’ve over ridden this and Cubase does it’s own core threading… and not as well , it would seem..so there’s a problem here that needs adressing.
In certain situations Cubase threads/core loads very well, but i’ve found in real world mix projects with lots of bussing and Aux etc etc Cubase will max out with only 25% system usage and poor thread loading. Audio gridder is the only way to leverage the full potential of your machine with Cubase and it does this by loading the plugins in external (to cubase) processes . Reaper also has this ability built in natively, i.e. you can right click on a plugin and chose to load it in an external process.
Cubase engine on windows definitely needs looking at , however perhaps the fact it has to run on MAc OS intel and AS and now Windows x86 and ARM means compromise , don’t know, Reaper manages to run on all these systems so we know it’s possible. However Cubase can outperform reaper in some scenarios so again, it’s a balancing act.