https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #12 from Ian Malone (ibmalone@xxxxxxxxx) --- Okay, I think we may have reached a dead end. Using wireplumber (creating rules in ~/.config/wireplumber/main.lua.d) it's possible to manipulate the audio formats that pipewire will use for a device, so I can independently request the 16 bit mode for the input and output streams. The bandwidth profiles for those are as follows (wMaxPacketSize is for the in/out interface descriptor with the corresponding bBitResolution as reported by lsusb -v): in (48kHz) 16bit, expected wMaxpacket size 192bytes bandwidth: 1-1.1 ep 81: 159 @ 0.2+1 mask f004 uframes 125 34 24bit, expected wMaxPacketSize 288bytes bandwidth: 1-1.1 ep 81: 234 @ 0.2+1 mask f004 uframes 125 109 out (48kHz) 16bit, expected wMaxPacketSize 768bytes (?!) bandwidth: 1-1.1 ep 01: 608 @ 0.1+1 mask 003e uframes 125 125 125 125 108 24bit, expected wMaxPacketSize 458bytes bandwidth: 1-1.1 ep 01: 458 @ 0.2+1 mask 003c uframes 125 125 125 83 There's also the HID endpoint (unbinding doesn't seem to remove the bandwidth usage) expected wMaxPacketSize 35bytes: 1-1.1 ep 84: 39 @ 0.0+1 mask 1c01 The bandwidth to wMaxPacketSize ratio is approximately the same for all streams (1.2-1.3, 1.11 for the HID I guess slightly different overheads). Following the rules that ehci-sched.c sets out, this can't be met: max_tt_usecs[] = { 125, 125, 125, 125, 125, 125, 30, 0 }; and: /* special case for isoc transfers larger than 125us: * the first and each subsequent fully used uframe * must be empty, so as to not illegally delay * already scheduled transactions */ The minimum bandwidth configuration is: out(24b) 125 125 125 83 in (16b) 125 34 hid 39 And there is no way to block them such that 30 in microframe 7 isn't exceeded. 125 125 125 83 125 34 39 0 etc. Unless it's legal to schedule the hid into microframe 6 after the audio input as its final microframe is not fully used? A final point of interest is 16bit output, wMaxPacketSize 768bytes. 24 bit output has allowed frequencies 44.1kHz, 48kHz, 96kHz, 2 channels. 16 bit has 8kHz, 16kHz, 32kHz, 441.kHz, 48kHz, 96kHz. Input 24 and 16 bit have only 48kHz and 44.1kHz, 2 channels. wMaxPacketSize / (Max sampling frequency * sample bytes * channels ) in16b 192 / (48kHz * 2 * 2) = 1ms in24b 288 / (48kHz * 3 * 2) = 1ms out16b 768 / (96kHz * 2 * 2) = 2ms out24b 576 / (96kHz * 3 * 2) = 1ms Out 16 bit mode claims to accept 2ms packets (but still interval 1). I'm wondering if this is just an error in the device reported capability (or maybe it can buffer?). Do isochronous outputs have to use the full max packet size? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
