Seeing similar results on an M4 Max Studio with C15/C14 here.
I have a project with around 30 tracks, mostly VST instruments / FX, but with minimal Group / routing. 96 / 128.
AsioGuard craps out with the total CPU at 22%. [ Core usage all spread out ].
Lowering buffer size doesn’t really help. Doing the ‘record-enable Halion’ trick does [ but it’s a bandaid ]
The same project [ via DAWtransfer ] plays fine in Bitwig 6 beta [ which cannot access all the M1 cores ] and does really well in Reaper.
I was wondering how that might affect the results mentioned in this thread. I haven’t needed to use it on my new (i9 285k-based) Windows 11 system thus far, but on my 11-year-old (i7 5820k-based) Windows 10 system it often meant the difference between being able to have playback work at mix time and not being able to hear what I was doing due to the audio engine’s not being able to keep up.
The key thing that workaround does is force a real-time audio engine thread, which, at least on my old Windows system, ended up balancing the CPUs better instead of having the first CPU thread overloaded. It’s interesting to hear that it works on modern Macs, too, as I’d only heard it discussed for Windows previously.
I’ve often thought it might be helpful in situations like this if Cubase displayed a detailed thread map.
When a project reaches a certain complexity and signal branches must be combined, that process of creating the combinations can be more art than science. That’s why seemingly random perturbations can sometimes improve performance.
In such a situation, a tool that displayed the map and allowed the user to tweak it, could possibly permit the user to improve on the mapping that Cubase does on your behalf. Of course, it could also open a can of worms 
.
I suspect that, at least for most Cubase users, the can of worms opening, or just feeling like someone is speaking to you in Martian, would be a strong likelihood. 
Then, for some of us (and I include myself in this group), it would get us at least jumping down some rabbit holes and experimenting, whether or not we ever found anything that was consistently useful. (Side note: Back toward the end of my period of using SONAR, while I was just starting up with Cubase 9.5, or maybe 10 by that point, I was working directly with Cakewalk’s CTO, who was having me try various performance configuration possibilities with the significant tuning possibilities offered in SONAR. Though I religiously tried all the things he requested and reported results back, ultimately, nothing addressed my issue, and I actually found I got at least a little more mileage out of Cubase on the performance front, specifically with my relatively heavy virtual instrument use – all my tracks other than vocals tend to be virtual instruments. That may actually have been due to ASIO Guard, or perhaps the combination of that with the Steinberg Power Plan though I’d also been using a high-performance power plan with SONAR.)
For the case of the “HALion trick” – i.e. adding a new instrument track with HALion (or really any relatively lightweight virtual instrument that doesn’t just hog a bunch of CPU when doing nothing) and giving it the focus so Cubase has to be ready to let the user play through it in real time – though, that was pretty consistent in making a difference, at least in my case (starting with Cubase 14, which is when I first heard about it on a Facebook group and found it worked, at least until you got up to a point where nothing would help enough, such as if Ozone’s music rebalance module was active in my case). And the Windows Task Manager clearly showed a difference in the CPU balance:
Thus, my question in later threads on the general subject (and also included in the “additional comments” section of my response to the annual Cubase feedback survey) was, since this is consistent, is there something Cubase could do internally to force the same result without having to add a virtual instrument thread with the focus? (While the workaround might seem pretty minor on the surface, a problem was that, if you had to do something that took the focus off that track, such as if you’re want to work on another track in the context of the mix where the focus needs to be on that track, not only would the audio engine dropout recur, but it also could sometimes make for big audio spikes at the transition of focus.)
That might be an interesting idea. I suspect the reason it works is because it causes a shuffling of the thread assignments. A button that tells Cubase to shuffle those assignments might accomplish the same thing without requiring the addition of an unwanted track.
I suspect that’s ultimately the issue in these cases where the same project works better in another DAW: that other DAW is using a different assignment scheme than Cubase. It’s difficult for the DAW to determine a priori what the “best” scheme is, but If you could press a button to instruct Cubase to try to find an alternative scheme, that might solve the problem in many of these cases.
I’d read about it in a thread here and had tried it before but it didn’t seem to have much effect. However, with this particular project the combined meter level dropped by maybe a fifth after record-enabling the Halion track. Pretty amazing.
I’m wondering why the difference would be so obvious for this project though, probably to do with having a lot more VI’s over audio tracks.
I’m not a computer expert; I know nothing about computer programming—I’m just an ordinary musician. The problem with ASIO Guard’s performance utilization has really bothered me for a long time（Now ，to cubase 15）. My CPU is an i9 14900k—there’s no better CPU than this (it’s a figure of speech)—but in my mixing projects, ASIO Guard often touches red, and the CPU utilization rate is indeed less than half.
I’ve read many forum posts on how to boost CPU utilization and came across methods using third-party tools (I use Lasso). After testing them out, I found that adjusting the affinity settings for CPU, I/O, and GPU and locking Cubase to P-cores while assigning other processes (like chat apps) to E-cores significantly improved Cubase’s performance. For the same project that used to trigger red alerts before, ASIO Guard now has nearly 1/4 headroom left and barely any peak surges.
From the perspective of an average computer user like me, there’s no doubt this is a problem with ASIO Guard’s scheduling.