linuxaudio.org

> First off any noise that you hear through your USB Audio

quoted text
> 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

quoted text
> 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

quoted text
> 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,

quoted text
> 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

quoted text
> 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

quoted text
> 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  - ).

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

quoted text
> 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

quoted text
> 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

_______________________________________________

Linux-audio-user mailing list

Linux-audio-user@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-user