Transfer rates of USB/Firewire/PCI

[darkecho]

Ok, This has always been a cloudy subject to me so im going to try and figure it out with everyones help so anyone else with the same fog might get enlightened.

from my research i have found:

USB1.0/1.1 = 12mbps
Firewire = 400mbps
USB2.0 = 480mbps
PCI2.2 = 533mbps
IEEE1394b (New firewire) = 800mbps/1600mbps/3200mbps


So with that said, before we can declare which is the best for say a Computer Audio Interface, what is the maximum neccesary speed of recording? I assume that a single channel of audio being inputted to a computer would probably take a max of 5mbps but this is a very unthorough guess. if this is the case however, then that means that even the oldest USB would be sufficient for about 2 input tracks. everything newer would provide wayyyy more speed than necessary and thus, Firewire=PCI=USB.

there is another question... I have a feeling that firewire would perform better under a heavy load (say 8 channels simultaneous recording).. for some reason it just seems that the USB counterpart (even though its faster at 480vs400) would maybe lag out or something.. I have no scientific stuff backing this up but it just seems the most logical.. maybe it because the firewire cables are beefier .

Anyone who can chime in and help me defeat this confusion it would be greatly appreciate!

 

[Creamyapples1]

I'm not sure what IEEE1394b (New firewire) = 800mbps/1600mbps/3200mbps is. What are the different speeds?

BUT
In theory, saying that firewire is on average 800mbps, and PCI is 533mbps, and being that you can run multiple PCI cards at a time, but there seems to be some grey area as to firewire and usb being able to function like this. 3 M-Audio Delta 1010LTs would provide 24 analog I/O at a collective 1599mbps, or 533mbps per 8. This is all just me talking, like I said, the 800, 1600, 3200 thing confuses me so I could just be talking out my ass, which I do frequently.

 

[darkecho]

I just read this info from a source and the newer firewire products (IEEE1394b) stuff starts at 800mb/s and I guess that other variations of it can run even faster (hence 1600mb/s and 3200mb/s)

the question at the moment for me is
a.) how much bandwidth does an average recording take for say 8 simultaneous tracks.

and

b.) how does USB perform in relation to Firewire under more intense loads? does USB crap out and lagg up if say your recording (could be any number right now, but lets say 50) tracks simultaneously? which one would do better? i have a feeling it doesnt have to do with the transferspeed but rather the technology of USB/Firewire.

 

[j-boy]

I don't have the exact figures handy but your ranking seems incorrect. PCI still has a greater bandwidth than FireWire 800. They are (least to greatest): USB1>FW 400> USB2> FW 800>PCI.

 

[darkecho]

are you sure? because I looked it up at answers.com and got the 533mbps for PCI 2.2... there is PCI express out now but mostly nothing uses that technology at the moment, especially soundcards. Likewise, nothing really uses the new firewire technology (not that i know of) so the main thing we need to know is what demands does recording audio have as far as Mbps.

 

[dgatwood]

Ok, This has always been a cloudy subject to me so im going to try and figure it out with everyones help so anyone else with the same fog might get enlightened.

from my research i have found:

USB1.0/1.1 = 12mbps
Firewire = 400mbps
USB2.0 = 480mbps
PCI2.2 = 533mbps
IEEE1394b (New firewire) = 800mbps/1600mbps/3200mbps

Not quite right. FireWire always included the 800/1600/3200mbps variants in the spec. However, 1394b is the 800 variety by itself. No manufacturers are actually building any release silicon with FW1600 or FW3200 yet, as there really isn't much of a market for it currently. It is in the spec, however, and has been since day one.

Also, PCI is way faster than that. Even first generation PCi was about 132 MBps (bytes, not bits), or a little over a gigabit per second. (That's 33 MHz times four bytes per cycle for 32-bit PCI.) The last generation of parallel PCI is 64-bit at 66 MHz. That's about four gigabit per second, so you're off by about a factor of 10. Maybe that's 533MBps. Yeah, that sounds close.

Of course, PCI-X (also parallel) can do 133 MHz, so even in parallel PCI, you're still low by a factor of two if you're looking for the latest and greatest. And then you have PCIe (A.K.A. PCI Express), which is in the process of replacing PCI. That peaks at 80 Gbps (10 GBps). But we won't go there, as there aren't any PCIe audio interfaces out yet, AFAIK, except maybe something from Digi.

I assume that a single channel of audio being inputted to a computer would probably take a max of 5mbps but this is a very unthorough guess.

32-bit float samples at 192 kHz would be 6.144 Mbps, the usual 24-bit int samples would be 4.5 Mbps, so 5Mbps seems like a pretty good rough estimator.

if this is the case however, then that means that even the oldest USB would be sufficient for about 2 input tracks. everything newer would provide wayyyy more speed than necessary and thus, Firewire=PCI=USB.

In theory, and under ideal circumstances, yes. By ideal, I mean an otherwise idle CPU, though....

there is another question... I have a feeling that firewire would perform better under a heavy load (say 8 channels simultaneous recording).. for some reason it just seems that the USB counterpart (even though its faster at 480vs400) would maybe lag out or something.. I have no scientific stuff backing this up but it just seems the most logical.. maybe it because the firewire cables are beefier .

Nothing to do with the cables, but yes, FW does perform better under heavy CPU load because the CPU isn't involved as much. There are many other subtleties as well, probably not worth going into.

And real world performance for USB isn't actually 480 Mbps. The practical limit in most tests ranges from about 400-420 Mbps, pretty much on par with FireWire... except that the USB setup is eating far more CPU cycles to keep up with those data rates.

 

[dgatwood]

I don't have the exact figures handy but your ranking seems incorrect. PCI still has a greater bandwidth than FireWire 800. They are (least to greatest): USB1>FW 400> USB2> FW 800>PCI.

In practice, it is approximately:

USB 1.x < (FW400 == USB2) < FW800 < PCI.

though the relationship between FW400 and USB2 varies widely depending on access pattern. For bulk transport (large mass storage requests), USB2 will edge out FireWire if your CPU can keep up. For smaller stuff, USB2 can lag behind slightly in raw performance.

Of course, for audio, none of this matters. What matters for real-time data traffic (isochronous communication) is latency at every layer of the driver stack and hardware chain. To explain why this is the case, it is necessary to explain a little bit about how audio drivers work at a high level.

At each stage of the audio pipeline from the input to the output (or at the very least, between the audio device driver and the audio device itself), you will find a ring buffer. A ring buffer is nothing more than a series of addresses in memory in which once you have written or read the last spot in memory, you jump back and write or read the first one, continuing in a circular loop (hence the term ring).

Pointers move this way -->
|XX|XX|XX|XX|XX|XX|XX|XX|XX|XX|
__read------^write----------------^

The way this works is that you have one side (for input, the audio interface) writing data while the other side (for input, the device driver) reads data. The read pointer always chases the write pointer around the ring buffer. In so doing, it always reads data after the new data is written, and is not allowed to catch up to the write pointer (or vice-versa), as this will cause a rather nasty glitch.

In the above image, the write pointer is about to wrap around to the first position in the buffer, while the read pointer will have to read several samples before it wraps back to the beginning. The distance (in samples) between the write pointer and the read pointer are the latency for this ring buffer. In the above drawing, about six samples.

The shorter the distance between the hardware's write pointer (for recording) and the driver's read pointer, the lower your latency, but this comes at a price.

The closer you try to keep this pointer, the smaller the chunk of data you have to read from the device each time. The smaller the chunk of data, the more overhead you have to put up with on the bus, and the more CPU overhead that is required. So USB's deficiencies in CPU overhead end up getting compounded by smaller transfer sizes and lower latency.

The problem then occurs when the CPU isn't fast enough to get one of these packets and ends up slipping the read pointer back a bit. This may be heard as an audible glitch while listening to software play-through, depending on how far behind it slips relative to the amount of data your audio software is expecting. At that point, depending on how your your audio software was written, it may also have just recorded a fraction of a second of silence that didn't really exist, in which case your recording is screwed.

Even if the audio software just lets its playback side skip a few samples and the recording side ignores the momentarily delayed data, though, you aren't out of the woods. There are only so many slots in the buffer, and once it slips a certain distance, wham. Suddenly your write pointer catches up with the read pointer, and effectively at this point, you have lost one entire buffer worth of audio, as it is being overwritten before the software can catch up.

The flip side of this also occurs occasionally, though it usually indicates a buggy driver/application/device rather than a performance issue. In the reverse case, the read pointer fails to remain behind the write pointer when a device stops. In a playback example, the device might fail to stop playing when the device driver stops sending it data. The result of this would be that the audio interface would play old data a second time. If the device completely fails to stop, you'll get a very lovely(*) looping sound.

(*) The word "lovely" is being used in an ironic sense.

This concludes part 1 of Dave's audio device driver basics....