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

No, native DSD with the M3x and M6x for example didn=E2=80=99t work =
before I added the vendor flag. That is precisely why I added it.

By the way, you can also just convert everything to 48k-base DSD during =
playback and then the playback speed is correct. It is common that DACs =
play 48k-base DSD with 44.1k-base clock (or just go silent or play =
noise), but in this case it seems to be another way around.


Best regards,

	- Jussi


> On 9. Jul 2026, at 10.54, Salvador Blaya <[email protected]> wrote:
>=20
> Hi Takashi,
>=20
> Thank you - that approach would fit this case well, and the risks you
> mention are fortunately minimal here:
>=20
> - 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.
>=20
> - 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.
>=20
> 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.
>=20
> Best regards,
>=20
> Salvador
>=20
> El jue, 9 jul 2026 a las 9:33, Takashi Iwai (<[email protected]>) =
escribi=C3=B3:
>>=20
>> On Thu, 09 Jul 2026 00:28:00 +0200,
>> Jussi Laako wrote:
>>>=20
>>> Hi,
>>>=20
>>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>>=20
>> thanks,
>>=20
>> Takashi
>>=20
>> -- 8< --
>> --- a/sound/usb/quirks.c
>> +++ b/sound/usb/quirks.c
>> @@ -2463,6 +2463,8 @@ static const struct usb_audio_quirk_flags_table =
quirk_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 =
match */
>>        DEVICE_FLG(0x2912, 0x30c8, /* Audioengine D1 */
>>                   QUIRK_FLAG_GET_SAMPLE_RATE),
>>        DEVICE_FLG(0x2a70, 0x1881, /* OnePlus Technology (Shenzhen) =
Co., Ltd. BE02T */