Re: [REGRESSION] snd-usb-audio: commit da3a7efff64e ("ALSA: usb-audio: Update for native DSD support quirks") breaks DSD playback on Musical Fidelity M6s DAC (2772:0502), plays ~8.8% fast

Hi,

I don=E2=80=99t think we currently have exclusion method for devices =
with buggy firmware, which claim to support native DSD, but do it =
incorrectly. And reverting with device specific white-listing is not a =
good approach for future maintenance. Having to device-specific =
white-list each new device appearing on the market from the manufacturer =
just because some old device is broken is not really a sustainable =
model.

So I would just suggest using PCM with the device if it=E2=80=99s DSD =
implementation is buggy/broken, while it claims to have such. Or =
alternatively update the firmware with a fixed one.

Newer MuFi devices work fine though, like for example the M3x DAC I have =
for testing this, and the M6x you mention.

Additional challenge is that many manufacturers use the same USB =
interface implementation with same VID:PID on multiple different =
products. So it is not even necessarily possible to distinguish a =
particular problematic product.


Best regards,

	- Jussi


> On 8. Jul 2026, at 19.33, Salvador Blaya <[email protected]> wrote:
>=20
> To: [email protected]
> Cc: [email protected], [email protected], [email protected]
> Subject: [REGRESSION] snd-usb-audio: commit da3a7ef ("ALSA: usb-audio:
> Update for native DSD support quirks") breaks DSD playback on Musical
> Fidelity M6s DAC (2772:0502), plays ~8.8% fast
>=20
> Hi,
>=20
> Commit da3a7efff64e ("ALSA: usb-audio: Update for native DSD support
> quirks") added VENDOR_FLG(0x2772) with QUIRK_FLAG_DSD_RAW for Musical
> Fidelity devices. This vendor-wide match also catches the (older,
> discontinued) Musical Fidelity M6s DAC, USB ID 2772:0502, which =
exposes
> a UAC2 altsetting with bmFormats 0x80000000 (RAW_DATA, 32-bit) but
> whose firmware cannot actually clock DSD playback correctly in any
> mode. As a result, since this commit, applications like MPD prefer the
> newly offered native DSD over DSD-to-PCM conversion and playback is
> audibly broken (runs ~8.8% fast, raised pitch), where kernels without
> the commit (e.g. 6.12.x) play correctly.
>=20
> Could 2772:0502 be excluded from the vendor flag (or the vendor flag
> be narrowed to the specific products that support native DSD, such as
> the newer M6x DAC)?
>=20
> Evidence gathered on Debian trixie, MPD, direct hw: access, no
> resampling:
>=20
> 1) Native DSD (observed on 7.0.7 through 7.0.12): host side is correct
>   - hw_params shows format DSD_U32_BE, rate 88200 (correct for DSD64)
>   - but playback runs ~8.8% fast with raised pitch. A 4:41 track
>   finishes in ~4:15, matching a 48 kHz-family clock (3.072 MHz)
>   applied to a 2.8224 MHz DSD64 stream (ratio 1.0884).
>=20
> 2) DoP (6.12.9, MPD dop=3Dyes): host side again correct - hw_params
>   shows S32_LE, rate 176400 - same ~8.8% fast playback. So the DAC's
>   internal DSD decoding path is misclocked regardless of transport.
>=20
> 3) Control test: the same DSD64 track converted to PCM FLAC at
>   176400 Hz plays at correct speed/pitch through the exact same path
>   (S32_LE @ 176400). The 44.1 kHz rate family is fine for PCM; only
>   DSD decoding inside the DAC is broken. This rules out any host-side
>   rate issue.
>=20
> 4) The same fault has long been reported for this DAC on Windows 10
>   with the official ASIO driver ("DSD via DoP plays noticeably
>   faster"):
>   =
https://community.roonlabs.com/t/musical-fidelity-m6-sdac-dsd-issues/39450=

>   including a follow-up for the successor model (M6sR). This is an
>   OS-independent firmware defect that the manufacturer never fixed,
>   which is presumably why this model was specified as DoP-only.
>=20
> Working configuration for reference (correct playback): MPD with
> dop "no", MPD's dsd2pcm conversion to 352800 Hz - i.e. the behaviour
> kernels without the commit provide by default for this device.
>=20
> Since these quirk updates tend to be backported to stable/LTS trees,
> please consider the fix for stable as well, so that currently working
> LTS kernels (e.g. 6.12.y) don't regress.
>=20
> Full lsusb -v output attached. Happy to test patches.
>=20
> #regzbot introduced: da3a7efff64ec0d63af4499eea3a46a2e13b5797
>=20
> Please CC me on replies, I'm not subscribed to the list.
>=20
> Best regards,
>=20
> S. Blaya
> <m6sdac-lsusb.txt>