DSP graphs / readouts - what do they actually measure? Which DAW is most reliable?

[antic604]

I know they don't measure the same average CPU load that Windows' Task Manager does.
On the other hand - I suspect - they also don't just show the single most used core.
Do they include somehow the available SSD/HDD streaming speed vs. what the project requires?
How about free vs. occupied RAM?

In ideal world they should tell us how much more can we push the project further, but in practice it doesn't really work well most of the time - typically I'll add few tracks & plugins and I'm at 0.25-0.5 of the DSP meter, but then I'll keep adding stuff and it would basically stay the same until an unexpected point when it suddenly goes overboard. I'm aware that audio is notoriously linear process and is often difficult to spread accross CPU cores to be calculated in parallel, that not all tracks consume DSP in the same way, that longer / heavier device chains will chew more of it and can overload the fastest multicore CPU by choking single core, that dependancies between tracks (bussing, sends, sidechaining) impact things as well... It must be really difficult to design and implement a proper DSP measure.

Which DAWs do you find are accurate and reliable and which are just "guesstimates"? I found Bitwig to be somewhat "random" here, with Live and - surprisingly - Reason being more predictable. I've not yet pushed S1 far, so can't comment on that.

Is there any reading available on how this works in popular DAWs?

[ilmai]

I don't have factual information, but an educated guess is that they're measuring time spent filling the audio buffer vs. maximum time available to fill it before dropouts happen. Because this is what really matters for audio, not CPU utilization %.

EDIT: This is why the number of cores or their individual utilization rates doesn't matter either, it's all about processing time regardless of how the processing is achieved.

For example, if you have a buffer of 128 samples @ 44.1kHz, you need to be filling the buffer 44100 / 128 =~ 345 times a second. In other words, you have 128 / 44100 =~ 2.9ms to fill the buffer. If calculating one buffer worth of audio takes you 1.45ms, the DSP meter would show 50% in this instance.

[antic604]

I don't have factual information, but an educated guess is that they're measuring time spent filling the audio buffer vs. maximum time available to fill it before dropouts happen. Because this is what really matters for audio, not CPU utilization %...

...which would more or less be equal to the utilisation % of the most occupied core, because if all cores work in parallel, then the one that finished last is the (potential) bottleneck and thus a conservative estimate of available DSP (under the assumptions that further plugins will be added to its chain). But that doesn't account for the situation that other cores might've finished their work long time ago and they could go through several additional tracks & plugins more and STILL finish before that most occupied core.

See, this is where it gets interesting (and/or confusing ) For example a predictive "AI" could be used which - based on your other projects and history of how you were building them - would weight the single core % and multi-core % based on the likelihood of you adding more processing to that heaviest track vs. adding more separate tracks respectively. So simplifying, for someone working usually with few tracks with heavy/long devices chains the DSP would be skewed heavily towards single core performance, whereas for someone who just records audio and slaps an odd EQ and/or compressor on a track it would gravitate closer to average multi-core utilisation.

[DJ Warmonger]

which would more or less be equal to the utilisation % of the most occupied core

This is not exactly true, as a core doesn't need 100% utilization to process a buffer. If it's very fast, it can do the job at 1% utilization and be fine.
in Ableton, the meter measures delay time. It can still take 10% of time allowed to copy empty buffer to audio output even if the empty project requires no DSP processing whatsoever. System and CPU architecture is complex and can introduce significant delay on its own.

[antic604]

This is not exactly true, as a core doesn't need 100% utilization to process a buffer. If it's very fast, it can do the job at 1% utilization and be fine...

I said "more or less" and you shouldn't quote it out of the context of the rest of the sentence

I'm trying to understand how DAWs balance between conservative measurement of DSP and overly optimistic measurement of Task Manager (columns are cores, coloured boxes are per-track serial DSP):

dsp.png

in Ableton, the meter measures delay time. It can still take 10% of time allowed to copy empty buffer to audio output even if the empty project requires no DSP processing whatsoever. System and CPU architecture is complex and can introduce significant delay on its own.

Yes, this is precisely the reason why I asked the questions in the first place! What other components of the DSP chain are taken into acount in addition to CPU use? Memory / bus bandwidth? SDD/HDD speeds, etc?

[ilmai]

Yes, this is precisely the reason why I asked the questions in the first place! What other components of the DSP chain are taken into acount in addition to CPU use? Memory / bus bandwidth? SDD/HDD speeds, etc?

It doesn’t take any of that into account explicitly, it’s very simply the time it took to fill the buffer versus how much time was available before an underrun. Implicitly all of the above and more affect it of course.

[antic604]

It doesn’t take any of that into account explicitly, it’s very simply the time it took to fill the buffer versus how much time was available before an underrun. Implicitly all of the above and more affect it of course.

How are you so certain? Are you a DAW developer?

If it's really as simple as you say, then it's the more conservative approach (as shown in my example earlier) and would explain the phenomenon I'm observing, i.e. that DSP isn't very linear and sometimes won't react to adding new tracks & devices at all and at other times will jump suddenly.

[DJ Warmonger]

If it's really as simple as you say

Simplest solutions are often the best. No one would bother implementing AI-based predictive meter or whatever just to entertain curious geeks.

that DSP isn't very linear and sometimes won't react to adding new tracks & devices

You forget that new tracks run in parallel on multi-core CPU.

[antic604]

that DSP isn't very linear and sometimes won't react to adding new tracks & devices

You forget that new tracks run in parallel on multi-core CPU.

No I don't. This is exactly what explains the situation I described and is presented on my picture in 2nd column - I've "added" 3 more tracks (almost doubled the project size) but the DSP increased only by 10pp or 20%