|
Posts: 2013
Location: No. California
Joined: October 13, 2002
|
I'm going to take a stab at this and hopefully do it in a nice even handed way.
Lets tackle the USB/I2S point first.
There is a conceptual difference here, USB is a computer bus, it is a way to get data in and out of a computer, so is firewire, I2S is not. Processors do not have an I2S "bus" to talk to the outside world. I2S is an interface designed to go between chips on a board. It CAN be used to go between boxes with appropriate drivers and connectors, but you still need some way to connect to the computer, something has to get the data out of the computer and generate the timing signals going over the I2S interface.
Currently there are three methods in use for getting the data out of the computer, PCI card, USB and firewire. A DAC with an I2S or S/PDIF interface (in any of its physical transport flavors) must still get its data and timing from something connected to the computer through one of these methods. A DAC connected to an I2S interface generated by a box connected to a USB bus is not going to be any better than a DAC that had that USB interface builtin.
From theoretical grounds the best way to get the computer data to a DAC chip is to have low jitter oscillators right next to the DAC chip generating the timing for the chip and that clock also being used to control the rate at which data comes from the computer so it matches the rate at which data goes into the DAC chips.
In traditional unidirectional S/PDIF, AES/EBU and I2S this cannot happen since there is no way for the DAC to control the rate of data from the computer. The DAC has to somehow deal with the data rate coming out of whatever generated that timing. All the many varied methods that have been invented to deal with this are essentially band aids used to deal with the non-ideal topology.
So how DO you do it right?
A PCI card can get data off the PCI bus at whatever speed it wants so it seems an ideal way to do things right. But that means putting the whole ball of wax on a PCI card, sitting inside of a computer, usually powered by the computer's power supply. There are a lot of engineering hurdles to overcome to get really good sound with this method.
The PCI card can also be used just as a digital interface, but then you need some method for getting the data to the DAC box. If you use I2S, S/PDIF etc you still have the problem of the PCI card generating the timing not the DAC. To do it right you would need to have some method for getting timing data from the DAC to the PCI card. This method works great and is not that hard to implement, but for some reason has hardly ever been implemented commercially. (I have done this myself and it DOES work great)
Both USB and firewire have both adaptive and asynchronous modes. In the adaptive modes the DAC has to adapt to the data rate coming over the bus, in async the DAC controls the timing. The async mode is exactly what we want, the low jitter clock can be right next to the DAC chips and no band aids are needed. (BTW firewire is no different in this respect than USB, most implementations use adaptive mode and a few use async. The assumption some people have that just because firewire is being used it is automatically async is not true)
Async USB is not just marketing BS, if implemented correctly with very low jitter local clocks its one of the best methods for achieving extremely low jitter at the DAC chips.
The problem is there are no off the shelf USB audio async chips available. There a few that theoretically can do async mode but they have to be programmed to do so. The manufacturers do NOT provide the programming to do this. This is what Gordon did, he spent almost two years writing the code to implement async mode on one of these chips. It is NOT easy!! Several years ago I tried this myself and gave up after 4 months of beating my head against a brick wall, Gordon stuck it out and was successful.
This effort he put in represents a huge investment on his part. As with any major R&D effort the payback for this has to be implemented by a slice of the price of the product sold to customers. The price of the actual hardware used to implement the async mode is quite low, its the intellectual property of the firmware running on that hardware where the value lies.
Then there is the rest of the DAC. One of these boxes is not just an async interface, its a high end DAC using high quality components. Most of the cost goes to other parts of the box, the DAC chips, I/V conversion, analog out stage and power supplies. I'm going to make a guess here that the reason for spending all the effort on the async interface was not to have some new marketing buzzword, but because he had figured out how to do a very good job on the DAC chips, analog stage, power supply etc and the limitations of the computer interface of existing solutions was the major bottleneck in achiveing exceptional sound. Going with async USB was one of the few methods to do it right and get jitter low enough to not hinder the rest of the design.
This is primarily why you see audio async only on expensive boxes, its hard to do and only people who are doing the rest of the equation very well are willing to pay the price to implement it properly.
There IS another way to do async USB, that is to throw away compatibility with the official audio async standard. It still takes significant firmware coding, but not nearly as bad as the official async mode. BUT you have to write custom drivers on the computer since you are in effect inventing your own custom USB protocol. If you go this route you have to be willing to write drivers for all the major platforms AND maintain them, provide upgrades when new OS's come out and provide support to end users. This is a lot of effort and most high end companies simply do not have the resources to implement this. The EMU 0404USB and that little new Musiland thingy have gone this route.
The HRT MusicStreamers (at least the ones anybody has seen) do NOT use an async interface, they use the adaptive mode like everybody else.
The one that is interesting is the Musiland thingy. It actually implements an async mode, but NOT the official one, so it requires a custom driver. They took an asynchronous bulk data mode implemented by the USB chip they use and wrote a custom driver to implement an audio interface for it. But then they messed up the rest of it by using a frequency synthesizer to generate the audio clocks rather than using very low jitter oscillators! They seem to have enough programmer resources to write the drivers, we shall see how well they do with multi-platform and long term support. They seem to be putting in the required effort for driver writing but are selling a very low priced product. We shall see whether this is economically viable.
The other thing I want to touch on is the AES/EBU digital interface (the XLR one). Any such interface needs to be able to pass high frequency digital signals, to do this right takes a broadband RF connector with a consistent impedance over a broad frequency range. The XLR connector is a LOUSY RF connector. There are many designs out there that are MUCH better RF connectors than the XLR and any of them would have been a better choice. As far as I can tell the only reason the XLR was chosen is that studios have miles of mic cables with XLR connectors. Because mic cables are lousy digital interconnects they chose to use a very high voltage level, 3-5 Volts so they would have some chance of having some signal left at the other end. (almost all other high speed digital interconnect systems use somewhere between 250mV and 500mV). Just think what it means when you put 5V onto a 110 ohm system, thats almost 50mA of current the driver has to provide, thats a huge amount of current switching very rapidly. That rapidly switching high current supplied to the driver chip is going to induce significant noise on the power supply traces and ground plane on the board. There is a high probability that noise is going to increase the jitter of the output signal.
Its one saving grace is that its balanced, if the input receiver is done right this can make it not quite as bad as it should be given the lousy composition of the rest of the system.
I'm not trying to say that the AES/EBU is always going to sound terrible, some companies have spent a lot of engineering talent trying to overcome its inherent liabilities. Its just that this interface could have been SOOOO much better if it had been designed on technical grounds rather than giving in to studios that wanted to use mic cables as digital interconnects.
I still think the best way to implement this whole getting audio data out of a computer is with a dedicated ethernet chip that can be timed by an external clock. Boxes such as the squeezebox are a step in the right direction, but still rely on computers themselves with all the issues of processor load etc. Its actually possible to implement something like the netjack protocol on a fairly simple custom chip that is actually doing far less processing than a USB receiver chip. My goal is to one of these days make such a chip.
There is more I want to share but this has gotten long enough so I'll stop now.
John S.
|
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2009, Audio Asylum, all rights reserved ]
[ Go Green ]
[ Take5 ]