Cubase 14.0.20 Performance meter is going nuts

Cubase
81

Having tried out Lasso yield no significant change in what the Cubase 14 performance meters show. The only significant change was that I could hear my CPU fan more loudly as the changes made it run at ~4.5GHz all the time. That is no good deal for me… that thing needs to stay low. Hence, I went back to my personal tweaking of how Windows should behave. A quick check with LatencyMon yields the same results: no (further) improvements to my system’s performance have been achieved. But I as already did some tweaking beforehand I might not be able observe some improvement at all.

What is measurable is the ASIO-Guard meter in Cubase 14 behaving worse with “Balanced” energy options compared to “High performance”.

→ IMHO Lasso is no silver bullet, which doesn’t mean this won’t work for other users.

Concluding, I’d say that given that the meter now seems to be more accurate and maybe that’s just all about it. The real-time indicator is always around ~1% for that specific project for both Cubase 12 and Cubase 14. So maybe there is no issue at all and its just the new performance meters driving people nuts?

82

I really think that’s it. There was another recent thread about the same thing:

I think what would really help is an “official” addendum to the referenced article where more specific references were made to metrics and methodology - with examples. Even though the docs say it’s a “troubleshooting tool,” they call it an “Audio Performance Monitor,” so it’s perfectly reasonable for people to think that “performance” is measured. I mean, even within the context of an actual “audio issue,” we still don’t know (I don’t, anyway) what the numbers actually mean and why. Even if we know not to use it as a performance meter, we should still know how the reported figures are derived - we shouldn’t have to guess.

83

I can reproduce this in context with a media player (DVB Viewer) that uses the LAV Video filter. I simply start both programs (Cubase 14.x + DVBViewer).

When I set the LAV Video Decoder hardware acceleration to to D3D11 (native mode), I get the instable performance meter in Cubase; from time to time it reaches even 40%, playback is stopped all the time, no MIDI input, no VSTi voices.

When I set its hardware acceleration to DXVA2 (native mode), 14.x performance meter is much more calm (as 13.x was), and never goes above 20%. That’s a whooping 20% difference on the same system, just depending on the hardware acceleration setting in a completely different application!

The video shows this behaviour in a modest project (which is stopped), RME audio hardware in 48kHz/64 samples buffer, Cubase and DVBViewer are both open. When I try the same thing with Cubase 13, the setting in DVB Viewer’s hardware acceleration has no effect at all, whatever I switch it to - Perofmance Meter is stable all the time.

So, 14.x seems to have a performance problem with certain graphics using D3D11 hardware acceleration.

Video:

0:00 - 0:50: D3D11 mode, instable performance meter (watch 0:08s!)

0:50 - 1:18: DXVA2 mode, stable performance meter

1:18 - 1:50: D3D11 mode again, instable

1:50 - 2:11: DXVA2 mode again, much more stable

Probably this helps if you contact support.

Best regards
Timo

84

This is interesting and i’m glad you found a solution.

Steinberg did post this article in the past where they acknowledged Cubase performance issues with newer hybrid cpu architectures.

January 04, 2024 12:44 Updated

Update: Recent tests indicated that the situation has improved significantly, and feedback from the user base supports the results. The behavior running on the latest Cubase/Nuendo 12 and Windows 11 builds is mostly as expected. Cubase/Nuendo 13 support hybrid CPU systems officially without any limitations!

They updated the documentation on January 04, 2024 saying that the issues should be fixed in Cubase v13.

Can you please clarify which version of Cubase you are using ?

85

No. No, that’s not “all it is”: it’s dropouts. Cubase 13 & 14 both have serious issues on some very mainstream PC builds when it comes to distributing VST instrument & effect load properly.

86

Steinberg has never addressed whatever is going on with 13 and 14. I had much better performance with 12, on the whole.

87

I’m not surprised at all by this; from the beginning, these issues seemed in some way related to GUI rendering.

88

I just wanted the OP to confirm that they are using Cubase v14, (which I think they are) just to prove that once again, Cubase just doesn’t work well on some users computers even when they are configured correctly. A user should not need to rely on 3rd party tools such as the Bitsum Process Lasso application to set up the CPU affinity / scheduling / prioritization, when Steinberg has officially announced that they have resolved any issues with hybrid architecture CPU’s since Cubase v13.

This is not a solution but rather a Band-Aid fix. If Process Lasso fixed this users performance issues with Cubase v14 just shows that there’s something seriously wrong with the communication between Windows and Cubase.

89

Couldn’t agree more.

In fact, I just tried the Process Lasso config of forcing all other processes that allow this (the vast majority of them) onto the Efficiency cores only (16-31), setting Cubase to only use the Performance cores (0-15) on my i9-14900K. I also set Cubase’s GPU Affinity to High, as suggested.

I’ll be damned if this isn’t the most stable I’ve ever seen Cubase run this particular project, my latest. It’s kind of unreal, really. I swear, it seems like I can’t get it to actually overload. I’ve not been able to push the meter into the red yet, even with more Repro-5 in HQ mode with Multicore on and all 8 voices, just as a test that I know often overloads things normally.

So yes, absolutely, @wavefunktion , you are correct, as so many of us have been: Steinberg has a glaring flaw on their hands here that they’ve simply not been competent enough on their own to recognize and isolate, and people like me have been shouting it from the rooftops for at least the last three years without any significant actions taken on their part. This situation really is pretty disgraceful and I believe a shakeup at their office is more than justified at this point.

The existence of Process Lasso and it being able to so profoundly affect Cubase’s performance and essentially PROVE that something about how Steinberg is allocating system resources in Cubase is extremely suboptimal on systems such as mine (and many others, considering how mainstream my build really is) points to that being the truth of the situation exactly.

In other words, this company dropped the ball, big time, and we as consumers have paid the price.

There is simply no way that one of the most expensive DAWs on the market should have been shipped with such glaring performance problems plaguing two versions in a row, at least.

This is a major, major problem and I believe we should keep highlighting it till Steinberg’s leadership is forced to acquiesce the point that we’ve uncovered something big and of great consequence.

This is too important to ignore, too important for them to shove back under the rug and pretend there’s nothing to see here.

THERE IS.

90

Wow. Go get ‘em, tiger!

There you go with the “we” crap again … :roll_eyes:

91

You probably wouldn’t think it was “crap” if you were one of the users experiencing poor Cubase performance.

92

Do I have to spell everything out for you? It should be obvious that I mean “we, the subset of consumers who have been affected by such issues, which is of substantial size".

Why do you people have to automatically include yourselves in these threads? Feeling left out or something? I honestly don’t understand why you all have to run interference for a subsidiary of a giant Japanese multinational conglomerate.

Any rational person knows exactly what I mean by these statements and doesn’t feel the need to reflexively split hairs and be all like, “Who’s we, paleface?”

Next thing you’re gonna report me for “racism” for using a common idiom originally popularized by The Lone Ranger to make my point. Nothing’s ever enough for people like you to just leave alone.

For my part, I would gladly shut the hell up if Steinberg would only:

  1. Acknowledge the problem
  2. Address the problem, fully and completely
93

I just want to know if the issues are caused by Windows, drivers or Cubase. The fact that some people experience issues and some people don’t lead me to believe it’s more of a issue with Cubase. I would have thought that the way Windows handles process scheduling, prioritization etc would remain consistent on each system, but i’m no computer science expert.

95

Agreed on all points.

What I’ve been able to intuit about this over the years:

  1. It almost certainly seems in some way related to processes governing the GUI
  2. The situation is radically different after using Process Lasso to ensure Core 0 never gets touched by Cubase (presumably so system processes or others that attack that core specifically and no others for some reason can do what they need without Cubase fighting them for cycles)
  3. It seems even more different when forcing Cubase only onto cores 0-15 (P-cores) and everything else, or as much as the system will allow, onto cores 16-31 (E-cores)

As mentioned, I’m not sure if the GPU Affinity settings make a difference yet.

But I’m 100% sure that the GUI processing is somehow involved, and you know what exposed this? Using Cherry Audio’s Voltage Modular as a MIDI controller for my little Dreadbox Nymphes analog desktop synth: it should be using negligible CPU for obvious reasons, but that was not the case: it would routinely spike the VST meter, triggering audible dropouts/pops/crackles and requiring me to reset it.

It seemed more likely to do this if I was using MIDI-learned, physical knobs to control the sliders on Tim Shoebridge’s nymphcc, what the module is called: if I used the mouse to grab & move the sliders directly, it seemed less likely.

So, this led me to suspect that actual MIDI processing coupled with the GUI update processing for the plugin which probably wasn’t coded to take proper advantage of the GPU at just the right intervals was bogarting Core 0 somehow, just when Cubase’s audio engine wanted to use it to keep the real time audio stream intact.

*Hmmm!*

Now we’re getting somewhere!

Just want to give everyone who has meaningfully contributed massive props: between all of us, the affected, we’ve sure managed to whittle this down to something that’s looking more and more definite.

And it goes without saying that we’ve exposed a legitimate, shared problem that most definitely falls under the rubric of engineering challenges the team in Hamburg should’ve risen to address by now. We’re doing a lot of engineering for them here, uncompensated.

That is the situation I would like to see changed. It’s hard to overstate the stress this situation has caused me, both professionally and personally.

96

Developers can optimize how their code interacts with Windows scheduling, but they can’t override the fundamental policies that Windows enforces. Good design = respecting these limits and writing code that plays well with the scheduler’s rules.

Steinberg please just be transparent and honest and tell us whether using Bitsum’s Process Lasso application for optimization is essential for better Cubase performance or not ? :sweat_smile:

97

Is there any chance you could re-test this issue you have described while using Bitsum’s Process Lasso ? I am curious to know.

98

You mean the one with nymphcc?

99

Yeah.

100

Sure, I’ll try to find the project I was working on that was in that exact state. May take me a bit, and I’m in the middle of an international move (well, the start of it, anyway), so responses may be delayed. Got a lot going on. Hopefully in a couple-three months that’ll all settle down. Dismantling the studio in pieces as we speak.

101

Sheesh, bad timing to ask :sweat_smile:. Goodluck with all of that.