[Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=220748

dylan_robinson@motu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dylan_robinson@motu.com

--- Comment #20 from dylan_robinson@motu.com ---
The issue, as it relates to the MOTU devices mentioned here, is that after
enabling a non-zero alternate setting with usb_set_interface(), once a transfer
is sent in a service interval (zero-length or otherwise), there must be a
transfer in every subsequent service interval. If, for any reason, a service
interval is missed, the alternate setting must be toggled back to zero and then
re-enabled, and the stream restarted.

MOTU's drivers on Windows and macOS take advantage of the ability on those
platforms to schedule the start frame of isochronous streams sufficiently far
into the future to ensure that enough URBs can be submitted before the first
URB completes.

On Linux, I have found that with snd-usb-audio, it is fairly typical for
streams to "stutter start." Because of the ASAP/SIA behavior discussed above,
when the first URB is submitted, it can sometimes complete before subsequent
URBs are enqueued. This creates a gap in the stream and causes the device
buffers to fall out of sync.

At one point, I investigated monitoring the start_frame in the completion
handler, but on non-CFC controllers it was not reliable (there were many
duplicated frame numbers or gaps that did not reflect reality).

Although more recent MOTU devices have improved buffer management and won't
fall out of sync due to missed intervals, the ability to specify a start frame
is still important for reasoning about the timing relationship between IN and
OUT streams, which helps guarantee consistent round-trip latency.

On non-Linux platforms, we have found that as long as a sufficient number of
transfers are enqueued before the first transfer starts, a missed service
interval, even on hosts that don't support CFC is quite rare. 

> If drivers want to insert a gap to resynchronize after detected lost packets,
> I'm afraid that's not supported in the current model.

That would not be necessary for MOTU devices.

> I wonder if this could be the reason for some weird snd-usb-audio behavior
> reported in the past (repeatedly unlinking and retrying URBs for unclear
> reason when running full-duplex with very low latency). But it's just a wild
> guess.

This sounds like an issue I just started investigating. I am exploring the
possibility that when an isochronous endpoint is restarted quickly on a CFC
host (all URBs are killed and immediately then resubmitted), if the new URBs
are submitted before all TRBs have been dequeued, their start_frame values may
be set as if they were contiguous with the canceled TRBs. This might be causing
the entire batch to fail with missed service intervals. This then happens over
and over again.

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

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