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 Jussi,

Thanks for the explanation - that's fair enough, understood. Since the
defect is in the device firmware and affects every OS, I agree the
right place to pursue a real fix is the manufacturer, which I'm doing
separately.

For the record, and for any other M6s DAC owner finding this thread:
the device plays DSD correctly only via DSD-to-PCM conversion. With
MPD this can be enforced regardless of kernel version by omitting dsd
entries from allowed_formats, e.g.:

audio_output {
    type            "alsa"
    device          "hw:CARD=3DM6sDAC,DEV=3D0"
    mixer_type      "none"
    dop             "no"
    allowed_formats "352800:32:2 176400:32:2 96000:32:2 88200:32:2
48000:32:2 44100:32:2"
}

This restores the pre-7.0.7 behaviour (dsd2pcm at 352.8 kHz), which
plays correctly.

Consider this report resolved as "device firmware defect, workaround
documented". Thanks again for your time.

#regzbot resolve: device firmware defect, not a kernel bug

Best regards

Salvador

El jue, 9 jul 2026 a las 0:28, Jussi Laako (<[email protected]>) escribi=
=C3=B3:
>
> 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 a=
ppearing on the market from the manufacturer just because some old device i=
s broken is not really a sustainable model.
>
> So I would just suggest using PCM with the device if it=E2=80=99s DSD imp=
lementation 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 interfac=
e implementation with same VID:PID on multiple different products. So it is=
 not even necessarily possible to distinguish a particular problematic prod=
uct.
>
>
> Best regards,
>
>         - Jussi
>
>
> > On 8. Jul 2026, at 19.33, Salvador Blaya <[email protected]> wrote:
> >
> > 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
> >
> > Hi,
> >
> > 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.
> >
> > 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)?
> >
> > Evidence gathered on Debian trixie, MPD, direct hw: access, no
> > resampling:
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Full lsusb -v output attached. Happy to test patches.
> >
> > #regzbot introduced: da3a7efff64ec0d63af4499eea3a46a2e13b5797
> >
> > Please CC me on replies, I'm not subscribed to the list.
> >
> > Best regards,
> >
> > S. Blaya
> > <m6sdac-lsusb.txt>
>