Bug 47201

Summary:	Error: cannot submit urb 0, error -28: not enough bandwidth - when starting USB capture device connected via hub
Product:	Drivers	Reporter:	WZab (wzab)
Component:	Sound(ALSA)	Assignee:	Jaroslav Kysela (perex)
Status:	NEEDINFO ---
Severity:	normal	CC:	adam, hvtaifwkbgefbaei, tiwai, zonque
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.5.3 3.6-rc4 3.5.4 3.6.1	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	Results of lsusb -v for UGM96 Results of lsusb -v for Creative Technology, Ltd Sound Blaster Play!

Description WZab 2012-09-07 17:19:20 UTC

Created attachment 79441 [details]
Results of lsusb -v for UGM96

When I try to start my UGM96 USB audio capture device:
ID 0a92:2041 EGO SYStems, Inc. 
connected via USB hub,
I get the error:
Error: cannot submit urb 0, error -28:

I've tried different sampling rates (22050, 32000, 44100, 48000) - result is always the same.
When UGM96 is connected directly, without hub, everything works fine.

What's interesting. Another USB audio device:
ID 041e:30d3 Creative Technology, Ltd Sound Blaster Play!
works correctly either connected directly or via hub.

I attach results of "lsusb -v" produced for both devices.
The problem was discovered, when investigating bug: 
https://bugzilla.kernel.org/show_bug.cgi?id=46011

Comment 1 WZab 2012-09-07 17:20:44 UTC

Created attachment 79451 [details]
Results of lsusb -v for Creative Technology, Ltd Sound Blaster Play!

Comment 2 WZab 2012-09-07 17:31:05 UTC

Comment on attachment 79441 [details]
Results of lsusb -v for UGM96

This device doesn't work, when connected via hub. Error: "cannot submit urb 0, error -28: not enough bandwidth" is reported

Comment 3 WZab 2012-09-07 17:31:48 UTC

Comment on attachment 79451 [details]
Results of lsusb -v for Creative Technology, Ltd Sound Blaster Play!

This device works. Both: connected directly and via hub

Comment 4 WZab 2012-09-19 20:22:34 UTC

I've checked the UGM96 (connected directly, without hub!) with another machine with 3.5.4 kernel
Whe trying to start jackd, I get the following errors in dmesg:
[...]
[  301.635317] delay: estimated 0, actual 144
[  301.663311] delay: estimated 0, actual 144
[  301.691303] delay: estimated 0, actual 144
[  301.714295] retire_capture_urb: 1062 callbacks suppressed
[  301.719317] delay: estimated 0, actual 144
[  301.747289] delay: estimated 0, actual 144
[  301.775279] delay: estimated 0, actual 144
[  301.803272] delay: estimated 0, actual 144
[  301.831264] delay: estimated 0, actual 144
[  301.859254] delay: estimated 0, actual 144
[  301.887260] delay: estimated 0, actual 144
[...]
repeated many times.
With kernel 3.4.10 the same configuration works perfectly!

Comment 5 Takashi Iwai 2012-09-20 05:47:16 UTC

The bogus error messages "delay: ..." were old fixed in 3.6 tree and will be merged to 3.5 soon.  These are harmless messages, so just ignore for now.

Comment 6 WZab 2012-09-20 08:32:03 UTC

OK. Even if "delay" ..." messages can be ignored, capture of sound doesn't start.
probably it can be somehow associated with the "[  301.714295] retire_capture_urb: 1062 callbacks suppressed message".

I'm especially interested why in one of the affected systems the "Sound Blaster Play!" works correctly, why the professional UGM96 doesn't.

Comment 7 WZab 2012-10-10 16:59:30 UTC

I've just checked, that the problem with UGM96 persists in kernel 3.6.1
Even when it is connected directly, without hub.

After I attempt to start jack, I can see in logs:

[  127.283709] retire_capture_urb: 4154 callbacks suppressed
[  132.281267] retire_capture_urb: 4414 callbacks suppressed
[  137.279773] retire_capture_urb: 4907 callbacks suppressed
[  142.278277] retire_capture_urb: 4890 callbacks suppressed
[  147.275784] retire_capture_urb: 4924 callbacks suppressed
[  379.647426] cannot submit urb 0, error -28: not enough bandwidth

Comment 8 WZab 2012-10-14 08:41:32 UTC

In kernel 3.6.2 problem seems to disappear.
I've checked both UGM96 connected directly, and via hub.
At 48 Ksmps/s UGM96 works perfectly.

Comment 9 WZab 2012-10-14 11:06:30 UTC

What's interesting. Previous tests, proving that problem disapeared in 3.6.2 was done on relatively slow Pentium 4 based machine (single core with HT).

On another, much faster machine - (Dell Vostro 3750) the problem still persists.

What's even more interesting, in Dell Vostro UGM96:
1.  works when connected to one of USB 3.0 capable ports
2.  doesn't work when connected directly to one of the USB 2.0 ports.
    (old "cannot submit urb 0, error -28: not enough bandwidth" errors)
3.  works when connected to USB 2.0 port via hub

I really can't understand, how connection via hub may increase bandwidth available for the USB audio device!

Comment 10 Takashi Iwai 2013-11-14 10:23:34 UTC

The urb handling and bandwidth calculation depends on the controller driver, and ehci tends to be problematic.  We have recently a rewrite of packet management in USB-audio driver, and also ehci has been updated in many places.

So, try first 3.12 kernel.  If the problem is still present with ehci, try sound git tree for-linus branch.
    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

Comment 11 Sami Farin 2014-06-09 07:59:29 UTC

I get the -28 error when Zoom H2n microphone is connected to USB3 port, but it works when connected to HP ZR24w monitor's USB2 hub.
Kernel 3.15.0.  Asus P8Z68-V PRO GEN3 motherboard.

Comment 12 Sami Farin 2014-06-09 08:08:59 UTC

Correction: -28 when connected to _USB2_ without hub, and when connected to _USB3_ port:
retire_capture_urb: 2492 callbacks suppressed
xhci_hcd 0000:03:00.0: Signal while waiting for configure endpoint command
usb 2-1: Not enough bandwidth for altsetting 0

(I managed to record some, but captured audio was just a buzz..!)

and recording does not work anymore

xhci_hcd 0000:03:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff880250a32ba0
xhci_hcd 0000:03:00.0: Trying to add endpoint 0x81 without dropping it.
usb 2-1: Not enough bandwidth for altsetting 1
usb 2-1: 2:1: usb_set_interface failed (-22)

Comment 13 Sami Farin 2015-12-25 13:06:42 UTC

Nobody would probably mind if you did some rate limiting—it's not necessary to repeat the same message 10000 times a second.
(Now with kernel 4.2.8.)