Discrepancies between Ableton CPU meter and the system CPU

[andydes]

Just don't ask where I got that from.

me thinks it's someone dumbing it down for you.
it's about MIPS,
Millions Of
Instructions
Per
Second.

MIPS to you too. Yes it's a lot of instructions. Does that make me wrong?

True, I'm not 100% certain, but I think what I said still makes sense.

[fishmonkey]

according to the Live manual the meter is a measure of CPU usage as it relates to audio processing only, i.e. it gives you a rough estimate of how close you are getting to Live not being able to process audio and get it out without glitches. it is not a general CPU usage meter; it doesn't even include the CPU usage required to maintain Live's GUI.

btw, multicore operating system CPU meters often display CPU with each individual core having a maximum of 100%, e.g. on a quad-core machine with hyperthreading your maximum CPU usage will be 800%, i.e. (4 real cores + 4 virtual cores) * 100%.

[lalo]

according to the Live manual the meter is a measure of CPU usage as it relates to audio processing only, i.e. it gives you a rough estimate of how close you are getting to Live not being able to process audio and get it out without glitches. it is not a general CPU usage meter; it doesn't even include the CPU usage required to maintain Live's GUI.

btw, multicore operating system CPU meters often display CPU with each individual core having a maximum of 100%, e.g. on a quad-core machine with hyperthreading your maximum CPU usage will be 800%, i.e. (4 real cores + 4 virtual cores) * 100%.

thanks.
so this means that i can reach with my quadcore i7 ( 4 real and 4 virtuals ) a total of 799% without glitches in audio stream.
am i right?

thanks
a.

[fishmonkey]

nope, i was just explaining why CPU usage greater than 100% is sometimes displayed in various system tools that show it.

in my experience once you start to approach 80–90% on the Live CPU meter then you are on the edge of the glitch zone. how sensitive Live is to glitching also depends a lot on your sample rate and buffer size. higher sample rates and lower buffer sizes require smaller chunks of audio to be processed at a higher rate.

[lalo]

nope, i was just explaining why CPU usage greater than 100% is sometimes displayed in various system tools that show it.

in my experience once you start to approach 80–90% on the Live CPU meter then you are on the edge of the glitch zone. how sensitive Live is to glitching also depends a lot on your sample rate and buffer size. higher sample rates and lower buffer sizes require smaller chunks of audio to be processed at a higher rate.

so is like saying that Live is using only one of my 4 + 4 cores?

[H20nly]

btw, multicore operating system CPU meters often display CPU with each individual core having a maximum of 100%, e.g. on a quad-core machine with hyperthreading your maximum CPU usage will be 800%, i.e. (4 real cores + 4 virtual cores) * 100%.

that makes sense... UNLESS... it goes over 800% then we're right back where i started

[steko]

From Friedemann (Ableton) in an old thread (in a now closed Live Beta forum):

Hi,

the CPU meter in Live works differently than the usual CPU meters in the operating system.

In Live you see the ratio of the time that was actually needed to compute the audio signal and the time that
is available to compute it. The latter is just determined by the sample rate of the audio interface, i.e. at 48kHz
sample rate you need to compute 48000 samples in one second, if it takes longer, there will be drop-outs.

Therefore, values below 100% mean that the samples were faster calculated
than needed by the audio interface while values above 100% mean that calculating the samples took too long
for being delivered to the audio interface on time. In the multi-processor-case the slowest path, i.e. the processor that has to calculate most, determines that number.

On the OS level you usually see how much time a certain processor (or all together) devotes to a certain process.

Although both meters show '%' values, they are not really comparable.

Best, Friedemann

http://www.google.com/search?&q=site:fo ... stem%20CPU

[lalo]

From Friedemann (Ableton) in an old thread (in a now closed Live Beta forum):

Hi,

the CPU meter in Live works differently than the usual CPU meters in the operating system.

In Live you see the ratio of the time that was actually needed to compute the audio signal and the time that
is available to compute it. The latter is just determined by the sample rate of the audio interface, i.e. at 48kHz
sample rate you need to compute 48000 samples in one second, if it takes longer, there will be drop-outs.

Therefore, values below 100% mean that the samples were faster calculated
than needed by the audio interface while values above 100% mean that calculating the samples took too long
for being delivered to the audio interface on time. In the multi-processor-case the slowest path, i.e. the processor that has to calculate most, determines that number.

On the OS level you usually see how much time a certain processor (or all together) devotes to a certain process.

Although both meters show '%' values, they are not really comparable.

Best, Friedemann

http://www.google.com/search?&q=site:fo ... stem%20CPU

thanks steko! your google coockie points right away to this thread
best
a.

[steko]

[H20nly]

nice one steko!

none of us guessed that. not even the manual

[fishmonkey]

nice one steko!

none of us guessed that. not even the manual

erm, that's basically what i said above...

[kitekrazy]

maybe there is some strange thing in Live about multicore processing?

Yes. In comparison to Reaper's implementation, it's crap.

That would go for most DAWs. It's an excellent coded piece of software.

[Linear Phase]

No.. I haven't noticed. Are you sure? Scientific proof?

[H20nly]

nice one steko!

none of us guessed that. not even the manual

erm, that's basically what i said above...

no offense, but i think the post steko quoted was a little more of a detailed/precise answer to the question.