I would switch to linux in an instant if it supported all of my general apps and games.
Let’s not let this devolve into a Linux thread. 
Well we would be using Linux right now if it held the market share, and it would be to all of our benefit. Lets hope the future is bright
SATA3: PNY: The series was SSD9SC(size)GLA-XLR, the units were tagged as having Firmware 5.6.0. I had purchased half a dozen or so of these in various sizes.
They seemed to perform well for anything but realtime d2d streaming. They had outstanding burst mode speeds, so I kept them around for other applications, but anytime I ran the daw I pulled sleds with those drives out! I avoided using them for system drives too.
This was several years ago. I’m not aware if any firmware or driver updates happened. I still run a few of them, but just for storage of a few games I still like to play and smaller daily mirror type backups. They do fine for the video games.
We are probably getting caught in semantics more than definitive technical descriptions of the under bonnet pinning involved, but when I refer to the audio engine, I am referring to thread management routines , and also how ASIOGuard and the engine arbitrates with those routines.
You are deflecting , Steinberg are well aware of the session logistics and dynamics that result in ASIOguard accumulating and overrunning prematurely. Its more than the usual excuse of the serial processing overloading a single core, as that is not always the case, but C14/C15 does seem to load core 1 ( 2nd core) far more than previously. We are also dealing with multiple serial buss instances , so if everything is landing on a single core, that is showing that something is amiss in how those busses are being arbitrated.
And there we have it !
If the same code practice was applied for Windows thread management routines, via the appropriate API’s to arbitrate the threading assignment via the Windows OS Scheduling, we would be seeing thread management and multi core performance and scaling akin to Reaper in these session logistics causing the issue in Cubendo.
And we are now having the discussion.
What ever the team are doing at the moment regards thread management on Windows is clearly not delivering the results, and we have been stepping around this minefield since the whole MMCSS threading debacle, which was never resolved correctly IMO.
A lot can be lost in non verbals, so someone being assertive may come across as being disrespectful or aggressive, which is not the intent.
Its also a 2 way street Matthias , and I understand you drew the short straw and are the public face of attempting to address this , but this has been communicated and navigated directly with members of the QA and dev team for quite a long while, and I have contacts in BETA as well that I know have navigated this area, and nothing seems to get done , except more excuses of why it can’t be done quickly.
The MMCSS threading mess was 2017/2018, Intel 12th Gen Hybrid architecture was 2021, threading behavior for AMD Ryzens have been confused since the optimizations for the Intel Hybrids , etc, etc. What ever needs to be done to align the thread management routines with the correct code practices used with the Apple OS , to Windows, aka handing the thread management to the O.S and associated, can’t come soon enough.
Of course there is no one size fits all, but there are preferred code practices that can be followed that will address a lot of the issue, which some DAW’s do, some don’t.
Technical Debt !
It’s always interesting reading posts from people who have in more in depth backgrounds, are more knowledgeable, experienced and are more technically savvy. It definitely makes the story more interesting.
I love it when users like this contribute their thoughts 
There are arguably way more Wintel systems in the wild that ‘focus’ on multi-media than Macs.
I have nothing against a Linux build, but that platform, running on the same seemingly unlimited choices of hardware as Windows, is pretty deeply uncharted territory. There’s no guarantee that the OS doesn’t end up with similar hardware/driver bottle necks as Windows. There simply aren’t many systems out there using it in hard core DAW applications to get much data on it. Intel Macs are a good reference point, and Mac OS on Intel had similar, if not identical performance bottle necks as Windows.
I understand linux is more common with live audio apps these days, but then again, the last ‘streaming step’ tends to be more linked with networking and IP protocols than with audio interface hardware/drivers. Maybe that’s something to consider when designing audio interfaces in the future? Maybe they should all tie into the networking protocols instead of directly accessing hardware? I dunno…
If the motherboards/chipsets and interfaces/drivers put up bottle necks (the gate is only so big, only allows so much to go through, and opens/closes only so many times per second), no amount of core reallocation can fix that. ALL of the cores are sitting around ‘waiting’ for a turn to access the hardware anyway.
Seems to me like multimedia R&D dollars might be better spent looking at motherboard designs for Intel/AMD that are more optimized for mixing/processing audio. Still, it’ll be an interesting challenge to make that happen and not ‘break’ hardware/drivers that people already have.
Apple M and ARM platforms are much newer, and whatever they’re doing with the motherboards probably has a LOT to do with why they seem to be better at multi-threading audio apps better than Wintel. Somebody took a whole new approach to how hardware can take over memory and communicate with the CPU.
I don’t have any numbers to objectively argument here. It’s quite possible that the absolute number is similar or maybe larger, but since the total market share of macOS is so much smaller, I certainly think that media production systems make a bigger share of macOS installations than they make of Windows installations, that was the point I was trying to make.
Music production, video editing and graphics have been core markets for Apple for a long time (well, at least for the Mac, iOS is another story), why else would they have bought products like Logic and Final Cut? But Microsoft has much larger core markets in other areas, so media production simply doesn’t have the same weight and has to compete more with other areas.
Perfect moment for Pete to step in but I’m guessing he can’t here 
Perhaps sb has already set this type of test structure. I’m certain they’re not oblivious to what you’re saying. If the test approach is then breaking 40 other things in the overall code structure, that would put the situation beyond your suggested solution…..wouldn’t it?
I hear that statement on a regular basis, and it sounds good in Mac Vs PC advocacy discussions, but I don’t believe it’s true.
I’ve spent a lot of time in all sorts of broadcasting, production studios and educational labs around the USA, and I can flat out assure that there are multitudes more Wintel rigs out there ‘focusing’ on multi-media than there are Macs. Hands down. Windows options simply offer way more range in gear, mass deployment tools, multi-user licenses, and more. You also get a much broader range of budgeting and financing options (including bulk deals or leasing arrangements through third party contractors). I.E. If you’re setting up a teaching lab with 30 workstations, you’ll want to be able to set up and manage as much as possible on all 30 of them from one master server/pc/location, and they need to be able to share a lot of existing hardware that’s already part of a larger ‘system’. It might even be better to contract and lease the stuff than to outright own it, and the list goes on. Macs do have a place in mass scale implementation plans, but currently it’s not to the degree and scale of stuff from the open architecture nature of the Wintel world.
The better mousetrap doesn’t always win the race if the tools for getting real world Purchase Orders and implementation plans aren’t there.
The thing to realize is that the vast majority of people doing multi-media are doing specialized portions of post production, and don’t need the highest end gear to meet their needs and objectives. A midrange system and a cup of coffee may even be overkill for most of them. If they do their homework and avoid trying to ‘edit’ with formats that require real-time encoding, it doesn’t require much CPU at all! It’s just those last stages of encoding it into whatever distribution format(s) are desired. To top it off, 2/3rds of them dump it on a server for distro in the wrong format anyway, and whatever server they send it ends up having to ‘reencode’ it anyway.
Since the M1 hit the market, and Apple now has some competitively priced entry level options (The Mac Minis are a great deal for under $600), so this may well change over the next decade or so. We’ll just have to wait and see.
Thing is, for Mac to really take over, it’ll need to do more than run more plugins than everything else before it chokes. It’ll need tools for mass deployment and key management, solid legacy support (work with more existing hardware), and much more competitive pricing.
I really try not to get involved in threads like this. I like Steinberg and I like working with them, and I like Cubase. But I’m also not going to comment one way or another about how an app is coded, as that is really not my place, nor is it anything I could share with anyone even if I did know any details.
Apple’s Workgroup thread API/model is nice. I couldn’t say how much impact it has performance-wise as folks have pointed out that Logic doesn’t use e-cores, and there are other DAWs on Windows that can tap out a pretty beefy CPU.
Pete
Microsoft
Thats the technical debt I am hinting at, essentially they have got themselves into a situation where fixing one thing could break 10, but what ever they are continuing to do in an attempt to circumnavigate, is never going to resolve the issue, IMO !
These are very fair points. Maybe also my use of the term media production was not very good and „content creation“ would have been better. I was thinking more about songwriter/producers, video production for YouTube etc. and graphics designers rather than broadcast or more industrial media production.
As you mention, Apple is too „boutique“ for many of the latter use cases and if anything, I see them rather move away from enterprise usage than towards it (except again for iOS maybe, but even there you‘d have to rely on 3rd parties like Jamf for management).
Well it’s nice to hear that at least someone from Microsoft is working with Steinberg
Yeh , thats an odd one when 3rd party DAW’s on MacOS are using the E-Cores “unofficially”, and I have watched a recent video where the E-Cores are only used “sometimes” with inbuilt plugins on another DAW, but using 3rd party plugins drops them out again ?
Not confusing at all !
I digress
I hope the community understand that this thread is under heavy sanitisation.
Three of my posts removed today.
I don’t use Windows for Audio work, so I have nothing else to say on the subject.
Most of the time, that stuff (especially when it happens almost right away) is from things like spam filters, not folks sitting around waiting to remove your posts.
Pete
Microsoft
Very happy to see @Matthias_Quellmann talking about this and interacting in this thread. It’s the kind of subject that stirs up passions in some people, of course, and I appreciate that Steinberg is jumping in to this thread – sanitized or not sanitized – to communicate with the community.
Communication is a GOOD thing for Steinberg to be doing, and I encourage Steinberg to keep doing it! Thanks also to the community for keeping things polite and professional.
Also happy to see Pete @Psychlist1972 and @TAFKAT jump in. I know Pete won’t say more for various logical reasons, and frankly it’s just good to see he’s monitoring the thread. I hope Pete’s and Steinberg’s relationship continues to flourish. I love what they (MS + Steinberg) have done recently together, so please keep it up!
It sounds like by Cubase 16 we’ll hopefully see some improvements. Cross fingers. While I wish they would come sooner, I understand the delicacy of changing something this fundamental that risks breaking things.
Please keep the communication coming, Steinberg, it makes a difference, even if the reality means that it will still take time to make significant improvements!
Cheers to all!
Story of my life. 
Luckily I haven’t been appointed yet to discuss our latest UI design decisions, the VST3 SDK MIDI situation, or why we still haven’t implemented that one feature EVERYONE has been asking for for decades.
Jokes aside, I really am here with good intentions and I appreciate your input and the work you’re doing at DAWbench, Vin. I’ve actually listened to a couple of your podcast episodes over the last few years and really enjoyed them. My remark about asking for respectful and constructive communication wasn’t directed at you. After spending so much time in this forum over the last 15 years, I’ve learned to focus my time and energy on meaningful exchanges rather than on sarcastic or provocative comments.
It’s not my intention or my assignment to make excuses, deny anything, or deflect. If it came across that way, it’s probably because I’m not an expert in the finer points of real-time thread prioritizing and I’m trying to answer these questions in my own words.
So let’s get straight to the point.
Are we aware that there’s room for improvement in how our audio engine performs on modern CPU generations on Windows? Yes, absolutely. And our team is actively working on new strategies to address this.
Are we dealing with technical debt? Yes, of course. And that really shouldn’t surprise anyone. This software has been evolving since 1989, and the audio engine has gone through many iterations and adaptations, shaped by different people, approaches, and strategies. These are just the facts and the reality we’re working with.
I’d just like to point out that statements like this are personal assumptions from the outside. I fully respect your expertise and the empirical work you’ve done over the years, but whether a specific strategy delivers the expected results can only be judged by our team. They work on the audio engine every day, they understand its unique architecture, its interdependencies, and its scheduling strategies, and they’re the ones who can properly evaluate the available options. That’s simply a fact we should agree on if we want a meaningful and respectful exchange.
I’d also appreciate a bit more goodwill toward our team. Especially regarding expectations around when certain improvements can realistically be delivered. Our team tends to take a conservative and diligent approach, and that’s partly because of the complexity and responsibility they have on their shoulders. And again, that’s not an excuse. I’m just trying to explain why things take time and may sometimes appear slow. Performance optimization is a high priority at Steinberg, and that’s not going to change. Would I like to see results faster? Of course. But I trust my colleagues, and I know they’re giving their best.
Just a quick comment on Pete’s involvement: Pete is kind of a regular at Steinberg, since he has worked closely with our teams on projects like MIDI 2.0 and Windows on Arm. @Psychlist1972 , I appreciate you following along!