* Re: [BUG] ALSA: usb-audio: RME Digiface USB (2a39:3f8c): corrupted playback on ~20% of stream starts, fixed by quirk_flags 0x100010
[not found] ` <fd618d1b-d4b2-44cc-b08d-7e664938e771@lina.yt>
@ 2026-11-07 9:19 ` Takashi Iwai
2026-11-07 11:23 ` Michal Pecio
0 siblings, 1 reply; 2+ messages in thread
From: Takashi Iwai @ 2026-11-07 9:19 UTC (permalink / raw)
To: Hoshino Lina; +Cc: Christoph Cheaure, linux-sound, tiwai, linux-usb
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.
^ permalink raw reply [flat|nested] 2+ messages in thread