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.)