[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 #15 from Alan Stern (stern@rowland.harvard.edu) ---
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.