Hi,
In short I have a USB to 3.5mm adapter which seems not to work in
duplex mode on USB2.0 systems, possibly due to a bandwidth calculation
bug.
This is an evolution of an issue I previously posted on the users list
with no luck. I have an Anker USB-C to 3.5mm audio dongle (lsusb:
Conexant Systems (Rockwell), Inc. Hi-Res Audio) which I've used for
some time on my phone (Android with USB-3.2). On trying to use it with
an older T420 laptop recently with only USB-2.0 ports I discovered it
will not work in duplex mode. Input-only and output-only profiles work
(tested recording and playback with audacity), but with duplex no
sound is recorded (Fedora 39, pipewire). This is easily reproduced by
looking at the pavucontrol volume monitor for Output Devices, if I
switch the device to Analog or Digital Input in configuration then the
Input Devices level monitor for it shows activity if I speak into or
tap the microphone. With duplex selected there is no activity, the
level monitor bar may or may not display. I can switch between the two
behaviours by changing the profile. Various applications such as
Audacity and Zoom appear to hang when accessing this microphone with
the duplex profile set. I've used pipewire configuration to force the
format to 16LE only (playback and recording), but this has not helped.
In dmesg this error appears when this happens (microphone opened, for
example by pavucontrol):
[ 294.825544] usb 1-1.1: cannot submit urb 0, error -28: not enough bandwidth
(T420, Fedora 39, kernel 6.7.5)
The T420 has USB 2 Type A ports, so a Type C to Type A adapter is
needed, but the problem is not limited to the T420 laptop. On an older
Samsung Tablet (Tab-A 2019, USB-2.0 Type C, kernel 4.4.177) I've been
able to test using Google Meet. Although there are no errors or
freezing observed, in headphone mode over USB the headphone microphone
is not being used and the tablet uses its onboard microphone instead
(although headphones are selected and playback is over the
headphones). Again, I can record (via voice recorder) from the headset
microphone, just no duplex. Trying google meet on my phone (USB3.2) I
do get duplex over the USB-3.5 adapter.
On a newer laptop with USB-3.2 and a mix of type A and C ports I also
get duplex (F37, kernel 6.5.12), however dmesg shows even here not all
is well, using the type A and C ports on the side:
[ 9172.326602] usb 3-1: new full-speed USB device number 6 using xhci_hcd
[ 9172.490169] usb 3-1: New USB device found, idVendor=0572,
idProduct=1b08, bcdDevice= 0.10
[ 9172.490174] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9172.490177] usb 3-1: Product: Hi-Res Audio
[ 9172.490178] usb 3-1: Manufacturer: Synaptics
[ 9172.490180] usb 3-1: SerialNumber: 000000000000000000000000
[ 9172.683435] input: Synaptics Hi-Res Audio as
/devices/pci0000:00/0000:00:08.1/0000:05:00.4/usb3/3-1/3-1:1.3/0003:0572:1B08.000A/input/input36
[ 9172.736025] hid-generic 0003:0572:1B08.000A: input,hidraw5: USB HID
v1.11 Device [Synaptics Hi-Res Audio] on usb-0000:05:00.4-1/input3
[ 9173.386988] usb 3-1: Not enough bandwidth for new device state.
[ 9173.386994] usb 3-1: Not enough bandwidth for altsetting 1
[ 9173.386996] endpoint_set_interface: 70 callbacks suppressed
[ 9173.386998] usb 3-1: 1:1: usb_set_interface failed (-28)
[ 9173.387110] usb 3-1: Not enough bandwidth for new device state.
[ 9173.387113] usb 3-1: Not enough bandwidth for altsetting 1
(...these 3 lines repeat 9 more times, followed by...)
[ 9173.388785] usb 3-1: Not enough bandwidth for new device state.
[ 9173.388789] usb 3-1: Not enough bandwidth for altsetting 1
(...these 2 lines repeat 5 more times, then stop)
This is a USB3.2 system, the onboard camera has a hardware switch, so
I can disable it, and the only other peripheral that appears is the
AX210 bluetooth (I'd thought that would have its own bus as it's part
of a separate wifi chip, but apparently not, lsusb -t below),
bandwidth for even a 96kHz 24bit duplex audio device shouldn't really
be an issue.
$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 003 Device 002: ID 048d:c965 Integrated Technology Express, Inc.
ITE Device(8295)
Bus 003 Device 007: ID 0572:1b08 Conexant Systems (Rockwell), Inc. Hi-Res Audio
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp. Hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 048d:c101 Integrated Technology Express, Inc.
ITE Device(8910)
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 1: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 7, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 4: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
The only situation in which I *don't* get these dmesg errors is if I
use one of the rear USB 3.2 ports that seem to lead to it being on its
own bus:
$ lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 3: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 4: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 4: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 3, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M
In this case the dmesg output is clear after device connection. This
seems like some kind of bandwidth calculation problem in
snd_usb_audio. I've tried building a kernel and modifying various of
the defines in sound/usb/card.h (currently MAX_PACKS 4 and
MAX_PACKS_HS (MAX_PACKS * 4), compared to 6 and *8) but not hit on a
winning formula yet. Is there any information I could collect to try
to fix this?
--
imalone
