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

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

[Takashi Iwai]

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
> 
> I mitigated this issue by manually binding IRQ affinity of xHCI
> controllers used for audio to specific CPU cores, and keeping other
> IRQs off of those cores. I wrote a tool for this here (which is
> intended to improve low-latency proaudio stability in general and
> reduce xruns, mitigating this bug is just a side effect):
> 
> https://github.com/hoshinolina/proaudio-setup
> 
> The quirk will not fully fix the underlying issue, which can cause
> this to happen any time a latency spike occurs during
> playback. However, if you find that it happens often when the device
> is opened, and the quirk makes that more reliable for you, it sounds
> like a good idea anyway.
> 
> It might be a good idea to take a usbmon log like I did. That might
> clarify whether what you're seeing is the same latency spike I was
> seeing happening some of the time early on during PCM open, or truly
> an issue with playback/capture open order. If it really is a startup
> order issue causing the offset, then the quirk is correct regardless
> of the latency problem.

Thanks for sharing the information.  I guess we should ping USB devs.
Adding linux-usb to Cc for awareness.

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.


Takashi

> (Note to anyone submitting a patch: I do not receive patch emails or
> most anything else kernel related these days, nor do I have time to
> test patches personally on the machine with the Digiface, so please
> don't expect me to review/reply to anything that comes from this
> discussion.)
> 
> > 
> > Environment
> > -----------
> > - Kernel: 6.12.95+deb12-amd64 (Debian bookworm-backports), x86_64,
> >    Intel NUC (Tiger Lake)
> > - Device: RME Digiface USB, 2a39:3f8c, bcdDevice 3.01, high speed,
> >    on xHCI 0000:00:14.0 behind the board's internal VIA USB 2.0 hub
> > - 48 kHz, 34 out / 32 in, S32_LE, period 384
> > - Clock: synced to S/PDIF input 1 (external master clock); the
> >    problem also reproduces with internal clock
> > 
> > Reproduction (PipeWire stopped, plain ALSA)
> > -------------------------------------------
> > - 34-channel S32_LE 48 kHz WAV with a 400 Hz tone at -24 dBFS on
> >    channels 1/2 and 33/34 (phones)
> > - repeatedly: aplay -D hw:CARD=USB24262729,DEV=0 tone.wav
> >    (3 s per run, 1 s pause, each run opens the device fresh)
> > - listen on the phones output: each run is either clean or corrupted
> >    for its whole duration
> > 
> > Minimal reproduction (PipeWire/PulseAudio stopped):
> > 
> >      python3 - <<'EOF'
> >      import wave, struct, math
> >      amp = 0.06 * 2147483647
> >      frames = b"".join(struct.pack("<34i", *[int(amp *
> > math.sin(2*math.pi*i/120))
> >               if c in (0, 1, 32, 33) else 0 for c in range(34)]) for
> > i in range(120))
> >      w = wave.open("/tmp/tone34.wav", "wb"); w.setnchannels(34);
> > w.setsampwidth(4)
> >      w.setframerate(48000); w.writeframes(frames * 1200); w.close()
> >  # 400 Hz, 3 s
> >      EOF
> >      for i in $(seq 30); do
> >          aplay -q -D hw:CARD=USB24262729,DEV=0 /tmp/tone34.wav; sleep 1
> >      done
> > 
> > Each aplay run is either clean or distorted for its whole duration.
> > 
> > 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
> > 
> > Exact setting used (/etc/modprobe.d/rme-digiface.conf):
> > 
> >      options snd-usb-audio quirk_flags=0x100010
> > 
> > /sys/module/snd_usb_audio/parameters/quirk_flags then reads 1048592
> > (= 0x100010) for the Digiface.
> > 
> > While the output was corrupted, recordings taken on the PipeWire side
> > (sink monitor) were clean, and the problem reproduces with plain aplay,
> > so the corruption seems to happen after the PCM buffer: in the driver,
> > on USB or in the device.

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

[Michal Pecio]

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