Re: [BUG] ALSA: usb-audio: RME Digiface USB (2a39:3f8c): corrupted playback on ~20% of stream starts, fixed by quirk_flags 0x100010

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

On Sat, 07 Nov 2026 10:19:01 +0100, Takashi Iwai wrote:
> On Sat, 07 Nov 2026 04:53:37 +0100,
> Hoshino Lina wrote:
> > 
> > Hi,
> > 
> > On 2026/11/07 8:26, Christoph Cheaure wrote:  
> > > Subject: [BUG] ALSA: usb-audio: RME Digiface USB (2a39:3f8c):
> > > corrupted playback on ~20% of stream starts, fixed by quirk_flags
> > > 0x100010
> > > 
> > > Hi,
> > > 
> > > I'm seeing intermittently corrupted playback on an RME Digiface
> > > USB (2a39:3f8c) with the in-kernel support added in 6.12, and
> > > found a quirk flag combination that fixes it for me.
> > > 
> > > Symptom
> > > -------
> > > On roughly 1 in 5 stream starts, the playback output is corrupted:
> > > any non-zero signal comes out heavily distorted / with clicks, on
> > > all outputs, including the analog phones output (channels 33/34).
> > > Digital silence stays silent, which made the problem hard to
> > > spot. The bad state persists for the whole time the PCM is open;
> > > after closing and reopening, the next start is usually clean.  
> > 
> > What you are hearing is what happens when playback falls behind by
> > one USB frame on the Digiface. This happens mainly due to a bug in
> > the xHCI kernel driver related to isochronous scheduling when IRQ
> > latency spikes occur (together with the Digiface handling playback
> > underruns rather poorly). I no longer contribute to the kernel
> > directly for personal reasons, so I filed it here on Fedora, but it
> > was never triaged/forwarded:
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2451673

Hi,

These are known problems and things should be improved in 7.3.

Particularly, if the HC is "hci version 0x110" or newer (see dmesg),
scheduling is exact in almost all cases.

As for dumping kernel patch suggestions on distro bugtrackers, you
should have known better what to expect...

> And, yes, if the USB-audio quirk option improves, it's worth to take
> it as default.  But, it'd be better to be investigated the root cause
> at first, of course.

It seems to be a common quirk of snd-usb-audio that duplex needs a few
xruns and restarts to begin running smoothly, not sure why. I guess
FORCE_IFACE_RESET was helping with that by clearing any xhci-hcd state.
It shouldn't be necessary anymore, we tried to make this case work.

The driver also has other potential issue: it relies solely on luck
for synchronization between multiple endpoints and doesn't even look
at urb->start_frame to check if sync has been achieved.

Regards,
Michal
 
> > > Results (bad starts / total)
> > > ----------------------------
> > > - default, external clock:                  2 / 30
> > > - default, internal clock:                  7 / 30
> > > - lowlatency=0:                             no improvement
> > > - keyboard/mouse unplugged (same xHCI):     no improvement
> > > - quirk_flags=0x100000 (FORCE_IFACE_RESET): 7 / 110 (~6%)
> > > - quirk_flags=0x100010
> > >    (FORCE_IFACE_RESET | PLAYBACK_FIRST):     0 / 90