Bit Transparency

Your digital audio's passage through the PC may not leave it unscathed: even if you avoid Windows performing sample-rate conversion behind the scenes, other factors can compromise 'bit transparency'. We explain.

For years some musicians have been rightly concerned at the possibility of Windows modifying their audio 'behind the scenes'. Although Windows XP and Vista can perform clever stuff such as mixing several audio streams together from different audio applications running at differing sample rates, sometimes sample-rate conversion can happen without your knowledge, even when the input and output sample rates are identical.

At the heart of the problem for both Windows 2000 and XP users is the Windows Kmixer (Kernel Mixer), which performs the multi-client mixing of Direct Sound and MME (also referred to as MME-WDM, Multimedia, or simply 'Wave') driver audio streams from the audio applications you're running. When it receives a variety of channels with differing sample rates and bit depths, it generates a mixed stream that is sent on to your audio output sockets. However, to perform all this clever stuff it must sample-rate-convert any stream that differs from the others, which involves using one of its internal sample-rate conversion (SRC) methods.

Windows XP defaults to the Best setting, which, according to Microsoft, results in an SRC algorithm with a signal-to-noise ratio of up to 85dB: great for most mainstream consumers, but less so for musicians, when most modern audio interfaces are capable of dynamic ranges well over 100dB! By contrast, Vista's sample-rate-conversion is of extremely high quality, up-sampling to the highest rate supported by your audio interface, and can be disabled by a manually set sample rate.

Back in Windows 2000, the Kmixer was also responsible for truncating 24-bit and 32-bit audio data to 16-bit, by discarding the other bits (http://support.microsoft.com/kb/...). Fortunately, this bug was cured by Windows 2000 Service Pack 3.

Bypass Operations

The majority of musicians running Windows XP should avoid Kmixer sample-rate conversion whenever possible. The easiest way to do this is by choosing driver formats such as ASIO, GSIF or WDM/KS (Windows Driver Model/Kernel Streaming, as featured in Cakewalk's Sonar).

As I explained in PC Notes March 2006, some interface manufacturers, such as Echo, also provide a special driver option that bypasses the Kernel Mixer altogether, to connect directly to the hardware beneath. Echo call their option 'Pure Wave', and although you lose Direct Sound support you get a much lower-latency alternative to the standard 'Wave' drivers inside applications that don't support the ASIO driver format, as well as avoiding possible SRC.

In general, then, avoid choosing the higher-latency Wave/MME options whenever possible, and if a particular application only provides a Wave/MME option, see if your interface offers special Wave driver options that bypass the Kmixer. If you have no choice but to use a Wave/MME driver, only run one audio application at a time (if multiple streams are being mixed, any of lower sample rates will undergo SRC to the highest used sample rate). You should also disable Windows system sounds, to prevent them playing back low-sample-rate WAV files and starting the SRC process (which sometimes even forces ASIO sample rates to change). The worst option for musicians is the Direct Sound driver: its SRC algorithms may be even worse than the MME ones.

As I explained in the February 2006 issue, Sonar users choosing the WDM/KS driver can assemble a composite interface from any combination of the stereo inputs and outputs that appear in the drop-down Sonar list and, as long as they're careful about running them all from the same clock signal, this can work very well. However, Cubase users should beware of attempting to mimic this composite approach using the program's ASIO Multimedia or ASIO Direct Sound drivers: not only will they end up with significantly higher latency, but their audio may also end up passing through lacklustre SRC algorithms.

Digital Decisions

Avoiding unwanted sample-rate conversion still doesn't ensure 'bit transparency' (ie. that every bit arriving at an audio input remains unchanged until received by the audio application, and every bit sent out by an audio application reaches your audio interface output exactly as it was sent). This is the case even when you're using ASIO and WDM/KS drivers, since various digital volume controls may still be 'in circuit'.

Bit transparency can be important: if you're auditioning bit-transparent material you're hearing the exact sound of the original data, without any alterations due to DSP algorithms, and bit transparency also ensures that you can bounce audio recordings digitally as many times as you like (for example, from a computer to a DAT or ADAT recorder) without them ever degrading in audio quality. Most importantly, for many users, it enables suitably-encoded digital audio material to be transmitted to a surround-sound receiver (if bits are altered en route, you'll just hear noise instead of music).

Wavelab provides an 'Audio file comparer' function that you can use to test for bit transparency.For exactly the same reason that we're all recommended not to automatically normalise recorded audio (because any change in level involves errors, however small), if you're aiming for bit transparency you should ensure that any digital volume controls that affect your audio signals are all set to their 0dB or 'unity gain' setting, so they pass audio unaltered, and that digital balance controls are also in their extreme left/right positions. You should also disable DSP effects offered by the audio interface, such as EQ and bass enhancement.

The most obvious place to look for these controls is in the Control Panel utility provided by your audio interface, which is in charge of the DSP mixer on the interface itself and generally operates with a large internal bit-depth to minimise rounding errors, therefore ensuring high audio quality. Sometimes such DSP mixers are optional (many M-Audio products, for instance, offer the choice of connecting the physical output sockets either to the combined output of their Monitor Mixer, or direct to stereo driver playback), and with other products (such as the Emu 1820/M) one pair of outputs is permanently connected to the combined output of the DSP mixer, while the other physical outputs can be connected directly to application playback. The RME DSP mixers are even advertised as being bit transparent if the faders are left in their 0dB positions.

Any level manipulation will alter the values of each and every bit, and although the difference is unlikely to be audible in most situations, if you're attempting to check for possible SRC effects you'll be able to do this a lot more easily when the audio level remains unaltered.

The best way to alter volume levels is in the analogue domain, but failing this you can use the dedicated DSP controls provided by the interface manufacturer (most offer high audio quality, if not total transparency). Musicians rarely investigate the Windows volume controls (which you can launch from the 'Sounds and Audio Devices' applet by clicking on the Advanced button of the Volume page), but for any who have done, in most cases these controls (level, balance, mute and possibly bass/treble) simply move the equivalent DSP controls provided by the interface manufacturers. So if you move one of the Windows controls you should see the corresponding control move in your interface's Control Panel mixing utility.

Exceptions include the sliders associated with the Kmixer engine, such as as Wave, SW Synth and CD Player, all of which alter audio levels only when you're using WDM-MME or Direct Sound drivers. The safest approach with these is to leave them at their (normally maximum or 0dB) default positions; however, for a few consumer soundcards the 0dB setting may be slightly lower than the maximum position and must be found by experiment.

Clear & Simple

How can you check whether sample-rate conversion, bit-depth changes or level changes are affecting your main audio output? Well, the only certain way is to send an audio signal out of a digital audio output, connect this via a loopback cable to the digital audio input, and then compare the resulting signal to the original. It should be bit-for-bit identical.

Audio Precision Analyzer hardware (http://ap.com) offers such a function, and some applications (such as Wavelab) provide an 'Audio file comparer' function that subtracts one file from the other and lets you hear the 'delta' file — the difference between the two original files. This is useful if you want to hear what changes a plug-in has made to your audio, for example, or compare two digitally recorded files in order to spot drop-outs or see if they are identical, in which case the delta file will be a perfect null, proving bit transparency. You do need to ensure that you time-align the recorded signal with the original and cut it to exactly the same length, but you can create a test file with an obvious start and finish to accomplish this.

If you have a surround-sound receiver, another approach is to play back a DTS test file (you can download some free from www.sr.se/cgi-bin/mall/index.asp?programid=2445). You will only hear noise if you play back these files in stereo audio applications. However, if you connect the application digitally to a surround receiver you'll hear music from it, but only if you're transmitting a bit-for-bit copy: the signal will revert to noise if any bits are being changed.