[Bug 218544] not enough bandwidth, synaptics hi-res audio duplex audio

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=218544

--- Comment #17 from Ian Malone (ibmalone@gmail.com) ---
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.