You're in luck! Because I did.
And yes, they crap out at different CPU usages. One might be 80%, another 50% and another 20%. But they all crap out below 100% usage. So unless you like staring at CPU usage graphs, who cares what the CPU usage is?
In my tests, the one that craps out at 80% CPU usage doesn't do so with significantly more FX loaded or voices playing. But maybe it does for you - but that's a meaningful metric that I don't see above: max number of FX/voices/whatever for a given CPU or DAW or whatever.
Pick a CPU type, or CPU speed or DAW or whatever and measure the point at which it no longer plays back smoothly. That's what we care about. So measure that.
Here's an example of a meaningful comparison: I have a pretty intense project that that I've used as a DAW benchmark for 7 or 8 years. I've run it on 4-core, 6-core and 10-core machines. On all three machines the lowest latency I could achieve is around 6 ms. The 4-core did 6 ms at the highest CPU usage. The 6-core had the next highest CPU usage and the 10-core had the lowest CPU usage.
Did the 10 core provide more FX than the 4-core? Nope. Did it achieve lower latency? Nope. The 10-core CPU is vastly more powerful (as evidenced by the lower CPU usage) but in terms of meaningful metrics like number of FX or voice count at dropouts all three CPUs were exactly the same.
Therefore, voice count, number of FX, etc at dropout, based on my measurements, are not related to CPU usage. QED.
rgames
It certainly is!if on the same machine with the same audio interface set to the same buffer size, I can run, e.g., 30 instances of Omnisphere in DAW A, 22 in DaW B, but only 15 in DAW C, without hearing problems or getting system overload messages, that's significant.
It certainly is!
And none of the metrics you posted there is CPU usage
QED again (with help from Jay).
rgames
Maybe - but who cares?But doesn't the lowest Core Utilization likely mean the less CPU usage?
Maybe - but who cares?
I think you're trying to relate CPU usage to number of synths/fx/whatever. But why bother? Just measure number of synths/fx/whatever.
A basic rule in quantifying something: if possible, measure what you care about. Don't measure something else and assume a relationship.
If you care about number of synths/fx/whatever, measure that (which is what you described above).
If you care about CPU usage, measure that.
rgames
Yes - real-time performance. That's related to the efficiency of the code and is only weakly related to CPU power for recent-vintage systems. As of about 10 years ago real-time performance is the major factor, not CPU performance. That's why you see threads on this board with titles like "Dropouts with Low CPU Usage".But is there any factor other than CPU usage that would account for a DAW being able to run more?
Yes - real-time performance. That's related to the efficiency of the code and is only weakly related to CPU power for recent-vintage systems. As of about 10 years ago real-time performance is the major factor, not CPU performance. That's why you see threads on this board with titles like "Dropouts with Low CPU Usage".
Back in the Windows 7 days on PC you could get decent measures of real-time performance with DPCLatencyChecker. But it's not supported in Windows 10 and not at all on Mac (I don't think). There's LatencyMon as well, which does work under Win10 but I've not found it to be as reliable as DPCLatencyChecker was.
But the best way to measure real-time performance is to just load up a bunch of FX/synths/whatever and drop the buffer until the machine starts to stutter/crackle/whatever.
It's like tire pressure: the shape of the tire is related to the pressure, sure. So you could measure the shape of the tire and infer/assume the pressure.
But why not just measure the pressure?
rgames
I did that with Omnisphere a while back - I posted the results somewhere on this board. I manually underclocked the CPU frequency and measured max number of vocies for a given buffer size on 4 and 6 core CPUs.the simplest test would be to manually adjust your processor frequency & core usage and see what happens
You are correct that the computer fills buffers. And it must do so within a given time period to ensure that the analog stream going to your monitors is uninterrupted.
That "within a given time period" part is the real-time performance part. If the system can't get the buffer filled in time, you hear crackles/pops/dropouts because there's garbage going out to your monitors.
Therefore, voice count, number of FX, etc at dropout, based on my measurements, are not related to CPU usage. QED.
rgames