[Katherine_Focusrite]

Great info, Katherine. Can you explain further your statement "However firewire is still better ( ... than USB2 ...) at bidirectional audio transfer and has a higher bandwidth."? Also, moving forward - what about USB3 or Thunderbolt or ESATA or ??? for audio I/O devices? Thanks - just trying to learn here !!!

Hi EGS,

Thank you for your comment.

On a very theoretical level the Firewire Protocol can run bidirectional transfer better. This comes down to how the packets are sent. While USB 2 has a higher max speed, 480Mbit/s this is not as easily sustained at all times, especially if going in two directions, ie many channels in and out, as compared to firewire.

See this Wiki on USB: https://en.wikipedia.org/wiki/Usb#USB_2.0

There are two types of pipes: stream and message pipes. A message pipe is bi-directional and is used for control transfers. Message pipes are typically used for short, simple commands to the device, and a status response, used, for example, by the bus control pipe number 0. A stream pipe is a uni-directional pipe connected to a uni-directional endpoint that transfers data using an isochronous, interrupt, or bulk transfer:
isochronous transfers: at some guaranteed data rate (often, but not necessarily, as fast as possible) but with possible data loss (e.g., realtime audio or video).
interrupt transfers: devices that need guaranteed quick responses (bounded latency) (e.g., pointing devices and keyboards).
bulk transfers: large sporadic transfers using all remaining available bandwidth, but with no guarantees on bandwidth or latency (e.g., file transfers).

versus: https://en.wikipedia.org/wiki/Firewire

FireWire is capable of safely operating critical systems due to the way multiple devices interact with the bus and how the bus allocates bandwidth to the devices. FireWire is capable of both asynchronous and isochronous transfer methods at once. Isochronous data transfers are transfers for devices that require continuous, guaranteed bandwidth.[5] In an aircraft, for instance, Isochronous devices include control of the rudder, mouse operations and data from pressure sensors outside the aircraft. All these elements require constant, uninterrupted bandwidth. To support both elements, FireWire dedicates a certain percentage to isochronous data and the rest to asynchronous data. In IEEE 1394 80% of the bus is reserved for isochronous cycles, leaving asynchronous data with a minimum of 20% of the bus.[22]

Remember though that this is all very theoretical. If you calculate out the theoretical maximum bandwidth of Firewire it will tell you you can send something crazy like 176 channels. This does not actually happen in practice.

Still you will see that we will not make a unit that cannot support it's own Channel Count fully.

Note that the Saffire Interfaces have a Dual Unit Mode, where the USB devices do not. So while the 18i20 and Pro 40 have the same Channel Count you can connect two Pro 40s together with a firewire cable and use their full channel counts, 40in 40 out.

However you cannot connect two LS56s or an LS56 and Pro 40 with official support.

Also Dual Unit Mode is only supported up to 48k.

Note that "not supported" doesn't mean I have not tried this and had minimal success. I have a Pro 40 and LS56 hooked up right now on my desk in 88.2 and they are passing audio. However as things reach the bandwidth maximum I will likely notice crackles, pops, or drop outs on the firewire bus. This will probably be a lot worse if I am also sending Outputs, rather than just using inputs, due to the bi-directional transfer, and use of much more bandwidth. Remember also that high Sample Rates are doubling your bandwidth, so going from 48k to 88.2 is HUGE difference in transfer.

This is why there is a "Supported up to two Pro 40s at 48k." We will make sure the units can actually 100% perform whatever max channel count we say they have. Above that we cannot support it or say it will actually function properly.

So rest assured, if you see it on the box it works for sure!