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’t 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:
> 
> 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ó:
>> 
>> On Thu, 09 Jul 2026 00:28:00 +0200,
>> Jussi Laako wrote:
>>> 
>>> Hi,
>>> 
>>> I don’t 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.
>> 
>> 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 quirk_flags_table[] = {
>>                   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 */