Is DoP such a bad thing?

[Audio_ELF]

Your post does not make sense. There is no such thing as ALAC driver.

Sorry I (of course) meant ALSA where I wrote ALAC... I'll blame autocorrect though I suspect I was my brain autocorrecting :-)

 

So to ask the question again and hopefully make sense...

Does not the DAC need a specific DSD capable ALSA driver rather than a generic UAC2 driver to support "native" DSD via ALSA?

 

As I understand it UAC2 specifies PCM and doesn't support DSD which is part of the "problem" DoP was designed to solve.

 

I ask as I've never seen any "native" DSD under Linux but I only use Linux as a server to a squeezebox system currently rather than direct.

 

Edit/Addition: as I read it ALSA 1.0.27.1 added "native" DSD support for specific DAC utilising XMOS USB chipset; specifically the iFi and a HIFIMAN DAC. It's unclear (to me) if there is specific coding (as there would be for an ASIO driver) or if it's just a case of adding supported DACs hardware IDs. This native support is used by mPD 0.19.

 

Eloise

[Miska]

Edit/Addition: as I read it ALSA 1.0.27.1 added "native" DSD support for specific DAC utilising XMOS USB chipset; specifically the iFi and a HIFIMAN DAC. It's unclear (to me) if there is specific coding (as there would be for an ASIO driver) or if it's just a case of adding supported DACs hardware IDs.

 

And before that, there was support for Playback Designs DACs, added I think last spring or so. It is DoP-less and done such way that the DAC represents two different endpoints and the second one (normally unused) is used for native DSD.

[Ran]

ALSA is a framework to allow applications to send data to a sound device.

 

Advanced Linux Sound Architecture - Wikipedia, the free encyclopedia

 

ALSA gets the sound card listed from the kernel. Open a terminal and type:

 

aplay -l

 

This will provide a list of all the sound card ALSA can work with.

 

Any UAC2 DAC will be visible to the kernel (and ALSA) without the need to install any drivers as they are built in. You can see all the format supported by the kernel here:

 

https://github.com/torvalds/linux/blob/master/include/uapi/sound/asound.h#L177

 

Linux can send native DSD to any DSD DAC that support it. You can use MPD to send native, DoP or transcoded DSD to your DAC.

[Miska]

If you read the DoP on Standard guide, you can see that for DSD64 for every 16 bits of data, another 8 bits need to be transferred. Each time you increase the DSD rate this is doubled - so for DSD128 its 32bits of data and 16bits of headers (requiring 24/352.8 PCM), DSD256 would require PCM rate of 24/705.6; and for DSD512 you would have to support 24/1411.2

 

With Navive DSD the transfer rates are much lower (by 1/3).

 

In addition, many new DACs like Sabre are 32-bit input for PCM and for that and efficiency reasons USB interfaces like XMOS also use 32-bit sample format over USB. So in those cases there's one unused extra byte more. So per 32-bit PCM sample there's only 16-bit worth of useful data and the other half is useless header and padding. So 8 channels of DSD512 would be 345 Mbps (exceeds practical capacity of USB2).

[Miska]

Linux can send native DSD to any DSD DAC that support it. You can use MPD to send native, DoP or transcoded DSD to your DAC.

 

But there needs to be quirks added for every DAC that is known to support DSD over UAC to inform about end point and such. So the support is not automatic as there's no standard in the UAC to inform about DSD capability. It needs to be encoded per every USB VID:PID.

[Audio_ELF]

But there needs to be quirks added for every DAC that is known to support DSD over UAC to inform about end point and such. So the support is not automatic as there's no standard in the UAC to inform about DSD capability. It needs to be encoded per every USB VID:PID.

Written so much better than I could manage :-)

[ted_b]

Ap-Linux is a distro that uses ALSA for DSD and it's supported DAC list looks to be somewhat unrelated to XMOS (and not terribly large), weirdly enough. I, too was under the impression that if a DAC was UAC2 it would accept ALSA...but there are many DACs that I have successfully interfaced to the UAC2-friendly Auralic Aries (Chord Hugo, Vega, Directstream, EE Supreme, M2Tech Young DSD, etc) that are not on the AP-Linux list. I am somewhat confused.

 

Edit: Didn't see Miska's response. So do I read this as UAC2 (i.e "driverless Linux support") is only really true for DoP and that ALSA support needs more code; therefore the reason the AP-Linux list is a small subset? Thx

[Miska]

Miska, Your explanations are very good, thanks. I will reiterate though, that Dop vs ASIO is not a differentiator for the aforementioned format switching POP...it is about the DAC not muting enough (or what I referred to as format changes).

 

Yes, but the mode switching model is vastly different. Firmware developers seem to be having much more challenge doing it right with DoP and I can understand why.

 

So you don't think dc offset is involved in DSD playback? I've had more than one DSD dac that let a LOT of dc through, shutting down my amps (Modwright amps do not block dc but are brutally protected). One was a modification, one was a chipless design.

 

That can happen if software or firmware misbehaves, but I have not seen DSD content with significant DC. In my opinion DACs shouldn't leak DC ever. I have just plain DC blocking capacitors in my simpler designs. But my amp also removes any DC using a DC-servo.

[Ran]

Ap-Linux is a distro that uses ALSA for DSD and it's supported DAC list looks to be somewhat unrelated to XMOS (and not terribly large), weirdly enough. I, too was under the impression that if a DAC was UAC2 it would accept ALSA...but there are many DACs that I have successfully interfaced to the UAC2-friendly Auralic Aries (Chord Hugo, Vega, Directstream, EE Supreme, M2Tech Young DSD, etc) that are not on the AP-Linux list. I am somewhat confused.

 

Any DAC that supports the UAC2 standard will work with basically every Linux distro that came in the last couple of years. The list you mentioned in incomplete. Both the Vega and the Chord are UAC2 devices.

[Audio_ELF]

Any DAC that supports the UAC2 standard will work with basically every Linux distro that came in the last couple of years. The list you mentioned in incomplete. Both the Vega and the Chord are UAC2 devices.

Yes; but not necessarily with "native" DSD from my reading and what Miska said.

[Ran]

As far as I remember, the XMOS implementation was the odd one out and not the rule.

[Miska]

I, too was under the impression that if a DAC was UAC2 it would accept ALSA...but there are many DACs that I have successfully interfaced to the UAC2-friendly Auralic Aries (Chord Hugo, Vega, Directstream, EE Supreme, M2Tech Young DSD, etc) that are not on the AP-Linux list.

 

ALSA contains pretty huge set of drivers for different PCI/PCIe devices and quite many for USB. M2Tech interfaces are also supported by ALSA while they have nothing to do with UAC in terms of implementation. Then there are quirks for UAC-style devices that are almost like UAC but need some special handling (like EMU 0404 USB, etc).

 

So do I read this as UAC2 (i.e "driverless Linux support") is only really true for DoP and that ALSA support needs more code; therefore the reason the AP-Linux list is a small subset? Thx

 

Well, there's one driver for UAC and then there's a way to tech it about all kinds of peculiar vendor-specific hardware features (quirks). The driver needs to be teached about every implementation. At the moment there are three quirks for DSD support. I remembered incorrectly, the Playback Designs support was introduced already in summer 2013, time flies...

 

You can see here:

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/usb/quirks.c

Scroll down to the last function snd_usb_interface_dsd_format_quirks() and you can see how it is done and the comment above explaining it.

[lintweaker]

ALSA contains pretty huge set of drivers for different PCI/PCIe devices and quite many for USB. M2Tech interfaces are also supported by ALSA while they have nothing to do with UAC in terms of implementation. Then there are quirks for UAC-style devices that are almost like UAC but need some special handling (like EMU 0404 USB, etc).

 

 

 

Well, there's one driver for UAC and then there's a way to tech it about all kinds of peculiar vendor-specific hardware features (quirks). The driver needs to be teached about every implementation. At the moment there are three quirks for DSD support. I remembered incorrectly, the Playback Designs support was introduced already in summer 2013, time flies...

 

You can see here:

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/usb/quirks.c

Scroll down to the last function snd_usb_interface_dsd_format_quirks() and you can see how it is done and the comment above explaining it.

 

Good thread. Getting native DSD to work for all the various HW out there is a bit of a challange.

I just managed to get native DSD (ie without DoP) working for my Marantz SA-14S1 and HD-DAC1. More Marantz/Denon devices using the same USB hardware should be easy to add.

[Miska]

Good thread. Getting native DSD to work for all the various HW out there is a bit of a challange.

I just managed to get native DSD (ie without DoP) working for my Marantz SA-14S1 and HD-DAC1. More Marantz/Denon devices using the same USB hardware should be easy to add.

 

I got the new DSD_U32 format working with HQPlayer too, but only after couple of minutes wondering why I get noisy output. There seems to be a bug in the driver quirk. The format is BE not LE...

[lintweaker]

I got the new DSD_U32 format working with HQPlayer too, but only after couple of minutes wondering why I get noisy output. There seems to be a bug in the driver quirk. The format is BE not LE...

 

Nice, hopefully I can add support for more DACs soon.

we're discussing BE vs LE right now in ALSA devel list.

[Miska]

Now everything works nice and dandy. Thanks to lintweaker for the native DSD support!

 

I'm waiting for the new Marantz to become available in Finland, hopefully sooner than later...

[Sam Lord]

Thank you Eloise! Sorry for the late answer, I don't get notification of replies.

 

There is no heavy penalty for computation, but the packaging of DSD within PCM frames does create an overhead in terms of data usage/transfer especially where an interface is limited to 32bit.

 

If you read the DoP on Standard guide, you can see that for DSD64 for every 16 bits of data, another 8 bits need to be transferred. Each time you increase the DSD rate this is doubled - so for DSD128 its 32bits of data and 16bits of headers (requiring 24/352.8 PCM), DSD256 would require PCM rate of 24/705.6; and for DSD512 you would have to support 24/1411.2

With Native DSD the transfer rates are much lower (by 1/3)... ...

[cjf]

So as I read this I wonder why it matters if the DSD data is transported in native format (No DOP) or WITH DOP if the DAC still recives the same unmolested DSD signal to decode?

 

I can see a potential Interface bandwidth issue being one reason to use one over the other if you intend to try and find music at rates higher then DSD128 but beyond that I dont see why It matters? Am I missing something here?

 

I have a DAC that can accept the whole direct DSD thing, I think, without conversion to PCM (Mietner MA1) but until this post I wasn't aware of any media serving devices capable of sending such information without using DOP. I use Voyage Linux with the DOP line of code set to true in the MPD.conf file for what's its worth.

 

Maybe the reason I don't find DSD to be the second coming of Christ is because I don't have something configured correctly but it appears that my DAC does recognize the DSD content I send it via DOP and it also switches between PCM and DSD without Clicks.

 

Other then Michael Jacksons Thriller in DSD that I own I dont find the format to sound leaps and bounds better then PCM IMO.

[Ran]

Indeed. DSD is obviously not the second coming of anything. It is just another format to listen to. Some people prefer DSD, some PCM.

[Boris75]

 

So I ask, what is so heinous about DoP?

 

Nothing. Same data sent at the same timing, just coded differently.

[Starre]

"Other then Michael Jacksons Thriller in DSD that I own I dont find the format to sound leaps and bounds better then PCMIMO."

cjf: I prefer DSD with ma-1 but since it only play DSD64 and upsamle it to 128, I think that after the coming firmware/software update of ma-1, if it plays DSD128 it will sound better than PCM.

[YashN]

"Other then Michael Jacksons Thriller in DSD that I own I dont find the format to sound leaps and bounds better then PCMIMO."

cjf: I prefer DSD with ma-1 but since it only play DSD64 and upsamle it to 128, I think that after the coming firmware/software update of ma-1, if it plays DSD128 it will sound better than PCM.

 

Some people won't hear differences if the PCM is internally converted to DSD and then output as DSD2x -> Analog.

 

Not saying your DAC does that, but implementation differences can make the differences larger or smaller.

[Jabs1542]

It's also been implied that many DACs have a sweet spot - where they sample best. This may affect your preferences as well, I think my Lynx Hilo likes 24:192 and my Lampi likes DSD128.

[YashN]

my Lampi likes DSD128.

 

DSD 2x + Tubes is the real deal.

[spirosgon]

Good thread. Getting native DSD to work for all the various HW out there is a bit of a challange.

I just managed to get native DSD (ie without DoP) working for my Marantz SA-14S1 and HD-DAC1. More Marantz/Denon devices using the same USB hardware should be easy to add.

 

I've just bought the marantz hd-dac1 but I cannot configure foobar to play native dsd ...

 

I'm not inexperienced, before this I had an Audio-gd dac and played dsd through foobar flawlessly.

 

I have installed the foo_input_sacd from soundforge website, I choose foo_dsd_asio as foobar's output and the in the asio tab, I configure ''foo_dsd_asio'' to use the ''marantz audio device'' .... No matter if I choose ''asio native'' or ''dop'' in the following su-menu, I have no playback ...

 

Can you help ??