I was hoping to understand deeper what’s going on with these images. It would appear that despite the fact that I have multiprocessing ticked in both the Cubase 7.5 and Cubase 8 settings, they are really only using part of my computers processing power. Why would that be?
I don’t understand how Cubase utilizes CPU so maybe someone would be so kind as to help me understand better.
I know there are lots of threads right now on how current iterations of Cubase are performing, but I would like to ask a more generalized question about why this condition of the Mac Activity monitor never has the CPU go above 20% usage while the Cubase one is floored.
Cheers and many thanks for any and all input.
-JB
MacPro 6,1 6x3.5Ghz - 16gb RAM - Cubase 7.5.3 on first pic - 8.0.5 on second.
I’m no expert on CPU load balancing in Cubase but will try and offer some insight from a software engineering perspective (my day job).
The two meters are measuring different things.
Apple activity meter measures the overall CPU processing load - this means exactly what you would expect - I am using 20% of my processor and wasting 80% of the available cycles on it.
Cubase activity meter measure REALTIME CPU processing load for the audio pipeline. All of the work for every instrument and effect must be completed before the audio buffer runs out otherwise you get a glitch.
The realtime requirement means that the slowest part of the audio chain will determine how much utilisation you can get. Note this isn’t just the CPU calculations, but all processing interrupts, fetches from memory, cache hits, IO, etc. If the CPU has to wait or an effect or instrument takes a lot of cycles to run then you’ll be able to use less processing power in the available time. Having multiple cores does help but you still have the limit of the slowest realtime path as somethings can’t be done out of order.
As I understand it ASIO Guard tries to help with this by computing tracks that don’t have realtime requirement “ahead” of time using excess processor cycles that aren’t in the realtime path, thus leaving more realtime cycles in future. You should expect that ASIO Guard would increase your processor utilisation overall.
I’d be fascinated to read design paper on how Steinberg organises all this internally. Strikes me as quite difficult given all the factors that are outside their control (driver and plugin implementations come to mind). At times I think its amazing it works at all!
