USB mic (Medeli 0a67:d156) works on Windows/Android but fails on Linux xHCI

I have a cheap USB microphone (Jmary MC-PW10; the chip is Medeli, USB ID 0a67:d156). It works perfectly on Windows and on Android, but on my Linux laptop it will not work reliably. I've controlled for the physical variables carefully and it still fails only on Linux, so I'm trying to find out whether there's a snd_usb_audio / usbcore quirk (or an xHCI setting) that makes Linux tolerate this device the way Windows does.

The key controlled comparison

Same microphone, same USB-C cable, same USB-C-to-USB-A adapter (the one that ships with the mic), plugged into a healthy USB-A port in every case:

• Windows PC: flawless. Detected instantly, records, and the hardware mode button switches modes with no dropouts.

• Android phone: flawless (works the moment it's plugged in; mode switching fine).

• Linux laptop: unreliable. Often won't enumerate at all; when it does, it frequently disconnects within a second at rest; and pressing the hardware mode button reliably disconnects it.

Because the cable, adapter, and port type are identical across all three, the difference points at the OS USB handling rather than the physical connection.

System

• Laptop: Dell Latitude 7480

• OS: Linux Mint 22.3 Cinnamon

• Kernel: 6.17.0-35-generic

• USB controller: Intel xHCI (0000:00:14.0)

• Audio server: PipeWire

• Note: the laptop's onboard USB-C port is dead (hardware fault), so I cannot test a direct USB-C connection. All Linux tests use the mic's USB-C-to-USB-A adapter into a USB-A port (tested on the laptop's own USB-A ports and via a hub).

Device

• USB ID: 0a67:d156 — Medeli Electronics Co., Ltd (vendor 0x0a67). Manufacturer string "Jin-Audio", product "MC-PW10".

• USB 2.0 full-speed, bus-powered, MaxPower 100 mA.

• UAC 1.0, 48000 Hz, 16-bit and 24-bit PCM, isochronous endpoints.

• bcdDevice 0.02.

• Hardware mode button cycles: pop (default on power-up) → studio → mic → ... → dodge → pop.

Two failure signatures observed (intermittent in form)

The failure is not always identical — sometimes it's a clean silent drop, sometimes it comes with -71 / -32 / -19 errors. That variability is itself part of the puzzle.

(A) Enumerates, then disconnects at rest — no error code. Happens on its own within about a second, and also right after powering on via the button:

(B) Mode-button press triggers disconnect with usb_set_interface failed (-19) (observed in earlier sessions). When it is stable enough to record, pressing the mode button (e.g. pop → studio) reliably drops it:

Also seen on some cycles, an HID-probe failure at enumeration:

And other enumeration-level errors across sessions:

When it does enumerate cleanly, it works fully — it shows as card N: MC-PW10 ... USB Audio, appears in PipeWire as a 24-bit stereo 48 kHz source, and records in OBS / arecord. So the hardware and audio path are fine; the problem is (A) staying connected and (B) surviving the mode-switch, both only on Linux.

What I've already tried (no success)

• Powered hub, and hub with external 5 V into its DC-input port. No change (device only requests 100 mA, so it isn't a power-budget issue).

• Three different USB-C cables. Cable quality affects (A) but never fixes it fully; it doesn't affect (B).

• The laptop's own USB-A ports directly, plus hub USB-A and hub USB-C ports.

• echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend (global). No change.

• usbcore.quirks=0a67:d156:gi — still detects but drops. ...:gik — stops detecting entirely (so k is harmful for this device).

• snd_usb_audio quirk_flags=0x02 and 0x200 via /etc/modprobe.d. Inconclusive — the connection is often too unstable to hold long enough to judge the mode-switch.

• Already on kernel 6.17, so a newer kernel isn't an available fix.

Questions

1. For a device that enumerates fine on Windows/Android but intermittently hits -71 (device not accepting address / can't set config) on Linux xHCI with the identical physical connection, is there a usbcore.quirks combination (beyond g/i) that improves enumeration tolerance? (k breaks detection for this device.)

2. Is usb_set_interface failed (-19) on the hardware mode-button switch fixable with a specific snd_usb_audio quirk_flags value (e.g. SET_IFACE_FIRST / IFACE_DELAY / IGNORE_CTL_ERROR)? Which value would you try for this chip?

3. Would forcing the port/device to plain USB 2.0 (rather than negotiating through xHCI) help this class of cheap UAC1 chip, and if so how would I do that on this controller?

Note: lsusb -v -d 0a67:d156 produces no output when the device has already dropped (it isn't on the bus long enough), which is part of the problem. The descriptor summary above is from a moment when it did enumerate.