> 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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
