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

Salvador Blaya <[email protected]> Thu, 9 Jul 2026 09:54:43 +0200
Newsgroups org.alsa-project.alsa-devel,dev.linux.lists.regressions
Message-ID <CAOdyq+ook_mDq_5wc_Na182bLvxZ1YJUJEchJ6MochU17QecQA@mail.gmail.com>
Hi Takashi,

Thank you - that approach would fit this case well, and the risks you
mention are fortunately minimal here:

- The M6s DAC has been discontinued for years and the defect was first
  reported to the vendor (via their Windows ASIO driver users) back in
  2018, with no firmware fix ever published. I have an inquiry open
  with Musical Fidelity about firmware and will report back if
  anything changes.

- The only other model possibly sharing this ID, the M6sR successor,
  exhibits the same defect per the Roon thread in my original report,
  so an empty entry for 2772:0502 cannot break a working device. The
  current MF models known to work with native DSD (M3x, M6x) already
  worked before the vendor flag was added, so they use different IDs.

I'm happy to test the patch on my unit - both that native DSD is no
longer offered (MPD falling back to dsd2pcm as on 6.12.y) and that
normal PCM playback is unaffected. Just let me know.

Best regards,

Salvador

El jue, 9 jul 2026 a las 9:33, Takashi Iwai (<[email protected]>) escribi=C3=B3=
:
>
> On Thu, 09 Jul 2026 00:28:00 +0200,
> Jussi Laako wrote:
> >
> > Hi,
> >
> > I don=E2=80=99t think we currently have exclusion method for devices wi=
th buggy firmware, which claim to support native DSD, but do it incorrectly=
. And reverting with device specific white-listing is not a good approach f=
or 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.
>
> While I fully agree that white-listing all needed devices won't scale,
> blacklisting the broken device might work.  We can an empty quirk
> entry for 2772:0502 for skipping the vendor match, something like
> below, as an ad hoc fix.
>
> Though, this blindly assumes that there aren't so many broken devices,
> and there will be no firmware fix or another model that works with the
> same ID.  If a model is relatively new and/or the vendor often updates
> the firmware, such an entry can be risky, too.
>
>
> thanks,
>
> Takashi
>
> -- 8< --
> --- a/sound/usb/quirks.c
> +++ b/sound/usb/quirks.c
> @@ -2463,6 +2463,8 @@ static const struct usb_audio_quirk_flags_table qui=
rk_flags_table[] =3D {
>                    QUIRK_FLAG_DSD_RAW),
>         DEVICE_FLG(0x2708, 0x0002, /* Audient iD14 */
>                    QUIRK_FLAG_IGNORE_CTL_ERROR),
> +       DEVICE_FLG(0x2772, 0x0502, /* Musical Fidelity M6s DAC */
> +                  0), /* for avoiding QUIRK_FLAG_DSD_RAW with vendor mat=
ch */
>         DEVICE_FLG(0x2912, 0x30c8, /* Audioengine D1 */
>                    QUIRK_FLAG_GET_SAMPLE_RATE),
>         DEVICE_FLG(0x2a70, 0x1881, /* OnePlus Technology (Shenzhen) Co., =
Ltd. BE02T */