RaspBerry PI - The Audio Engine - Part 6 - DSD

Now, I'd like to show you how to get  DSD (Direct Stream Digital) working... 

Scope of article

I'll talk about 

  • DSD-native vs. DoP (DSD over PCM) and 
  • DSD related file formats 
  • system requirements 
  • limitations
  • setup and finetuning - a HowTo based on LMS & pCP 


The audio crowd seems to be pretty divided about DSD DSD always was and still is a niche audio format.  
There are pros and cons - as usual.
A rather small community is considering it a must-have-feature for audiophile audio playback systems. I own some DSD tracks and albums. To me it would be very difficult to associate any of the experienced sound qualities to the DSD format, especially in times where other HD audio formats are available and even every remastered CD sounds "sooo" much better. 
There are so many more, too many, factors that could make a (the) difference...

Beside that there are some factors that really let me question the whole DSD hype:

  1. Lack of material 
  2. Utilization of resources  (-> puts high load on systems and networks)
  3. Increased complexity in playback chain
  4. During the mastering process DSD will be converted to DxD - guess what - a PCM format. Then, why not listening to a DxD master!?!? 
  5. ..and more

Many DAC manufacturers must have DSD onboard though. And that's IMO mostly for competitive/marketing reasons.
The vast majority of users out there simply enjoy (HD-)PCM and will continue to do so.

However. Since we have the DSD feature on many DACs available and our platforms also support it, why not having a closer look at it and make it accessible. It won't cost us a dime.

This exercise will show you how to get DSD working on your LogitechMediaServer (LMS) -  squeezelite audio streaming environment.  

DSD Technology

DSD is a delta-sigma modulated 1bit audio-data format (more on Wikipedia). 
It offers samplerates starting at 2.8224Mhz (DSD64) to 45.2Mhz (DSD1024).
DSD512 and DSD1024 are more of theoretical nature due to the lack of material and rather insane HW requirements. 
Even DSD256 can IMO be considered overkill. You hardly find any DSD256 material out there.

How do we get these DSD data down to the DAC?

DSD File Formats

To store DSD audio tracks two different file types are used:
  1. Digital Interchange File Format (DSDIFF)suffix: .DFF (uncompressed, no metadata support)
  2. Direct Stream Transfer (DST)suffix: .DSF (lossless compressed, metadata support)
Most widely used is the .DSF format.

DSD Processing

There are two ways to process or stream DSD data. 
  1. DSD-native 
  2. DoP (DSD over PCM)


The .DSF file will be streamed down to the DAC AS-IS. It requires a DSD-native streaming/playback chain to get DSD-native working
Applications and drivers need to support the DSD related features throughout the chain.
And it requires 100% bit transparency. Not a single bit can change on the way down.

That's not as trivial as it might sound in a 99,9% PCM world! 

DSD-native increases the complexity of the playback chain. Compatibility issues were and still are a common obstacle. 

This basically lead to the... 


DoP basically is DSD wrapped into PCM format. PCM is used as a container. From the outside a DoP track looks like a ".wav" or ".flac" track, from the inside it's DSD. 

DoP has been developed to make use of a given PCM infrastructure. The entire digital chain treats a DoP track as PCM. That'll avoid most compatibility issues.
Only the DAC will then figure out that he's looking at a DoP stream and extracts the DSD data from the incoming stream.

DoP is quite an inefficient format though, even more inefficient then DSD-native. DoP requires double the bandwidth compared to DSD-native for the same DSD data. 
E.g. DoP128 requires a PCM rate of 352.8kHz, while DSD128 requires a bandwidth of just 176.4kHz. 

WARNING: Trying to play a DSD filled .flac or .wav  (DoP) as normal PCM audio file on a DAC that doesn't support DoP, will generate pretty nasty and potentially dangerous 0dB=100% noise on your system and ears. 
You better try to avoid it!  If your chain is not properly set or working this can also happen! 
You better make sure you've turned down your ANALOG volume controls before you start testing! 


What both modes - DoP and DSD-native - have in common: 

The filesize of DSD-native/DoP tracks can get insane. It quickly gets you into the GByte region for a single track!! 
Processing such a monster track puts a lot of load on the entire chain.

There can't be any digital volume control or DSP (filters/convolution/equalizer) in the path down to the DAC!  You'd simply corrupt the DSD data stream. DSD demands bit-perfect data down to the DAC! 

Even mastering studios, while producing and mixing a track must convert the DSD tracks to DxD - a PCM format  -  for post-processing purposes. It simply requires PCM for applying any DSP to DSD!

With DSD it would typically require a volume control after the DAC chip - in the analog domain - to comply to the DO-NOT-TOUCH-DSD stream demand.

That brings us to another subject.

TrueDSD vs. 1-bit PCM

Yep. There are some very smart people out there, realizing that in modern times the lack of digital volume control would hardly be acceptable by the vast majority of users.

Guess what. Some DACs somehow do offer digital volume control for DSD!! How's that!?!? 

I use two terms describing it

  • TrueDSD
  • 1-bit PCM

TrueDSD is and stays DSD.  The DO-NOT-TOUCH-DSD rule applies. That's supplied by e.g. Burr Brown DACs.

And then there seems to be a 1-bit PCM method out there. That method seems to be
implemented (or even developed) by ESS for the Sabre DACs. 
Bringing the DSD stream back in the PCM domain before DA conversion somehow allows them to apply digital volume control. 
Are we still talking about a DSD DAC? Or just a DAC supporting DSD playback?

DACs for RPI supporting DSD  

Basically there are two types of DACs that can be used on a RPi. 

  1. I2S-HAT DACs and 
  2. USB DACs. 
  3. ...(let's skip HDMI or Bluetooth options)
Out of these two groups you'll find DACs supporting DSD playback


Pretty much all HAT DACs are connected via I2S right to the SOC. 
I2S is made for PCM formats only. And that's why I2S-HAT DSD DACs can support DoP only.  

As mentioned before, DoP is treated like PCM and it'll look like PCM, even if transferred over I2S. That DoP stream taken from I2S will than get converted to DSD by an on-DAC MCU (microcomputer) or the DAC chip itself.

That brings us to the samplerate limitations. 

I2S-HAT DSD DACS samplerate limitations

The RPI I2S interface is limited to 384kHz.   

  • DoP64   requires 176.4kHz 
  • DoP128 requires 352.8kHz

And that explains why DoP128 is the limit for a I2S-HAT DSD DAC.


We meanwhile know why DSD-native works on DSD capable USB-DACs only? Don't we?
Yep. Because it won't work on I2S-HATs! Ok. That's one conclusion.
Internally USB DACs don't have to stick to the I2S bus. The USB receiver chip recognizes
the type of data and simply switches from PCM (I2S) to DSD (serial connection) mode. 

So far I tested rates up to DSD512. I do recommend to stay at DSD256 max. 

At one point the RPI is just to weak to cope with these high data rates and related load conditions. 
As you might recall ethernet and USB (USB2.0) are shared on a RPI. Just a single USB2.0 pipe is used towards the SOC. You'll have in- and outgoing traffic at the same time on that narrow USB2.0 pipe. That's what I call a major bottleneck. You'll for sure will hit XRUNS, clicks and pops at one point. 
To get your system properly working at DSD256 demands already quite some patience in many cases. 

TrueDSD vs. 1-bit PCM

Once the DSD data is unwrapped from DoP - you might call it DSD-native at that point - it gets fed to the DAC chip. 

And here comes another topic. The way DSD-native is treated by different DACs differs big time.  E.g. take ESS Sabre. After reading this or that about it, I got the impression that the DSD data somehow get converted to 1-bit PCM on Sabre DACs.  (Please, don't nail me on that!)  They use some kind of trick here to use the PCM infrastructure.
And that would explain why digital volume 
control still works on DSD with the Sabre ES9038 series. Can this be called true-DSD then?!?!? Hmmh. I'm not sure.

I do know that e.g. iFi uses Burr Brown DAC chips that are processing DSD data as a true-DSD stream. That's why they don't/can't offer digital volume control. 


All RPI I2S-HAT DACs which support DSD, can run DoP at best. Which still doesn't mean they are TrueDSD DACs!

The Audiophonics I-Sabre ES9038Q2M or the Allo Katana, both are Sabre ES9038Q2M based DACs, would match that segment.

The RPI I2S allows DoP128 max. if 352,8 kHz samplerates are supported by the audio
HAT setup. Using e.g. the Allo Isolator HAT (192kHz max) would limit you to DoP64!

If we want to run DSD-native in TrueDSD or 1-bit-PCM there's no way to get around a USB DAC. And here the limits will be set by the RPI processing capabilities. Streaming DSD IN
over Ethernet and OUT over the same bus towards the USB DAC is causing a hell lot of stress to the system.

Luckily I have three DACs at hand to test pretty much all possible scenarios

  1. TrueDSD - iFi nano iOne - USB
  2. DoP - Audiophonics iSabre 9038Q2M - I2S
  3. DSD2PCM - Allo Boss - I2S

iFi, Audiophonics and Allo generously supported me with these devices to do integration work and integration testing on Moode and piCorePlayer. 
And I use them to design and test my system optimizations. 
And of course all these devices are used to support me writing this and other articles.


How do we get DSD playback going !?!?

Playback Modes

There are basically three ways for DSD track playback within the LMS - squeezelite environment.

  1. LMS converts DSD-native and streams PCM 
  2. LMS converts DSD-native and streams DoP
  3. LMS streams  DSD-native

These 3 options would cover playback for any DSD file on pretty much all DACs out there.

  1.  up to 384kHz PCM -> PCM capable I2S-DACs.
  2.  up to DSD128 -> DoP capable DACs
  3.  up to DSD256 -> DSD-native capable USB-DACs

DSD Chain Setup

There are 7 locations where to do some configurations and adjustments.

  1. pCP -> squeezelite -> binaries -> squeezelite-DSD
  2. pCP -> squeezelite -> codecs
  3. pCP -> squeezelite  -> DSD settings -> DoP/DSD-native
  4. Optional: pCP -> squeezelite  -> buffersettings
  5. LMS -> Plugins  -> Plugin activation
  6. LMS ->Advanced -> FileTypes ->DFF/DSF routing
  7. LMS -> Player ->DSD -> DoP and DSD2PCM conversion settings
  8. LMS ->Advanced -> FileTypes ->DFF/DSF routing

We need to setup pCP - the streaming client first. This way LMS will recognize the DSD capabilities of the streaming client during the LMS setup process.

DSD - pCP Squeezelite binary setup

I assume your audio interface is properly working on PCM at this point in time!

Let's prepare for the DSD setup.

First we need to enable the DSD capable squeezelite binary. Simply select DSD Squeezelite and press "Set Binary". squeezelite will then be restarted. 

DSD - pCP Squeezelite codec setup

The DSD binary comes with a new codec. It's called "dsd".

If the codec setting fields, as shown in below screenshot,  are empty, "dsd" will be active by default. Nothing to be done.
However. If you have followed this blog you might added "pcm,flac,mp3" to the "Restrict Codec Setting field". At this point you could simply add dsd, "pcm,flac,mp3,dsd" to the "Restrict Codec Setting field"

DSD - pCP Squeezelite DSD settings

At this point we'll set the DSD support and DSD mode for squeezelite.

To enable  the DSD support we need to add "-D" to squeezelite.

By adding just "-D" squeezelite will enter the "DoP" mode. That's it.

Actually that's almost it.

When playing back mixed PCM/DSD playlists you might experience 
a kind of statics or pop noise between the tracks. Adding a tiny break
helps avoiding this.  squeezelite offers a DSD delay parameter for that.
It's given in milliseconds. You'd add e.g. "-D 3" for a 3ms delay. That's about the
order (+-/2ms) that should work.

Now comes the crucial parameter to activate DSD-native support. 
There are several DSD-native formatting options offered by squeezelite

u8, u16le, u16be, u32le or u32be

I hear you !?!? How do I figure out what to use for my DACs !?!? Trial and Error!

Start with ":u32be" if the manufacturer hasn't communicated anything around this. 
If that doesn't work run the "trial and error" method and try each of them.

The iFi nano iOne is e.g. working with ":u32be".

DSD - squeezelite buffer settings

We need to have a look at two further fields

"Buffer size settings"
"Alsa Setting"

The "Buffer size settings" cover two buffers. The streaming buffer and the output buffer.  

As you might have noticed in the screenshot I decreased the output buffersize to 60MB. The DSD files are that big that full-file RAM buffering would be impossible to accomplish. The output buffer is used to buffer the fully processed data stream data - just to mention it.

The first field in the "Alsa Setting" row reflects the "Alsa Buffer" size. That's the buffer being used between the actual audio driver and the audio device. 

That's an important buffer. Usually these buffer settings impact XRUNS, clicks etc.

I suggest for to start with

I2S-HAT DSD DACs -> 65536


If you experience issues try to play around with these values. The I2S buffer is given in bits btw. And the USB DAC buffer in ms. USB DACs need much larger buffer sizes.

DSD - HW Volume Control 

To make use of the digital HW volume control of your DAC you need to activate it. 
You need to tell LMS/squeezelite what control to use. 
As mentioned that'll work on DSD DACs that support DSD volume control. In this case the Audiophonics 9038Q2M DAC. 

The "Alsa volume control" field needs the mixer entry "Digital". And that's for the Audiophonics DAC only! Your DAC might need a different entry!

That'll be it.

Don't forget to SAVE your changes.

LMS DSD setup

Let's have a look at the LMS side. 


LMS comes with a 3rd Party plugin called DSDPlayer. That one covers the whole
DSD handling inside the streaming environment.

First we need to activate the DSDPlayer plugin.

DSD - LMS File Routing

Then we make sure that the .DSF/.DFF file format routings are properly set.

As you can see. .DFF and .DSF are differentiated. The current settings means

  • DFF and DSF streams are routed & streamed as-is "native" to DSD-native capable clients.
  • DFF and DSF streams are routed & streamed as .flac. And that's the case for either DoP or DSD2PCM files.
That'll be it over here. Next.

DSD - LMS Player Setup

And finally we check if our Player (client) has the right mode activated.

There are now 3 options available.


As you can see above. You'll have to enable DSD-over-PCM for your DoP capable DAC.
That'd be the case for e.g. Audiophonics iSabre9038Q2M or Allo Katana.


If you now want to convert your DSD files to PCM on the fly, for DACs not supporting DSD at all, you can do it this way.

You'll be able to set the quality parameters of the conversion process.


As you can see. The plugin detects automatically what mode your player is in.
There's nothing to be done.

Wrap UP

Let's have a look at the LMS playback panel. As you can see I loaded a DSD256 file
to play it back in DSD-native on the iFi DAC. And it worked!

You might also notice in above screenshot that the volume control is in its lowest position = OFF.  It's done by the system automatically on DSD-native DACs.

Just as  a comparison the Audiophonics DAC in DoP mode. I loaded a DSD128 track.

And guess what. It also worked.

The volume control as indicated above acts normal because there's a Sabre DAC involved.

Finally. You're set and you'll be on your own from now on.

DSD Test Material

How about DSD test material? Do you own DSD tracks?
You'll find plenty of nice real music test tracks over here for download.

Final words

I hope I could fulfill my objectives. Getting DSD to work is quiet a task. Writing it all up is 
quite a project. 
I really hope you can make some use of it. Otherwise the efforts would have been wasted.

A final remark. 
DSD playback, DSD-native in particular, causes a lot of load on the RPI. Because you have to use a USB DAC for that. You'll have a single USB2.0 pipe for in-and outbound traffic. 
You might look at XRUNS, clicks and pops. And you'll have difficulties to get rid of them. 
If you're really looking into higher rate DSD or DSD-native playback, I'd suggest to opt for an e.g. Intel NUC with a very fast SSD inside instead of RPI. 

Ooookay. I think we're all set.  Again thx to iFi, Audiophonics and Allo , the piCorePlayer team and the LMS crowd for making this exercise possible.