Same here. Switched from Ryzen 5600 to 9900X and received only cosmetic upgrade of performance. Cubase’s engine is maxed out while the CPU is loaded around 8%. On 5600 it was around 20%.
2 Likes
MacOS uses a hybrid kernel which combines aspects of a monolithic kernel and a microservice kernel and that may change how the scheduler works compared to Windows, which uses a monolithic kernel. If Cubase had a native Linux version, that would be a fair comparison as Linux is also a monolithic kernel.
That doesn’t really impact this, but it’s also incorrect.
The NT kernel is a hybrid kernel. Windows hasn’t had a monolithic kernel since the old 9x-derived family.
More info:
For comparisons of the OS scheduler across the different operating systems, I recommend REAPER. It has the OS handle all the thread scheduling and also runs on macOS, Linux, and Windows.
macOS also uses a hybrid kernel.
Monolithic kernels, including Linux:
Pete
Microsoft
9 Likes
You have to read the fine print though. When you look at the bar charts it is quite dramatic. But in actuality this is the count of additional plugins that could be loaded on top of the normal DAWbench session which is already very heavily loaded and all DAWs could handle.
In other words, imagine Cubase and Reaper both had 100 plugins each in their test config and both handle that just fine. Then you decide to see how many you can add before you start getting overloads and dropouts and find with Cubase you can only add (say) 2 more copies but with Reaper you can add (say) 12 more copies. Really the performance difference is 112 vs 102 but if you are instead graphing the difference from 100 you’re going to see 12 vs 2 so it will appear exaggerated.
Certainly Reaper is better performing, it is clear, by a good margin, but if you just look at the bar graphs without reading the explanation, it can be misleading. It caused confusion on vi-control too - when these graphs were posted there by the author who did the testing, somebody said “this can’t be right - this seems to show Repear performs 700% faster than Cubase, the difference shouldn’t be this huge” and the report author replied that they didn’t read the explanatory text.
1 Like
it still doesn’t change the fact that my 9950x machine on the mix bus test will be maxed out in with less that 20% system use…… what’s the point in having all thses resources if 80% of it is unused.
Also the difference isn’t between 12 vs 2 extra plugins …. on my machine it’s 70 vs 8 …. a massive difference……..
I think the issue is Stenberg have fiddled with the windows scheduler around C12 time and it’s not working with modern x86 architecture compared to Reaper which lets the OS do it’s thing.
I’ve not tried a high core count Apple machine , but my 10 core M1 Max threads really nicely on this test compared to the 16/32 9950x windows DAW I’ve tested on.
The 9950x has twice the power of the 10 core M1 max but in practice with Cubase, the M1 has 90% of the performance, Cubase uses all the avaiable power with the M1 . On the 9950x 80% of it is left on drawing board with the mix bus test.
M
6 Likes
Cubase should let Windows do the core handling. It is as simple as that. Asio Guard overloads way too quickly, and I shouldn’t have to use Audiogridder to improve things.
i really have a hard time understanding why you and other users feel the need to defend Steinberg in this respect. The very simple fact is that Cubase on Windows is not performing well here, and this should be addressed by Steinberg.
Best
Magnus
8 Likes
Absolutely.
When I frst got my M1 max MBP I was blown away with the performance when I opened a large session from my 9950x machine and it ran perfectly…… I thought Apple had done th impossible….
I then started to look into this more closely on my windows machine by looking at some metrics from the Task/resource manager…..
I quickly realised it wasn’t that Apple had defied the laws of physics but to my horror I could see my windows machine was only running at 20% before Cubase hit the red!!!
I’m not sure how this is going to be adressed. It’s not going to be easy but hopefully it will be.
I’m at the point where I’m contemplating buying an M3 ultra becasue of how things are ATM….. They’re incredibly expensive here in the UK and TBH I’m not a fan of Mac OS, I prefer windows…. but…… I wan’t the best machine for Cubase/Nuendo and ATM my gut feeling is things are working better on Apple silicone machines 
M
7 Likes
Or you/we could use a different DAW. Why should we have to spend money on a different computer when you already have a perfectly capable PC just because Steinberg can’t get it right. Pro Tools has pretty much the same midi capability as Cubase now. Competition is fierce at the moment, Steinberg had better step up their game before they lose a whole lot of customers.
2 Likes
I’ve been using Reaper quite a bit of late because of this ..however…… I have invested in Eucon… I have an Avid S3 and a Dock etc and Reaper doesn’t have the same hardware control I also prefer the GUI of Cubase/nuendo and I’ve been using it since the Atari days.
Pro tools would be an obvious choice in that regard but I hate the pricing model of subscription and having to learn a new DAW ….urgh……
M
6 Likes
Yes, Cubase significantly underperforms on Ryzen even compared to Intel. For my new build, I went with an Intel Ultra 9 285k myself because I read about this first (I was originally planning on the 9950x). With the Ryzens in Cubase, it was established that you hit a brick wall on performance well before the CPU has reached its limit, at a fraction of the CPU’s potential.
And yes, this has also been suggested and seems to make sense that the scheduling improvements for Intel CPUs made then caused the Ryzen performance to be so poor compared to the Intel performance.
The DAWbench results that have been posted show that the Intel Ultra 9 series are faster for DAW applications as a general rule than the Ryzen series (ex. 9950X), additional testing has shown this difference to be greatly oversized in the specific case of Cubase, as it runs circles on an Ultra 9 265k or 285k around its own performance on a 9950X. The performance difference should not be that extreme between Cubase on those two processors - the Intel should still be faster, but not by as extreme of a margin.
I’m not “defending” them on this - I’m simply pointing out something that could be otherwise missed about the bar graph where it is misleading. I said even with that there was still a big difference between Reaper performance and Cubase performance, and this shouldn’t be the case obviously.
Similarly Cubase also shouldn’t underperform so much on AMD Ryzen processors vs the newest Intel processors. I would have bought a Ryzen if it wasn’t for Cubase.
1 Like
I haven’t participated here in many years but I think I need to step in here just to clarify a few things.
The Threadripper report was more to show the lack of scaling from 32-64 threads across all the DAW’s actually, but of course anytime we step out and present DAWbench Data across multiple DAW’s, inevitably the gallery will kick in regards the comparative performance of the respective DAW’s.
That wasn’t the main focus, but here we are.
What the report does highlight and is the focus in this discussion is the issue of ASIOGuard prematurely being overrun under certain session logistics, which I have posted volumes of reports about across various online platforms, and is way too detailed to cover again here, but there are links in the report to the initial discussion and testing that triggered that particular area of investigation in the report.
Now lets be clear, the problem of ASIOGuard being prematurely overloaded is not anything that will be a surprise to many reading in, across a large range of session logistics and layouts.
What is evident in the MIX session logistic we emulated using tracks/groups/busses/FXsends, etc, and highlighted in that report is that scaling from 32-64 threads in Cubendo will not be delivering any substantial RW gains, but what is not overly evident for those skimming the report but covered in the previous reports, is that in that certain session layout logistic, I could run the original session based off Marcus’ MIX on his 9950X on a baseline i5 12600K ( 6P/4E), with near identical delivered performance, negating the increases in available core/clock of the larger system.
In both instances overall resource usage was 15-25% depending on the system , leaving a vast majority of available overhead unavailable to Cubendo’s thread management/audio engine.
Now some may want to argue that is the fault of the Windows Scheduler, but that doesn’t hold much water when we see results from Reaper and even Sonar exceeding easily what is available within Cubendo, and it becomes evident that the problem lies within, not outside of the application.
I also closely monitor at every major and point revision what Cubendo is doing regards thread management across multiple CPU architectures, and there is no consistency.
Despite the claims of optimization for Intel Hybrid 12-14th Gen, some examples of the shifting dots is where certain cores were reserved between Cubase 12-14 on Intel only ?, its ongoing guestimation of what is a P and E Core, while ignoring upper cores of AMD Ryzens as if they were E-Cores, etc, etc. I could go on, but its exhausting.
The current thread management and allocation to the Ultra series where Intel have actually re-ordered the P and E cores has completely thrown Cubendos into a loop, as it applies thread management routines as if they are still in the same order as 12th-14 Gen.
It is ridiculous !
And before anyone pipes in that is the fault of Windows Scheduling in some way, its not !
For Intel systems at least, Intel provides a Thread Director that works in combination with the Windows Thread Scheduling to correctly recognize and assign priority threads to the correct cores P/E. That is if the DAW thread management routines are actually capable of utilizing those key components correctly.
AMD’s for the most part except for the X3D’s, should be less complicated, as all cores are equal.
The solution I suspect is not an easy one for Cubendo, as it seems they are trapped by a high level of technical debt around their threading routines, which have been getting steadily worse since Steinberg were blindsided by the MMCSS mess, and their so called fix at Cubase 10 !
Now before anyone chips in that it will take years to fix the mess, well, we have been navigating the knock on after MMCSS since 2017-2018 , how long did it take them to rewrite the engine for Apple Silicon ?
Not sure what the answer is moving forward, but ducking, weaving and ignoring the issue will not get anything done, if anything can be done at this point except a total engine rewrite !
V
13 Likes
Is this the case with both Windows 10 and Windows 11? I had suggested in an unrelated thread on another forum that Windows 11 is supposed to have a better scheduler than Windows 10 from what I had read from Intel when it comes to dealing with the P and E cores, but someone said otherwise. So I wasn’t sure what the actual situation was.
Is this the case with both Windows 10 and Windows 11? I had suggested in an unrelated thread on another forum that Windows 11 is supposed to have a better scheduler than Windows 10 from what I had read from Intel when it comes to dealing with the P and E cores, but someone said otherwise. So I wasn’t sure what the actual situation was.
Well for Intel 12-15th Gen Windows 11 is a requirement because the Thread Director does not have full functionality in W10, so point is kind of mute for those chips.
2 Likes
I suppose SB has ways to rebuild the engine in steps…which I imagine they’re actively doing..and I don’t want to sound like a code moron saying that.
It would seem to me that an entire engine rewrite as one massive project would essentially potentially instantly break a zillion things for a zillion systems.
My guestimate anyway.
2 Likes
It was somewhat explained back here:
Yeah, I wasn’t thinking user settings for better results….I was thinking about Takfat’s comment of an entire engine rewrite. In my head, SB probably is rebuilding on a pretty constant basis to eventually get the core thing under control.
From the sounds of the beta tester post, it appears Steinberg is aware of the path forward, must do a fair bit of code rearrange, feel they can do it (ie not a complete rewrite) but it will take x amount of time. Who knows what that means….a year….two…three.
Personally, I never have issues with anything primarily because I run a brute force system…master Nuendo and 3-5 Cubendo synchronized slaves in a massive daw farms. Nothing ever overloads. My 24trk tape machines are even slaves/masters to the system.
Yeah, I recapped that too.
What exactly is that supposed to mean ?
When exactly was the scheduler “less smart” ?
When it was dealing with 2, 4 maybe 8 cores, so Windows XP era ?
Time to cut the chord I would think ?!
You mean exactly like you were required to do moving to Apple Silicon native ?!
All you have confirmed here is what I noted in my earlier post, you are trapped with so much technical debt maintaining and patching that old legacy code, instead of addressing the issue head on, that you are sliding further and further away from the pin.
And FWIW, its not only in this specific MIX test session layout that was the focus of the report posted here. We have measurable , quantifiable data of a performance deficit against other DAW’s , in test sessions emulating exact stress and load balancing testing conditions that are preferred by known Steinberg reps. Its pretty much any test session logistic we have tested in.
9 Likes
Hi again, Martin,
I have now updated to 0.40 and performance is identical to 0.30. So please let me know why you mentioned this update in this specific context.
All the best,
Magnus
1 Like