Ableton Forum

Tone Deft wrote:

andydes wrote: 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.

fishmonkey wrote: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%.

fishmonkey wrote: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.

fishmonkey wrote: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%.

Friedemann wrote: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

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

Friedemann wrote: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

H20nly wrote:nice one steko!

none of us guessed that. not even the manual

Mister36 wrote:

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

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

fishmonkey wrote:

H20nly wrote:nice one steko!

none of us guessed that. not even the manual

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