Cubase 11 Pro doesn't use all my CPU potential

Cubase
,
1

Hi!

I read a lot here about multi core CPU. But nobody has the answer. Cubase has to fix his managing of Mac multi-core processors.

I compose demos with EW Composer cloud, Opus, Komplete (Keys, Drums, Performed Brass), Maschine 2, Serum, Spectrasonics Suite as Vst + Audio tracks for vocals. Total about 60 out tracks.

I use Slate Digital Virtual Mix Rack, Waves CLA-2A and Frequency on certain tracks but principally, my plugins are on 8 busses (Virtual Mix Rack, CLA-2A, Nectar Pro, Waves GW Voicecentrix, Frequency, Voice Doubler, UAD 1176LN, Versuit Classics, Rbass). In a last final bus, there’s a GW MixCentric an Ozone Pro with only an Imager an Maximiser).
I use a UAD Apollo Twin Thunderbolt.
I recently change my iMac 4-core 3,4ghz 32 gb RAM for a MacPro 2013 12-core 2,7ghz, 128gb RAM.
Barely no gain of Audio performance. Weird!
I work in 44,1.
Buffer 512 samples (15 ms latency) (Changing fo a bigger buffer makes no difference)
Asio-guard On (off is a disaster)

See the capture below. Cores are not use at their full potential.

I don’t want to know how to saving CPU. I know how… I can mix in another project and use my Ozone in final project. But I don’t want. I’m not a engineer, I compose sexy demos in a single project.

I don’t want to know that PT or Logic or Reapper do a better job with multicore… I’m a Cubase user and will still.

I want to know why, with my boosted MacPro, I don’t have overhead in Audio performance who are at the maximum of his capacity… but my Mac Activity Monitor says my cores still have lot to give…

Why?

Thanks!

(sorry my English do what he can)

Capture d’écran, le 2021-10-25 à 20.38.07
Capture d’écran, le 2021-10-25 à 20.38.071920×961 150 KB

2

It’s a funny thing. You have more cores and more threads… and that allows you to run more simultaneous processing, side-by-side… BUT… those threads have to wait for each other, you know?

Real world example… If you have a vocal, 2 backing vocals, 2 guitars, a bass, 2 keyboards, and a 10-track live drumset… well, you have 18 simultaneous tracks… OK, so let’s say you put some processing on your vocal track. That uses 1 thread. Now, you have a guitar part that you put some processing on… Well, that gets assigned to a different thread. And so on, and so on. So, with a multi-core PC, you can have MORE simultaneous threads, right? OK, but let’s say you put a ton of processing on your vocal track. Well, that’s going to use up a lot of processing power of that thread. But when you play your track back in real time, the guitar part gets processed easily on one thread, and the vocal part requires much work from the other thread… and then they come together to be played back together… so the guitar thread kind of sits there getting much less use while it “waits” for the vocal thread, you see? One thread is being used to, say, 90%, and another thread is being used to, like, 20%. So that’s why all your threads aren’t maxed out. The threads need to cooperate.

Now, in this scenario, your ASIO meter will read 90%, not 20%. Interesting, right? You know you have more power to spare, but your ASIO meter is saying no… Well, all it means is that on ONE THREAD (or more) there is high CPU use. So, at this point you can leave your vocal track alone and move on to all the other tracks and you will be fine adding processing to all those other tracks because they will be using different threads. You see? You ASIO meter will stay at 90% still.

So, yes, you have more power with a multi-core machine… but it is not the kind of power you expect, because the threads have to work together, to cooperate. And hey, when they all finally come together on your Mixbus, that final mix-chain processing can really push your ASIO meter up, for some reason… as if it’s an extension of your most maxxed out thread. At least that’s what I experience.

So, again, you don’t JUST need a multi-core machine for power, you also need a machine whose single core performance is exceptional, in order to be able to put a lot of processing on single threads… like your vocal… or the Master Bus, etc.

I hope that makes sense.

10 Likes
3

This is something I’ve been very concerned with lately, having upgraded my cpu from from 4 cores to 12, and barely seeing any improvement. From what I’ve understood, routing tracks through busses/groups forces them to the same core. I have large projects that max out ASIO, but only uses 3 cpu cores…

I see two things that could be done to improve this:

  • Guidance about how to structure the projects to maximise multi core processing. After all, mixing through busses is very much the norm. Are there workarounds?

  • A better ASIO meter, that breaks down threads, cores, tracks so we don’t have to guess what’s holding us back.

If anyone has more info about this, please share!

4 Likes
4

Better metering to find out where the bottlenecks are would be very welcome as I would be more than happy to temporarily disable some processing while working on another part, to then enable it again for export.

It also just occurred to me that implementing track caching like some video editing software does might help - first time a track is played, realtime processing is cached for that track. That cache is then used for subsequent playback (with processing automatically disabled) until any changes are made to anything on that track (or any tracks that might influence it e.g. sidechains) The cache is then recalculated and used on subsequent playthroughs.

With a well thought out implementation across all tracks, that could free up massive amounts of processing power without having to do track bouncing, offline processing, render in place or any of the other “semi-permanent” methods we currently have that we actively have to choose to do.

1 Like
5

There must be some reason why that’s not already done as it’s such a good idea. But you do always get to a point when working on video when the timeline stutters. Maybe that has something to do with it. Background caching would be excellent. Maybe that’s somewhere in the future.

Re: Peter’s: “A better ASIO meter, that breaks down threads, cores, tracks so we don’t have to guess what’s holding us back.”

I agree with that. Logic actually has that. I’m not sure if it’s broken down into what’s using what core, but there’s a nice view of all your threads. For me, it’s usually fairly obvious what’s causing it - the tracks with the most insert plugins, which again are usually vocal and mixbus. And soft synths too. I went and bought a Waves server to help reduce the demand on my host CPU. It works quite well, but with it does come a bit of latency, 40ms, so not so great for recording… I find myself using Cubase’s delay compensation feature a lot. I think I may use freeze more often, now that it’s been mentioned. That, and try not to simultaneously mix and record.

1 Like
6

After I’d typed my reply I started thinking about background caching. There must be a reasonable amount of time while working on something that playback is halted for whatever reason. That would be a great opportunity to hit most of the threads/cores hard to create those caches, leaving a few threads for the foreground stuff that isn’t time critical.

The more I think about this the more I can’t believe it’s not been tried before. Years ago disk throughput used to be an issue, nowadays the disk meter doesn’t move from zero for me. My point being the caching doesn’t even need to be in memory for a relatively modern system.

1 Like
7

Maybe it only begins to make sense when your system is powerful enough, and that’s why it hasn’t been done. And maybe systems are now powerful enough to finally not need it.

Even when I’m working in Final Cut, sometimes I turn the background caching off and just use a key command to render… which is like freezing a track. Sort of.

But hey, how about proxy files? How about 16-bit proxy files, and calculations done in 16 bit processing? Gosh, I’m not even sure that’s a thing. But I guess it was.

1 Like
8

Hey!
Thank you very much everyone for your explanations and propositions.
I understand that, for the moment, there is no solution to use the other cores.
Since my question, I read your responses and observed the activity in my projects. Finally, independently of which bus is the most filled of insert plugins, Cubase always use to the almost full the first Core, than a little less the second, a little less the third, etc… to the twelfth there nothing but the first is now completely satured.
Than, I understand that the most important for doing audio freely with Cubase is not the number of cores - this potential is not really used - but the speed of the first one!
I thing to sell my MacPro 12-cores for something else will really let my create without always use a part of my brain to preserve my CPU use. Witch was my goal when I buy this one.
Any Idea? Which machine professional users use to work really freely? Or other solution to redistribute CPU load?

Again, thank you for all your very interesting posts!!

And sorry for my English…

9

you could just turn your processing off, finish recording the track, then create stems or freeze tracks and mix.

but that doesn’t answer your question.

Just look for any machine with a single-core performance higher than, what, say, 1400, and up into the 1700’s. (You see these numbers in Geekbench. Google that.) My current machine has a single core score of like 950. Not good. But I have a MacBook Air now that reaches 1750… but these M1 MACS are still 6 months to a year behind being fully supported, in my humble opinion.

So, I can’t really answer your question. Just look for those CPU scores I mentioned above.