CPU Power in relation to VST Performance

So, I just recently upgraded my 2006 Mac Pro 1.1
I went from 2 duo-core 2,66 Xeons to 2 quad-core 3,0, from 9Gig Ram to 32Gig.

But I got the impression that it felt like it still wasn’t enough… Real-time peak spikes at 128 buffersize with 2 ampsims and maybe 5 to 10 insert plug ins.
So I tried to “max out” a song I was working on.
Loaded around 25 Waves SSL G channelstrips, 3 Steiny reverbs, 1 Halion Sonic SE (3 sounds playing) 2 Superior drummers, a Waves Maserati plug in on the masterchannel and various ampsims and tubecompressors on several inserts.
While trying to max out my Cubase performance I noticed something…
Allthough I pushed Cubase into the redzone, I still had plenty off CPU power left…
This picture is with 128 buffersize, still 54% CPU power left?!??!? :unamused:

Raising the buffer size to 2048 lowers VST Performance to about 50% and 80% CPU power left.

Am I missing a setting somewhere??? (Multi processing + ASIO guard are switched on.)
Not that I’m complaining, means I have plenty off power left and money well spend, but just looks like Cubase isn’t using everything to it’s power.

Same result here.

This seems to be sorta related:

But ASIO Guard is enabled on all plugins that support it on my system.

This also has to do with synchronization (dependencies between tracks).

I have explained it in detail in German here:


I have to say that Cubase does not seem to use multixore processors very well. Studio One and Sonar both seem to utilize cores a little better. I still love Cubase.

The ASIO-meter has not the same function as the performance meter (CPU).

The performance meter shows you how much CPU is being used on a certain moment. A CPU nowadays has multiple cores. Each core handles certain tasks, and the strain on each core is different for each core. (most of the times) The global (average) metering of you CPU should be more or less the same as the “average” load.

The peak meter is core-“indipendent” and shows the processing load in the realtime path of the audio engine. (i.e the audio driver) Thus: it shows the usage of the core that is being used “the most”. That is why you still have plenty of “average” cpu-load, but somewhere in that CPU, one of the cores is having trouble te keep up and reaches 100%.

The result is that the data sent to the driver does not reach the audio driver “in time” and a dropout or “pop” occurs and thus affecting performance. An overload simply means "adio packages hav not reached the driver “in time”. Nothing is burning or overloading in your system. :slight_smile:

What you indeed have noticed, and many of us, is something that is also well know.

On the VST Audio System page you will find the “Advanced options” section. Here you find advanced settings for the VST Engine, including a Multi Processing option. When this is activated and there is more than one CPU in your system, Steinberg states that “the processing load is distributed evenly to all available CPUs”, allowing Cubase to make full use of the combined power of the multiple processors.

Well… that is a bit of an overstatement imho, since cubase does not distribute the processing load evenly, and tends to “prefer” one single core, and thus blowing up the realtime asio-measurements.

Many people see that other software nowadays is indeed being able to do this core-handling in a more efficient way nowadays. Those programs mentioned above, but also reaper and vienna are examples of a more efficient corehandling then cubase.

I guess optimizing this in cubase is not easy also, since you will have to dive deep into the code.

But, on the other hand, is is not that bad that you can say that it is an issue. It is true that there are more efficient (evenly distributing processor load) programs available if you just take the core handling in to focus, but overall cubase is indeed multicore and still more then able to handle multiple cores

Even better is not trying to blow up your system, and learn the principles of handling cubase in an efficient way. Try to see if a freeze function can help you in avoiding reaching your system limits.

kind regards,

Well, the way multi-core is handled does not only depend on Cubase itself.
OS, how plug-ins are used (a multi-timbral VSTi with 16 sounds usually won’t spread like 16 instances with 1 sound), which plug-ins are used (a few cannot evenly spread). In the attachment the results of a mid-sized test project running on my main test machine at the office (Win 7 x64, UR28M).

Kind regards,

@Henry1970: Would you please contact Support?
Although 128 is pretty low (for mixing, that is), those figures do not look as they should considering the processing power you have at your disposal.

Thank you.

DAWs need to be set up for the best worst case. In other words, having some reserve beyond its worst likely PEAK performance latency.

Just like peak meters are required to make sure full-scale is not reached, even though the RMS might be much lower, the same holds for performance, where the VST Performance is like a peak meter, and the OS CPU performance figures are closer to RMS meters in function.

You can have a system only using 20% on average, but a short peak CPU usage spike may allow the buffers to empty, resulting in hiccups. So, unless something is wrong, one would still need to increase the sample buffer size (or overclock the CPU) to prevent such spikes from creating problems in future.

Further to this, VST Performance and the OS CPU meter do not measure the same thing. This applies to both Win and OS X.

Hmm, I guess I have changed some settings somewhere along the way…
At 128 buffersize I no longer have those peaks any more… (maybe ASIO Guard was off and it was actually 64 buffersize or buffersize & quality settings in my ampsims, I don’t know.)
For mixing I wouldn’t use a buffersize of 128 anyway. :wink:

I agree with Fabio’s statement (as Always :slight_smile: )
Good example is what i am trying to do for the moment.
I created a (half finished) template full of frozen (and unloaded dll’s) of 450 tracks.
Virtually cubase is thus empty, but the tracks are created.

Unfortunatly, the asio is finally on the rise even with status “idle”… (and still with only 15 % on 1 fysical core, but now that is spreading more and more evenly)
But when i unfreeze a track the impact on the asio is way bigger then i have normally when i work with few tracks.
damn…damn… But it is still manageable and working.

There should be a good and thourough document on this core-handling and how ASIO really is determing how cubase works…

kind regards,

Highlights the extra attention required to manage frozen tracks. If necessary, rendering stems (and disabling the source tracks - grouped by folder to simplify) to free up large chunks of tracks may be required to have enough CPU overhead for the occasional unfreeze.

… or to accept that my machine just has it’s limits. :slight_smile:
It’s only a i7 2760Q.

Film compositions are not my goal, but i started to hope that this freeze method was a way to have those preferred sounds as close as possible and ready for recording straight in cubase.

Probably i will stay with the VEP configuration.
Actually, the VEP-cubase thing is what i use live and when working with others, because of the fact that everything is active, and the combination is extremely stable. No popping or dropping. :slight_smile:

But my second machine was not powerfull enough LAN-wise, so the total combination was max 100-150 tracks.
I guess i will have to wait for another moment to upgrade. I gave away my old machine to a nephew and he is very excited about it. :slight_smile: So i will stick on what i have, and keep on dreaming i guess…

kind regards,

I am running AMD 8 core @ 36% CPU.
Average load for VST performance is 100%.

I Never had this problem on Cubase 6, C6 seemed to use a lot more of the CPU.
I have tried many options, and nothing seems to fix this problem.

Any more ideas would be helpful ?

Song structure.

Do you use many sends / side chains?

No side chains , 6 sends. The problem for me is on all projects , I don’t think it is a song structure issue…

Is there a reason this problem is occurring in C7 ? C6 was utilizing CPU power more effectively.