Third Time Lucky?
This week, we hear again from Benchmark: Elias Gwinn clarifies what he describes as Siau's "initial observations based on preliminary testing." Gwinn writes, "After extensive testing and communicating directly with the engineering team at Apple, some of these initial observations have been explained. We now know the reason for the poor performance observed in the initial tests, and we have conclusive information about the operation of iTunes 7.x on Mac OS X."
We present Gwinn's notes in their entirety:
" iTunes 7.x can work very well on Mac OS X with the proper configuration, but the wrong configuration can cause serious distortion. It is important to understand the fundamental modes of operation of both iTunes and CoreAudio, specifically regarding sample rates.
"CoreAudio and iTunes can simultaneously operate at independent sample rates. At all times, the sample rate set in AudioMIDI Setup dictates the sample rate at which CoreAudio is operating. When iTunes is launched, iTunes locks to the sample rate at which CoreAudio is currently operating (which is the sample rate that is set in AudioMIDI) and does not change until it is closed and re-launched. However, after iTunes launches and locks its sample rate, its sample rate will not change thereafter, even if CoreAudio’s sample rate setting in AudioMIDI Setup is changed. To change the sample-rate of iTunes, iTunes must be shut down, and then restarted after the desired sample rate is set in AudioMIDI Setup.
"The audio being played in iTunes will always stream from iTunes at the locked-in sample rate. In other words, if iTunes is locked to 44.1 kHz, all audio with other sample rates will be converted to 44.1 kHz by iTunes. iTunes then streams this audio to CoreAudio to be mixed and/or streamed to the hardware.
"What does all of this mean for the end user? If the user changes CoreAudio’s sample-rate in AudioMIDI Setup to something different than what iTunes is locked to, CoreAudio will convert the sample rate of the audio that it is receiving from iTunes. In this case, the audio may be undergoing two levels of sample-rate conversion (once by iTunes and once by CoreAudio). (The SRC in iTunes is of very high quality (virtually inaudible), but the SRC in CoreAudio is horrible and will cause significant distortion.) If the user wants to change the sample rate of CoreAudio, iTunes should be restarted so that it can lock to the correct sample rate.
"We are suggesting two different recommended solutions to our customers:
"1) The 'Set It And Forget It' solution for iTunes 7.x: Before opening iTunes, set the sample rate of CoreAudio (in AudioMIDI Setup) to 96kHz. Do not change the sample rate of CoreAudio unless iTunes is restarted after the change is made. This solution will prevent CoreAudio from applying SRC, as the quality of CoreAudio’s SRC is horrible. Also, by having iTunes locked at 96kHz, all audio with sample rates below 96kHz will be up-sampled to 96kHz. This will cause virtually no loss in sonic quality, as the quality of iTunes’ SRC is very good—virtually inaudible. Also, by avoiding down-sampling by iTunes, this setting will never result in a loss of bandwidth.
"2) The 'Bit-Transparency For Each Sample Rate' solution: (NOTE: This solution is rather cumbersome, offers virtually no quality improvement over the first solution, and can easily be mis-configured, which will cause severe distortion.) Before opening iTunes, set the sample rate of CoreAudio (in AudioMIDI Setup) to that of the audio you will be playing. Do not change the sample rate of CoreAudio unless iTunes is restarted after the change is made. This solution will prevent CoreAudio from applying SRC, and avoid SRC by iTunes for all audio with the same sample rate that iTunes is locked to.
"Also, the end user should not hesitate to use the volume control in iTunes 7.x, as it is very well designed and operates at 24-bits for audio devices that support 24-bit operation.
"For iTunes 6 and earlier, simply set the sample-rate in AudioMIDI to match that of the audio being played, and keep the volume control at 100%."
Thanks to John Siau, Gordon Rankin, and Elias Gwinn for bringing this to our attention and then helping sort it out.