Hey All,
As a follow up to one of the topics being discussed on Ep 02 of the Radio Show , specifically regards hybrid audio engine performance and my concern at the time that Cubase 10 had thrown a few additional curves into the mix with ASIOGuard/MMCSS , I did some some additional testing after the show had been recorded which explains some of the oddities we were navigating , but hadn't connected the dots as yet.
My initial concerns were surrounding some very weird and confusing benchmark testing results that Pete from Scan had been experiencing when testing the last round with Cubase 10. That initial report has been pulled as we further investigated some of the performance variables, I'll let Pete detail that further if he feels warranted , but I can offer up my testing and observations.
There are 2 areas being navigated, one being the MMCSS issue with anything above 7 cores which effected Cubase on Windows 10 , and performance of the audio engine with ASIO Guard On/Off.
I posted a report at my FB Page , which I will repost here with some additional detail.
Steinberg vs Windows 10 MMCSS !
Those using Cubase 9 that had been navigating the issues introduced in Windows 10 due to the limiting of MMCSS threading, will be familiar with just how debilitating the issue was on higher core systems.
Quick overview of the problem for those not affected or unaware. Windows 10 assigned a max 32 thread limit to MMCSS optimised processes , whereas Windows 7 did not have the same limitation.
Windows 10 reserves 4 threads leaving 28, however each process call assigns 2 threads , so that is halved again to allow 14 max. So to be clear, specific MMCSS processes can only be assigned to maximum 14 logical cores.
In practicality anything above 6 physical cores / 12 logical had the potential to be impacted , and the severity of the performance issues increased the higher the core count.
Steinberg were essentially blindsided due to investing very heavily into the MMCSS optimisations , so without an easy or quick fix, they released a hack/workaround where by Cubendo could be forced to see max 7 physical / 14 logical cores.
For those with the higher core systems that were affected , it at least gave them the ability to stabilize the system until a proper fix was found.
For me that was nowhere near an acceptable solution, considering I had clients with up to 16 core / 32 logical systems that were needing to hobble the systems to that degree.
I assembled a group of like minded colleagues comprising of Professional DAW builders and we effectively lobbied via a trusted MS rep for a fix. This took many months of extensive effort from all involved to finally convince MS to offer an "unofficial fix" for the MMCSS thread limiting , which comprised of allowing the limit to be raised. This was applied to larger core systems and completely resolved the issue.
It was unofficial because it was not a permanent fix , nor will it ever be, and was overwritten by updates that saw the entries as rouge , but it did resolve the issue and we had procedures in place to deploy and administrate it.
Steinberg were offered the fix by MS , they had absolutely zero involvement in getting it across the line, nor had any interest in being involved in lobbying for the fix. They were simply the beneficiary, and to be honest, were very clumsy in how they deployed it to the affected end users that were outside of our immediate catchment, so to speak.
Fast Forward to Cubase 10, and Steinberg announce that the MMCSS issue has been completely resolved , no need for workarounds or patches. From the initial release of C10, lets say I wasn't convinced, there was something not quite sitting with me, which I mentioned numerous times in the podcasts, but I hadn't put my finger on it as yet.
We were getting some wild and fluctuating results with the recent CPU testing with AG On/Off as well, which I will detail later the report , as its a deep rabbit hole , but first I'll highlight one area that is quite obviously changed, and I am informed this is part of the MMCSS " fix " for C10/N10.
What we are looking at is Cubase 9 and Cubase 10 with ASIOGuard Off , on a 6 Core with a reasonably heavy session running around 200 RXC Plugins.
Both C9 and C10 equally load balance as expected for the 6 Core / 12 Logical as it is below the threshold of max logical cores even without the MMCSS Hack/Fix.
Move to the 8 Core / 16 Logical and we have a clear difference in how C10 is assigning and load balancing across the available logical cores on the same session.
What is being displayed is Steinbergs C10 MMCSS "fix" that triggers at anything above 6 Cores / 12 Logical , in limiting the maximum number of threads to number of physical cores -1.
Yep, thats correct, on an 8 Core / 16 Logical CPU you are allowed max 7 logical cores of the 16 , whereas a 6 Core CPU will allow you to utilize all 12 !
I also tested this system with 7 Cores / 14 Logical and sure enough , physical cores -1 , so 6 max logical cores.
Obviously this isn't making much sense to me, and I am expecting Steinberg to just dismiss it as irrelevant as it only applies if ASIOGuard is switched off.
But its not as simple as that, there are working scenarios where ASIOGuard needs to be disabled, and it isn't the magic bullet they claim it to be in all instances anyway.
Sessions that are at a processing level that is higher than what is available with AG off, when track armed can collapse as tracks are forced to the lower hardware buffer, so overdubbing can be a challenge, and thats being polite.
That does not happen with AG off , simply because the realtime processing is known at any given time at the respective buffer setting being used.
Track arm has zero effect !
All that aside, the fact that they allowed a 6 Core CPU to still have all of its logical cores available, but anything above they come up with this mathematical theory where they need to hobble the total threads below the max available on the smaller CPU, is simply inane
Whats the fix, no idea to be honest, Steinberg by all right should not even have the ability to disable ASIOGuard with this behavior active, IMO, and the bigger question is whether its a bug or by design.
This is only Part 1 of the curves recently navigated , and its relevant to plugins in this specific test, but its not reserved to just plugins, and applies to VI's as well.
There are more curves to navigate with multipart instruments like Kontakt as well, which have their own multiprocessing / load balancing in play , but that is a whole other chapter, as Steinberg recommend disabling the MP capability of any VI that has it available.
For now I can highlight that Kontakt's own multiprocessing will initially mask the fact that Cubase is pulling cores with AG Off , but it is no longer working in sync with the max cores that Cubase is allowing to be assigned and load balanced across, so there are more than a few variables being thrown in the mix.
As noted earlier Steinberg could simply just dismiss all of the above as irrelevant and state that ASIOGuard needs to remain on for optimal performance.
Fair enough , until we get into a working scenario depicted below.
DAWbench VI, 8 Core , session running at 064 , moderate load with AG On , very minimal resources used, delivering the benefit of the 23+ms playback buffer that AG provides.
Same session with a single instrument track armed, and we get an immediate spiked core and session collapse.
The above environment is what was being navigated on some of the last round of CPU testing, when a single track was accidentally track armed, resulting in the wild variables that were not immediately picked up on.
Further investigation lead us to this scenario , but inevitably has opened an even wider line of questioning.
Stay Tuned , the rabbit warren is going to be deep.
P.S. I scrolled back to the start of this thread and realized its just tipped over 9 years since I originally posted it. It was fun reading back on some of those earlier exchanges, definitely a different time but the testing is still relevant and continues to evolve
I haven't done a lot of testing apart from the Audio Interface LLP for a while, but now that I have dipped my toe back in, I am returning to posting on this thread for all other performance reports , suite and podcast announcements, etc
The No.1 Website for Pro Audio
Latest
Trending
). Was just afk, paying the bills, writing the tunes. I hang out over in the SOS forums mostly, where Vin has parallel running LLP and Dawbench threads in their PC Music forum (seems he has closed his own forum). 
)
