C7.5 Multithread processing performance experience?

Thx !

I quite agree but he did ask about the overclocking. As not everyone gets the performance drops the OP is reporting it’s important to find out, given the high number of components that could possible be involved, that if it is a Cubase problem it may involve some computers and not others. He does know how to present a case (more than most) but given the initial description and not knowing the OP I had to ask. Because you never know… His observations, if they are to get fixed, will involve much more detailed interrogation than I’m prepared to give and in all probability he won’t see closer inspection by the people he’s trying to get to look at this more closely ie: the programmers.
My advice to him now would be to repost this in the Issues section as I think he’s done the best he can here.
If it wasn’t a mystery issue he’d have had an exact answer as to what is causing it within minutes. The “real answer” would be? The real answer would not be just “bad programming” but what sort of bad programming. On most issues that look interesting I try to be a problem solver and not just a nodding dog. Therefore you’ll find a certain amount of devils advocacy to find alternative approaches.

To the OP… In your first post, you said: “I very rarely saw the multicore in-use count go over 2, although VST performance was peaking out.”

Are you talking about the active core count in ‘Intel Extreme Tuning’? If so, yes, I see the same thing. I have a quite busy project running (ASIO meter at around 75%) and I see an active core count of 1, very occasionally hitting 2 (this is with a 6 core 4930k). My understanding is that this doesn’t mean the cores are 100% unused -just that this software only registers them as ‘active’ when they show significant load over a certain period of time rather than just an occasional spike. What are you seeing in Windows Resource monitor?

J-S-Q, the answer to your long question is yes, it sounds like you’re experiencing something similar to what I have.

The Resource Monitor shows fluctuating but constant minimal activity (that is, around 5% on its simplistic scale) on those “idle” virtual cores. And a high activity level on the 2/4 active virtual cores. Whereas Intel Extreme Tuning utility indicates that only 1 or 2 cores are active.

That’s why although you’d said all your cores seemed to be equaly used, I’d suggest rechecking, as you may really find out the same effect that I’m reporting. I say this since you mention you can confirm you’re seeing the same on the Intel Tuning utility. Hope this sounds reasonable.

I do appreciate the wave of later responses, I appreciate the conversation being elevated.

@Jalcide: Much appreciate your reference, and a few other references included in those other threads. It has somewhat helped to see that a few have been reporting some relatively similar experiences. I thought listing the threads here for everyone’s benefit and faster reference:

Part of what drove me to finally spend time trying to benchmark my system’s performance was, as I already said, my own instrumental template growth and thus, Cubase’s performance starting to show capacity issues I’d not experienced before. But another factor was a colleague (also Cubase user) reporting that even though he had just assembled a new Haswell i7 PC (upgrading from a first gen i7-900 series) with some of the bells and whistles you’d expect, he had been unable to see any important performance improvement as a result (which I found impossible to accept). But that’s his reality, which I obviously don’t doubt for a second.

It is curious to see somebody on one of the above references reporting basically the same experience with his new i7-4770 build. This would hint, to me, that there is something about Cubase’s multiprocessing performance that is not yet up-to-par, close to being optimal. The fact that the coupling with VEP effectively enhances system performance substantially, reported by me and several other users, seems to support that notion. This is my first re-observation.

But something else I find worth clarifying is that, at no point have I been specifically concerned, or have uniquely questioned ASIO performance. Not at all. My concern is about my system’s performance as a whole. Cubase is the centerpiece, but there are several factors that importantly influence its performance. One of them, the audio hardware interface, as many have mentioned. Having said that though, I feel I can somewhat safely leave that factor aside from my main concerns, since this is a fixed constrain in the system, a hardware latency, regardless of what DAW, VSTi’s or plug-ins I use.

In other words, at my Mackie ONYX driver buffer size of 128, my ASIO performance will be what it is, what the hardware can handle, and however efficiently the driver has been written or not. In my case, theoretically a driver-reported 5.2ms latency (regardless of whether or not that is 100% accurate). But it is what it is, a fixed constant factor. So when dawbench.com tested audio interfaces, and they found ABC is more efficient than XYZ, and I happen to have XYZ, that just means that there are other interfaces with better electronics and drivers, that can process the ASIO audio flow faster. Thus able to handle more before drop-outs.

Point I’m trying to make, this is just one factor amongst many. And it is fixed. Something I have to live with.

Now, my real interest is in exploring the conditions, beyond the above, how my system performance reaches what I call “capacity” (defined on first post).

More succinctly, to close out the thought-

Since that system performance, and reaching this (max) “capacity” is associated with flawless (no drop-out) audio, and I believe ASIO performance basically depends on how well and promptly the audio software can keep up filling the ASIO buffer to avoid flow interruptions and thus drop-outs, I believe there is a strong relationship between ASIO performance and system performance. So excluding the ASIO hardware/driver latency factor, it is Cubase + your system’s processing power that determine what that “capacity” is to be.

On the one side of my tests, I did see a slightly lower capacity when I switched my CPU to stock speeds, e.g. no OC’ing, more noticeable on the VEP series of tests. Which I think substantiate my above observation. But at the same time, the system speed difference was not substantially different for me to see major changes.

It also intrigues me that some people have reported such effect (no major improvement, that is) when they upgrade their systems. And I can only try an educated guess at it in saying that it might well be the case if Cubase’s overall “VST Performance” is being somewhat limited by the way their code now handles all the processing, or multi-processing. Why in turn might be in line with the observation that C7.5 is not fully utilizing the multi-core capacity, at least in my tests results.

Would welcome thoughts and comments. (and sorry for the wordiness)

I just ran the DAWbench test using Waves Kramer Master Tape (160 instances) and to my surprise, Windows Resource Monitor showed all cores fully loaded and the overall CPU load up to 98%. I also see the ‘Active Core Count’ go to 6 (i.e. all cores). This shows it’s definitely possible for Cubase to take full advantage of multiple cores.

However, In a typical real world project, my CPU use might be at 50% or less when the ASIO is maxed out. I think it depends a lot on exactly what plugins your are running and/or how things are routed. I’ve seen it suggested that using lots of group channels and complex routing can add to the ASIO load in Cubase. No idea of this is true but if I find some time I might investigate this as I tend to use quite a lot of groups/routing.

And for anyone who is interested, I kept a record of when I ran the same DAWbench test on my old i7 920 setup and it could run 82 Kramer Tape instances. Bearing in mind that my i7 920 was overclocked by about 50% from stock speed, these results are roughly in line with what one would expect from looking at their ‘CPU Mark’ benchmark scores.

I’ve done some more investigation and it seems that how your audio is routed can make a BIG difference to your ASIO meter, and to how many plugins you are able to run.

I ran three tests, each one using 24 instances of Waves Kramer Master Tape (KMT).

#1. ASIO meter at 15%, Win CPU at 15%
24 x stereo tracks, each with 1 KMT, no group tracks.

#2. ASIO meter at 45%, Win CPU at 11.5%
3 x Stereo tracks, each with 8 KMT’s, no group tracks

#3. ASIO meter at 100%, Win CPU at 11%
1 Stereo track, with 8 KMT’s, routed to two groups in series, each with 8 KMT’s. i.e. a continuous chain of 24 Kramer instances.


So… it appears that running long chains of plugins (i.e. like test #3) is a LOT more ASIO intensive than many short chains of plugins. It is also clear from the Windows Resource Meter that long chains can not be spread between CPU cores as effectively as multiple short chains (Test 1 showed a perfectly even spread between all cores. Test 3 was very uneven with some cores seeing virtually no load at all).

I’m curious, were the Kramer instances on individual tracks or group channels?

I have a sneaking suspicion reproducing that test, both ways, might yield different results.

If Cubase is similar in any way to Sonar, this would be true. Sonar treats tracks as “parallel” signal paths, and can therefore assign a given instance to a different core, if needed. However, when plugins are anywhere on the 2bus, in Sonar, it sees them in a “serial” signal path and can only assign all of them to one physical core. This is what causes the dreaded Sonar audio engine spikes, which also tend to happen with plenty of CPU left.

It would be interesting to see if Cubase has a similar architecture under the hood. It should be easy to test.

EDIT: Ha! While I was typing up this post, it seems J-S-Q posted just such findings. Interesting…(and thanks for doing that).

It just may be that serial vs parallel configuration thing, after all. The CTO of Cakewalk kindly confirmed that for me in a public thread over in the Sonar forums. Very cool of him, as he didn’t have to do that. It would be awesome if Steinberg did the same.

Anyway, Cubase may be dealing with the issue in a similar way. I really think it’s just Reaper that is the odd ball in the DAW universe, in how it so aggressively slices up the audio and schedules it across cores so well. I think latency has been a problem / tradeoff in Reaper, however, but would need to test more scientifically to be sure.

Thanks for your active interest and contribution J-S-Q. I’m also right now just starting to check the DSP pack to see how it was set up. There must certainly be a difference somewhere if you are seeing all cores active.

I guess we posted at the same time but see my previous post. I did test exactly what you are talking about and yes, the way in which the plugins are arranged makes a BIG difference.

The VSTI engine was rewritten for 7.5 so my theory is that they also made updates to signal engine code but havent had time to optimize it… resulting in bad vst performance.

I am hoping for next patch :slight_smile:

Where was it announced / revealed that the VST engine was rewritten?

I don’t think it was.

Either way, this issue goes back to the beginning of time. They’ve been optimizing that code for 20 years, by hardcore, German, old-school, machine-language-level coders (you would not want to mess with them :wink: ).

It ain’t an optimization issue. It’s an architecture issue. To be fair, an architecture decision; one that they now have to deal with in our modern, multi-core, plugin-heavy context. That’s what ASIO Guard is all about.

I predict we are not going to see any changes to ASIO Guard for about two years. Just a hunch, based on how many other things are likely to be higher on the marketing priority list. And, honestly, I will take things like bounce-in-place and batch freeze-unfreeze over ASIO Guard 2.0, as there are ways around the issue (e.g., VEP). But no way around other, core DAW features where Cubase is falling behind (dockable UI, insert limits, touch support, etc.)

Sorry, that was editorial and off-topic from the goal of this thread: plugin count metrics. Please continue the discussion and pay no attention to my personal wishes… :smiley:

Yeah, well I can feel it. I can feel it in me bones!

But seriously, I have experienced more stability problems with VSTs in general in 7.5 than 7.0.6.

Bummer, sorry to hear that. That was me with 6.5. With prefs-trashing every time I launched it, just about. It was maddening.

7.0.4+ has been very stable for me.

Back to topic, I think they probably “eat their own dog food,” as it’s said in the industry. In other words, they’re probably using the same VST 3.x SDK they make available to developers (I could be wrong). If so, it probably wasn’t rewritten so much as evolved and iterated on. So, bugs are possible on either side of the fence.

But, I’m sure there is a great deal of decoupling between the VST containers and the ASIO audio engine. I think performance-wise, the ASIO engine and now ASIO Guard, is the lead story.

I’m pretty sure they can’t optimize the ASIO engine anymore than it is. ASIO Gaurd (what we really care about now) can definitely be made more aggressive than it is. A simple benchmark against Reaper is all that’s needed to see what the upper limit could be. I don’t think it will ever match Reaper, but even 80% would remove close to 100% of the pain for most of us.

I know it’s a moving target, we tend to use more as we get more, but I swear just a few more plugins and I’d be happy. :smiley: (Yeah, right)

Same problem, Cubase says 100% when my computer says 40% cpu used. And look at the core loads in this image. Some barely being used… ???


Thank you Jalcide! Solved my problem,

Any one have any joy with this problem,

my Cubase project was working fine then turned it on to find the “averadge audio processing load” meter maxed out


I didnt change anything to make it do this - no more plugins nothing, one minute working next making all kinds of cracking noise and that meter on the left of the transport bar maxed out…

Had far more plugins processing run fine before than this, is a new thing

Seems to load sometimes ok sometimes but the transport “averadge audio processing load” meter is always pretty high

Only thing that changed is my HD is now full like 3.5 gb left on it

Cpu load in windows task manager is fine


God bless ppl