Jeremy Jongepier wrote: Is CONFIG_USB_EHCI_TT_NEWSCHED enabled in your kernel's configuration? Can you try with or without a hub? Regards, Clemens

On Tue, Sep 14, 2010 at 8:29 AM, Jeremy Jongepier <jeremy(a)autostatic.com> wrote: The bandwidth has been fragmented by other devices. USB-1 audio devices require large _contiguous_ blocks of bandwidth schedule, and a mouse or whatever that has carved its tiny little block out of the middle of the bandwidth schedule makes all the bandwidth on either side useless to an isochronous device. Simply unplugging it (or whatever caused the scheduling problem) is not enough; the schedule remains fragmented, as the linux EHCI driver does not know how to reconsolidate fragmented bandwidth chunks. You have to rmmod EHCI or reboot to get a fresh start. It's possible you're on a hub and don't know it. Most machines with multiple USB ports are actually using a single controller and a built in hub. Hubs make things *far* worse, as the hub is a dumb puppet controlled entirely by the host controller, and Linux's hub scheduling algorithm (even the 'new improved' one mentioned above) is rather poor. I wrote a new one years ago that approached theoretical maximum efficiency and could rebalance/reconsolidate the schedule, but I couldn't keep up with repatching it during the complete free-for-all that has been kernel 2.6 (I'd literally spent months of full-time work *just* keeping up with the churn) and it was dropped from -mm. Monty

On 09/14/2010 07:57 PM, Monty Montgomery wrote: Hello Monty, lspci | grep USB2 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) The manual explicitly mentions USB2.0 ports, no USB3.0 SuperSpeed. This is about a Dell XPS 8100. Best, Jeremy

Excerpts from david's message of 2010-09-15 19:32:44 +0200: That usb hub stuff seems to be really strange. I do have an external hub, but I only use it for HDs. The USB interface is connected directly to one of the laptops ports. The laptop seems to have an internal hub, or two? Anyway, it works just fine, as far as I can tell. Some jack2 test I ran showed quite immense jitter, but I guess that's normal with USB devices. $ lsusb Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 002: ID 0582:0074 Roland Corp. EDIROL UA-25 Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

Excerpts from Monty Montgomery's message of 2010-09-15 20:42:53 +0200: Thanks Monty for the insight. Sadly I understand little of the technical side of things, but what it tells me is that I better stay away from audio over USB in future and choose something like expresscard instead. PCI is still the best way to go, right? -- Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

On Thu, Sep 16, 2010 at 8:32 AM, Clemens Ladisch <clemens(a)ladisch.de> wrote: Sure. I think the latest monolithic version of the patch is: http://web.mit.edu/xiphmont/Public/ehci-sched-2.6.17-20060809.patch I give it zero chance of working on a modern 2.6 kernel. [The problem was that upstream would not accept the patch as the EHCI scheduler rewrite it was... they wanted individual 'funcitonal changes' so I had to replace the driver a tiny piece at a time... it was about 50 seperate patches if I remember correctly. And every time someone submitted a small conflicting change, they dropped my patch set and told me to regenerate it from scratch. After three or four rounds of this I gave up.] This new driver *did* have bugs, and there were good reasons it could not have gone mainline as is; regardless I ran it for years. It also doesn't solve problems like momentary starvation causing the higher level Linux USB stack to revoke your bandwidth allocation, which there's no guarantee you can get back. This is a fundamental aspect of the (weird) way the Linux USB stack is designed. It makes low-latency nearly impossible, as any time the USB stack pulls the last submission off the queue, it takes it as an implicit request to shut the device down. You must have URBs in flight at all times to keep running, so that doubles [minimum] the necessary playback latency on Linux, which is already high. Monty

Hi, A little info on USB Audio that will be helpful to those here and others reading this thread. 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. Second, regarding USB Hubs, USB Audio does not handle going through USB Hubs unless the hubs are designed properly. Regardless if it's 1.1, 2.0 or 3.0. Some Hubs are just splitters, they mult one port into two or more using the same power and bandwidth as the source port. 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. 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. Griffin used to make a hub called the UH-124, it was a 4 port USB 1.1 powered hub that properly replicated the source port power and data stream to each of the 4 outputs. Dr Bott also made a 7 Port hub that did the same thing. Typically powered hubs offer a better chance of allowing USB Audio and USB MIDI to function properly regardless of operating system. Another item to consider is that laptops especially PC laptops are designed so that there are 2 physical ports per internal USB controller. These USB controllers are bound to other devices on the laptop that are sharing power. It is not uncommon for PC Laptop USB ports to actually have reduced bandwidth (and in some cases with (Ultra Low Voltage notebooks (Sony makes one)) there isn't enough power on the USB bus to power a single USB Audio or USB MIDI device. So no passive hubs. Don't waste your money unless you're absolutely mobile (in a forest, desert, etc) and you don't have a choice, your mileage will vary. 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). If you're not sure if you're getting the right one, each USB port carries 500ma at 5VDC. The PSU should be able to say what the total output current is. Divide output current by number of USB ports, if the number is 500 or greater per port then it's a good indication the vendor made the hub correctly. Their might be a little more than 500 to drive the leds on the unit. If not, get a different one. The only downside to powered hubs is that the lesser expensive ones have huge wall-wart power adapters. The better ones will have a smaller power adapter. 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. 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. Why is this this way you might ask? (geeking out here for a moment). The USB Audio spec per the USB.org website is not how Microsoft designed the intended use of USB in their OS. We're talking about Linux though, yes. However the computer you're installing Linux on was designed and intended for use with a Windows OS to make it ACPI compliant. Microsoft required starting back during Win 98SE that the OS must be able to shared 2 USB devices with not more than 40% max bandwidth per device and allowing 10% for overhead per device. That equals out to 100%. On Win98SE in the device manager you could actually view the device bandwidth for each USB device connected. That all went away with Win2K and the rest is history. That's why PC's have 2 USB ports per controller. Since Apple utilizes the controllers the way USB.org presented it's use, anyone using a x86 or x86_64 laptop will have an extra port to confuse matters when only one should be used per controller. This applies to x86 and x86_64 machines, Mac Books do not have as many issues because they are designed with all of this in mind. Macs limit one USB port to one internal controller, that's why those machines have so few USB ports. Hope this helps. On 9/17/2010 1:32 AM, david wrote:

On Fri, September 17, 2010 2:21 pm, Monty Montgomery wrote: Belkin are the brand of choice for multi port hubs. 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". 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.

On Fri, Sep 17, 2010 at 05:21:14PM -0400, Monty Montgomery wrote: <... massive snippage ...> OK, so, with Firewire going away as an option on many new laptops (and not available at all on netbooks) what are we supposed to do if we have laptops and need to make music? Run Windoze? Go get MacBooks? I've been using Linux on stage and in the studio with a FastTrack Pro USB for 3 years now. Latency on my systems has been noticeably better than the couple MacBooks running Live or Reason that I've had a chance to play. Doesn't the Ingo patchset fix this, or mitigate it? Interesting, thanks for explaining. I've gotten those -28 errors with my Sprint wireless USB card in combination with USB external drives and USB flash drives, and wondered WTF was up. Haven't had any such errors with audio-- probably because I unplug and turn off everything except my keyboard controller and audio interface whenever I'm working. All that said, I'd be very happy to use a forked version of the Linux kernel that has all this USB and scheduler stuff fixed and cleaned up for better audio support, and is isolated from the mainline churn. if the mainline maintainers don't want it, then so what. I'd love to have a patch for USB fixen which could be compatible with whatever Ingo patches are available for whatever kernel it was forked off of. It's the kind of thing I'd only need to change or update once every several years anyway. -ken

Bill Whitlock from Jensen gave a presentation to the AES group in Los Angeles 3 months ago on Common Mode Rejection in Real-World environments, If you're interested in learning more about how to combat the "hum" in your audio, check out his information page, there's multiple application documents and an AES document (which they usually charge for) he has posted about dealing with noise in audio setups. Some of them are a lengthy read, very informative though even if you decide not to buy this products. Bill gives speeches regularly, if you can catch him at a presentation go check it out. http://www.jensen-transformers.com/apps_wp.html BTW: AES meetings are always free to attend. On 9/18/2010 12:51 AM, david wrote:

david wrote: Yes, that Intel "rate-matching hub" has an internal hub for devices that do not run at USB2 high speed. Regards, Clemens

On 09/15/2010 09:59 AM, Jeremy Jongepier wrote: I've checked with lsusb. Only two buses, and even if I try the least crowded bus and use rtirq to prioritize that bus my UA-25 refuses to work in duplex mode. So it might be that I'm behind a hub after all and it's probably got nothing to do with a buggy USB chipset in my case. But I already had a suspicion that USB soundcards wouldn't work on this machine so I've equipped it with a decent FireWire PCIe card (the one on the motherboard is crap also) and a FireWire soundcard. Best, Jeremy

On 09/18/2010 08:58 AM, Philipp Überbacher wrote: Hello Philipp, Yes I know, I was testing with 48Khz samplerate in advanced mode. Best, Jeremy