[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

--- Comment #21 from Michał Pecio (michal.pecio@gmail.com) ---
Thanks for taking the time to explain.

(In reply to dylan_robinson from comment #20)
> 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.
That would be something for snd-usb-audio to do.
Does the same apply to missed service on IN endpoints?
Or IN endpoints with lost/corrupted packets?

And for the record, are you saying there is no hope to predict what the HW
expects to send and receive in the next interval and handle it right? Users say
that streams go out of sync but the HW continues to function in some manner.

> 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.
I remember noticing this tendency to restart streams (unlink and resubmit URBs)
during startup with short buffers/low latency, presumably without going through
altsetting 0. So I can see how this can be a problem. IIRC it was at least
partly due xhci-hcd scheduling too far into the future. I will try to find some
time to look into it again.

> 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).
These fields are filled by xhci-hcd so they may be bogus due to bugs.

For reliable information it's better to log "Frame ID" written to Isoch TDs and
MFINDEX register in process_isoc_td() (sensitive only to IRQ latency).

IIRC, on non-CFC even if things are initially right, they may fall out of sync
due to missed service, with the MSE event being the only sign of trouble.

> 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.
The "Linux way" appears to be guaranteeing two things to drivers:
- start_frame in completed URBs accurately reflects the time of execution
- streams are always continuous - even if an interval is missed, the next URB
frame reliably completes (or is missed) in the next interval

For continuity, class driver only needs to ensure that the URB is resubmitted
from its completion handler. If that happens several ms later, the URB is
expected to immediately "complete in the past" with EXDEV.

AFAIK that's how ehci-hcd does it, but xhci-hcd doesn't and maybe should.

Wouldn't this be enough to make IN/OUT synchronization work?
What's people's experience using MOTU HW and audio in general on ehci-hcd?

> > 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.
IIRC the repeated unlink/resubmit cycles during startup were due to
snd-usb-audio getting some "xrun" callback from ALSA core for some reason. Then
it would unlink everything and try again. I didn't know why it happens.

New URBs may be contiguous with past ones if you don't wait for them to
complete
after usb_unlink_urb(). OTOH, usb_kill_urb() is synchronous. Once all URBs are
killed synchronously or completed (including due to unlink) and the queue is
empty, then submitting a new URB should schedule it far enough into the future
to ensure no missed service. That's the theory.

See usb_submit_urb() and usb_unlink_urb() comments in drivers/usb/core/urb.c

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

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