Again - how to force Cubase to use all cores?

It’s 2022, and I just bought me Cubase 11.5 update. It still doesn’t do proper multi-core support. Why is that?

It’s not the machine (i7-8700K) - because whenever I export anything in Reaper for instance, all the cores (6/12) are working 100% all the time during export.

But when I do the same thing in Cubase…I get cpu 0 at 100%, then 1 at 90% and then on very little core activity, so that overall CPU use is well below 50%.

Is there anything one could do to force Cubase to use more than 2-3 cores effectively?

If you’re using something like halion - kontakt - PLAY / OPUS and open multiple instances (instead of one instance and loading multiple instruments into it) - it should spread the load across the cores.

The project has about 30 audio tracks, several VST guitar plugins, Spitfire BBC symphiny Orchestra, waves Grand Piano, about 20 or so plugins…should be plenty of stuff to spread across different cores…the render takes about 8 minutes…but it heavily prefers the first one.

1 Like

Oh my God…8 minutes!

Great question!

I have the same issue and any suggestions would be very much appreciated!

You could up your buffer size to max available.
Say you are used to work at 128 sample buffer, changing that to 4096 sample buffer, can reduce rendering time significantly. It really depends on the project, how much.

1 Like

Given your situation, ASIO-Guard may be of interest to you. Pull up the manual and review page 1157. It’s been suggested by other users ASIO Guard has an impact on multi-core/multi-threading.

At the expense of latency, general consensus seems to suggest that it should remain enabled for best performance. Increasing the buffer size prior to rendering can drastically improve rendering speed and make better use of your CPU.

I was using 512 buffer, 32 bit audio engine, multi-core processing on and asio guard at normal.
Changed to 4024 buffer, and export got even slower. Hardly any activity past the two first cores:

Absolutely no change whether I use 64 bit processing, asio guard on or off…it just refuses to use much else than the first two cores :frowning: seems to me that Cubase simply cannot properly use a multi-core cpu. Bad programming, simple as that. No wonder Reaper exports similar projects at 4 x speed.

2 Likes

Its been this way on and off since the beginning (of cubase, and desktop multicore/multi-thread). There are numerous pages published by steinberg that acknowledge some or all of the issue, but make claims that “ASIO Guard will mitigate this issue for most users.” This isnt true, and many users dont even use guard because it creates more issues than it solves. If you bring this up on these forums, it usually results in denial, misdirection, and frustration.

Cubase does better or worse depending on your platform, but nearly all of them require various BIOS tweaks such as 1) disabling p-states/power management and/or 2) disabling all virtual cores and/or 3) disabling speedstep or similar technologies. I was once patient and understanding about the issue, but after all these years and the attitude steinberg takes toward the issue, my patience ran out. Good luck.

3 Likes

I think @Scheissberg said it all, but just want to add that emphatically agree with this analysis. Cubase/Steinberg management team, which is now Yamaha Inc for some time now, is not addressing Cubase issues seriously, despite it’s large, but dwindling user base. Sad, very sad. Why should I stay with Cubase? I keep asking myself this question, lately. I patient is running out as well. The cooperate gamesmanship around updates has become tiresome.

2 Likes

Well, I for one have tried it all over the years, disabling p-states/power management ?it’s still off) and disabling all virtual cores ie Hyperthreading (doesn’t change the situation at all) disabling speedstep or similar technologies - I always keep my CPU locked to full power no throttling…nothing changes the fact that it only uses a couple of processor cores efficiently.

Well, it does work fine nevertheless. Simply it’s annoying to think how much faster could the export be, when you’re waiting for it to finish and stare at the resource monitor, and disk use is like 0.02% at best (twin nvme m2 drives), memory use is like 20% or so (32GB 3600MHz ram), and CPU use 42%. Simply spreading the load better across the cores and getting the CPU working at 100% would in my view immediately cut the render times to half.

I’ve already bought v12 and will see if that improves the situation, but I’m starting to use Reaper more and more.

Guys,
I found out something really odd about this.

I did this test where I started adding tracks and putting my fave VST:s on them one by one, always testing export.

Every time the CPU load was very even and nice.

THEN I added an FX bus and put a reverb there and sent three channels to that verb (abbey this time)…and lo and behold, the load suddenly centered on first cores!!!

That’s just crazy. FX channels are meant to LIGHTEN the load, aren’t they, so you can use the same VST for several channels…?

And it seems to do the opposite.

ONE instance of reverb in VST and sending 3 channels thru that; cpu load 46% and centered on cores 0 and 1; instead I put three instances of the same verb in the channel inserts directly…CPU load 100% and ALL CORES EVENLY USED.
The more FX channels I added, or more channels sent to the FX loops…the less the CPU load but also the more the load centered on just a few cores!!!

THIS IS STRANGE…

2 Likes

Wow…so bizarre!!

You should put that in a bug report

Nothing strange. you have to first process all the tracks feeding that bus before the bus can be processed. its sequential in nature and reverb in particular is highly sequential. same for certain things like compressing ( codec ) require a sequential series of steps that simply doesn’t parallelize very well. Of course if Cu did you all those cores, then you would be complaining its a resource hog and uses too much CPU time and other things are slow. pick ONE.

2 Likes

Yes the more you think of it, the more obvious it seems why is it so.

Well, I for one love to see my machine resources employed to the max, so I’m placing my verbs in buses rather than FX loops and that seems to help and seems more straightforward. It’s better to have more instances of the same plugin than summing them all to the same fx loop. The FX loops are best employed for external FX, which I like to do at later stages but not early on because then it’s real time export only of course.

Meanwhile, now upgrading my CPU from 6/12 cores to 12/24 cores…

An other area where cpu utilization is real poor is during startup.

Yes, I initially had Cubase on a fast NVMe drive, but soon realized it barely loads from the drive anyway, most of the time during startup is just processing…something. Moved it to normal SSD and it loads just as fast…or slow.

2 strikes, its not 2022 yet, and there is no Cubase 11.5 )))
but seriously, hope cubase 12 will be better in overall performance and cpu utilization ,program load/close times ,adding instrument tracks quicker etc…

Good luck.

Reverb is inherently a single thread bottle neck. It has to wait for everything going into it to get there, process it, forward it to the next stage etc. Once it gets there, it has to slam through doing the processing and hopefully get it done without big buffers building up at both ends of the process. Sometimes it’s most definitely better in terms of thread distribution to use more instances of the plugin rather than sharing one on another bus. That can also change the sound of a mix significantly.

Oh well…at least you’re not having to use a $4k external unit that drinks $20 worth of electricity a month, only works in real time and only has half a dozen preset options. Set a huge buffer and mix it down if you’re out of head-room then shrink the buffer again if the project is choking.

What else can ya do short of rerouting half the project so it uses more cores, or offload some stuff to a secondary synced up workstation? (In 2021, sometimes it’s better to have two machines with 4 cores each, than a single one with 24 cores)

Know of a way to divide that among different threads and put it all back together again? Lotta folks would like to know the secret.

The app isn’t using more cores because it doesn’t need them, or you’re routing some things in a way that make it virtually impossible to multi-thread the task. If you follow the signal chain from beginning to end, and it’s all tapering down to a single output…there are a ton of things going on in that signal chain that just cannot be done discretely and stay in ‘sync’. At least ‘not yet’, with the current CPU, memory, storage, and audio device designs.

The more stuff you throw at a single bus that is connected to the same end-point at the very end of the signal chain, the closer it’ll get to maxing out a single core.

At least one core will need to be pretty taxed, as that’s the one cobbling all the other mess ‘back together’ that’s been threaded off ‘back’ into your final destination for the stream.

Can Cubase do more discrete processing with more things? Maybe, but time tampering effects like long reverbs of more than a few milliseconds ain’t one of them. A 3 second reverb, while also trying to achieve near zero latency using device buffers of less than half a second and crazy high 21century sampling rates at 64bit dynamic precision? Good luck with ‘multi-threading’ that processor demand on the current ‘system’ architectures! You’ll need to redo ASIO, the buses that motherboards provide for attaching the hardware (USB/Thunderbolt/Etc. ain’t gonna allow it) the audio hardware, how the processors work, and more.

Processor design, and the way it’s configured also has something to do with it for some things. LOADS of things are handled at Firmware, OS, and Driver levels that higher level apps like Cubase have ZERO control over.

1 Like