I too have made many optimisations on my pc. But that is not the issue here. What I am highlighting - the way Cubase takes over the core handling from Windows - is a well established fact. A bit of googling on Gearspace - particularly the thread “Today we build our studio pc” - should make that obvious.
Thanks for trying to help me, though. That is much appreciated. But what I really aim for here is some kind of statement from Steinberg.
I am very happy with Cubase. But core handling is the one area where it has ample room for improvement.
Hi @pmallett57 , Steinberg tester here. You probably could benefit from raising the AsioGuard level to high. If your instruments are not heavily working all the time, there’s a chance that this helps balancing out the load.
Another typical issue is the automatic Rec arming of selected VSTi and Midi tracks. For those tracks, a red REC button moves that track into real time mode. This means, the connected VSTis and all parts along its signal path are processed with the short latency of your hardware settings (in your case, the 128 samples). This can lead to heavy overloads. Be sure to not have a VSTi selected accidentally. The Performance Monitor can help to detect such issues.
In both cases, it’s not the lack of CPUs used by Cubase, but the dependency along the signal path, which cannot be processed by parallel threads on separate CPUs.
I hope this was helpful.
And @Magnus_N : regarding the idea that we are trying to “outsmart” the Windows scheduler: We don’t. Our code was designed when schedulers were way less smart (and dedicated to audio processing) than today. But we can’t just switch the way we do our audio processing like we would, when we were building Cubase today from scratch. Changing such fundamental code takes time and caution to not break the rest which is working fine.
And thank you so much for replying and commenting. I fully understand and respect that the task at hand may take time. I am very happy to hear that you are working on it, though. I am in no hurry.
As I wrote, I am very satisfied with Cubase. This is the one and only area where I am hoping for improvement.
Anyway, thanks again for confirming that Steinberg are aware of the issue and addressing it. Cubase is great, and I love it. And I look forward to it becoming even better!
It’s nice to get some validation on this topic. Hopefully this outdated fundamental code can be updated sooner rather than later, it’s a major problem for people who have Cubase performance issues.
While I don’t dispute this is sound advice, in some cases however, moving a track from the ASIO Guard path to the realtime path can prove beneficial when ASIO Guard becomes overloaded.
I read Chris’ response twice and didn’t see anywhere where they actually confirm Steinberg is actively working on updating the core audio engine of Cubase. I do wish that they are though.
It’s been hinted at more than once before that re-writing the audio engine is a monumental task due in part to its age and non-modular architecture. At the same time it has also been suggested that Steinberg is working on upgrading its code base so it is likely just a matter of time before they will tackle the core audio engine and all that goes with it.
I found significant change in performance between version 10.5 and 14. From 13 onwards I have to use higher buffer settings to avoid dropouts but this, of course increases the latency. This is not related to any VST. A project with one audio track with enabled monitoring can show decreased performance. Version 10 seems to be the last one not affected by this issue.
Belive me or not but I know how it is to improve performance in a big and long term project. It’s tens of staff months but doable. The only problem is to convince senior management to agree spending money on this.
How about giving us the option to switch to native core handling till all the kinks are worked out? It doesn’t necessarily have to be one or the other, right?
Yes, I’ve noticed roughly that same pattern. 10 was quite good, 11 & 12 were worse, and 13 just fell off a cliff which didn’t change at all in 14 for me from a performance perspective. This very problem… I’ve tried EVERYTHING: Defender exclusions, the whole nine. Process Lasso tweaks especially the one denying Cubase access to Core 0 seem to be the only things that make a significant difference.
For a piece of software this expensive, one would hope that this is one of if not the biggest priorities for the company.
Yup. This aspect of Cubase for Win is subpar. Steinberg did rewrite the audio engine for Apple Silicon, apparently, so let’s hope they do this for Windows as well. And asap…
Thanks for joining this conversation. Martin. But I am a little bewildered as to why you post here about the update. The version history mentions nothing about core handling.
This is more a Windows scheduler issue than a Cubase issue and it was discovered since people started having performance issues with high-core count CPUs (over 64 cores/threads) under Windows.
The issue is not with Windows, but how Cubase handles cores on Windows. Reaper handles this well on Windows. And Steinberg addressed this successfully on Apple machines.
which scales well with other DAW’s like Reaper ….. Reaper leaves the scheduling to windows/Mac OS an doesn’t get in the way or try be clever…
Steinberg decided to outwit the windows scheduler IIRC and while it worked originally with quad core PC’s etc it’s now a big issue as we can see.
I can hit 100% ASIO guard and therefore the limits of my machine and only see my machine running at 16% …. I’ve got 32 threads with 80% of their perfomrance doing nothing yet Cubase is maxed out.
this happens on projects when mixing and using lots of Aux and bussing.
copy/paste an audio track with some plugins on and Cubase will scale well. Unfortunately that’s not how most make music.
