usb is (as correctly pointed out) an issue for some interfaces... that tacam as i understand it should not have this problem as it is a usb2 device... most of the others are only usb(1) and have problems with throughput...
No, that's not true at all. Problems with USB have nothing to do with throughput. USB 1.0 is fast enough to handle ten channels at 44.1, eight at 48 kHz. People have trouble with USB just doing -two- channels.
also with usb devices the bus reserves some of the bandwidth for other devices even if not being actively used... so make sure printers and other perriferals are disconnected...
Also not true. The only bus reservations supported by USB are isochronous mode. With the exception of audio devices and webcams (video devices), no USB devices do bandwidth reservation. If you reserve bandwidth, you are expected to have data to send down the wire for X frames out of every Y, and you are basically told which time slices on the bus are yours. It's worthless for anything other than audio/video streaming, and it is not
possible for most USB devices devices to use isoch, as none of the USB standards (e.g. USB mass storage) except for the A/V standards use isoch as part of the protocol.
The problems with USB are:
1. Isoch mode is broken. It's way too easy to lose your isoch reservation. This causes severe audio malfunctions.
2. The USB 1.0 Audio standard is hopelessly broken. USB 2.0 is better in that regard.
3. Intel (UHCI) chipsets are problematic, particularly on the USB 1.1 side. A lot of problems go away if you buy an OHCI USB card, but if you have to buy a card anyway, it might as well be FireWire....
4. Built-in USB host controllers almost always share interrupts with multiple other devices because USB devices are considered low priority by motherboard manufacturers.
5. USB causes high CPU load because the controllers are really, really dumb. They don't support true DMA, nor do they have any way to do automated data copying for isoch support without using the CPU.
Those last two are the real killers. Shared IRQs are problematic if driver writers don't know how to handle it, and for audio, it's an even bigger problem because it means somebody else's driver can cause arbitrarily large amounts of latency before the interrupt is delivered to your driver.
The lack of automated data copying (such as FireWire DCL programs) in hardware is also a major weakness. In effect, with FireWire, you can basically do bounceless data exchange in which the audio app is seeing a buffer that is filled entirely by the FireWire hardware. In some OSes, you'll have an intermediate buffer. Either way, with USB, the OS has to manage an additional copy operation, and in the worst case (a bounce-buffered OS), two additional copy operations. That means more CPU overhead again.
However, disconnecting other devices is still a good idea. USB isn't a very smart bus. Depending on the hub, you may or may not be able to mix USB 1.1 and USB 2.0 devices without everything slowing down to USB 1.1 speeds.
