What is required for native DSD on linux?

Hi,

I’m busy with building a light weight, Archlinux based, image for a RPi.
One of the things that I’m trying to achieve is native DSD support for my brand new W4S DAC2v2.

Now I’ve build a kernel with patches from this project https://github.com/lintweaker/xmos-native-dsd and added the ID of my DAC.

However, no luck. Still the log file of the RAAT server shows that it is using DoP.

Can someone (from the Roon team) tell me how actually this selection takes place? Am I missing something here?

Regards,

In Roon, how do you have “DSD Playback Strategy” set up in Settings->Audio->Device Setup on the Playback tab? I think if you’re seeing DoP it may not be set up in Native mode there.

Also, the output from cat /proc/asound/cardX/stream0 might help tell us what that kernel patch did/didn’t do.

In the menu there’s indeed only DoP available.

The proc interface shows this:

[root@roonpi Logs]# cat /proc/asound/card0/stream0
Wyred 4 Sound 32bit 384kHz DSD Interface at usb-3f980000.usb-1.2, high speed : USB Audio

Playback:
Status: Stop
Interface 2
Altset 1
Format: S32_LE
Channels: 2
Endpoint: 5 OUT (ASYNC)
Rates: 32000, 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
Data packet interval: 125 us
[root@roonpi Logs]#

Hmmm… I think I see a problem. It states ‘Altset 1’ where the linux kernel patch only handles altset 2 and 3.
I assumed the DAC has an XMOS based chip set, as the earlier versions of the W4S DAC has that as well. I might be wrong though…

This is what it looks like when the native DSD stuff is working properly:

iFi (by AMR) iFi (by AMR) HD USB Audio at usb-0000:00:14.0-1, high speed : USB Audio

Playback:
  Status: Stop
  Interface 1
    Altset 1
    Format: S32_LE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
    Data packet interval: 125 us
  Interface 1
    Altset 2
    Format: SPECIAL DSD_U32_BE
    Channels: 2
    Endpoint: 1 OUT (ASYNC)
    Rates: 44100, 48000, 88200, 96000, 176400, 192000, 352800, 384000
    Data packet interval: 125 us

You end up with more Altsets–often 2 but occasionally 3 or 4. And at least one has a SPECIAL DSD_* format.

1 Like

ok thanks. creating a new patch and gonna start a rebuild.

ok… this is gonna take some more time.
Right now building the kernel with debug output as I don’t see enough.

Ah well. The weather is not too good anyway :wink:

1 Like

This “patch the kernel per device” is ruining things for everyone.

Someone really needs to bite the bullet and make this quirks stuff data driven instead of baking it into the kernel. It’s a simple lookup table, and it wouldn’t be that hard. Make a way to replace (or augment, or whatever the kernel dudes think is most appropriate) the lookup table in the kernel in a global way at runtime…then either Roon Bridge could inject an up-to-date list of mappings, or OS providers like Raspbian or DietPi could do it. Or maybe a combination.

If it were data driven, it would be possible to make a tool that helped a much less technical person fiddle with their DAC and try out the few different options and make it work. It could be a step-by-step wizard–there’s only a handful of DSD formats. All it has to do is let you pick your device then try them one by one and play a test tone. If one of them works, great, lets set you up and submit it to a global database somewhere so other people can benefit automatically. If not, sorry.

No idea what it would take to make the Linux guys accept that patch. The politics in that project make me afraid that the effort won’t bear fruit.

1 Like

Yeah. Building kernels all week for an ARM kernel is not fun at all. Especially as it takes ages :wink:

So ideally you want to bring this to userspace. To be honest, I think that such an effort would take a long time to finally materialise and end up in the kernel.

What we could do is start a new github project that provides the information in an ‘easy’ readable format. Right now the information is only available in kernel patches (https://github.com/lintweaker/xmos-native-dsd), and even for an old 3.x kernel for Fedora. And I can imagine that this is rather intimidating as well. So maybe I just pull the information out, create a new project (that is not specifically tied to xmos), and also administer there if it is already merged upstream and in which kernel.

Providing this data on a higher level could make lives a little bit easier if things actually need to be patched.

One of the things that doesn’t work now also is the fact that these patches are not even merged in upstream. I contacted the maintainer and he said that he would create one large patch ‘soon’. He is part of the kernel alsa maintainer group afaik.

Right now I’m looking if it is possible to manipulate usb id’s from user space (udev ?) so it would be possible to create a patch that allocates the few possibilities to a ‘special set’ of USB id’s. That way it would be possible to test a DAC from user space by simply booting the kernel and manipulate the USB id to one of those in the special set.

I noticed this exchange a few days ago and recognized your name on it :slight_smile:

I don’t think this is possible (or a good idea). If you actually muck with the VIDs/PIDs it will break other stuff. It’s a really DSD-centric hack.

Based on the patches, the userspace mapping should look like:

VID,PID,altset -> dop,bitrev,format

And to do it with a data format that allowed for new conditions to appear on the left, and new flags on the right, in case things change over time.

ok… maybe it would be enough then to create a patch that provides a way to write the data to the kernel (sysctl or something else) and patch the quirk code to use that data if it’s there.

Than you can manipulate this from user space and add known (connected) devices. I’m not sure about how feasible it is that this gets accepted upstream, but at least ‘everyone’ would have to apply one patch that can fix this (somewhat).

Hi Harry,

May be premature but once you get native DSD working you will find a full volume “pop” after pressing play if using ALSA and a USB DAC. The problem has been patched in ALSA as set out here.

1 Like

Thanks @andybob for the warning. Already noticed that one, and that was the next thing to add to my kernel build.

Right now still struggling to get some debug info from the kernel. If this is gonna work … I think I deserve a nice bottle of scotch :wink:

1 Like

Ok… quick update. Finally managed to get some debugging from the kernel. It turns out my DAC only provides an altset 1, which just does the usual PCM.

Send a mail to Wyred4Sound if they can help me. Some DAC’s require a command sent to them to put it in native DSD mode. Maybe this is one of them, although I would find that awkward as that’s not very common.

Does the pi have enough bandwith for DSD? Ethernet and USB are on the same bus.

It should do DSD64 as that has a PCM equivalence of 176k.

Pi and native DSD128 working fine so far for me…

1 Like

Yeah the Pi can do that. This was not about DSD in general, but native DSD.

Thanks for the reply, always thought it was a no go due to the shared bus.
will take a look at it…

Does ROCK, which is running on it’s linux form has it ALSA updated to the latest to support native DSD as opposed to DoP?

Most software manufacturers like Roopieee will list down USB-DACs tested using native DSD below: