Re: [PATCH] usb-audio: Fix boot-time crackling for Generic USB Audio device

[Gordon Chen]

On Mon, Jul 13, 2026 at 04:10:48PM +0800, Zhang Heng wrote:
> +		/* Generic USB Audio (0x1e0b:d01e): use SIA for consistent scheduling */
> +		if (ep->chip->usb_id == USB_ID(0x1e0b, 0xd01e))
> +			u->urb->transfer_flags |= URB_ISO_ASAP;

Not a maintainer, just a bystander who was Cc'd -- two small notes on the
form of the patch, plus one question I can't answer myself.

A per-device usb_id comparison in the endpoint.c fast path seems like the
kind of thing the quirk_flags_table in quirks.c exists to avoid. Would a
QUIRK_FLAG_ISO_ASAP (set in the table, tested here as
chip->quirk_flags & QUIRK_FLAG_ISO_ASAP) work for you? It keeps endpoint.c
device-agnostic, and the next device with the same symptom becomes a
one-line table entry rather than another if.

> +	if (ep->chip->usb_id == USB_ID(0x1e0b, 0xd01e) &&
> +	    ep->type == SND_USB_ENDPOINT_TYPE_SYNC)
> +		ep->skip_packets = 4;

The block immediately above this one already does exactly
"type == SND_USB_ENDPOINT_TYPE_SYNC -> skip_packets = 4"; adding the ID to
that condition would avoid the duplicate if. Also, the changelog doesn't
say what this hunk contributes on its own -- is URB_ISO_ASAP alone
insufficient, and if so, what does skipping the first 4 sync packets fix
that ASAP doesn't? Right now the two changes are indistinguishable in the
commit message, and skip_packets = 4 reads as belt-and-braces.

And the question. If xhci_get_isoc_frame_id() really does compute a
stale Frame ID for TDs at index > 0 -- because the frame has advanced by
the time validation runs -- then isn't that generic to any isoc URB with
number_of_packets > 1, rather than specific to 1e0b:d01e? The index=0 TD
gets clamped back into range, later TDs don't, and the endpoint ends up
mixing explicit Frame IDs with SIA. Nothing in that description looks
device-specific to me. If it is in fact generic, a per-device quirk in
sound/usb papers over it for one device while every other multi-TD isoc
consumer keeps hitting it -- and the fix would belong in xhci-ring.c.

I'm not familiar enough with the xHCI scheduling side to say whether
that's right, so it may be worth Cc'ing Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> to get a verdict before this is settled as
a usb-audio quirk. If your device is the only one that turns the mixed
scheduling into audible corruption, then the quirk is arguably the right
scope after all -- but that reasoning should be in the changelog.

One data point that cuts against my own question above: on an AMD xHCI
here, streaming to a class-compliant USB audio device, I see no "beyond
range" / "Ignore frame ID field" messages at all. If the index > 0
staleness were unconditional I would expect to hit it too. So something
about your device's packet layout or your host's timing is presumably
what actually trips it -- which would make the device-specific scope
defensible, but that is exactly the reasoning I would want to see spelled
out in the changelog.

Thanks,
Gordon Chen