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

[Takashi Iwai <tiwai@suse.de>]

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.