C7.5 Multithread processing performance experience?

Why would that matter?

Well I’ll quote myself from the post I made in this very thread:

J-S-Q “And yes… I know, the ASIO METER IS NOT A CPU METER because this is the (unhelpful) response that is always posted when this issue is raised. But WHAT EXACTLY is the bottleneck here?”

Well done for being yet another person to post this unhelpful response. Now please explain EXACTLY what it is that is causing Cubase to run out of steam when there is still a lot of CPU power left. Or please explain why, on the same computer, Vienna Ensemble can apparently run 12 instances of Altiverb with no problem when Cubase can only cope with 4:

I’d be a little patient with Hippo as he knows more than most. He is a little blunt. Especially when he suspects that someone will not appreciate his advice. If he thinks you the subject is up it’s own sack you won’t see him again. Talk turkey and he’ll most likely be better than Steinberg support staff.

To the OP. Overclocking can cause rather a lot of mysterious trouble. Are you overclocked? A simple answer takes half a second. Just humour me.

OC’ed? Yes. The i7 990X is basically a CPU sold for that purpose, only.

Second hint: My tests included a full round of stock conditions trials, following exactly the same methodology. Absolutely the same effect observed. Just at different capacity levels. Again, please excuse my brevity here, as I said I have a good amount of documented evidence of my tests. So can tell you OC’ing did not influence the overall observation.

In return, could I now be humored and explain what kind of mysterious trouble OC’ing may cause? Is that what you’ve heard or is it your personal experience? I’m not trying to be a prick, I’d just much prefer to speak in clear(er) terms that can lead us, the conversation, this thread, to somewhere helpful and meaningful.

Cubase is a great app. I want to congratulate all of their developers for the work they’ve rendered.

I’ve paid them money.

I’m willing to pay them more money for future improvements on this product they’ve created.

I’m not sour about the incidental bugs.

I just want to know what we can do to assist the guys at Steinberg at addressing these sort of issues; the kind of issues that are critical for a minority of their user-base.

The kind of issues that directly affect my livelihood, and my ability to do this thing that I love: which is to make music without moving the buffer to 512 samples.

So please: could somebody at Steinberg let us know how we can help. Thank you

This topic has been discussed quite a bit lately. You may find some additional food for thought here:

I share my thoughts on it, as well.

The short answer to the question is that there is an inherent battle, competing forces, between an architecture that’s been built to favor low-latency, and one that’s built to “schedule audio tasks” across multiple processors (cores). Each DAW does it differently. Cubase’s roots in the low-latency end of this spectrum is why those of us who favor more plugins over low-latency, are feeling unsatisfied.

There are other DAWs that have chosen a different design, that suffer less, but more in other areas and vice versa. Cubase was second in my test of DAWs I own (in multi-core scaling).

VEP on the same machine circumvents the issues because it gets its own cores to work with and has a different audio engine design than Cubase.

Cubase’s anwser to all this is ASIO Guard. Clearly, not as aggressive as many of us would like, but it’s version 1.0.

Hopefully, awareness, like these posts, will bump it up on their priority list.

I think the future is definitely one that requires ASIO Guard to be in a “Reaper” ballpark of how it schedules audio slices across cores and makes more use of modern, multi-core CPUs. Cubase does use them, but is hampered by its ASIO, ultra-low-latency roots.

great answer jalcide! Didn’t come across those earlier discussions. They contain a lot of usefull info too.

Thanks Gus. Some programs just plain don’t like overclocking. Long time since I’ve looked and it was a spur of the moment question, just something to look at if you had, or the vendor had, OCed. Probably much improved now especially on an i7 but in some circumstances data flow could hit bottlenecks and interrupt, say, midi data so you get catch-up and hiccups. My aim is to get somewhere too. You seem to have all the elements in place. I just thought that there might be something missed as there is a lot going on TO miss.
The reason I think it could be a setting is that I have the i7 generation behind yours. Mine works low m/thread issues. Meters are just visible although no VEP. So in theory your machine should not be going like the clappers. My first call on a new build would be the BIOS settings and even on an i7 I get the occasional anomaly with unrecognised usb ports. Not serious as everything seems to work but it just niggles.
Another thought; does Cubase actually RUN ok with no seeming effect other than the metering looking odd?

RE: Overclocking, on my previous machine (i7 920) I found that overclocking (from 2.6 to 3.9GHz in my case) definitely gave better performance. I was able to run more plugins before the ASIO meter maxed.

The discussion in this thread involves more than one topic I think. There is the OP’s question specifically about multithread processing and then there is the wider question of why the ASIO meter hits max a long time before the available CPU power is utilised. Certainly on my system, observation of the windows resource meter is showing a roughly even spread between all cores.

One factor I have only become aware of recently is the differing performance of various audio interfaces when run at low latencies. The guy behind DAWBench.com has done a lot of investigation on this and one of his tests showed that at a buffer setting of 64 with a Focusrite Saffire Pro 40, Cubase could run 57 instances of a given plugin but with an RME HD SPe, it could run 151. At higher latencies, the effect is far less noticeable (137 instances vs 163 with a buffer of 256). These tests were carried out on Cubase 5 (with Win7 x64 Pro) so hard to say how relevant they are with the newer versions.

Read about it here if you’re interested:
http://www.dawbench.com/audio-int-lowlatency.htm

I am sorry but as someone who came in with their first post sounding like OP needed to learn about computers each subsequent posting has indicated its quite the opposite. As someone who has worked in IT for decades I appreciate OP methodical and detailed approach.

I’m glad OP is bring attention to this. While I believe Steinberg does a great job, they also need constant feedback on what concerns users have in order to improve and stay competitive. This thread is based upon the thinking that there is no such thing as mystery issues and that there actually real answers for all problems.

i agree. OP has placed the question in a very correct way. And i must say i was glad i joined the topic since the answers given here are spot on. Learned a lot today. But also noticed that it is an issue where sb isn’t very clear on. Running out of juice too soon with our new cpu monsters isn’t what we want. Maybe we should have some profiles where we can actually “tweak” our DAW engine in the way the user wants its priorities, maybe with some kind of priority setting per track/rack. One person wants to have a lot of vsti’s, another wants to have very low latency, and so one… And our simple tweaks under devices that exist for the moment are well outperformed by other vendors, not to mention vienna who seems to blow the competition away since everybody seems to agree they are able to “avoid” the performance issues and do more with the same hardware. (And even without mentioning the usage of the functionality of adding extra hardware/servers to multiply the performance) More and more people are taking the vsti-path nowadays in my opinion so this is a battleground for the vendors. Cubase is probably the best for many in terms of workflow, but having a constant fear under your customers while they are watching the asiometer is something that can be done better.They still do have the authority of being the founders of asio after all.

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).