[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 #14 from Ian Malone (ibmalone@gmail.com) ---
I wrote the following before seeing your most recent reply, but it's a bit long
to rewrite...

Not suggesting this as a patch, but it turns out that if you flip the order
that microframes get assigned then it will all get packed in:

--- /tmp/drivers/usb/host/ehci-sched.c  2024-03-04 18:25:48.000000000 +0000
+++ linux-6.7.5-200.prom.fc39.x86_64/drivers/usb/host/ehci-sched.c     
2024-03-08 14:09:08.085984284 +0000
@@ -868,11 +868,13 @@

                for (i = qh->ps.bw_period; i > 0; --i) {
                        frame = ++ehci->random_frame & (qh->ps.bw_period - 1);
-                       for (uframe = 0; uframe < 8; uframe++) {
+                       for (uframe = 7; ; uframe--) {
                                status = check_intr_schedule(ehci,
                                                frame, uframe, qh, &c_mask,
tt);
                                if (status == 0)
                                        goto got_it;
+                               if(uframe == 0)
+                                       break;
                        }
                }

With the 24bit interfaces (default behaviour, no forcing formats in pipewire,
the bluetooth device still enabled):
FS/LS budget (us per microframe)
 0:  125 109 125 125 125 125  21   0
 8:  125 109 125 125 125 125  21   0
16:  125 109 125 125 125 125  21   0
24:  125 109 125 125 125 125  21   0
32:  125 109 125 125 125 125  21   0
40:  125 109 125 125 125 125  21   0
48:  125 109 125 125 125 125  21   0
56:  125 109 125 125 125 125  21   0
1-1.1 ep 84:    39 @  0.5+1 mask 8020
1-1.4 ep 81:    24 @  0.5+1 mask 8020
1-1.1 ep 01:   458 @  0.2+1 mask 003c
1-1.1 ep 81:   234 @  0.0+1 mask 3c01

I guess this is because of an asymmetry (after your reply: probably related to
what you mention about interrupt packets in later microframes):
microframe-spanning transfers start with full microframes but will usually
finish on partially filled ones. On top of this the seventh uframe is allowed
only 30us, so filling from the back prevents the first microframe being
partially occupied by transfers and forcing any microframe-spanning transfers
forward a frame. This causes the space single microframe transfers can fit into
to become a little more fragmented than it would otherwise be. In the case
where:
39   0   0   0   0   0   0   0
is in place then adding a couple of larger transfers:

39  125 109 0   0   0    0   0

39  125 109 125 125 125  83x 0
                          ^ no longer fits (<=30)
It's still not optimum which terminating partial microframe is best to put
where will depend on the smaller transfers to be fitted in, but there's one
less gap.


The 16bit output (608us per frame) still wont work in duplex, but this is
unsurprising as the limit is 6*125us+30us=780us, while the 608us output plus
the smallest input (159us) and the 39us HID comes to 806us, so there's no way
to fit it. I do wonder if snd-usb-audio would be able to help there by using a
smaller packet size in the output streams. 

The bluetooth controller is 12Mbps too and wants to open extra endpoints if
anything connects, so I'm actually better plugging into the other bus, but at
least this is due to absolute bandwidth limits. It's actually possible to get
away with duplex bluetooth audio (sMBC) and usb audio from this device on the
same bus if I use the 16 bit input format:
TT 1-1 port 0  FS/LS bandwidth allocation (us per frame)
    713  713  713  713  713  713  713  713
FS/LS budget (us per microframe)
 0:  125  67 125 125 125 125  21   0
 8:  125  67 125 125 125 125  21   0
16:  125  67 125 125 125 125  21   0
24:  125  67 125 125 125 125  21   0
32:  125  67 125 125 125 125  21   0
40:  125  67 125 125 125 125  21   0
48:  125  67 125 125 125 125  21   0
56:  125  67 125 125 125 125  21   0
1-1.4 ep 81:    24 @  0.5+1 mask 8020
1-1.1 ep 84:    39 @  0.5+1 mask 8020
1-1.1 ep 01:   458 @  0.2+1 mask 003c
1-1.1 ep 81:   159 @  0.0+1 mask 3c01
1-1.4 ep 83:    17 @  0.1+1 mask 3802
1-1.4 ep 03:    16 @  0.1+1 mask 0002
(Let's take a moment to admire what a compressed codec can do.)

Not sure if this is a good idea or actually legal by the USB spec of course...
(My knowledge of which is limited to a recent skim though the EHCI
specification, although I think from fig 4-17 start splits are issued the
microframe before the transfer starts, a transfer starting in microframe 6 has
its start-split in microframe 5, although I'm not clear if it then spans the
frame boundary, it it fits in microframe 6 on its own does it use a
complete-split instead? And if starting closer to the front the it should be
fine.)

(Also after your reply: I suppose the different rate support is intended for
playback only modes? Although 96kHz makes more sense recording than playing
anyway...)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.