https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #14 from Ian Malone (ibmalone@xxxxxxxxx) --- 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.
