[LAU] USB audio interface and a buggy USB controller
pshirkey at boosthardware.com
Sat Sep 18 07:06:00 UTC 2010
On Fri, September 17, 2010 2:21 pm, Monty Montgomery wrote:
>> 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
>> 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
> 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
> 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.
Belkin are the brand of choice for multi port hubs.
> Well, actually, if you want working USB, you don't use Linux.
Not according to my experience. There are currently 4 machines installed
at the Louvre which are used to manage 2000 usb devices on a daily/weekly
basis and they are all running Linux. I know because I installed them and
built the software to manage them.
In addition I think several of our most active musical contributors use
usb devices and perform live without hassles. Most notably is French
>> 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
> 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.
This may be the case but it certainly doesn't stop Linux from being used
to do the heavy lifting at the Louvre.
Boost Hardware Ltd.
More information about the Linux-audio-user