DSD Direct (again)

Help and Support Help
#1

Ok, my first post. I run the latest version of Volumio on a PI 3B+ and I’m running into some problems, one of which is DSD Direct. I own several DACs around the house.

  1. With a Nuprime uDSD DAC, ‘DSD Direct’ does the exact opposite of what I think it should do: DSD music files are converted to PCM instead of played natively. In DoP, DSD plays as DSD but only up to DSD128 (yes, I do have about 40 albums in native DSD256).
  2. The exact same behaviour occurs with the Audiolab M-DAC+ .
  3. With the DAC section of a Marantz SA-14S1, there’s no sound at all, regardless of file format. Volumio does show its name etc, but that’s about it.

A general problem with DoP is the increased network overhead (traffic) due to PCM padding, which may account for the DSD128 limit, although the DoP version may also be to blame.

I should mention that these DACs all work fine with different PC hardware and software (foobar, JRiver, etc) except Volumio x86 and the Pi.

Now I read somewhere that Linux has issues with XMOS USB implementations, and someone even developed a generic patch for it, but this is just a wild guess.

Could anyone please provide solutions to these issues?

Thanks, Marco

#2

Hi Marco,
Volumio does this:

  • If set on DoP, it will work on most USB DAC and send DoP
  • If set on DSD Direct, if the DAC is direct DSD compatible it will send Direct DSD, if not, resample to PCM.

Now, with linux we need to patch the kernel for EVERY DAC model to make it compatible with native DSD, which is something I’ve not figured out how to handle properly and in a sustainable way. We’re working on that, bother with us…

#3

Wow, that was fast, thanks!

I wasn’t aware that you have to account for every single DAC under Linux, wow what a nightmare!

This is what happens with DSD Direct (I’m assuming that if there’s the selectable option in Playback Option “DSD Direct” then the DAC in question is supported as native DSD compatible). But when I start playing a native DSD file in DSD Direct mode, the PCM led on the Nuprime DAC lights up, indicating that it’s getting a PCM stream.
The same happens with the Audiolab M-DAC+, its display indicates PCM with sampling rate with the DSD Direct setting. Both the Nuprime uDSD and the Audiolab are XMOS USB implementations.

When setting Playback Options to DoP, everything works as intended. BTW: I have observed the same behaviour with other Linux-based music client/server systems.

However, some client/server systems (I don’t know about Volumio) use the SoX resampler when creating a DSD DoP stream. With higher sampling rates, this will overtax even an Intel NUC with 6th gen I3 processor, never mind the Pi!

As a side note, I use a QNAP NAS TS431P2 that Volumio (and others!) has issues with. The QNAP’s SMB implementation has a number of bugs that QNAP is unwilling (or incapable of) fixing. Just so you know.

I don’t want to be a wise guy but there’s a XMOS patch at least for the Audiolab M-DAC+: github.com/lintweaker/xmos-native-dsd BUT I have no way of knowing whether this is any good for Volumio. I have seen a generic XMOS patch also somewhere on Github but I can’t find it anymore. The Linux drivers for Marantz and Denon, and many others are there too. Though I think you know all this already, much better than I ever could…

Anyway, thank you for a wonderful music system, I really like it a lot!
Best regards, marco

#4

Oh, and I forgot to mention:

With the Nuprime uDSD, DSD256 in Volumio’s DoP Mode, results in a PCM stream (PCM led lights up on the DAC). So DoP works up to DSD128. Under Windows with its own driver, the Nuprime works up to DSD256.

Best regards, marco

#5

A further note: a friend loaned me his iFi Nano iDSD, and it behaved perfectly. So DSD Direct works as intended (native DSD) and DSD256 played natively without a single hitch or stutter.
I think the conclusion is rather simple, the issues I mentioned with the other DACs are purely (Linux) driver-based.

#6

I tried to PM you about the generic XMOS (Thesycon) native DSD patch but it was flagged as spam. So I’m posting it here.
I posted some messages entitled “DSD Direct (again)” a few days ago. I wrote that I had found information on a generic native DSD patch for XMOS (Thesycon) based USB DACs. Although this patch was originally developed for a Topping DAC, it says it should also work with similar XMOS based DACs, right up to DSD512.

I’m not sure if it’s any use to you (so sorry if this is just a waste of time) but I thought I’d send it anyway. Attached is the original message with the details. Ok, attaching also doesn’t work, so let’s see if I can include the text message below.

Thanks & good luck, marco

#7

That’s very useful indeed. If with this we can support all XMOS based USB receivers (which will make up a great percentage of all USB DACs) that’s a great addition.
On top of that, I had an idea yesterday that can make this happen in a very nice way.
Can you post again the patch link?

#8

Sorry, I was off-line for a couple of days so I saw your replay late. The link I had unfortunately died in the mean time. I found some related links though:

https://patchwork.kernel.org/patch/10540439/
https://www.spinics.net/lists/stable/msg258747.html
http://lkml.iu.edu/hypermail/linux/kernel/1806.1/04894.html
https://lwn.net/Articles/766748/

I must say I’m not familiar with these URLs so I can’t say if it’s any good to you. I get the impression that the patch will be included in the Linux kernel (future release?).
Source appears to go something like:

[code] sound/usb/quirks.c | 1 +
1 file changed, 1 insertion(+)

— a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1444,6 +1444,7 @@ u64 snd_usb_interface_dsd_format_quirks(
/
switch (USB_ID_VENDOR(chip->usb_id)) {
case 0x20b1: / XMOS based devices */

  • case 0x152a: /* Thesycon devices /
    case 0x25ce: /     Mytek devices */
    if (fp->dsd_raw)
    return SNDRV_PCM_FMTBIT_DSD_U32_BE;[/code]

The last link (lwn.net) contains a reference to the patch somewhere, but no link. Otherwise, try mailing the author: yuleopen@gmail.com .

Good luck & thx, marco

#9

It seems I missed a bit. There was an error in the original patch, which was corrected by this one:

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 02b6cc02767f..c51e2dee3075 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -1374,6 +1374,7 @@  u64 snd_usb_interface_dsd_format_quirks(struct snd_usb_audio *chip,
 		break;
 
 	case USB_ID(0x0d8c, 0x0316): /* Hegel HD12 DSD */
+	case USB_ID(0x152a, 0x8750): /* Topping DX7s */
 	case USB_ID(0x16b0, 0x06b2): /* NuPrime DAC-10 */
 	case USB_ID(0x16d0, 0x0733): /* Furutech ADL Stratos */
 	case USB_ID(0x16d0, 0x09db): /* NuPrime Audio DAC-9 */

I could imagine a line of code starting with

case USB_ID

etc. is needed for each individual X-MOS/Thesycon hardware/driver combo.

The preceding (explanatory) text originally went like

>
> Thesycon provides solutions to XMOS chips, and has its own device vendor id.
>
> In this patch, we use generic method to detect DSD capability of Thesycon-based UAC2
> implementations in order to support a wide range of current and future devices.
>
> The patch will enable the SNDRV_PCM_FMTBIT_DSD_U32_BE bit for the DAC
> hence enable native DSD playback up to DSD512 format.
>
> Signed-off-by: Yue Wang <yuleopen@gmail.com>

Could you please let us know if this will help you in enabling volumio to access the native DSD mode for all XMOS/Thesycon based DACs, such as the Nuprime uDSD, out there?

Thanks & best regards, Marco

#10

Hi there,

Same problem here… i am unable to play direct dsd (only dop) with nuprime dac-9
with dsd direct, my dac is switching to 352 pcm …
i am using volumio 2.513 with cubox i4

Is there any solutions ? any driver update scheduled in volumio next versions?

best regards Yohan

#11

Yohan: sorry for a late reply, but your NuPrime DAC is included in the patch list. These patches are probably to be included in a new Linux kernel (that would be 3.4.3 off the top of my head, its release status I haven’t followed).

I don’t know Volumio’s development road map but if the developers are planning a future release based on the new kernel, then this is not trivial and thus may take (a lot of) time and effort. Furthermore, existing drivers (or rather their capability descriptions) in volumio’s system may need to be reset and replaced, which may or may not involve user action.

There’s another thing to be aware of: I’ve noticed with several DACs that there can be a discrepancy with what’s being displayed on the DAC screen and what the DAC chip is actually doing. So it is entirely possible that the DAC displays the incoming stream as PCM (from the interface) but is in reality working in DSD128 (through DoP) mode. This disparity can sometimes be observed under Windows 10, comparing the data on the Thesycon driver panel (or, better, the Thesycon USB Spy utility if it’s included) to the DAC display. After all, in DoP mode, the actual DSD stream is wrapped in a PCM container. To make matters worse, some systems don’t care what the PCM stream contains in terms of bit-length/sample rate as it is discarded anyway. Worse still, there are several different (incompatible) ways to wrap DSD as DoP in a PCM stream.

Best regards, marco

#12

This is weird, I never built an image for cubox with version 2.513 :astonished:
Actually I don’t think I have done an image for cubox since the middle of the year…
But… look no further, since today there is one: volumio-2.518-2018-12-22-cuboxi
myVolumio has not been integrated yet, I’ll do that a next time.

However, this does not solve the nuprime dac-9 issue, because that would mean I need to patch and recompile the kernel.
Normally not an issue (I know how and where to patch) but with cubox, the kernel is not ours.
The one we used is maintained by the Armbian team.
Last time I tried, their current version did not boot on cubox i4.

Please put a request in the Cubox section of the Community Portings for a new version and the Thesycon patch.
Armbian is on 4.14.90 now and perhaps they fixed a few things.
No guarantee this will be done soon, there are other issues on the backlog with a higher priority :wink:
Please follow up in the Community Portings thread, not here…

#13

This patch is in kernel 4.19.y, so as far as x86 is concerned, we should be ok with the upcoming Debian stretch beta for Volumio. It will be based on 4.19.y as it is an LTS release (currently 4.19.12).
Thesycon has vendor id 0x152a, which differs from normal XMOS (0x20b1).

I have worked out the patch for 4.14.90 in case we want to backport it.
Testing it for the next cubox version.

#14

Thanks for letting us know. It is a bit weird that there are two different ID’s for basically the same drivers. Almost all ‘contemporary’ XMOS USB interfaces use a Thesycon driver. However, DAC manufacturers can have their ‘own’ version of the drivers, these are slightly tweaked versions of the ‘standard’ Thesycon driver. Some manufacturers use this in their marketing (“customized Thesycon driver”). The drivers (under Windows at least) also facilitate firmware updates.

Anyway, thanks for your efforts!

Best regards, marco

#15

Sorry, your assumption is wrong, it is the other way round.
Check the XMOS site and their licensing rules, you will see XMOS is not equal to Thesycon.
A lot of devices will be licensed to use the xmos vendor id, but they do leave room for vendor specific id’s.

#16

This is slightly getting off-topic, OTOH it may clarify that not all is what it seems.
Sorry, but I don’t think I’m mistaken. Yes, I know they are two separate, independent companies (UK vs Germany). I own several different XMOS based DACs (7 in fact), of which some have a ‘generic’ Thesycon driver, branded as such (e.g. Xduoo) with the Thesycon name, icon, etc., and others that have branded their Thesycon driver with their own name, logo, icons etc. If you look up Topping D10 on aliexpress, for instance, you will see that it comes with a ‘custom Thesycon driver’ as they put it. And I have yet to see a consumer DAC with a ‘contemporary’ XMOS USB interface (by contemporary I mean the newer XMOS implementations for native DSD128/DxD and up support), that does not have a Thesycon driver.

At least, this is the situation under Windows. I don’t know about Linux, and I think that that accounts for your comments, as that is probably your perspective. Under Linux, the situation will be much different, as I don’t think the XMOS/Thesycon ‘driver’ comes with the Thesycon tools such as TUSBAudioDfu (for firmware updates), TUSBAudioSpy (which monitors what’s going on on the USB bus the DAC is connected to, in great detail) and the ASIO driver, not to mention full native DSD support. To my mind, the Linux situation is much less transparent than Windows’. The newer Windows 10 versions with UAC 2.0 implemented, is a different story: you don’t get all the extras mentioned above either, with the exception of full native DSD support, but I’m impressed with the level of USB DAC support. There doesn’t seem to be a problem with any XMOS/Thesycon based DAC I have tried with just the Windows UAC 2.0 implementation.

With regard to licensing agreements, it is very possible to have ‘generic’ ones and specific agreements between two companies; big companies have their own purchasing rules/agreements that may override (aspects of) the generic licensing in a specific agreement. Think Denon/Marantz, Panasonic etc., if you want to do business with those guys, you will have to bend to their rules instead. In the end, it’s all about money.

#17

I agree with you about Windows and the software tools you get with it, also that an XMOS driver driver can very well be Thesycon’s.
Still, the vendor id used is mostly from XMOS, each with a different product id.
The only exceptions I’m aware of are Thesycon and Mytek devices.
Sorry for not being clear.

#18

Yes, that is actually the problem: the varying vendor IDs. I think you can add iFi (some or all, I don’t know) to the exceptions as well, though I’m not 100% sure. Just out of curiosity: have you come across a recent XMOS equipped DAC without a Thesycon driver? That would complicate matters even further for you developers.
It would seem that Thesycon has a monopoly when it comes to driving XMOS USB interfaces. Never a good thing.

Any way, I greatly appreciate the effort & time you’re all investing in this topic, and in Volumio as a whole.

Thanks & cheers,
Marco

#19

The situation is less complex as we only develop for linux and deal with a generic driver for usb audio devices.
This does not mean we don’t have issues as each DSD-direct capable XMOS device needs to be known to the kernel.
It is currently hardcoded in a “quirks” module.
For kernel 4.19 the list of registered DSD devices is already quite comprehensive (the iFi’s are also included).
I’m trying to add all these supported devices to the HK kernel next month.

#20

I too have a number of DSD capable DACs, Arcam IRDAC II and most recently a Roksan K3 Kandy. There’s no indication on the IRDAC whether its receiving PCM or DSD, but the Roksan has a DSD indicator which does not light when I playback DSD files. I asked Roksan why and they replied:
[i]Please see the below from the technical department:

I have read that USB drivers are built into the Linux kernel, some people are rebuilding some distributions to support DSD. The DAC Vendor & Product ID need to be added to the kernel drivers with Volumio. Without that, Linux won’t recognise the DAC so you are unlikely to get anything.

USB Vendor ID: 0x152A
Product ID: 0x85D2
[/i]
which made no sense to me until I found this thread. So is there anyway to tell

  1. if the IRDAC II and Kandy are currently / planned to be added to the Kernel
  2. if the MDAC+ previously mentioned in the thread is currently / planned ? (I’m thinking of buying a M-ONE which I understand uses the same input as the MDAC+ - course that might just be manufacturer’s hype!

As a general observation - if the makers of DACs are going to economise on displays (even a simple LED!) is there any way to establish exactly what volumio (via mpd & aplay if my analysis is correct) is actually sending down the wire (as opposed to reading off the media).

Many thanks for the product in general and especially if we can get this working too!