First Steps into Computer Audio

Guys - just for history. Apple introduced FW400 - it was very cool at the time since we were living in the bad old days of SCSI.

But the WinTel world (remember that) didn't like it (OK they hated it) because they had to pay a royalty for each computer equipped with FW.

So they backed USB. And pretty soon USB was ubiquitous and FW a niche product. Remember we are talking a global market here which is what put USB over the top. I suspect there are a 1,000 USB machines for every FW machine and that might be conservative.

Later USB 1.1 begat 2.0 and soon there will be a 3.0. There are also five iterations of FW by now.

As long as we are using RedBook and 24/96; speed is not an issue - the audio files are very small, while cache, RAM and busses are very fast. To be sure an old PC which is asked to do some other processor intensive tasks at the same time or whose HD is an overloaded nasty mess may have some trouble keeping up. Same for a 386 PC that is being asked to upsample. This is one of those fascinating things that the bit biters like to bring up over and over but one never finds a concrete example of... YMMV

FWIW the general consensus seems to be that while we can agree that FW is a much better format then USB for some things, the war is long over and FW is and will remain a niche product.

Consider that many of the newer Apple Notebooks like the MacBook, the MacBook Air and the Mac Mini don't come with FW. No argument that its a way to control costs - but it reflects the fact that no one uses it.

There is a reason that Steve, Gordon and most everyone else designs for USB - it's what people use. Which is why that is most likely where the innovations will occur. And is most certainly the choices are.

These comments from Charles Hansen of Ayre are a pretty strong refutation of the Firewire point of view.

Thanks for the link, Drubin...that's an interesting read. Also, Ckorody for the computer interface history.

Yeah, he asked that same series of questions of several (many!) digital gurus. Great stuff, and they were the right questions as far as I'm concerned.

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 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.