I fully understand that you’re eagerly waiting for improvements, but we’re not planning any major changes in this area within the Cubase 15 development cycle. Because of the high complexity and interdependencies involved, these efforts need more time if we want to get it right.
Thank you, Matthias, for letting me know. It is, however, very disappointing, since Cubase on Windows, in its current state, is unable to utilise more than say 30% of the latest cpus total processing power, particularly in mixing projects like mine. So this is bad news, as you are basically stating that Cubase will remain in this crippling state for at least one more year.
Audiogridder is one workaround, but it shouldn’t be necessary to turn to third party freeware to be able to use Cubase on Windows in a more satisfying way.
I was hoping that the core handling would be addressed in C15.
All the best,
Magnus
Hi Magnus, I’m on a Mac and haven’t run into any issues in this area, but for reasons unbeknownst to me I read this thread (nice to see Steinberg answering questions). I’ve used reaper too and remember some discussion there as well about maximizing core distribution performance by handling routing differently - I think it had to do with not using master parent send or not doing mastering on the master channel but rather an a sub master. Might be something to investigate if you decide to switch daws, or maybe there is a way to hack your Cubase setup to distribute load differently in the meantime (maybe split mastering chain over a couple group tracks?). Just thought I’d mention after reading this discussion.
Hi Elessar,
Steinberg rewrote the audio engine for Apple OS, so Cubase is very efficient on that platform. On Windows, it is another matter completely. These issues are very well documented, and addressing them should be top on Steinberg’s to-do-list.
I am considering Reaper, but like everything about Cubase - except that it is so stunningly under-performing in utilising the full power of modern pc cpus.
All the best,
Magnus
I’ve seen this mentioned several times here, but while I agree that Cubase runs very well on Apple Silicon systems, our team didn’t rewrite the audio engine for macOS. That’s simply not the case.
Thanks Matthias for your great work. Really appreciate your honesty and the good explanations. Keep up the good work.
Cheers Paddy
The problem is though @Matthias_Quellmann this doesn’t show itself in the windows taskmanager when looking at CPU threading/performance.
If ASIO guard meter correlated with a single core it would be easy to see and would be understandable when looking at the cubase and windows CPU meters.
The mix projects though where ASIO guard gets overloaded , when looking at the windows CPU meters do not show ANY core/thread being utilised to anywhere near 100% so it makes it all the more confusing as to what is happening.
Regarding the Apple silicone recompile: Can you tell us on AS whether Cubase or the OS takes care of thread scheduling? We know that on windows Steinberg does it’s own thread scheduling , and this is part of the problem now in 2026. The million dollar question though is …..
Is this the same on Apple silicone?…
M
It’s hard to say much about the CPU meters without knowing your project, settings, and system. But in many cases, performance issues like this happen when a lot of processing ends up on a single core, which is likely what’s causing the limitations you’re running into.
Just a heads-up: this is getting pretty deep into technical details, way beyond my expertise. But if the tech-heads in this thread cut me some slack, I’ll try to explain this in my own words:
On macOS, our audio engine communicates with the operating system through the Workgroup API. With this setup, macOS handles the thread scheduling based on the information it receives. So again, we didn’t rewrite the audio engine for macOS, we just use the available API to improve the communication.
Whether this is part of the problem or part of the solution is up for discussion. It’s important to understand that audio engines in complex DAW environments all work differently. What works well for one DAW might not be the right approach for another.
Our team is evaluating different strategies based on the infrastructure provided by the operating systems and the hardware. Making our audio engine more flexible and robust gives us the freedom to try different approaches and adapt to new developments.
As I mentioned before, I’m here with good intentions and I’m doing my best to answer your questions. All I’m asking for is respectful and constructive communication. My tolerance is pretty low for the kind of communication habits some users are used to in other corners of the internet.
And it’s very much appreciated.
I’ve been following this thread as an Apple silicon user and I agree that Cubase works effortlessly on my MacBook Pro. I’m quite interested in Cubase on Arm64 and the Snapdragon stuff looks good. I am a huge fan of the fact that Steinberg spans Mac silicon, Mac intel, Windows x64 and Windows arm64, I think that’s an enormous achievement 
Steve.
It’s hard to say much about the CPU meters without knowing your project, settings, and system. But in many cases, performance issues like this happen when a lot of processing ends up on a single core, which is likely what’s causing the limitations you’re running into.
This is exactly what happens and what needs to be addressed. One workaround is Audiogridder, which seems to distribute the processing load more evenly than Cubase on Windows. This means that Cubase handles typical heavy mixing sessions with groups and busses etc in an unsatisfactory way, where Asioguard overloads when perhaps only a third of the available processing power is used.
I mean this in no disrespectful way, Matthias, but it needs to be addressed asap-ish.
On macOS, our audio engine communicates with the operating system through the Workgroup API. With this setup, macOS handles the thread scheduling based on the information it receives. So again, we didn’t rewrite the audio engine for macOS, we just use the available API to improve the communication.
You did, however, rewrite code to make this work. In exacly this way, Reaper, for instance, lets Windows do the thread handling, with excellent results in heavy mixing scenarios. Why can’t Cubase leave this Windows as well? It seems a logical and satisfactory solution.
I understand that Rome wasn’t built in one day, and that things like these take time. But the new multicore cpus are years old by now, and this issue remains for Cubase Windows users.
All the best,
Magnus
Meanwhile, keep in mind that while the grass is always greener on the other side, one popular DAW from a vendor with a lot of vertical integration and its own platform doesn’t even seem to use the efficiency cores on said platform and at least in synthetic tests, Cubase performs much better. Now try to find the logic behind that…
Dear Matthias, thank you for your replies.
Rest assured that the vast majority of us value much positively the fact that people from Steinberg read and answer our posts.
Please do not pay any attention to those disrespectful users. Some of us may be a bit heated sometimes, but all we should try to keep good manners and proper respect to everyone.
What tools like Audio Gridder, Vienna Ensemble, or Patchwork do is take the plug-in processing out of Cubase’s main processing chain. This lets them run heavy DSP in a separate process and on a separate core, at the cost of some extra latency.
Of course I can’t comment on how other DAWs handle cross-platform real-time thread prioritizing. What I can say is that a strategy that works well for one audio engine might not be the right solution for another. If it were as simple as applying the same approach, we would have done that already. Why wouldn’t we?
Is that not what Aiso gaurd supposed to be for?
ASIO-Guard follows a completely different concept. It works on the track/channel level inside Cubase’s own audio engine, while tools like AudioGridder offload the processing of individual plug-ins. ASIO-Guard pre-calculates the audio of tracks that are not part of the real-time signal path and prepares their results ahead of time. In contrast, AudioGridder runs plug-ins externally and processes them in parallel, outside of Cubase’s real-time thread.
There are many models of processors and motherboard chipsets in the wild. It’s possible that changes could be helpful for a few of the most modern builds, and terrible for everything else (maybe even making things worse for the majority of Cubase users).
It’s also possible that the way Wintel motherboards, audio interfaces, and their drivers for Windows are designed, that the bottle neck in putting more cores to work comes from some other system limitations aside from simple CPU core allocation.
I’ve seen many strange things with Windows builds over the years. I.E. I once had fits with pops, crackles and ASIO overruns that I never could get rid of. I had both Intel and AMD builds and the same problem (but peers with similar builds didn’t have the issue). The problems went away with instant renders, and way more of the system resources seemed to be getting used with instant renders.
I ran every latency and performance test I could find, and nothing obvious popped up. One day by total accident I found the problem. I changed out some hard drives that were hosting sample libraries and projects, and realized that it was one particular brand/model of SSD drive that was causing ALL of my Cubase issues, as it had some kind of IRQ going on in the drivers that made ALL of my audio streaming apps pop and crackle (Not just Cubase).
The point to this little anecdotal story is that any given system build can have strange hardware/drivers/configurations that will ultimately impact real time system resource allocation. I’m not sure if it’s possible for Steinberg to predict and have some hacky ‘work around’ for even a fraction of the funky things hardware/drivers can do to a Windows build.
As for options like VEP and AudioGridder, I think it’s important to realize that each plug in instance is pretty much a stand alone deal. AG isn’t running complex latency inducing plugin chains per channel while also mixing and processing multiple streams in real time (aux sends, groups, etc). It’s also able to be a bit more discrete since it just needs a clock, and sends streams over networking protocols (in adjustable packet sizes) instead of to an Audio Interface that’s going to have pretty strict rules on things like data packet sizes and timing. If each plugin is more or less sandboxed in its own little world, then of course the system can more freely pass the load to whatever core is best for the job at the moment. Under this scenario, it’s also way less likely that an idle plugin is using resources….in contrast, if you have it in your DAW, with 2 aux sends, plus a chain of effects….then even if the base VSTi isn’t making sound at the moment, all those other plugins still use resources, and having those aux sends and group routings will keep the track/channel bound to other processes that require a common clock/buffer/stream.
No, I’m not just trying to make excuses for Steinberg on the matter. It’d be nice to get our money’s worth out of a high end system build without manually sand boxing aspects of a project that can run that way, and in theory, it should be working some better than it is.
My only point is that it’s not that simple. It’ll take time, and it still probably won’t work for everybody that installs Cubase (might even turn out worse for more modest system builds).
With the new Mac OS and Architecture…it is possible that Steinberg simply got ‘lucky’, and the compiles ended up working like a charm. The system architecture is quite different from the old Intel setup, plus, if/when tweaks and changes are made to it, there are only a few CPU models and chip sets, and maybe few dozen (if that many) Mac models out there to run tests.
If configuration issues with the operating system, the audio hardware in use, drivers and the general system setup are such a big issue in regards to Cubase performance than Steinberg should assign some employees to dedicate their focus on troubleshooting and research. Where their main task is to analyze users Windows trace files, build and test different system configurations and to provide regular publication updates to the Cubase user base. Help users to build a system that will not have issues with Cubase performance.
For example, if the Steinberg “Windows: How to set up and optimize a Digital Audio Workstation” guide is so important to avoid Cubase performance issues than I would expect this publication to be provided here on the forum, in the Cubase Hub, in the Download Assistant, and possibly even on the product page itself instead of being hidden away in the Help Center.
It’s truly dis-heartening when people post on the forums saying things such as “i’m having Cubase performance issues on my AMD 9950X or my Intel 285”. These systems can cost $2,000, $3,000, $4,000, $5,000 and upwards and most users simply do not have this amount of disposable income to keep buying new systems or replacing hardware components to try and figure out what is causing the issue with Cubase performance.
I feel like troubleshooting is one of the weakest areas in the DAW industry. It would be nice if companies were more pro-active in regards to troubleshooting.
Just some food for thought.
Can you please inform us what the brand and model of these SSD drives were ?
One problem here is that DAWs are a niche usage for systems like Windows. macOS always had a bit more focus on media production, but it also has its shares of issues.
A dedicated Linux distribution might actually be interesting, you could even have realtime kernels there. Who knows what the future holds.