Around the same time as the original thread I linked above, there was another, at least somewhat related thread, in which @Ed_Doll of Steinberg mentioned they were looking into how processor affinity might come into play in some of the differences in audio engine performance between Cubase 12 and Cubase 13, saying there was a possibility that changes they made to improve things for newer hybrid CPU environments may have negatively affected older, non-hybrid CPUs, but they were still investigating:
I seem to remember there was a maintenance release for Cubase 13 that had a note that suggested some change may have been made in this area, but, if so, it didn’t appear to make a difference for my (older, non-hybrid) CPU. And, until seeing this thread, I’d forgotten about the record-enabled HALion track trick to (potentially) improve audio streaming behavior at mix time (when I tend to be using heavy CPU usage, and high latency plugins that often get to a point where my CPU, or at least something in the audio buffer supply path, can’t keep up).
I’m not sure what you’re alluding to here, but, just doing a quick Google search on the topic, I did come across Google’s AI-generated response that talks about the difference in buffer size behavior when there is a record-enabled track and ASIO Guard is in use. The main part of the response says:
When a track is record-enabled in Cubase, it utilizes a smaller buffer size within the real-time path, which can strain the CPU. This is because all calculations must be completed in time to fill the buffer, otherwise, audio dropouts may occur. The ASIOGuard path, used for other tracks, employs a larger buffer to prevent dropouts but introduces higher latency.
Of course, what seems to be happening here is that, although CPU usage goes up overall, Cubase does a better job of supplying the ASIO Guard-related buffers in time for streaming, assumedly due to the more balanced allocation of CPU threads that my screen shots above show. Perhaps having to give higher priority to the real time thread (which doesn’t actually have buffers to supply to the audio engine in this case) somehow lets Cubase distribute the ASIO Guard threads a bit more???
From what CPU usage would seem to show in the non-HALion case, it’s not like the system overall is overwhelmed, but the net is that Cubase can’t supply buffers quickly enough (and I’m using the highest buffer size my audio interface supports – 2048 samples at my project’s 96 kHz sample rate), so audio dropouts happen. But why this improves when the real-time thread is added???