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

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

[Jasmeet (Jazz) Bhatia]

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