ALSA: usb-audio: Blue Yeti 046d:0ab7 fw 0.20 capture fails until device-side MCU reset

Hello,

I'm encountering a reproducible capture failure with multiple Logitech/Blue Yeti Classic USB microphone and wanted to ask where the best place for this workaround to live, as I feel it may belong in snd-usb-audio instead of userspace but wanted a more experienced opinion.

Device:

ID 046d:0ab7 Logitech, Inc. Blue Microphones
bcdDevice: 0.20
USB Audio Class: UAC1

System:
Linux 7.2.6-arch2-1 x86_64
xHCI
snd-usb-audio

When booting with the microphone already connected, USB enumeration succeeds normally. snd-usb-audio binds, ALSA creates PCM device, and Pipewire also sees the microphone.

Example:

$ arecord -D hw:Microphones,0 \ 
      -f S16_LE -r 48000 -c 2 \ 
	  -d 5 -vv /tmp/yeti.wav

Recording WAVE '/tmp/yeti.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo arecord: pcm_read:2285: read error: Input/output error

The same thing happens at 44100 Hz.

I tested a couple recovery methods with the device in this failing state:

- 44100 Hz Capture      -> EIO
- 48000 Hz Capture      -> EIO
- host USB reset        -> EIO
- USB unbind/rebinding  -> EIO

- device-side MCU reset -> Capture works immediately

Digging deeper, I tested an existing blue-yeti-autoreset userspace utility for this exact bug, which sends a UAC Extension Unit SET_CUR Request:

bmRequestType = 0x21

bRequest      = 0x01
wValue        = 0x0a00
wIndex        = 0x1900
xLength       = 8

payload = 00 09 00 00 00 00 00 00

After this is done, the Yeti will disconnect and reenumerate, with my system having the device change from 002 to 003, and arecord begins to work normally. Physically unplugging/replugging the device also does the same fix.

At the end of the day, this looks like a firmware issue with the Blue Yeti, as USB enumeration and snd-usb-audio are working as intended and succeeding, but some internal device state survives host-side USB reset not allowing the capture engine to operate, with the device-specific MCU appearing to be the cause.

With there being no obvious xHCI disconnect or USB transport errors in the kernel log, I'm left to assume this a quirk within the firmware of the microphone itself. A couple other Bugzilla reports I found seem to show the same issue I'm reporting here, with Bugzilla #220238 showing a same bug I'm describing.

https://bugzilla.kernel.org/show_bug.cgi?id=220238

My main question is whether the kernel should work around this in snd-usb-audio or whether maintainers would prefer the device-specific reset to remain in userspace because it intentionally causes a USB disconnect/enumeration.

If a snd-usb-audio workaround is considered ok, I would be interested in working on the patch and can test it reliably.

Please let me know if any additional usbmon traces, dmesg outputs or other diagnostics would be useful.

Thanks,

Jazz