USB to Firewire....is this thing okay to use?!

[LeedyGuy]

Can I use this thing in good conscience? I don't have firewire capability in my new laptop, but I am using a MOTU 828.

http://www.ebay.com/itm/Firewire-IEEE-1 ... %26ps%3D54

[Nick Sevilla]

It should work, however remember it will be a USB speeds, dictated by the laptops motherboard.

Cheers

[agershon]

Danger Will Robinson! Mixing protocols is a dodgy bet. But plug it in and see.

Does your lappy have room for a card? I used a firewire card for a Digi002 on an old Dell and it worked fine.

[TimOBrien]

Those are for burst mode copying of things like camera photos to the computer, not sustained transfer of audio data.

If your new laptop does not have thunderbolt or cardbuss port to allow a firewire card, you need to sell your interface and get a usb one.

[Randyman...]

Those are for burst mode copying of things like camera photos to the computer, not sustained transfer of audio data.

If your new laptop does not have thunderbolt or cardbuss port to allow a firewire card, you need to sell your interface and get a usb one.

Agreed. I'd bet the MOTU FW Driver will be all kinds of fubar'd when trying to translate-on-the-fly via the USB dongle (probably wouldn't work at all TBH as the MOTU FW Driver won't see any FW Controllers). Unload your old unit on eBay and look for one of the newer 828's with FW+USB - or look to RME for insane USB ASIO performance.

FW is quickly becoming obsolete - on par with legacy PCI IMO. PCIe; External PCIe, and USB3 are the future. Cheaper than Thunderbolt (on all fronts: cards, cables, and licensing), and faster in some cases...

[calaverasgrandes]

MOTU 828 is great piece of gear, been my converter for a while now.
But it is super picky about firewire. You are better off using a cardbuss or PC card firewire solution with TI chips on it.
The Ricoh, and Via chips are pretty lousy, Agere appears to work sometimes.
There is a MOTU mesage board called motunation with a lot of discussion of what works and what doesnt with various MOTU boxes. Be wary if you are a Windows user. They are kind of abusive of the WIntel faction over there.

[TimOBrien]

FW is quickly becoming obsolete...

The nice thing is that Thunderbolt is backwards compatible with firewire by using the $30 Apple tbolt>firewire adapter. Thunderbolt has 12x the capacity/bandwidth of firewire800 so this is not a problem.

[apropos of nothing]

MOTU 828 is great piece of gear, been my converter for a while now.
But it is super picky about firewire. You are better off using a cardbuss or PC card firewire solution with TI chips on it.
The Ricoh, and Via chips are pretty lousy, Agere appears to work sometimes.
There is a MOTU mesage board called motunation with a lot of discussion of what works and what doesnt with various MOTU boxes. Be wary if you are a Windows user. They are kind of abusive of the WIntel faction over there.

So. Happy. About. This. Upgrade. Path.

Also CG is spot-on about everything. Listen to the man; he is wise.

[diogo_c]

FWIW - the speeds:

Firefire 400 = 400 Mbit/s
USB 2.0 = 480 Mbit/s
FireWire 800 = 800 Mbit/s
USB 3.0 = 5 Gbit/s

Source:

http://en.wikipedia.org/wiki/List_of_de ... Peripheral

[Randyman...]

And just as a reference, USB2.0 is PLENTY for 128 Channels of 44.1/24 audio. RME's soon to be released MADIface USB does just this over USB2.0, and with impressive latency specs

[analogika]

FWIW - the speeds:

Firefire 400 = 400 Mbit/s
USB 2.0 = 480 Mbit/s
FireWire 800 = 800 Mbit/s
USB 3.0 = 5 Gbit/s

Source:

http://en.wikipedia.org/wiki/List_of_de ... Peripheral

Those are nominal bitrates, and as such, do not mean what you think they mean.

FW400, for example, GUARANTEES a sustained 400 Mbit, with error reporting. The device controllers sync up and handle the transfer.

USB 2.0 is CPU-dependent and has a PEAK throughput of 480 Mbit/s. This looks higher than FW400's bandwidth, but comes with several strings attached:
1.) If your CPU is under heavy load, USB transfer speeds go down the toilet, as does your recording.
To fix this, USB 2.0 had a "synchronous" mode, whose bandwidth is guaranteed but WAY lower than the nominal 480 Mbit, but which
2.) doesn't have error reporting. In other words, your interface may have conked out, sync lost, massive dropouts and clicks all over the recording, and you won't even know about it until you're sitting down to edit/mix the damn thing.

In practice, USB 2.0 is no faster than FW 400, and an absolute no-go for anything requiring sustained data rates approaching its nominal limit.

To say nothing of Firewire 800.

There are very very few high-end audio interfaces that run via USB 2.0, and AFAIK, they all use custom drivers and protocols through the USB port, but don't actually work via the USB standard.

With the advent of copious CPU resources and USB 3.0 (which IIRC still suffers many of the same limitations as 2.0, but is fast enough for that not to matter), the Firewire advantage has all but disappeared, just in time to be replaced by the almost infinitely more flexible Thunderbolt.


Edit: Also, FW and USB are completely opposite approaches to building a transfer protocol. Converters like the one mentioned in the original post are possibly barely useful for the purposes stated on the box, but completely out of the question for anything involving actual timing, let alone real work.

[Andy Peters]

Those are nominal bitrates, and as such, do not mean what you think they mean.

FW400, for example, GUARANTEES a sustained 400 Mbit, with error reporting. The device controllers sync up and handle the transfer.

USB 2.0 is CPU-dependent and has a PEAK throughput of 480 Mbit/s.

These bit rates do not mean what you think they mean.

FireWire's 400 Mbps bit rate, as well as USB's High Speed 480 Mbps, are signaling rates. They are the speeds at which the bits toggle on the wire.

Every USB High Speed transaction runs on the wire at 480 Mbps half duplex. Every FireWire 400 transaction runs on the wire at 400 Mbps full duplex.

Signaling rate is entirely independent of (except to set a maximum for) "data rate" which is imposed by the protocol.

USB 2.0 is CPU-dependent and has a PEAK throughput of 480 Mbit/s. This looks higher than FW400's bandwidth, but comes with several strings attached:
1.) If your CPU is under heavy load, USB transfer speeds go down the toilet, as does your recording.

It is entirely possible for a FireWire system to fall down under heavy CPU load, too.

To fix this, USB 2.0 had a "synchronous" mode, whose bandwidth is guaranteed but WAY lower than the nominal 480 Mbit, but which
2.) doesn't have error reporting. In other words, your interface may have conked out, sync lost, massive dropouts and clicks all over the recording, and you won't even know about it until you're sitting down to edit/mix the damn thing.

Sorry, no. Please, if you don't understand how USB works, perhaps you should consider not commenting.

USB has four transaction types: Control, Interrupt, Bulk, and Isochronous. FireWire has two: non-Isochronous and Isochronous.

For transactions where real-time data transfer isn't important, a design uses one of the non-isochronous transaction types. For the Control, Interrupt and Bulk types with USB, and the FW non-isochronous, data transfer is guaranteed. Retry is possible if the device is not ready to send or receive data.

For audio and video work, where real-time data transfer is imperative, both FireWire and USB use the isochronous data transfer mode. In this case, bus bandwidth is reserved for the transactions. When the device is plugged in, it enumerates and the host computer learns about what the device needs to operate. Specifically for audio and video, the device reports what bandwidth is required when it is actually transferring those data. In practical terms the device can use up to over 80% of the bus bandwidth. (The operating system will reserve 10% for Control transactions, and if a device which uses Interrupt transfers, the bandwidth needed for them is reserved, too.) I have watched audio device bus traffic on a USB analyzer and it will use all of the bandwidth it can if necessary.

The major difference between the isochronous and non-isochronous endpoints is that the former cannot retry transactions. That's reasonable: you can't ask your microphone to give you that same sound again. So the system must designed to ensure that you don't actually overrun or underrun.

When you are not recording or playing back, the isochronous audio device doesn't use any bandwidth. Other devices on the bus can use it as needed.

When your DAW is to start playback or recording, it will attempt to open the audio interface. That's when the device driver asks the host for the bandwidth it needs. If the bandwidth is not available, the driver returns an error message which hopefully your software will interpret as "not enough bandwidth." Otherwise, the required bandwidth is reserved for use by your device. NOTHING else is allowed to use that bandwidth. It will remain reserved until the driver releases it, after your DAW stops playing back or recording.

You might see something here. Imagine that your hard disk and your audio device are connected to the same hub, sharing a port on your computer. So what happens if the audio device is using all of the bandwidth? Well, it seems like your hard disk won't get any bus time, and that's true. But that's also true for FireWire systems.

As a consideration, remember that 16 channels of 48 kHz 24-bit audio require 18.4 Mbps bandwidth (not including overhead, so add 10% for that), a small fraction of the High Speed 480 Mbps toggle rate. There's no reason for the system to fall down or be starved of data, even with a hard disk on the same bus. (Of course that wasn't true at all back in the day of USB 1.1 and its max 12 Mbps Full Speed bus rate. But you can't buy a computer with only USB 1.1 ports on it any more.)

-----------------------------

Now you mentioned "USB 2.0 has a synchronous mode ...." You're confusing the isochronous endpoint synchronization mechanism with the transaction type. For non-isochronous transactions, there's no synchronization so that "mode" doesn't apply.

For isochronous transactions, the synchronization mode is how the host and the device manage the data flow. In all cases, the device tells the host its packet size, which by design must be within the capability of the bus to handle. (A device should never demand more data transfer than the bus allows.)

When in "synchronous mode," data transfers are synchronized to the USB "Start Of Frame," which occurs every 1 millisecond. Every millisecond, the host will transmit and/or expect to receive a specific number of bytes. It is assumed that the device can sink or source the data properly. (That's why you set up the bandwidth, after all, since you should know how fast your device can sink/source data so you should never starve or overrun.) Your audio sample clock is phase-locked to the USB SOF.

In the "adaptive" synchronization mode, the data sink (your audio device in playback mode, the computer in record mode) controls the data flow by telling the source when it's ready for data. A properly-designed system still ensures that the pipe is neither starved nor overrun. Your audio sample clock is locked to the data sink.

In the "asynchronous" mode, the audio clock is free-running with respect to the USB Start Of Frame. Data are put into and pulled out of buffers as needed. The asynchronous source tells the sink its data rate implicitly, as it transmits. The asynchronous sink needs to tell the source its data requirements. Since the audio is not synchronized to the data, some elasticity in the buffering is necessary to ensure that nothing is lost. In practice, this is not a concern.

FireWire isochronous transfers work pretty much the same way.

Sorry this was so long. But it's kind of frustrating to read someone expounding on about something they don't understand. (I'm not new to the Internet!)

[analogika]

Your clarification is very much appreciated. Saved and filed for future reference.

And FWIW, I was referring to isochronous mode.