# USB-headset fails to work, "error -28: not enough bandwidth"

## Letharion

When I connect my USB headset, I'm used to KDE giving me a notification, and move sound to my headset. Currently however, nothing at all happens.

```
# tail -f /var/log/messages

kernel: [ 6702.834839] usb 1-1.2: new full-speed USB device number 16 using ehci_hcd

kernel: [ 6703.139460] usb 1-1.2: New USB device found, idVendor=047f, idProduct=c001

kernel: [ 6703.139464] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0

kernel: [ 6703.139467] usb 1-1.2: Product: Plantronics .Audio 646 DSP

kernel: [ 6703.139469] usb 1-1.2: Manufacturer: Plantronics

kernel: [ 6703.245744] input: Plantronics Plantronics .Audio 646 DSP as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.3/input/input23

kernel: [ 6703.245977] generic-usb 0003:047F:C001.000F: input: USB HID v1.00 Device [Plantronics Plantronics .Audio 646 DSP] on usb-0000:00:1a.0-1.2/input3

kdm[2307]: The XKEYBOARD keymap compiler (xkbcomp) reports:

kdm[2307]: > Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols

kdm[2307]: >                   Ignoring extra symbols

kdm[2307]: Errors from xkbcomp are not fatal to the X server

kernel: [ 6703.736611] cannot submit datapipe for urb 0, error -28: not enough bandwidth
```

Kernel configuration (that I believe I haven't changed)

```
# zgrep HCI /proc/config.gz 

CONFIG_SATA_AHCI=y

# CONFIG_SATA_AHCI_PLATFORM is not set

# CONFIG_SATA_ACARD_AHCI is not set

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_ARCH_HAS_EHCI=y

CONFIG_USB_ARCH_HAS_XHCI=y

CONFIG_USB_XHCI_HCD=y

# CONFIG_USB_XHCI_HCD_DEBUGGING is not set

CONFIG_USB_EHCI_HCD=y

# CONFIG_USB_EHCI_ROOT_HUB_TT is not set

# CONFIG_USB_EHCI_TT_NEWSCHED is not set

CONFIG_USB_OHCI_HCD=y

# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set

# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set

CONFIG_USB_OHCI_LITTLE_ENDIAN=y

CONFIG_USB_UHCI_HCD=y

# CONFIG_USB_WHCI_HCD is not set

# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
```

I found another thread on f.g.o saying that this could be because a USB 1.1 headset can fail to reserve the necessary bandwidth. However, not only has this worked well before together with all my other perpherials (keyboard, mouse, phone), it also doesn't help unplug all usb-devices and connect only the headset.

----------

## NeddySeagoon

Letharion,

```
CONFIG_USB_UHCI_HCD=y

CONFIG_USB_OHCI_HCD=y 
```

Please choose the one that you need for your hardware.  They are known to conflict.

For Intel/VIA, chose UHCI - otherwise its OHCI. If you feel adventuerous, turn them both off and enable

```
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set 

# CONFIG_USB_EHCI_TT_NEWSCHED is not set 
```

You need hardware support fot Transaction Translation. If you have it, USB1.x devices will be controlled by the EHCI driver and Transaction Translation.  If you don't have hardware suppoer, USB 1.x will be broken.  

Don't try Transaction Translation if you depend on a USB keyboard, you may loose console control of your system..

----------

## Letharion

Thank you very much NeddySeagoon, unfortuntately, the situation appears to be same regardless.

```
# lspci | grep -i usb

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)

00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
```

```
# zgrep HCI /proc/config.gz 

CONFIG_SATA_AHCI=y

# CONFIG_SATA_AHCI_PLATFORM is not set

# CONFIG_SATA_ACARD_AHCI is not set

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_ARCH_HAS_EHCI=y

CONFIG_USB_ARCH_HAS_XHCI=y

CONFIG_USB_XHCI_HCD=y

# CONFIG_USB_XHCI_HCD_DEBUGGING is not set

CONFIG_USB_EHCI_HCD=y

# CONFIG_USB_EHCI_ROOT_HUB_TT is not set

# CONFIG_USB_EHCI_TT_NEWSCHED is not set

# CONFIG_USB_OHCI_HCD is not set

CONFIG_USB_UHCI_HCD=y

# CONFIG_USB_WHCI_HCD is not set

# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
```

I could give the adventuerous version a try, but is there a way to know that my laptop keyboard isn't using usb internally? Cause that could be bad  :Wink: 

----------

## gentoo_ram

I've had little luck getting Plantronics USB headsets to work on my Linux for this same reason.  Maybe they don't follow the spec like Linux expects.

----------

## NeddySeagoon

Letharion,

I've just discovered that I have an identical USB headset. It ceartainly used to work for me as I used it for a podcast. That was about 4 years ago now.

Its seen little use since.  Anyway, when I plug it in I get,

```
[  533.252109] usb 6-3: new full-speed USB device number 2 using ohci_hcd

[  533.429138] input: HID 047f:c001 as /devices/pci0000:00/0000:00:13.1/usb6/6-3/6-3:1.3/input/input14

[  533.429365] generic-usb 0003:047F:C001.0004: input,hidraw3: USB HID v1.00 Device [HID 047f:c001] on usb-0000:00:13.1-3/input3
```

An poking about with usbview, shows its using the snd-usb-audio / usbhid drivers.

usbview depends on usbfs which is depreciated now.

Please post your entire .config file to a pastebin. wgetpaste is your friend.

----------

## Letharion

I have posted my entire .config.

Most grateful for your support.

I have also had this headset working fine with this particular computer before, so I've probably just done something wrong in a recent configuration change.

NeddySeagoon, which kernel are you using? I'm using the latest stable, 3.2.12.

----------

## NeddySeagoon

Letharion

I'm all ~ARCH here.  The following from from 

```

#

# Automatically generated file; DO NOT EDIT.

# Linux/x86_64 3.3.1-gentoo Kernel Configuration

#

```

I can see two differences, so that may be it.

```
CONFIG_HID_SUPPORT=y

CONFIG_HID=y

CONFIG_HIDRAW=y

CONFIG_USB_HID=m

# CONFIG_HID_PID is not set

CONFIG_USB_HIDDEV=y
```

You have 

```
# CONFIG_HIDRAW is not set

# CONFIG_USB_HIDDEV is not set
```

----------

## Letharion

I added the options, one at a time, but that didn't help.

Rather annoying. Thanks a lot for your time, should I think of something, I'll post back.

----------

## Jaglover

You also have XHCI, I recall reading somewhere the USB drivers have to be loaded in certain order to make sure they do not conflict with each other. Sorry being so vague, hope google will help to find more details on it.

----------

## NeddySeagoon

Jsaglovers idea is easy to test if your USB hardware drivers are made  as modules.

modprobe -r all of them then reload only the USB1 driver.

If you have a usb keyboard, that sequence of commands takes some care. 

Why and how is left as an exercise for the reader.  

I'll tell you if you ask.

----------

## fpires

Hello,

I had this same issue with my usb headsets with EHCI USB 2.0 drivers. I resolved it by activating 2 configurations in the kernel for EHCI controllers called:

"Root Hub transactions translators"

"Improved transaction translators scheduling"

They are in:

Device Drivers --> USB support --> EHCI HCD (USB 2.0) support

On the help comments they recommend to enable both, and in the "Improved transaction translators scheduling" help comments, it mentions this can resolve "error -28" issues.

Hope this helps.

Regards,

----------

## NeddySeagoon

fpires,

Thats interesting.  I have those options set and no USB1.x drivers.

However,  USB Tranaction Translationis a hardware feature. Your hardware either supports it or it doesn't.

----------

## fpires

Yes, it says that for the first one, but even if I disable it, I can still enable the scheduling one. In my case, for my dell vostro with hardened 3.2.11, it worked like a charm. Here are the help comments for both.

CONFIG_USB_EHCI_ROOT_HUB_TT:                                                                                                                                     │  

  │                                                                                                                                                                  │  

  │ Some EHCI chips have vendor-specific extensions to integrate                                                                                                     │  

  │ transaction translators, so that no OHCI or UHCI companion                                                                                                       │  

  │ controller is needed.  It's safe to say "y" even if your                                                                                                         │  

  │ controller doesn't support this feature.                                                                                                                         │  

  │                                                                                                                                                                  │  

  │ This supports the EHCI implementation that's originally                                                                                                          │  

  │ from ARC, and has since changed hands a few times.  

CONFIG_USB_EHCI_TT_NEWSCHED:                                                                                                                                     │  

  │                                                                                                                                                                  │  

  │ This changes the periodic scheduling code to fill more of the low                                                                                                │  

  │ and full speed bandwidth available from the Transaction Translator                                                                                               │  

  │ (TT) in USB 2.0 hubs.  Without this, only one transfer will be                                                                                                   │  

  │ issued in each microframe, significantly reducing the number of                                                                                                  │  

  │ periodic low/fullspeed transfers possible.                                                                                                                       │  

  │                                                                                                                                                                  │  

  │ If you have multiple periodic low/fullspeed devices connected to a                                                                                               │  

  │ highspeed USB hub which is connected to a highspeed USB Host                                                                                                     │  

  │ Controller, and some of those devices will not work correctly                                                                                                    │  

  │ (possibly due to "ENOSPC" or "-28" errors), say Y.  Conversely, if                                                                                               │  

  │ you have only one such device and it doesn't work, you could try                                                                                                 │  

  │ saying N.                                                                                                                                                        │  

  │                                                                                                                                                                  │  

  │ If unsure, say Y.

----------

## devsk

This was an issue with a specific kernel version (3.3.1 I think or thereabouts) which I also hit. Just upgrade to latest stable and it should work.

----------

## Letharion

The last stable is still 3.2.12 though. The problem has disappeared for me, as far as I can tell without me having changed any config, just the way it showed up. It's interesting to note that the headset is no longer identified as a plantronics one.

```
ehci_hcd 0000:00:1a.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1a.0: BAR 0: set to [mem 0xf3a2a000-0xf3a2a3ff] (PCI address [0xf3a2a000-0xf3a2a3ff])

ehci_hcd 0000:00:1a.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1a.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1a.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1a.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 

ehci_hcd 0000:00:1d.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1d.0: BAR 0: set to [mem 0xf3a29000-0xf3a293ff] (PCI address [0xf3a29000-0xf3a293ff])

ehci_hcd 0000:00:1d.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1d.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1d.0: power state changed by ACPI to D0 

ehci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 

ehci_hcd 0000:00:1d.0: PCI INT A disabled

ehci_hcd 0000:00:1d.0: power state changed by ACPI to D3 

usb 1-1.1: new full-speed USB device number 9 using ehci_hcd

usb 1-1.1: New USB device found, idVendor=0d8c, idProduct=000c

usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0

usb 1-1.1: Product: C-Media USB Headphone Set

input: C-Media USB Headphone Set   as /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.3/input/input13

generic-usb 0003:0D8C:000C.0005: input,hidraw0: USB HID v1.00 Device [C-Media USB Headphone Set  ] on usb-0000:00:1a.0-1.1/input3

cannot submit datapipe for urb 0, error -28: not enough bandwidth

The XKEYBOARD keymap compiler (xkbcomp) reports:

> Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols

>                   Ignoring extra symbols

Errors from xkbcomp are not fatal to the X server
```

----------

## NeddySeagoon

Letharion,

Odd.  In your original post the device claimed to be 

```
idVendor=047f, idProduct=c001
```

 now its changed to be

```
 idVendor=0d8c, idProduct=000c 
```

Reading back, your first post said

```
 kernel: [ 6702.834839] usb 1-1.2: new full-speed USB device number 16 using ehci_hcd
```

Thats interesting as it shows a full speed USB 1.1 device is being controlled by the USB2 EHCI_HID driver.  That means you have transaction translation support in your kernel.

Depending on what else is going on on that USB bas, as the error message says, USB1 devices could be struggling for bandwidth.

There are two things to try. First, check your kernel and be sure you have all three options below on.

```
    │    <*>   EHCI HCD (USB 2.0) support                                          │ │  

  │ │    [*]     Root Hub Transaction Translators                                  │ │  

  │ │    [*]     Improved Transaction Translator scheduling                        │ │  
```

If that fails, turn off the last two above and enable either OHCI-HCD or UHCI-HCD - whever is correct for your hardware. UHCI-HCD is for Intel and VIA.  Evryone elses uses the other one.

With separate USB1 and USB2 drivers, you must not mix and match USB1 and USB2 devices on the same root hub or it will ball back to USB1 speeds for all connected hardware.

Your most recent post still shows 

```
usb 1-1.1: new full-speed USB device number 9 using ehci_hcd 
```

 so transaction translation is still in use.

Low-spped=1.5Mbit/sec  mice, keyboards etc. USB1

Full speed =12Mbit/sec almost everything else. USB1

High speed =480Mbit/sec  USB2

----------

## KaZeR

Same el cheapo device, same issue.

Activating Transaction Translators solved the problem.

Thanks!

----------

## rudregues

 *KaZeR wrote:*   

> Same el cheapo device, same issue.
> 
> Activating Transaction Translators solved the problem.
> 
> Thanks!

 

I was with the same issue and it fixed. Thanks!

----------

## FroL_Onn

 *NeddySeagoon wrote:*   

> There are two things to try. First, check your kernel and be sure you have all three options below on.
> 
> ```
>     │    <*>   EHCI HCD (USB 2.0) support                                          │ │  
> 
> ...

 

Thanks a lot! That solved my problem too!

Love forums.gentoo.org!   :Wink: 

----------

