Thanks - I didn't even notice that. EXCELLENT information from various perspectives. For Cerrot, here is the take from the initial question about interfaces posed to Steve Nugent of Empirical. This also goes directly to the question of USB vs Firewire:
The index of all of the interviews is here
Thanks again for pointing that out, Drubin.
The only interface of those listed that can have Async protocol, or handshake with flow-control is USB. Firewire does not support it and neither does AES/EBU or S/PDIF, coax or Toslink. Async protocol allows the master clock to be located at the designation device, either a converter, reclocker or the DAC itself, which is the optimum scenario. This establishes the master clock near the D/A conversion and then controls the source rate using a flow-control protocol.
However many USB and all Firewire interfaces do not use flow-control. The jitter characteristics with these is only as good as the circuits/chips that track the incoming stream from the computer. The master clock is established at the source, which is the computer, and then this must be maintained by all circuits up to the D/A conversion. The jitter from the computer must be dealt with by using PLL-type devices (Phase-Locked-Loop). These track the incoming datastream and synchronize to it, as the same time using filtering and other clever tricks to reduce the jitter of the original stream. Fortunately, there are a few very good chips available that deal with jitter very effectively, namely the DiceII chip for Firewire and the TAS1020 for USB. Even though these do not establish the master clock for the system and instead track the computer datastream clock, their jitter rejection is excellent. Current support for samples rates is: USB - 24/96, Firewire - 24/192 and S/PDIF - 24/192. Look for this to change in 2009.
Of the interfaces listed, an important one was omitted, and that is networked, otherwise known as LAN, Ethernet or Wi-Fi wireless network. The protocol of this network has inherent in it the flow-control and retry mechanisms that enable the optimum audio streaming scenario, as well as having the advantage of avoiding altogether the sometimes troublesome audio software stack of the computer OS. Using networked devices, either wired or wireless can be no different than sending data to a printer. The only concern is getting the data to the device intact. There is no timing information sent or implied. The data is not contiguously streamed at real-time speed as with USB, Firewire or S/PDIF interfaces. It is packetized and sent periodically in high-speed bursts over the network, whenever the network has an "opening". These packets are then collected in a buffer memory at the destination device where they can be clocked out to the D/A using a local low-jitter master clock. The fact that networked data flow incorporates flow-control and retry, and bypasses the computer audio stack makes it the superior method. The only disadvantage is that the player that interfaces to the network is currently a custom player, such as Squeezecenter or Sonos. Hopefully, in the future Microsoft and/or Apple will create more generic player software to drive a networked interface so that more player options will be available. As for bandwidth, networked interfaces can not only support the highest audio sample-rates, such as 24/192, but it can support multiple channels of this, allowing for multiple channel playback for software generated speaker crossover and even movie surround-sound.
The index of all of the interviews is here
Thanks again for pointing that out, Drubin.
