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 > 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. > 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 DJ/Producer "Hitmuri". >> 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. > This may be the case but it certainly doesn't stop Linux from being used to do the heavy lifting at the Louvre. -- Patrick Shirkey Boost Hardware Ltd. _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
