"
JF: How do you ensure bit-perfect output from a music server?
MA: "Bit-perfect" is merely a stepping-stone to achieving good sound. In the most simplistic terms, it is also the default manner in which a computer treats data -- when you copy a file from your hard disk to a USB stick, it is "bit-perfect" in the sense that each and every bit of the original and destination files are perfectly identical. This can be validated using mathematical algorithms that have an error rate of about 2^80 (that is, the odds of a mistake are approximately one in 12 trillion trillions). To validate bit-perfectness, we created a set of test files with bit patterns that are statistically the most vulnerable to jitter and other corruption. We stream these files and use a multichannel, high-speed logic analyzer to measure the bitstream at the output of the server, at the input of the DAC, and (when using the Pacific Microsonics Model 2) at the digital output of the DAC. The resultant plots show us the signals and any skew between them, and the logic analyzer also captures the datastream, which we then compare to the original file using those same mathematical algorithms. Also, on HDCD-capable DACs, confirming that the HDCD light turns on and stays on is a good (but not definite) indication. Human listening tests follow. But, as mentioned, bit-perfect is just the start; unlike conventional computer files, audio data are very timing-dependent, so we have to make sure that we move the bits to the AES interface (inside its subenclosure) and then to the DAC at the most precise intervals, and without any variance. Less is more: Fewer interruptions and fewer irregularities result in better audio.
"
"
JF: How important is noise -- electrical, mechanical, etc. -- in a music server? Is EMI or RFI an issue?
MA: Extremely important. Once weve established that a music server is bit-accurate (and virtually all good ones are), and after weve reduced jitter to the minimum possible, we have to start looking at the analog aspects of the digital connection to the DAC. Let me explain this for a second: Even though the connection between the music server and the DAC is a digital one, that digital signal still passes through a cable, which is an analog medium. Transmitting a pure digital signal through any analog medium requires infinite bandwidth, which can be achieved only theoretically. Thus, the digital signals are modulated (the exact modulation type depends on the type of connection and cable) so they can be transmitted through a cable, and the modulation/demodulation process can add undesired effects to the signal. In most computer-based scenarios this isnt a problem, but with a DAC it matters, because DACs bridge the digital and analog domains and are highly susceptible to analog noise. Furthermore, since the computer is an environment full of electromagnetic noise, some of this noise can be transmitted by the cable and work its way into the DAC. Based on our experiments, I believe that differences in the analog parameters of the connection between the music server and the DAC account for the majority of the differences in how different music servers sound, even when using the same DAC. It is this radiated noise (along with differences in grounding) which is also the reason why some people notice differences in the sound when different USB cables are used, or why music servers with solid-state disk drives generally sound better than those with mechanical hard drives. As before, less vibration and less noise mean better quality.
".
"
JF: Are there any intrinsic advantages to either Mac- or Windows-based computers? What other options are there?
MA: The design of any modern desktop operating system is not ideal for a music server or other real-time devices. This is the reason why many medical, aviation, and aerospace computers use dedicated, minimalistic, real-time operating systems. In a desktop computer, the operating system must handle the screen, the keyboard, the mouse, various applications, etc., all while maintaining the stability of the entire system. This is very useful for a general-purpose computer such as a Windows PC or Mac, but comes at a price.
In contrast, real-time operating systems such as VxWorks, or specialized versions of Linux, can afford to shed many of these safeguards and functionality because they serve dedicated purposes and operate within tightly controlled parameters, and thus can push the envelope. Both Windows 7 and Mac OS X are very good operating systems, and, with some careful tuning -- such as reducing the running processes and drivers to the bare minimum, optimum memory configuration, and so forth -- can certainly sound decent. But one has to understand that there is only so much that can be done. Contemporary desktop and laptop computers are a total overkill for music playback, as any processor can handle the computational requirements for audio playback in its sleep! Making matters worse, all monitors contain inverters, high-frequency drivers, and other electronic circuitry that emits lots of EMI/RFI, as does the graphics card that drives the monitor.
I like the Linux-based players, such as Jesus VortexBox and Demians Auraliti, because they dont employ a local graphical user interface, yet bring a streamlined Linux-based platform to the realm of the nongeek audiophile at reasonable cost and deliver great performance. Just to give you an example, a typical general-purpose operating system such as Windows 7 or Mac OS X might have close to a hundred discrete processes running at the same time in its default, out-of-the-box configuration. Careful tuning and optimization might halve that; our proprietary operating system has a total of five processes that run concurrently, with three of them dedicated to the real-time music-playback application. Its simply impossible to achieve that with anything that is generic.
"
"JF: Is there anything you can do to minimize jitter coming from the music-server side? What about internal jitter generated by the music server itself?
MA: The same practices that were discussed above apply here. There is no inherent jitter inside the computer in the digital domain, because as long as data are moved around inside the computer, the timing doesnt matter. Jitter becomes a problem when timing starts to matter, and that happens close to the DAC, either on the interface that carries PCM audio to the DAC, or inside the DAC, where a digital protocol such as USB is decoded into the PCM samples that are then fed into the DAC. Weve gone to great lengths to isolate the AES interface from the EMI horror that is the modern computer, and also to provide the most deterministic environment, devoid of interrupts and context switches, for the AES interface to take data from the computer and send them to the DAC with minimum jitter and latency. Low latency is required to ensure that the audio playback process is optimally predictable and deterministic in its access to the AES interface. Slaving the entire playback chain to a solid clock source as close to the DAC as possible will almost always provide a sonic benefit, as the DAC is the interface with the outside (i.e., analog) world, and everything must therefore march to its rhythm.
"