The Bitstream Blog :: Posts

Ah, Which Bus Should I Take?

Hallo hoppy reader,

Several times this month, I’ve been asked about USB, FireWire and which is “better” for audio. Because of the recent jive about Apple “dropping” FireWire to control costs on some of their consumer products, I cannah take it any longer and this Bitstream installment is a response.

Let me start by saying neither is “better,” only different so, let’s tweeze some factoids so you can better decode the rants and adverts regarding CE and pro computer audio interfaces. First, a bit of background…USB 1.1 was designed to replace legacy buses for plugging in low speed, serial HUI (human user interface) peripherals, such as mice and keyboards. USB 2.0 is the current version, with USB 3.0, aka “SuperSpeed USB,” on the horizon. USB is designed to be inexpensive to build into a design and, because of its loose spec, allows the designer very wide freedom to implement their vision but lessening the chances of seamless interoperability. A veritable plethora of USB is available on all but the tiniest computers.

On the other hand, FireWire 400 was designed to replace legacy buses for high speed, parallel peripherals, such as disk and optical drives and scanners for graphics. FireWire 800 is the current version, with FireWire S3200 on the horizon. FireWire is more expensive to build into a design and the protocol is tightly specified for maximum interoperability. This means the designer is constrained when implementing their vision. The marketing guys are also constrained since FireWire is available only on enthusiast/gaming machines in the Windows world, and on Macs.

One spec that folks always focus on is “speed” though, in the real world, tossing around a theoretical spec usually has little to do with real world performance because many factors converge in actual operation. USB 2.0 is advertised as having a theoretical limit of 60 MBps while FireWire 800 is supposed to hit 100 Mbps. Either number seems to say that handling data transfers of good ol’ stereo AES/EBU 96/24 at 4.6 kbps (576 Bps) should be a walk in the park from either protocol and, indeed it is. In the real world, USB 2.0’s average speed of about 32 MBps, in one direction only, is way more than is needed and that brings up a key consideration, that of over–provisioning.

 You see, USB 1, 2 and 3 were designed to be cost effective bus protocols where what engineers call “quality of service” is not a consideration. With USB, transfered data arrives at some unspecified time, just as long as it gets there. USB employs a Host/Device model whereby the Host has “intelligence” and is a bus master, while the Device or “endpoint” is “dumb,” without any intelligence and is a slave. Because of this, USB devices cannot operate autonomously and can, in some situations, impose a noticeable load on the Host’s CPU. Also USB 1.1 and USB 2.0 are simplex or one way connections only, like a walkie talkie. One party talks, the other listens.

Taking a different tack, FireWire was designed from the get–go for multimedia applications, where audio and/or video data packets must arrive together, in the right order [unlike ethernet] and at an appropriate time. FireWire employs a peer–to–peer model whereby all devices has equal privileges, is as smart as it needs to be, and can operate autonomously without a computer involved. FireWire also has two data transfer modes, asynchronous and isochronous. Isochronous signaling dependents on uniform timing or carries its own timing information imbedded as part of the signal. Audio and video data is isochronous, but data transfers generally are not.

An extreme example of asynchronous data transport is, once again, ethernet. Any version of ethernet, from 1000BaseT [a.k.a Gigabit Ethernet] down to basic 10BaseT, is so asynchronous that the data arrives at the receiver in random order and the data transport systems have to sort out the mess, reassembling the data stream in the correct order, if possible. Sometime data packets are “dropped” and never arrive at the receiver. if that happens, a request is made to resent the lost packets, further delaying the arrival of a complete data sequence.

One last point…FireWire is full duplex, like a telephone. Anybody can talk any time they want. USB, in all its forms, is general purpose. It’s data type–agnostic and so manages to “do” audio and video by virtue of that phrase I mentioned in the last paragraph, over–provisioning.

Over–provisioning…One way of getting any job done is by studying the problem and designing a methodology tailored to the job description. Take Fibre Channel, a tightly controlled networked storage protocol used where errors and slow–downs are not an option. It’s a very high reliability method of data transport. Another approach is deciding what is the worst case scenario, then over–engineering the system so it can always do better than the worst case spec. A storage example would be iSCSI, where data arrives over ethernet at no particular time and in no particular order and it’s the Target or destination’s job to sort out the mess and deliver a nice, neat result. In general, FireWire is designed specifically to deliver time critical payloads or “essence” as part of its repertoire, while USB is the general purpose, Swiss Army knife of serial buses. Though I own a nice swiss army knife, my go–to blade of choice is my purpose–built, Benchmade 550 with a locking blade. Far safer and, purpose–built.

By throwing way more resources at the problem than will ever be needed, USB is able to unidirectionally move 2 channels of 96/24, from the Host to a Device, without dropping packets. Even if the host is busy servicing interrupts, “Hey, I’m talkin’ to you!”, from some other peripheral or application, there’s so much “slop” in the system that, when the host finally gets around to the USB interface’s request to send or receive data, all is well. The beauty of, yes, over–provisioning, along with generous buffering when an audio peripheral is involved. Remember, this discussion is about moving the data from the host into the endpoint, in this case a DAC. Reframing and clocking the data out of the DAC is a completely different process and has its own collection of issues and compromises.

OK, what if you absolutely, positively must get 2 or 6 or 64 channels of bi–directional 96/24 from point A to point B without one single hiccup or dropped AES frame? Use the tool designed for the job; FireWire. Isochronous mode was specifically designed for the job and that’s why most pro audio vendors provide FireWire unless they’re either hitting a certain price point, want to reach a mass market or, the product is stereo. The maximum isochronous bandwidth of the FireWire 400 bus is approximately 39 MBps so, a well designed FireWire 400 interface can move over 80 channels of 96 kHz/24 bit audio in both directions at the same time over an isochronous connection with bandwidth to spare. That’s 40 channels of 176.4 k/24. Hah, I laugh at your USB interface! Just kidding but, those real world numbers, taken from a professional multichannel FireWire interface, the Model 304 and its brother the ULN-8, does serve to illustrate the fundamental differences between USB and FireWire for audio applications.

Over–provisioning and clever engineering can make a “best effort” interface like USB do the job but why settle for a swiss army knife approach? This brings us back to the original question; which is better? Again, neither. One or the other is appropriate given the selling price of the final product, the desire to target a huge audience of host computers or a niche market of enthusiast/professionals and, channel count and sample rate considerations. Looking to the future, both USB and FireWire are scheduled for a facelift and one important point is that USB 3.0 will, like FireWire, employ duplex signaling. Woot! With a maximum data rate of 625 MBps, USB 3.0 will be ahead in the numbers game since FireWire S3200 will support a max data rate of only 400 MBps. Still, USB 3.0 continues to employ a Host/Endpoint model and lacks isoch mode so, the pros and cons of each protocol continue to cause designers to sit down and make very hard choices…

I’ll save a discussion of the wireless versions of local buses in development, “Wires? We don’t need no stinking wires!”, for a future venting session but, one last thing I’d like to address is the “OK, how does it sound?” debate. Hate to tell you but, unless a peripheral is either malfunctioning or was designed by a twit, data is data and it either arrives unchanged or it does not. Disregarding the effects of conversion to and from analog, which is beyond the scope of this here rant, we can assume that bit transparency is a given, at least for hardware and bus transfers. Nope, the problem is software, and starts with the driver, the go–between software that “makes the hardware work” with a particular type of host computer and operating system. The audio software (application) you choose to use with your audio peripheral and its driver also has a profound effect on sound quality, which you can easily prove to yourself by playing the same file through the same converter, but using different applications/and or drivers to play the file back. Try it, it’s a fun experiment.

If you’d like more reading on this subject, head over to the USB Implements Forum, and the  FireWire Trade Association. I wrote about FireWire back in 2000 and again in February of 2002 while USB got its day in the sun back in August of 2000 and April of 2002. As I said back in November of 2000, “…as goes CE, so goes FireWire.” And lo, it came to pass that USB 2.0 has just about killed off FireWire, in CE applications anyway,  due to its lower total cost of implementation, and consumer electronics is nothing if it ain’t about cheap. So, going forward FireWire will continue to serve hard core rich media pros and enthusiasts while USB will continue to be The Bus for All Occasions!


2 Responses to “Ah, Which Bus Should I Take?”

  1. Good read!

  2. Thanks! Do share the love, links are on the footer… 😉