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