DSD streaming

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 finetuning - a HowTo based on LMS & pCP 

and would like to support 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 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 - beside DSD - 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. Lack of SW volume control (in most setups)
5. During the mastering process DSD will be converted to DxD - guess what - a PCM format. Then, why not listening to a DxD master!?!? 
6. ..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)

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.


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 led to... 

DoP

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. 

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. 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 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 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 mayor 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 DACs supporting DSD playback.

I2S-HAT DSD DACs

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 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. DoP256 simply wouldn'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 DSD512. 

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 its predecessors. Not to forget more RAM will also improve the handling of data in the GByte area. If USB DSD DAC, then go for RPi 4.

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 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, 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 several DACs at hand to test pretty much all possible scenarios

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

iFi, Audiophonics and Allo generously supported me with these devices to be able do design and integration work for several projects that I've been supporting - such as Moode and piCorePlayer or all my own little projects that I share with you. Thx for that.


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.

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

Note: Most recent pCP versions won't come with a separate DSD squeezelite binary anymore.

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"

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

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

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 about it. 

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 almost be impossible to accomplish. The output buffer is used to buffer the fully processed data stream data - just to mention it once more.

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

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. 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.

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.