https://bugzilla.kernel.org/show_bug.cgi?id=218544 --- Comment #15 from Alan Stern (stern@xxxxxxxxxxxxxxxxxxx) --- Some years ago I did try allocating interrupt transfers from the end of frame backwards, but decided against it in the end -- I don't remember why. It certainly helps in your case, so maybe that decision should be reconsidered. Maybe the reason was that the absence of FSTN nodes makes interrupt transfers near the end of the frame less reliable. If any unexpected delays should push the transfer back a few hundred microseconds, there wouldn't be enough complete-splits to guarantee it could finish correctly. In the examples you give above, 1-1.4 ep 81 and 1-1.1 ep 84 each have only one complete-split (only one bit set in the high-order byte of the mask), whereas the spec says there should be enough complete-splits for the entire LS/FS packet plus two extra. snd-usb-audio using a smaller packet size for the output streams wouldn't help the scheduling; the scheduler has to assume that each endpoint will use the maximum packet size allowed (i.e., the maxpacket value). The reason for scheduling isochronous transfers earlier than interrupt transfers has to do with the way transaction translators in hubs behave. I forget the details (it's described in the USB-2 spec), but there's some scenario in which they will lose data if an isochronous packet comes after an interrupt packet in the same microframe. Scheduling interrupt transfers late in the frame _is_ legal according to the spec, so long as it is done properly. And in theory the driver could rebalance the schedule, changing which microframes are assigned to each endpoint, as new endpoints are added. But that would add another whole new level of complexity to the driver and I never implemented it. Besides, without FSTN nodes you still wouldn't be able to get the full benefit. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
