Re: [BUG] snd-usb-audio: Elgato XLR Dock 0fd9:00a6 capture silent when playback starts first

[Takashi Iwai <tiwai@suse.de>]

On Sat, 07 Nov 2026 01:38:15 +0100,
James Barnette wrote:
> 
> 
> Hello,
> 
> I can reproducibly make an Elgato XLR Dock return digital silence from its
> microphone by starting playback before capture. Starting capture before
> playback works. This has caused repeated microphone failures during normal
> desktop use.
> 
> I would appreciate guidance on whether this needs an snd-usb-audio device
> quirk, and what additional traces or tests would help identify the correct
> fix. I have not established whether the underlying issue is device firmware
> or a host initialization requirement, and I do not have a tested kernel patch.
> 
> Hardware and software
> ---------------------
> Device: Elgato XLR Dock, USB ID 0fd9:00a6
> USB bcdDevice: 2.10 (device release descriptor, not independently verified
> as the vendor's firmware version)
> Connection: full-speed USB through xHCI
> Kernel: 7.2.5-3-omarchy, x86_64 (distribution/custom kernel)
> ALSA library: 1.2.16.1
> PipeWire: 1.6.8
> WirePlumber: 0.5.17
> 
> I have not yet tested a stock upstream kernel or another kernel version,
> so I cannot identify this as a kernel regression.
> 
> Reproduction
> ------------
> I temporarily disabled the PipeWire card profile for this device to release
> its hardware PCMs. I then ran arecord/aplay directly against hw:4,0. Card
> numbers are machine-specific. No PipeWire mixer, WaveSink routing, or
> OpenDeck plugin participates in these direct ALSA trials.
> 
> Both streams use 48000 Hz and S24_3LE. Playback is two channels of zeros
> from /dev/zero; microphone capture is mono. Each capture lasts two seconds.
> The microphone was unmuted, with hardware gain 49.5 dB. Hardware settings,
> including phantom power, were unchanged between trials.
> 
> Failing order:
> 1. Start aplay -D hw:4,0 -t raw -f S24_3LE -r 48000 -c 2 /dev/zero
> 2. Wait 300 ms, then start arecord -D hw:4,0 -t raw -f S24_3LE -r 48000 -c 1
> -d 2
> 3. Inspect capture samples, then close both streams.
> 
> Working order:
> 1. Start the same arecord command and wait until it supplies PCM data.
> 2. Start the same aplay command while capture remains open.
> 3. Inspect capture samples, then close both streams.
> 
> The attached Python reproducer discards audio, prints sample statistics,
> validates the exact USB ID, and restores the previous PipeWire card profile
> with capture started first. It briefly interrupts this device's audio.
> Run: python reproduce-xlrdock-startup.py --card 4
> 
> Results
> -------
> Across two runs, playback-first failed in 4/4 trials and capture-first worked
> in 4/4 trials. The second run captured exactly 96000 mono samples per trial:
> 
> Playback-first: 0 nonzero samples / 96000
> Capture-first: 95700 nonzero samples / 96000
> Playback-first: 0 nonzero samples / 96000
> Capture-first: 95701 nonzero samples / 96000
> 
> USB observations
> ----------------
> In the first run, usbmon showed completed isochronous capture transfers on
> endpoint 0x82. For each playback-first trial, all 2012 retained packet data
> prefixes were zero. For each capture-first trial, 2006/2012 prefixes contained
> nonzero data. I retained statistics and setup-request metadata, not audio or
> a complete usbmon recording. This localizes the observed silence to capture
> USB buffers, below the application mixer; it does not prove an internal
> firmware defect.
> 
> The relevant SET_INTERFACE activation order was:
> Failing: interface 1 alt 1 (playback), then interface 2 alt 1 (capture)
> Working: interface 2 alt 1 (capture), then interface 1 alt 1 (playback)
> 
> The descriptors advertise playback endpoint 0x01 with explicit feedback
> endpoint 0x81, and mono capture endpoint 0x82. Both advertise 48/96 kHz.
> I have not tested the same ordering at 96 kHz.
> 
> Recovery and limitations
> ------------------------
> Capture-first restores the microphone. In the desktop session I verified
> recovery by selecting the input-only profile, starting capture and waiting
> for PCM, then restoring the duplex profile while capture remained open.
> Microphone audio and the mixer meter worked afterward.
> 
> An application-level capture pin can protect that application's own output
> links, but cannot control earlier playback from other clients. I did not
> have boot-time USB tracing enabled, so I cannot identify which client
> started playback first during the original failure.
> 
> Could you advise whether a device-specific initialization quirk is
> appropriate, or suggest a targeted trace/test to distinguish the relevant
> USB setup operations? I can test a proposed fix on this physical device.

Might it be improved when enforcing the implicit feedback mode?
Just a blind shot judging from the description.


Takashi