Load balancing chitchat...


I was wondering about cpu load balancing… And processing distribution…

See, some vsts are super heavy on the cpu nowadays…

Well, my cubase “average audio processing load” meter is in the red and while the crackles give a nice vinyl effect, i dont really like this meter in the red since it does not give me pleasant saturation or distortion…

But wait, what is this? The windows task manager cpu-usage is only at around 50%… - meaning, if there was a better load balancing, i could totally rock this sound without crackles…

Ah, yes, i hear that good 'ol cpu sync one core per vst talk… (Or something like that)…

But i must throw this in the room again:

Do you think that a better load balancing of cpu processing power among vsts is possible somehow?
(I.e. Split one super heavy vst up among cpu cores) - maybe with some kind of “syncy container”?

Please share your thoughts on this matter…
(- yes, is it possible / no, it isnt possible because / should steiny follow up on this / yadda yadda…)

My thoughts?

  • my cubase meter is in the red, i should have 50% more power (one core is maxing out, the other is nearly idle) ,
    i think this should be realized if possible…:stuck_out_tongue:

Happy everything, everybody:)

For the here and now - I’ve read that Cubase will always assign a complete channels to a single core. If true, it may be advantageous to split CPU-hog plugins among different channels.

Hmm, maybe that’s why the “8 insert per channel” limit is in place …


Sometimes, some man made laws are meant to be broken if they do not promote goodness, well being, integrity,
And do not have our advancement in mind…If they are not here to serve us but to limit, enslave and destroy…
(Like witch burning laws etc)

But , i never thought of moores law to be in this category…

Yes, we have multicores and such… But… We should have surpassed the 20Ghz cpu by now… We have been hovering between 3-4 Ghz for the longest time now…
And while more cores kinda allow for more multitasking, the speed has not increased any…

Maybe this is (also) why i am wondering about load balancing… One channel per core does not really work out in the long run if instruments etc need more and more power and the cores are stuck at a certain speed… Right?


Unrelated: heat dissipation is why we haven’t really gone beyond 4GHz. That plus the laws of physics are giving us some difficulty in terms of shrinking the chips by much more.

You have to remember that Windows task manager counts “virtual cores” of hyper-threading processor as “real” resources. In real-life situation you can never see Task Manager reporting 100% cpu usage. And if the workload of the processor is non-hyper-threadable (I know, horrible word, disgusting, believe me) best you can get is 50%.

And then, it’s not possible to perfectly load-balance a software like a DAW. There is one critical piece of code: the one that fills the output buffers. If this piece isn’t given enough time to run or not run often enough, you are screwed.

Just increase the size of ASIO buffers and try again.

“Moore’s law” is really a bit more ‘complicated’ than that. If I understand history correctly he was referring to transistor count doubling every year, then revised it to every two years, then someone else came along and predicted doubled performance every 18 months.

The law still holds true from a general performance perspective if you look at all CPUs in the market. The very high end sees this doubling in performance roughly every 18 months.

Well, if we’re going to stack a bunch of very CPU hungry effects into one channel then I suppose we may end up going beyond what a given CPU can handle, but the questions are really if there are other CPUs that can do the job better. Because let’s face it; most of us aren’t spending $1,000+ on CPUs in our DAWs. We’re spending less than that. But there are higher performance CPUs out there for sure.

In addition to that there are also dedicated processing to consider. These CPUs we’re talking about do everything but more advanced graphics processing. They run the GUI, they run the DAW, they run the plugins, they run a million things. I think that if we took our generic modern CPU, like an i7 or a new Ryzen, and had that CPU ONLY run plugins, we’d see entirely different results.

PS: I could be wrong, but one workaround for anyone running into these issues would be to route the signal through a group and spread out processing that way. I think that may alleviate issues in some cases (by loading more cores).

I’m not sure, but I think that may be similar/same to what I suggested earlier in the thread.

It would be nice (though from whom?) to get some confirmation on that.

It’s a bit more complicated.

First: track / mixer channel dependencies

As soon as you have tracks (mixer channels) depending on other tracks / mixer channels, their processing will have to wait for all tracks / mixer channels they depend on to finish their calculations.

This affects busses (sum, fx, groups) and sidechains.

Second: system latencies

This is even worse - realtime processing also depends on reliable response times / low latencies… and modern OS can’t really provide that, even though there is some progress.

Whenever there is a critical section in hardware driver code (graphics, network, whatever), the CPU can’t issue other critical sections - and this is only ONE of the reasons for having 50% of CPU meaning 100% ASIO load.

What we would need from Microsoft (and Apple, of course) is a mode of operation where device drivers are singled out to a single CPU core and where priorities can be handed out (so a critical section in the ASIO driver is always handled first and probably even breaks other critical section locks - this would of course cause problems with system stability, but it could most probably be controlled, etc…).

So your 6 core CPU will become a 5 core CPU for Cubase, etc… but would run MUCH faster and with much higher available CPU power.

Third: the low latency buffer sizes

It took me some time to wrap my head around this one when I first encountered it back in 2003 or so… smaller buffer sizes are bad for ASIO load. But why?

First, thread / context switches are costly. We’re talking about thousands or even ten thousands of clock cycles here.

Especially problematic: raw CPU performance is highly dependent on locality of data nowadays (because of caching) - but every time you work on a different plugin, different track you basically thrash the L1, L2 and (possibly) L3 cache. Reason: other data sets are used which are seriously not local enough.

Second, smaller buffer sizes mean more interrupts to the ASIO driver, therefore higher sensibility to badly written drivers for all the other hardware drivers in your system.

(ASIO drivers are generally quite good or even outright excellent. Problem is some special archetype of “hardware / software engineer” in typical hardware manufacturer companies. Learned his tools of the trade back in the 80s or early 90s at best and never bothered to really learn new ways of thinking, only on the surface if he has to. And still is considered a “capacity” by many - because they don’t know better. Which is sad. And the source of so much hassle.

Have a look at POS printer drivers -and firmwares - and the insane amount of problems they cause - just to give you one very strong example. Most POS printer drivers are so buggy that when you develop software which uses them, about 80% of the time spent with printing actually concerns workarounds and similar things.

This is just a placative example. WiFi and similar devices are often not much better.)

Add a second machine and split the load that way. :sunglasses:

A dog going twice as fast is still a dog…


Would be nice, if…

  1. No dongle
  2. No latencies

First, I’m not any sort of expert on this, but I wouldn’t necessarily conclude that your problems are caused by poor CPU balancing. To my understanding, the clicks and dropouts occur when audio buffers can’t empty fast enough. I always thought that faster CPU’s would improve this, but I now realize that there can be many other sources of the problem. When I first moved to Win 10 about a year ago with my (now) 5-year-old machine, I had a hard time getting Cubase to perform as it did under Win 7, and it took a while before I found several culprits, including one as simple as Windows Defender scanning plugins the first time they were run.

Maybe you’re well beyond this, but are you familiar with

There are really good explanations of the types of bottlenecks affecting audio processing, as well as tools to analyze your system.