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

[Michal Pecio <michal.pecio@gmail.com>]

On Fri, 8 May 2026 17:39:20 -0400, Dylan Robinson wrote:
> On Thu, May 7, 2026 at 5:54 PM Michal Pecio wrote:
> > It would surely need to be optional on per-URB basis, to avoid
> > updating all drivers and to enable sub-1ms URBs without gaps on HW
> > like xHCI, where we can't request starting frame with microframe
> > granularity.
> >
> > I suppose Windows/OSX have to be doing it this way too?  
> 
> Windows isochronous transfers behave similarly to the outdated
> documentation in Documentation/driver-api/usb.
> 
> Setting USBD_START_ISO_TRANSFER_ASAP in the URB instructs the USB
> driver stack to schedule the transfer in the next appropriate frame.
> For the first URB on a pipe, transfers with this flag are scheduled as
> soon as possible. For subsequent URBs, the stack automatically tracks
> stream continuity.
> 
> Otherwise, the UrbIsochronousTransfer.StartFrame member specifies the
> starting USB frame number for the transfer.
> 
> Source:
> https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/transfer-data-to-isochronous-endpoints

Looks like Windows ASAP is similar to Linux non-ASAP behavior, except
that they consider new URBs to continue the stream for 1024 USB frames
after the last completed URB. In Linux that number is 0 instead, as
there is no way to indicate a new stream by other means.

Windows requires isoc URBs to be frame-aligned. Linux doesn't have this
limitation. I can run a high-speed UAC dongle with two 0.5ms URBs just
fine, though ALSA won't let me go shorter for some reason. 

> The USBDriverKit API on macOS for submitting isochronous transfers is:
> 
> virtual kern_return_t IsochIO(
>     IOMemoryDescriptor *dataBuffer,
>     IOMemoryDescriptor *frameList,
>     uint64_t firstFrameNumber,
>     OSAction *completion);
> 
> firstFrameNumber: The starting frame number for the request. You can
> get the current frame number from the GetFrameNumber method of
> IOUSBHostDevice or IOUSBHostInterface. Specify 0 to begin the transfer
> on the next available frame (XHCI only).
> 
> Source:
> https://developer.apple.com/documentation/usbdriverkit/iousbhostpipe/isochio

Not sure how Apple and MS deal with the "phase" issue, i.e. does a
bInterval=6 endpoint run in frames 0,4,8,... or 3,7,11,... and how
are drivers supposed to set firstFrameNumber then.

Looking at the MS article, I suspect they want drivers to pretend it's
always 0,4,8, which is what the xHCI spec requires too.

> > It's supposed to be implied that submission from a complete()
> > callback is a continuation. I believe one of the submitted patches
> > fixes that.  
> 
> Because our devices use the implicit feedback synchronization model,
> our drivers typically submit OUT transfers from the IN pipe's
> completion callbacks. Would those submissions also be considered
> continuations of the existing OUT stream, or is continuity only
> inferred when a URB is submitted from the completion handler
> associated with the same pipe?

I meant completion at the same endpoint because it's a common case,
but submission while any URBs are pending and not completed yet also
is supposed to continues the stream, regardless of who submits.

Or at least that's the intent stated by Alan and what it was before
"BH giveback". I think today there is a short window after completion
by HW and before complete() runs, where even ehci-hcd may fail to
detect that the last remaining URB is still "in flight". In this case
it's likely too late to avoid a gap on OUT, but the gap should produce
EXDEV completions rather than delay the next URB by a few uframes.

Perhaps this should be fixed for all HCDs. The alternative is to ask
drivers to make the IN completion give the OUT completion any required
information to resubmit, which increases latency and chance of EXDEV,
or they risk potential hard to detect gaps due to SW latency. (The gaps
could be detected by looking at frame_desc->start_frame, at least when
xhci-hcd is fixed to fill it properly on non-CFC chips).

Regards,
Michal