17 Sep
2010
17 Sep
'10
11:21 p.m.
First off any noise that you hear through your USB
Audio
interface is because the grounding in the audio device is using
the grounding on the laptop which is most commonly data ground
wired to earth ground. So you hear all computer noise through the
audio output. One way to alleviate this is to lift the ground on
the laptop (unplug the power adapter from the laptop or get a
ground lift adapter). Noise goes away. A lot of devices suffer
from this, 1394 has same issue.
This depends on the device and the computer, of course. A well
designed ground, especially on balanced outputs, is not going to
have difficulties.
Some Hubs are just splitters, they mult one port into
two or more
using the same power and bandwidth as the source port.
All hubs are active. If you're talking about *power*, this is sort of
correct (it is still actively managed, nothing passive about it,
there's just less available as there's a max draw allowed on the host
cable).
These are
typically passive devices (i.e. no power supply) and are not
recommended for anything that requires full power of the USB bus
like a USB Audio device.
It has nothing to do with the power requirements and unpowered hubs
are not passive.
The difference between 2.0 hubs lies in the number of Transaction
Translators they have. A hub with a single Transaction Translator
(the vast majority of them) is like a single host controller; all your
devices compete for a single bandwidth 'schedule', so that if a single
1.1 device demands the whole schedule, it doesn't matter that it's USB
2.0 in or there are four ports.
A very few hubs have more than one TT (usually one per port), and that
means that you can have multiple USB 1/1.1 devices on multiple ports
not compete with each other for 1.1 bandwidth (obviously they still compete
for total source bandwidth).
...but the point is mostly moot on Linux where the TT scheduler code
in EHCI can't fully utilize a single TT let alone more than one. The
TT bandwidth schedule is set by the host controller in USB, it is
merely a puppet that follows the host controller's commands. So the
EHCI driver is actively managing not only the host controller, but all
hubs plugged into it and all TTs as if they are direct extensions of
the hive mind.
However using USB Hub that is powered will improve
your chances,
even there you might have an issue unless you know exactly
whether or not the Hub vendor made the device to properly
replicate data and power to each output port.
A powered hub is allowed to source more power for its devices because
it's not limited by host port draw requirements, but it has nothing to
do with bandwidth.
Another item to consider is that laptops especially PC
laptops are
designed so that there are 2 physical ports per internal USB
controller.
That depends entirely on the machine, eg, it wasn't true of PowerMacs
(I had one; it had a full controller per port). My thinkpad's SS
ports are one controller per as well.
When using a powered hub, make sure you don't have
anything plugged
into the second port (above, below or next to) the one you're already
plugged into when running a single USB Audio device or when running
with a Hub. Powered hubs cost more (typically $25 - $50).
The hubs you want are multi-TT hubs. Cost doesn't seem to be a
predictor, and it's hard to spot in the marketing.
Well, actually, if you want working USB, you don't use Linux.
Another item to remember with USB Audio is that the
devices typically
pull 50 - 80% of the USB bus data stream for 16 bit 44.1 to 24 bit 48k
recording. and up to 95% when running 24bit 88.2 or 96 or higher (on
USB 2.0) sharing that port with other devices will almost always
interfere.
It is not the amount of data as much as the way the bandwidth is
scheduled and the fact that Linux can't do a very good job of it. I
use old eMagic boxes (still) that do eight channels of 48/24bit or
four 96/24. *that* is pushing the bounds of 1.1. A stereo device
shouldn't be making a system sweat.
Most notorious are USB Mice and Cameras. If you must
use a
USB Mouse or other USB media device (Camera, MP3 player, etc) plug it
into another port.
This is true, but it's true because the linux scheduler is poor.
The problem is that audio devices use 'isochronous' transfers, which
means that their transfer blocks are prescheduled and must be
contiguous/uninterrupted. Even if a device only needs 25% of the
available bandwidth, when Linux schedules a mouse to sprinkle
'interrupt heads' throughout a schedule such that there no contiguous
blocks bigger than 10% of the schedule, you've lost even if the mouse
is idle and using no bandwidth. You get the dreaded error -28. Also,
there are just a ton of scheduler bugs.
Monty