Cubase Multi Processing CPU Core Performance

I don’t know if any of this has been mentioned here before, but here are some things I’ve discovered about how Cubase delegates tasks to the various cores on the PC with a Quad Core i7 CPU. I imagine the results would be similar with other multi core CPUs and on the Mac.

1. Any single track in Cubase can only use one CPU core.
So all the inserts on a track will all share the same core. If you put 8 CPU intensive plugins on one track you may find the CPU meter in Cubase is maxed out, while the Windows Task Manager is showing you are only using a small percentage of your total CPU, but overloading a single core.

2. If you have a track that is overloading a CPU core, you can move some or all of it’s inserts to an FX channel and put that FX channel in series with the audio track.
This will force those plugins to another core.

3. If you have a track that is overloading a CPU core, you can move some or all of it’s inserts to sends.
Edited: If you have one audio track, and use an FX channel as a send, the first send for the audio track may use the same core as that audio track. If this occurs and you only need one FX channel send, but want to force it to it’s own core, you can create a dummy send before it with it either muted or it’s level set to negative infinite dB. So the audio track will have two sends, the first one being a dummy that doesn’t do anything except force the next send to it’s own core. This may not be necessary though. I’m not really sure what the condition is for the first send getting it’s own core, so you just have to check to see if it did or not.


  1. This should be explained in the manual.
  2. I’d like to see a numerical reading next to each insert showing how much cpu it is using.
  3. For instrument tracks I would like to see a numerical reading of how much cpu the instrument is using.
  4. I’d like to see a CPU Performance window that shows all the cores on the computer so you can quickly gauge how effectively you are using your cores.

If you think about it that all make sense.

As the input of an insert is dependent on the output of the previous process on the same channel then spreading the dependent processes across multiple cores would be time inefficient.

Moving processes to FX channels, where the process has to wait for the results from multiple channels would then make sense to utilise another core.

According to what you’ve written, doesn’t that make 4 cores? 1 for the audio channel and send 1, and 1 each for the other 3?

This is very interesting - and important - research, don’t get me wrong, but in the interests of science:

  • it must be subjected to peer review before we accept it,
  • is this work you have carried out yourself or did you get some of it from elsewhere?

As for the feature requests:

  • putting in CPU meters all over the place would take up CPU, wouldn’t it?
  • there is already a per-core meter in Windows Task manager. Won’t that do?

Apologies for my scepticism, but I hope you understand it’s necessary. :ugeek:

I think he means to have the individual idea of the CPU usage for each vst instrument.( which I think it´s pretty good idea in order to control your session.
If you go to task manager you will only have the general idea of what cubase is eating from CPU :wink:

Thanks for the info,
this is a Cubase problem since years and they don´t fix it.
I´m working in another studio with Studio One we both have identical machines we built ourselves and in Studio One you can throw doublle as much plug ins in a session with no problems, whereas Cubase´s ASIO meter goes up like crazy…

That’s what I expected, but it was not the result that I got. The first send did not use another core. The second send, and each send after that used separate cores. That’s why I gave the workaround above.

All me, though when I mentioned my findings on Gearslutz to a reverb developer, he confirmed that he believed it was true for most (if not all) DAW’s that any single track and it’s inserts will use a single core.

Relevant posts at the link above are numbers, 700, 701, 703, 705, and 706. Post numbers are at the top right corner of each post.

I have no way to test if a noticeable amount of CPU would be used by the meters since they don’t exist yet. :slight_smile:

If it turned out that such meters did use a noticeable amount of CPU, they could always be a feature that could be toggled for trouble-shooting purposes.

My thought is it would be nice to be able to do all the troubleshooting right in the DAW without having to flip between active windows.

I think it’s a pretty good idea too but metering takes up CPU, does it not? Maybe not much per meter but they can amount to quite a bit.

I think this is a very interesting contribution, I’ve never seen a thread quite like it, so +1 for doing it. I’d just like to know where he’s got it from - which I notice he’s just done while I was writing this.

Gotta go out now but will check back later. This may have legs.

This post was moved to the lounge. :slight_smile:

Does that mean Steinberg doesn’t like something about it and doesn’t want it showing up on Google searches? I thought it was helpful information.

1 Like

Good suggestions for sure. If the metering does not eat much processing, and it is an option per plugin, then I’d be all for it.

I just ran the DAWbench DSP test project (a bunch of MBCs) and it shows the cores loading in the order 0 3 2 1 (I don’t have h/t running on this system) so it looks like Greg’s got a point. I haven’t tried the Sends bit yet but will do later.

CPU: Intel i7 860 @ 2.80 GHz (HT OFF, C-State OFF, SpeedStep ON, TurboBoost OFF)

This extract from the accompanying readme backs him up too:

While the session is playing, progressively turn on the first Multiband Compressor on each Channel- going horizontally across from Channel 1-40, > this will distribute the load more evenly> .

I just ran the same test as above but this time ran up to 4 Sends to FX Channels equally loaded (6x MBC). In my case, the load was spread evenly across all 4 cores, even with the first Send. I repeated with the FX Channels loaded with AmpSims, in case different Inserts made a difference but the cores loaded up in the same order (0 3 2 1).

This isn’t what Greg reported. Don’t know what to make of it but the way the load is distributed doesn’t seem to be Cubase dependent, based on this. There must be something else to it.

Just to remind everyone:
CPU: Intel i7 860 @ 2.80 GHz (HT OFF, C-State OFF, SpeedStep ON, TurboBoost OFF)

PS: I wouldn’t worry about the thread being moved. Moved threads still show up in the original forum.

Thought I’d better re-run the test (the first one with all MBCs) with Hyperthreading ON and extra FX Channels (all 8 Sends). This behaved differently on the two occasions I tried it.

  1. In the first run, the cores loaded up in the order 0 3 2 1, then 0 again, totally ignoring the extra cores.
  2. In the second run, they loaded up 0 7 6 5 4 3 2 1, then 0 again.

So, an even load but not on both occasions.

I now have a headache so I’m retiring for the night. Hope this all helps shed light on the issue, because it’s obviously not being imagined and is rather significant.

I wonder if in the first run Cubase wasn’t actually using the hyperthreading yet, and then it had kicked in so-to-speak on the second go.

An interesting difference is mine load up in order, 0 ,1, 2, 3, 4, 5, 6, 7. That might be a difference in our processors. I have a 2600k and you have an 860, or maybe its effected by some sort of setting somewhere, the drivers, or the chipset. I have no idea really, though I don’t imagine it’s of much import what order they load in.

I tried my test with the sends a third time now, and I got a slightly different result this time. The first send used it’s own core, but then the second didn’t. The third and fourth both used their own cores. So the end result was the same, 1 audio track, 4 sends to 4 FX channels, and only 4 cores being used rather than 5.

In any case I think you have validated all 3 of my main points in the original post with the caveat (regarding point #3) that a dummy send may not be necessary depending on some condition we haven’t identified.

Aloha and great thread guys.

Just following along here and wondering how
all of this might shake out on the Mac side?

Yes, that sounds about right.

They’re both in sequence so maybe we have anti/clockwise cpus (I don’t know how much of a joke this is).

Definitely #1 and #2. As for #3, I think spreading the load with Sends is a great idea but I don’t have the issue here…so far…

Thoughts so far

It could be down to cpu (I get the impression that not all h/t implementations are equivalent) and let’s not be too hasty in letting Windows off the hook :wink: . One of my cores (2) is always very spikey but Cubase uses it quite early on in this process, regardless. Is there a way of seeing what process are using which core?

At low ASIO load my machine works best with h/t OFF, but when I pile it on in a benchmark I get much more performance with h/t ON. I find this curious but I don’t encounter problems so have ignored it. My normal work doesn’t load the CPU much so I usually have h/t OFF.

I’ve just had a look in Resource Monitor and noticed that half my cores (I still have h/t on at the moment) are Parked. I remember this but not well enough to comment more fully. Could this have anything to do with what you’re seeing?

We could do with someone else joining here.

(I was also wondering about the Mac boys.)

I think if we try to go to far into the pros and cons of hyperthreading this thread will become a lot more complicated than my simple observations on core usage and splitting the load. I started reading some of the forum posts at DAW Bench and that stuff makes my head spin. :slight_smile:

Makes my head spin too but it may be behind the uneven load nonetheless. If on/off makes no difference then you can forget about it and leave the rest to the GearSlutz.

  1. Not (really) in Windows. Per the way performance counters are implemented, they report usage regardless of whether that data is consumed or not. The only CPU hit would be on the calls to get the data and display it. On Windows 7 I have a desktop gadget that displays all cores separately.

  2. That window is huge. Plus it would have to be Always on Top unless you have a dual monitor setup and are willing to lose some real estate for the Task Manager.

Sounds handy. What’s it called?

But you don’t need to be monitoring performance all the time, only when you’re hitting the buffers. And if you’re hitting the buffers then the last thing you need is to be taking up cycles by monitoring the problem.

I used the WTM to monitor the benchmarks described above in checking out Greg’s observations. Luckily, you can run it On Top or it would have been a royal pain, but I had enough screen space to have it sat there while I clicked away at Cubase’s mixer to see what affected what and get some screenshots of the monitor at the same time.

Running the WTM did highlight something that I wouldn’t have noticed from within Cubase - that one of my cores runs noticeably hotter and spikier than the others. This didn’t stop Cubase from using it before some of the quieter ones, which means that Windows may be significantly contributing to whatever ASIO issue there are (not the distribution issue discussed here, though - I’m not getting that, although clearly some are).