https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #17 from Ian Malone (ibmalone@xxxxxxxxx) --- Created attachment 305995 --> https://bugzilla.kernel.org/attachment.cgi?id=305995&action=edit wireplumber rule for 16bit input on conexant/synaptics hi res audio Hi, I'll close this (wasn't sure what resolution to put, but doesn't matter much). Some final observations though in case they help anyone else. It turned out to be possible to use the device in 16 bit input and 24 bit output without kernel modification. I'd thought this didn't work, but it turns out to be an interaction between wireplumber and pavucontrol that breaks it: changing device profiles (duplex/in/out) in pavucontrol changes the device interface back to 24bit requiring a restart of wireplumber to reapply the 16 bit rule for the input, this messed up some of my testing. I couldn't see this happening normally as the connection failing means the format can't be seen in pw-top. However if the 16bit rule for the input is present then restarting wireplumber after changing the profile does work ("systemctl --user restart wireplumber"). The bandwidth profile then looks like this (bluetooth device 1-1.4 on bus too): TT 1-1 port 0 FS/LS bandwidth allocation (us per frame) 680 680 680 680 680 680 680 680 FS/LS budget (us per microframe) 0: 63 125 125 125 125 117 0 0 8: 63 125 125 125 125 117 0 0 16: 63 125 125 125 125 117 0 0 24: 63 125 125 125 125 117 0 0 32: 63 125 125 125 125 117 0 0 40: 63 125 125 125 125 117 0 0 48: 63 125 125 125 125 117 0 0 56: 63 125 125 125 125 117 0 0 1-1.4 ep 81: 24 @ 0.0+1 mask 1c01 1-1.1 ep 84: 39 @ 0.0+1 mask 1c01 1-1.1 ep 01: 458 @ 0.2+1 mask 003c 1-1.1 ep 81: 159 @ 0.1+1 mask 7802 The pipewire lua rule for this is attached. (I must have misunderstood the scheduler comment about >125us transfers needing to start on a fresh microframe, since the unmodified scheduler seems to be combining the 458 and 159us transfers (going by the budget, not sure how to interpret the mask information.) Although the two channel input takes more bandwidth than single channel it does appear to fit. The two other devices I've got have identical chipsets, so hard to draw wide conclusions, but they only have 16bit single channel input, I suspect that's more common, but hard to find reliable information on this type of device. Fully duplex 24 bit mode doesn't work with the current scheduler, we already knew that. Packed as above it would run over to 67us in microframe 7 and only 30us are allowed there (and possibly an issue with where split-completes sit?). Hacking the sound/usb driver module to force the 16bit output mode to maximum packet size 384 works fine (if forcing wireplumber to 16bit everything then duplex now works and sound quality fine). I'll report that as a sound/usb bug; it's possibly addressable as a device quirk, although I couldn't get that working on my own and had to resort to a brute force hack: --- sound/usb.orig/stream.c 2024-03-08 10:19:27.430507385 +0000 +++ sound/usb/stream.c 2024-03-12 16:13:43.212737555 +0000 @@ -690,6 +690,10 @@ fp->ep_attr = get_endpoint(alts, 0)->bmAttributes; fp->datainterval = snd_usb_parse_datainterval(chip, alts); fp->protocol = protocol; + if(le16_to_cpu(get_endpoint(alts, 0)->wMaxPacketSize)==768){ + get_endpoint(alts, 0)->wMaxPacketSize = cpu_to_le16(384); + usb_audio_err_ratelimited(chip,"overwrote in stream"); + } fp->maxpacksize = le16_to_cpu(get_endpoint(alts, 0)->wMaxPacketSize); fp->channels = num_channels; if (snd_usb_get_speed(chip->dev) == USB_SPEED_HIGH) (Overwriting the usb drivers MaxPacketSize rather than sound/usb's structure, the later doesn't seem to work.) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
