One of the techniques BitPerfect uses to maximize playback sound
quality is to play from RAM memory. Most music players will play
directly from the music file. The advantage of that method is that you
only read the music data from the file as you need it, and stream it to
the audio output device. If you change your mind and decide to play
something else, or move playback to a different
part of the track, that is easy to accomplish - at least from a
programming simplicity perspective - using that method.
BitPerfect instead takes advantage of the phenomenal processing power of
a modern computer and pre-loads the music into a RAM buffer. When you
want to play the music, you simply pass the “address” of the RAM buffer
to the audio output device, and it automatically handles the rest. In
order for this to be practical, you must be able to not only read the
file, decode it, and load the music data into the buffer, but also
perform any manipulation that might be necessary, such as sample rate
conversion, all in double-quick time.
So how practical is this?
Surprisingly so, it turns out. Here is a peg in the ground taken from
the totally basic 2013 Mac Mini I use in our reference system. It has a
2.5GHz Core i5 processor, and 4GB of system RAM. I allocate 512MB of
RAM for the audio buffers. For this test I have BitPerfect set to
upsample from 44.1kHz to 176.4kHz and (for purposes of full disclosure) I
am using the as-yet unreleased version 1.1 of BitPerfect which has a
new and improved 64-bit audio engine. Using this system, a piece of
music of 1 minute 35 seconds duration, is read from an Apple Lossless
file, decoded, upsampled to 176.4kHz, and loaded into its RAM buffer in
only 1.9 seconds.
There are many advantages to doing it this
way, and one of those is the ability to minimize CPU time during
playback. In the early days of BitPerfect we discovered that reducing
the CPU time tended to have an improving effect on sound quality. More
recently we have established that it is only certain kinds of CPU
activity that have this effect, but nonetheless, minimizing
“undesirable” CPU load is one BitPerfect’s key goals in improving
playback quality.
BitPerfect is able to start playing the track
as soon as you start loading it into the buffer, so playback commences
pretty much instantly, and the loading of the track continues during the
first 1.9 seconds of playback. Beyond that, BitPerfect requires CPU
cycles only for the direct management of playback. In principle, then,
there exists the possibility that the sound quality of playback is
degraded slightly by the additional CPU load during those first 1.9
seconds, but frankly, we know of nobody who has been able to detect this
audibly. Certainly, we can’t. However, for the remaining 1 minute 33
seconds, playback will be at BitPerfect’s highest caliber.
What
happens if the track is too big to fit into the buffer? No problem.
The RAM that you allocate in BitPerfect’s Preferences menu is actually
equally divided into two buffers. If the whole track does not fit into
the first buffer, the remainder is put into the second buffer. As soon
as the contents of the first buffer finishes playing, playback is
instantaneously switched to the second buffer. The switching occupies
only a tiny fraction of the time interval between consecutive samples,
so the audio output device does not even know it is happening. And if
the track still does not fit into two buffers, then as soon as the first
buffer finishes playing and playback switches to the second buffer, the
remaining unplayed content is loaded into the first buffer. BitPerfect
can do this ad infinitum, in effect maintaining the two buffers as a
“wash and wear” pair, with one in use and the other containing whatever
is up next.
This has important ramifications for those who like
to claim that lossless music encoded in different formats, such as WAV,
AIFF, FLAC, and Apple Lossless, all sound different. Of those three formats,
the third and fourth are losslessly compressed. Like unzipping a ZIP
file, they need to be decoded after opening before they can be played.
But after decoding, their contents are absolutely identical (“bit
perfect”, if you like) to the contents of the uncompressed WAV or AIFF file. I
suppose there is room for playback of a losslessly compressed file to
sound different to a WAV/AIFF file if you make the assumption that the
additional processing involved in decoding the file results in some kind
of audible degradation. But either way, if you are playing those files
using BitPerfect, then once the 1.9 second buffer load is over, then
there is nothing left that would be in any way different depending on
whether the music data had originally been extracted from a WAV, AIFF, FLAC, or Apple
Lossless file. Absolutely none whatsoever.
The other take-away
from this is that it is not really necessary to allocate a particularly
large amount of system RAM to the audio buffer. We used to think that
by pre-loading the whole track into memory it would sound better than if
it was loaded chunk by chunk into a pair of wash-and-wear buffers. The
additional CPU cycles involved in loading and switching ought to be
degrading the sound. Over time, though, it has not turned out that way.
We find that setting a larger audio buffer size seems to imbue the
system with no audible improvements that we can reliably observe. I
have for some time now left the audio buffer size on my reference system
set to either 256MB or 512MB, and it seems to sound just fine to me.
Tim does the same - and he listens on Stax SR009s.
All this is good news, because OS/X Mavericks seems to appreciate having lots of system RAM to play with.
