Firewire Audio Bandwith

[Rocket Boy]

I'm just curious if there is a specific number that can be attributed to this. I know that FW400 is 400mbps and FW800 is 800mbsp, but what does that translate into regarding how many tracks can be streamed back and forth at one time?

I guess the question breaks down to: How much of an advantage does 800 give when running an external hard drive or interface?

 

[dementedchord]

well do the math...X=#tracks(44k/24) in short fw is real fast... of course thats in a perfect world... you'll most likely not see/need that bandwidth...

 

[brzilian]

1 mono track of 24bit/96Khz audio eats up 2.3 mbits/sec (24*96,000). That means Firewire 400 is capable of handling just under 200 mono 24/96 tracks at any given time. 16/44.1 audio only eats up .7mbits/sec, so your track count would double to 400.

 

[dgatwood]

It depends. A FireWire audio device may make a reservation that is substantially larger than the actual bandwidth. I asked some people on the Core Audio team about my little experiment with an insane number of inputs (was it 42? I forget) and the resulting hang. Their best guess was a bandwidth reservation failure.

Anyway, in the course of the conversation, they told me that the drivers for some interfaces may reserve as much as 100-200 Mbps of isochronous bandwidth per device instance even though the device won't ever really use anywhere near that. You can safely assume that any bandwidth resesrved for isoch is lost. Thus, when dealing with FireWire interfaces, you should assume that in the worst case, one interface can cut the available bandwidth of FW400 in half just because of overkill by the driver writers.

Once you subtract the isoch bandwidth reservation from the available bandwidth, you can then do the usual channel math on whatever remains and you should be in the ballpark.

 

[brzilian]

It depends. A FireWire audio device may make a reservation that is substantially larger than the actual bandwidth. I asked some people on the Core Audio team about my little experiment with an insane number of inputs (was it 42? I forget) and the resulting hang. Their best guess was a bandwidth reservation failure.

Anyway, in the course of the conversation, they told me that the drivers for some interfaces may reserve as much as 100-200 Mbps of isochronous bandwidth per device instance even though the device won't ever really use anywhere near that. You can safely assume that any bandwidth resesrved for isoch is lost. Thus, when dealing with FireWire interfaces, you should assume that in the worst case, one interface can cut the available bandwidth of FW400 in half just because of overkill by the driver writers.

Once you subtract the isoch bandwidth reservation from the available bandwidth, you can then do the usual channel math on whatever remains and you should be in the ballpark.

I would think that would be accounted for already. By that, I mean the actual bandwitdth is higher than 400mbps, but once you remove the handshaking overhead you actually end up with the 400mpbs figure. Otherwise, the spec is pretty much useless for developers who need to max available bandwidth for whatever useage scenario they are looking at.

 

[dgatwood]

I would think that would be accounted for already. By that, I mean the actual bandwitdth is higher than 400mbps, but once you remove the handshaking overhead you actually end up with the 400mpbs figure. Otherwise, the spec is pretty much useless for developers who need to max available bandwidth for whatever useage scenario they are looking at.

I'm not talking about overhead. I'm talking about bandwidth reservation. They're completely unrelated.

The way an audio device does communication is called isochronous mode. What this means is that the notion of time on the bus is divided up into small pieces of equal length. Let's say that it is divided into a hundred pieces. (It's really 8000, but I'm trying to give a simple example for illustration.)

The device asks the bus for a chunk of bandwidth. Assuming there is sufficient bandwidth available for reservation (that is, assuming other devices haven't reserved too much), that device will have exclusive rights to a certain number of those equal length units of time per second, separated by an equal amount of time (approximately). So if a device asks for ten of the hundred pieces in our example, it might get chunks 1, 11, 21, 31, 41, 51, 61, 71, 81, and 91.

Such a reservation has the effect of guaranteeing that the device need not compete with other devices for available bandwidth. The bus is guaranteed to be available to the device during those periods of time, period.

What if the device really only needed eight chunks? It runs out of data after four chunks and does not use the fifth chunk, then starts sending data again on the sixth. In that case, chunks 41 and 91 are wasted. No other device can use those periods of time even if the isoch device only uses a portion of the amount of time that it requested. If some other device were to use that amount of time and the isoch device later discovered that it needed the time, you would get a glitch because the device would assume that it had exclusive rights to that period of time.

Here's an explanation of FireWire isochronous mode.