DSD streaming - a guideline

Latest Update: 2024 - December - 27th

Several people have reached out to me about issues setting up and enabling DSD playback in a Lyrion Media Server (LMS) and Squeezelite streaming environment. Honestly, I’m not surprised—it’s not exactly straightforward. Even as an experienced user, it took me quite a while to figure everything out. Since you’re unlikely to find a similar guide online, I’ve decided to share my findings with you all to save you the trouble.

Enjoy!

As usual.  Before you start make sure you've got all your streaming environment upd2date.

########

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

Objective

I'll talk about 

• DSD-native vs. DoP (DSD over PCM) and 
• DSD related file formats 
• system requirements 
• limitations
• setup and fine tuning - a HowTo related to LMS, piCorePlayer and squeezelite 

And I hope that all this helps you in getting DSD playback on your LMS-squeezelite setup going.

Introduction

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 do own some DSD tracks and albums. To me it would be very difficult to associate any of the experienced sound qualities or differences to the DSD format, especially in times where other HD audio formats are available and even every remastered CD sounds "sooo" much better then the one before. 

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

1. Lack of material 
2. Utilization of resources  (-> puts high load on systems and networks)
3. Increased complexity in playback chain
4. Lack of SW volume control (in most setups)
5. No True DSD - During the mastering process DSD recordings will be converted to DxD - guess what - a PCM format, and then converted back to DSD. At that point there are 2 conversions
   done. 
6. ..and yes there'd be more stuff to consider, I leave it at this though

Many DAC manufacturers are forced by the market to have DSD onboard though. Basically for competitive/marketing reasons. If you don't have it you're out. But you know the drill. It's not just DSD. 
Bottom line. The vast majority of listeners out there simply enjoy (HD-)PCM and will continue to do so. DSD remains a niche market.

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 at least accessible. It won't cost us a dime. And we get to know what the hype (!?!??) is all about.

This exercise will show you how to get DSD working within your Lyrion Media Server (LMS) -  squeezelite audio streaming environment.  

DSD Technology

Let's start with some background info. Always good to have that knowledge in the background.

DSD is a delta-sigma modulated 1bit audio-data format (more on Wikipedia). 
It supports 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.

Now we've got the formats and files. 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 though.

DSD Processing

There are two ways to process or stream DSD data. 

1. DSD-native 
2. DoP (DSD over PCM)

DSD-native

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. This would corrupt the whole stream.


And becoming 100% bit-transparent is 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  common obstacles. That's why you're here I guess. 

All this basically led to... 

DoP - DSD over PCM

DoP 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. You could consider it a Trojan DSD horse.

DoP was 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. Still. Not a single bit can be changed down to the DAC!
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 avoid it!  If your chain is not properly set or working this can also happen! 

Make sure you've turned down your ANALOG volume controls before you start testing! 

Commonalities

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

The files of DSD-native/DoP tracks can get insanely large. 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 digital processing and manipulation!

With DSD it would typically require a volume control after the DAC chip - in the analog domain - to comply to the DO-NOT-TOUCH-A-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 remains DSD. The DO-NOT-TOUCH-DSD rule still applies.
TrueDSD support is offered 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. A nice trick. 
Are we still talking about a DSD DAC? Or just a DAC supporting DSD playback? That's why I call it a 1-bit PCM DAC.

DACs for RPI supporting DSD  

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

1. I2S-HAT DACs and 
2. USB DACs. 

Within these two groups you'll find plenty of DACs supporting DSD playback.

I2S-HAT DSD DACs

Pretty much all HAT DACs are connected via I2S right to the SOC (CPU chip). 

The I2S interface supports the PCM format only. That's why DoP is a must to feed DSD audio data to a DSD capable I2S-HAT.  

As mentioned before, DoP is treated like PCM and it'll look like PCM, even if transferred over I2S. The DoP stream that's been transferred over I2S, will than have to get converted to DSD after leaving I2S right inside the DAC chip itself. As an alternative a MCU (microcomputer) on the HAT could be fed with I2S and could run the DoP/DSD conversion and would further feed the native DSD data to a DSD capable DAC chip.


That brings us to the limitations. 

I2S-HAT DSD DACS samplerate limitations

The RPI I2S interface is limited to 384kHz.   Not even all HATs support 384kHz (e.g. Allo Boss2)!

That leaves us with

• DoP64   requires 176.4kHz PCM
• DoP128 requires 352.8kHz PCM

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

DoP256 simply doesn't work! 

USB DSD-DACs

Meanwhile we 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 or an internal MCU recognizes the type of data and simply switches from PCM (I2S) to DSD (serial connection) mode towards the DAC chip. 

The USB DACs with their special purpose receiver chips and internal structures can handle much higher samplerates, than the RPi SOC. If you really look for DSD256+ on the RPI, USB is a must. 

So far I tested rates up to DSD256. 

The introduction of the RPi 4 with USB 3.0 and Gbit ethernet made life regarding DSD playback much easier. In that area we see a night and day difference compared to the RPi4s predecessors. Not to forget more RAM will also improve the handling of data in the GByte area. 

If you look for serious DSD playback, skip the DoP HATs and use a DSD capable USB DAC attached to a RPi4!

As you might recall ethernet and USB (USB2.0) are shared on a RPis <= version 3B+. 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. Nope. No fun. The RPi 4 runs a (single) PCI lane now and also separates USB and ethernet. For those of you who get serious about DSD, consider the RPi 4 as the device of choice!

Summary

All RPI I2S-HAT DACs which support DSD, can run DoP only. No TrueDSD!

The Audiophonics I-Sabre ES9038Q2M or the Allo Katana, both are Sabre ES9038Q2M based DACs, or Allo Boss2 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) or the Boss2 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.


I have only a few DACs at hand to test pretty much all possible scenarios

1. TrueDSD - iFi nano iOne - USB
2. DoP - Allo Katana - I2S     (unfortunately too complex)

      (3.) Audiophonics iSabre 9038Q2M
            It's of no use since quite some time. There've been serious firmware issues with this DAC!
            Audiophonics didn't intend to replace it.

iFi, Allo ( and Audiophonics !?!?) generously supported me with these devices to be able to do design and integration work for several projects that I've been supporting - such as Moode and piCorePlayer or the Audiophonics kernel driver integration. Thx for that. Would be nice if any of those could provide an up-2-date  replacement DAC for continuing doing testing.  

Finally. 

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.

Recent squeezelite versions of pCP have DSD binary by default. You can use it as is.

DSD - pCP Squeezelite codec setup

The DSD capable 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. There's nothing more to be done.
However. If you have followed this blog you might have 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"

Now. If you have just a DoP capable DAC, try this:

Note: 23May2021: There's a bug inside pCP. In above shown DSD field the <delay> parameter is not optional! The field requires at least a "0" value to be specified.

I reported this to Paul from pCP and he will fix it in the next release.

DSD - pCP Squeezelite DSD settings

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

To enable DSD native support we need to set the DSD formatting parameter as shown above.

To enable DoP, replace "u32be" with "dop".

Actually that's almost it.

When playing back mixed PCM/DSD/DoP playlists you might experience 

a kind of static pulse 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. The above screenshot shows a 3ms delay.
That's about the ballpark (+-/1ms) that should help to get rid of the noise.

Now comes the crucial parameter to activate DSD-native support. 

There are several DSD-native formatting options offered by squeezelite

dop, 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 DAC manufacturer hasn't communicated anything specific about it. 

If that doesn't work run the "trial and error" method and try each of them.

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

DSD - squeezelite buffer settings

We need to have a look at two more fields now

"Buffer size settings"

"Alsa Setting"

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

As you might have noticed in the screenshot above, I changed the streaming and output buffer sizes from earlier recommendations. It's now 50MB for the streaming buffer and 300MB for the output buffer. This simply worked. For sure there are more or even better settings.

The output buffer is used to buffer the fully processed data stream data, before these hit the Alsa output layer and device driver - just to mention it once more.
I had to increase the output buffer because I was experiencing stuttering on native DSD256 streams.

If you experience issues try playing around with these buffers.

NOTE: The DSD files are that big that full-file RAM buffering is pretty much impossible to accomplish.

Let's have a look at the Alsa - the Linux soundlayer - settings. 

The first field in the squeezelite "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 the Alsa output buffer settings play a role when facing rather short, clicks, scratching or similar (so called XRUNS) during playback.

I suggest for to start with

I2S-HAT DSD DACs -> 65536

USB DSD DACS -> 160

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 so called volume control mixer control (as shown in amixer or alsamixer) to use. 

As mentioned that'll work on DSD DACs that support DSD volume control. In this case the Audiophonics 9038Q2M DAC or Allo Katana. 

The "Alsa volume control" field needs the mixer entry "Digital". And that's for the Audiophonics DAC only! The Katana would require "Master". And your DAC might need another entry!

That'll be it.

Don't forget to SAVE your changes.

LMS DSD setup

Let's have a look at the LMS side. 

DSD-Plugin

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.

DoP

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.


DSD2PCM

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.
If you run an RPI , even a RPi4, as server, I wouldn't recommend to run this configurations.

You'll face pretty high load conditions.

DSD-Native 

As you can see below. The plugin detects automatically what mode your player is in. Below shows

the iFi DAC being attached.

There's nothing to be done.

Make sure that your volume control is set to 100% and crossfade is disabled for DSD native and DoP DACs without software volume control, as shown below.

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. As you can see  - it works!

You might also notice in above screenshot that the volume control is in its lowest position = OFF.  

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 the Audiophonics DAC comes with a ESS Sabre DAC inside that allows software volume control on DsD.

DSD Test Material

How about DSD test material? Do you actually own some DSD tracks?

You'll find plenty of HQ DSD test tracks over here@2L for download.

Final words

Getting DSD to work is quite a task. 

(Figuring it all out and writing it all up turns into quite a project. ;) )

 

I really hope that you can make some use (and sense out)  of the article. 

Again. Keep in mind. DSD playback, DSD-native in particular, causes a lot of load on the RPI. 

All predecessors before RPi4 are IMO simply not suitable for DSD playback in a streaming environment. It gets worse if you decide to use a USB DAC on these old RPis.

Using the RPI4 is the much better choice. But even on the RPi4 resources are limited.

Even now with PCI in place, it's still just a single PCI lane that gets shared by all in-and outbound traffic (network and usb).

If you consider to run realtime DSD conversions (on the server), you can try it. From my experience heavy DSD duties is still not the strongest side of an RPi, even RPI4 based,  streaming environment.

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.

Enjoy.