synaptics hi-res audio usb device duplex, usb bandwidth issues
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?
As an additional datapoint on this issue, I fired up an ancient copy of Windows 7 on the T420 and in that OS, testing with Zoom (with webcam running) shows duplex sound working with the Conexant Systems (Rockwell) device, so it's definitely possible with the hardware.
On Mon, 26 Feb 2024 at 13:05, Ian Malone ibmalone@gmail.com wrote:
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?
В Пн, 26/02/2024 в 13:05 +0000, Ian Malone пишет:
---------->%-----------
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?
I always had bandwidth allocation problems with full-speed isochronous devices connected directly to xhci host controllers (and no other devices connected!). The same devices works with ehci host controllers without issues. So I think the problem is somewhere in the xhci code.
Also if device is connected to the hub which is connected to xhci controller, everything also works. This is why rear ports works for you - they are connected to the internal hub.
В Вт, 27/02/2024 в 21:27 +0300, Alexander Tsoy пишет:
В Пн, 26/02/2024 в 13:05 +0000, Ian Malone пишет:
---------->%-----------
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?
I always had bandwidth allocation problems with full-speed isochronous devices connected directly to xhci host controllers (and no other devices connected!). The same devices works with ehci host controllers without issues. So I think the problem is somewhere in the xhci code.
Also if device is connected to the hub which is connected to xhci controller, everything also works. This is why rear ports works for you
- they are connected to the internal hub.
And this is because transaction translation is performed on the hub, so the controller is only dealing with high-speed transfers.
BTW, I just tested all mentioned connection scenarios with Audiotrak Prodigy CUBE. And indeed I get "Not enough bandwidth" errors in duplex mode only if it is connected directly to xhci controller.
В Пн, 26/02/2024 в 13:05 +0000, Ian Malone пишет:
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)
Sorry, I somehow misread the first part of an email and was under impression that the problem is only with xhci host controller. Here I can only add that I have a system with the same "6 Series/C200 Series" chipset where I cannot reproduce this issue. But my full-speed card has a lower wMaxPacketSize.
On Tue, 27 Feb 2024 at 20:45, Alexander Tsoy alexander@tsoy.me wrote:
В Пн, 26/02/2024 в 13:05 +0000, Ian Malone пишет:
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)
Sorry, I somehow misread the first part of an email and was under impression that the problem is only with xhci host controller. Here I can only add that I have a system with the same "6 Series/C200 Series" chipset where I cannot reproduce this issue. But my full-speed card has a lower wMaxPacketSize.
Yes, a brief summary would on EHCI this device doesn't work in duplex while XHCI works but moans a bit in the log, the same EHCI hardware works in duplex on Win7.
I've got another adaptor (KTMicro/KT USB Audio, vendor "Huawei Technologies Co., Ltd") which on the Legion 5 Pro USB 3.0 side ports doesn't cause the same complaining that the Synaptics/Hi-Res Audio/Conexant Systems (Rockwell) device (not had a chance to test it on the T420 yet as it sits in the office). The KTMicro device has similar playback, but mono input with only 16LE format, wMaxPacketSize 0x0060 1x 96 bytes, while the Synaptics has 24 bit stereo, and wMaxPacketSize sizes 0x00c0 1x 192 bytes and 0x0120 1x 288 bytes in the input descriptors (and a 0x0300 1x 768 bytes output descriptor).
Best filed as a bug in the driver? (The Tab A/SM-T510 may be a blind alley, although it is supposed to be USB2.0 I've been able to dump the logs and its using an XHCI controller.)
On Wed, 28 Feb 2024 at 12:08, Ian Malone ibmalone@gmail.com wrote:
On Tue, 27 Feb 2024 at 20:45, Alexander Tsoy alexander@tsoy.me wrote:
В Пн, 26/02/2024 в 13:05 +0000, Ian Malone пишет:
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).
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)
Sorry, I somehow misread the first part of an email and was under impression that the problem is only with xhci host controller. Here I can only add that I have a system with the same "6 Series/C200 Series" chipset where I cannot reproduce this issue. But my full-speed card has a lower wMaxPacketSize.
Yes, a brief summary would on EHCI this device doesn't work in duplex while XHCI works but moans a bit in the log, the same EHCI hardware works in duplex on Win7.
After a brief foray into EHCI (some of the issues are EHCI scheduling limits for full speed devices, the 24 bit duplex comes right up against FS limits). I've found two things: 1. Adding a wireplumber rule to force 16 bit for the microphone/input endpoint reduces the bandwidth requirement enough that it will work in duplex. (Changing profile to and from duplex in pavucontrol appears to change it back to 24 bit and then fail, needing a wireplumber restart to fix it).
2. The 16 bit alt mode for the output endpoint seems to be misconfigured in the firmware, it reports 768byte max packet size which should be 384bytes (2 channels * 2 bytes * 96kHz * 1ms). I can hack the sound/usb driver to overwrite this packet size in the output driver (and then it works correctly), but I can't figure out how to correctly write a quirk to reconfigure that alt mode. My attempt is an attachment on https://bugzilla.kernel.org/show_bug.cgi?id=218603, but I haven't managed to define a QUIRK_AUDIO_FIXED_ENDPOINT that actually works (it takes data, but no sound plays) and the other interfaces need to be explicily specified QUIRK_AUDIO_STANDARD_INTERFACE, QUIRK_AUDIO_STANDARD_MIXER or the USB probe fails (at least they work if this is done). What is the correct way to do it? (Not sure the driver has the machinery to apply an overridden max packet size in this way either, seems it needs to update the value in the usb structure, but knowing how to get a working endpoint quirk working would be a start.)
participants (2)
-
Alexander Tsoy -
Ian Malone