You asked for it, here you go, USB audio 101! The USB audio specs define a set of protocols for sending audio over USB. Not every audio device uses these rpotocols, for example M2Tech wrote their own protocol, which means they need their own driver. In this post I will just cover the official ones.
Fairly often you will hear someone say something like: "my USB hard drive works perfectly, how come USB audio has so many problems", well USB audio does NOT work the same way a disk drive does. The audio protocols use what is called "isochronous" mode. This is a fancy work for constant time. It means the USB bus is sending out data at a constant rate. For a disk there is handshaking, the device says I want some data, the host sends over a bunch then waits. When the device is through with that chunk of data it asks for more. Audio doesn't work this way. The host sends out a constant stream of packets with no request or reply form the device. The packets on the bus go at 1KHz rate no matter what, the audio driver has to figure how many bytes in each packet go to the audio device. Since that would never come out exactly to a audio sample rate (44.1KHz etc) it actually changes the number of bytes per packet in a regular packet. For example it might send out 100 bytes perpackets most of the time, but every so often it sends out 101 bytes. The ratio between the 100 and 101 byte packets determines the average sample rate. On the receiver side these bytes are put in a buffer and read out by a local clock and sent to the DAC chip. The problem is that the frequency of the clock is never going to match the average data rate coming from the host. How this is handled is THE prime differentiator, there are two methods: adaptive and asynchronous. Note both of these are still isochronous. First off, adaptive. With this method the local clock is variable in some way. Hardware in the device monitors the buffer and if it starts getting too full it speeds up the local clock. If it gets too empty it slows down the clock. There are two primary sources of jitter with this scheme, the first is the inherant jitter of the variable oscillator. There are MANY different ways to make a variable oscillator, all of them have higer jitter than a good fixed oscillator. Some have fairly low jitter and some have quite high jitter. Its usually a tradeoff between cost/complexity and jitter. If you use a $2 off the shelf chip, figure out where you will be in that range. The other is the timing of the input signal. The packet timing is rarely perfectly constant and how often the stream switches between say 100 and 101 bytes also varies. Both these can affect when the clock gets changed and by how much. This changes the time between clock pulses as well as the intrinsic jitter. The software on the processor controls this timing, so things like interrupt timing CAN directly affect the jitter on the clock. How much it does is very design dependant. Now on the asynchronous. This is still isochronous, the host just sends out packets at contant rate, the difference is the clock. It uses a fixed clock, which can have significantly lower jitter than a variable clock. In addition there is no relationship between its timing and whats happening with the timing on the bus. The problem is that you need some way to deal with the different rates between host and local clock. This is taken care of by a feedback path from the receiver to the host. The receiver monitors the buffer just like it does in adaptive mode, but instead of changing its own clock, it sends commands back to the host to tell IT to slow down or speed up. The host does this by changing the ratio between the 100 and 101 byte packets (remeber thats just an example, it's not really 100). Theoretically this should produce an interface that just has the intrinsic jitter of the fixed oscillator. Unfortunately that rarely happens in practice. In reality the input receivers in the DAC still produce ground current in the groundplane with the timing of the input signal. This ground current can change the timing of the local clock and other circuitry. It takes a LOT of design effort to isolate the sensitive parts from that noise. Thus an asynchronous interface is theoretically the best way to go, it still does not guarantee that the DAC will be completely immune from host computer affects. Even if they DO exist its still better over all. The things on the computer that affect jitter in the DAC will be less with the async interface. Some tweaking of the computer to lessen these effects will soon get the DAC near the intrinsic jitter of the fixed oscillator, which is going to be much less than the jitter of the variable oscillator used in async mode. So the upshot is that async IS a good thing, it may not be perfect in many implementations, but its still better than a good adaptive implementation. So there you go, way more than you ever wanted to know about USB audio. John S. -- JohnSwenson ------------------------------------------------------------------------ JohnSwenson's Profile: http://forums.slimdevices.com/member.php?userid=5974 View this thread: http://forums.slimdevices.com/showthread.php?t=84903 _______________________________________________ audiophiles mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/audiophiles
