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.
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.
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 “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.
Yeah. Building kernels all week for an ARM kernel is not fun at all. Especially as it takes ages
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.
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).
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.
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.