iTunes CPU use: WAV Vs Apple Lossless
Posted by: winkyincanada on 04 September 2010
I've just noticed that iTunes uses about the same percentage (3%-3.5%) of the CPU when playing 96/24 WAV as it does when playing a lossless file 44/16. This surprises me a little that the de-compression doesn't take more resource, or that the higher-res file isn't more resource hungry. Not sure which way I expected it to be, but I expected a difference.
The small amount in both cases seems evidence that other processes running shouldn't make much difference to SQ. In fact, in the past I've successfully played music with some heavy duty video processing going on in the background with the combined processes taking close to 100% of CPU. No loss of SQ to my ears. It also seems to suggest that all lossless (compressed and uncompressed) should sound the same (provided of course that bit-rate and depth are the same).
Others' experiences?
Posted on: 04 September 2010 by Ballan
From what I understand (there are more educated people here), Apple uses Apple Lossless (ALAC) as a transmission codec. Meaning that iTunes, Core Audio (OSX) and Bonjour all transcode into ALAC as the native 16/44 codec. Supposedly this is done for efficiency more than anything.
Posted on: 08 September 2010 by bhaagensen
Two points. Modern computers are hugely overpowered relative to what is needed for decoding for audioplayback. So for that reason, differences in utilised resources are going to be minor, and probably too small to be detected reliably without doing controlled benchmarking. Moreover, most codecs, and in particular FLAC and ALAC, are asymetric with respect to processing power. Encoding is hard. Decoding is easy. Held together with the first point, you aren't likely to notice any difference at all in practise.
Posted on: 08 September 2010 by David Dever
quote:
Originally posted by bhaagensen:
Two points. Modern computers are hugely overpowered relative to what is needed for decoding for audioplayback. So for that reason, differences in utilised resources are going to be minor, and probably too small to be detected reliably without doing controlled benchmarking. Moreover, most codecs, and in particular FLAC and ALAC, are asymetric with respect to processing power. Encoding is hard. Decoding is easy. Held together with the first point, you aren't likely to notice any difference at all in practise.
This is largely true for general-purpose computing devices, but falls flat when discussing embedded playback devices (including the AirPort Express), where system resources are far smaller and a decode footprint is more costly with respect to power consumption (proportional to processing power) and available memory space within which to work.
A very good example of this lies within the differences between iOS and OS X audio frameworks (you couldn't, for example, shoehorn all of the features of OS X Core Audio onto a limited-footprint device such as an iPod touch).
Posted on: 08 September 2010 by js
There are still added buffers and layers to get any lossless done. I've always wondered about processor load in a high powered pc but it is one more thing running in parallel. If you hear a dif, fine. If you don't, that's fine too. I do.
Posted on: 09 September 2010 by winkyincanada
quote:
Originally posted by David Dever:
........embedded playback devices (including the AirPort Express), where system resources are far smaller and a decode footprint is more costly with respect to power consumption (proportional to processing power).........
This is a good point. Extra power consumed by the decoding processing could affect the quality of downstream functions, particulary if a DAC is sharing the power.
Posted on: 09 September 2010 by Eric Barry
But it's not just the CPU load. The disk I/o takes power and resources too, and ALAC has the advantage there.
Posted on: 09 September 2010 by David Dever
quote:
Originally posted by Eric Barry:
But it's not just the CPU load. The disk I/o takes power and resources too, and ALAC has the advantage there.
The read duty cycle for WAV, FLAC and Apple Lossless is nearly identical.
Posted on: 10 September 2010 by Deltaunit
When a cpu is idling it is running an idle process, it's not doing any less work.
Posted on: 10 September 2010 by David Dever
Sure it is - it's transitioning from state to state. Each transition utilizes switching current across a junction, and, the more switching taking place, the more current is consumed.
Furthermore - noise is bounced around the circuits from events that took place at some (short) prior time in the past.
There is no stasis in running processes, even at "idle".
