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:
- Lack of material
- Utilization of resources (-> puts high load on systems and networks)
- Increased complexity in playback chain
- Lack of SW volume control (in most setups)
- During the mastering process DSD will be converted to DxD - guess what - a PCM format. Then, why not listening to a DxD master!?!?
- ..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:
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.
- Digital Interchange File Format (DSDIFF)
suffix: .DFF (uncompressed, no metadata support) - 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.- DSD-native
- 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.
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.
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.
Guess what. Some DACs somehow do offer digital volume control for DSD!! How's that!?!?
I use two terms describing it
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.
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.
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.
- I2S-HAT DACs and
- USB DACs.
Within these two groups you'll find DACs supporting DSD playback.
I2S-HAT DSD DACs
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.
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.
And that explains why DoP128 is the limit for a I2S-HAT DSD DAC. DoP256 simply wouldn't work.
- DoP64 requires 176.4kHz
- DoP128 requires 352.8kHz
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
- TrueDSD - iFi nano iOne - USB
- DoP - Audiophonics iSabre 9038Q2M or Allo Katana - I2S
- 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.
- LMS converts DSD-native and streams PCM
- LMS converts DSD-native and streams DoP
- LMS streams DSD-native
These 3 options would cover playback for any DSD file on pretty much all DACs out there.
- up to 384kHz PCM -> PCM capable I2S-DACs.
- up to DSD128 -> DoP capable DACs
- up to DSD256 -> DSD-native capable USB-DACs
DSD Chain Setup
- pCP -> squeezelite -> binaries -> squeezelite-DSD
- pCP -> squeezelite -> codecs
- pCP -> squeezelite -> DSD settings -> DoP/DSD-native
- Optional: pCP -> squeezelite -> buffersettings
- LMS -> Plugins -> Plugin activation
- LMS ->Advanced -> FileTypes ->DFF/DSF routing
- LMS -> Player ->DSD -> DoP and DSD2PCM conversion settings
- 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
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 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
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.
When playing back mixed PCM/DSD playlists you might experience
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.
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.
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".
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.
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
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.
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.
Then we make sure that the .DSF/.DFF file format routings are properly set.
DSD-Plugin
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
And finally we check if our Player (client) has the right mode activated.
There are now 3 options available.
- 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.
Enjoy.
I have been trying to get DSD running. I have the latest PiCorePlayer installed, but I do not have the Squeezelite binary option for DSD. What version of PCP is your example from?
ReplyDeleteThere's no separate DSD binary anymore. I introduced a note to the text.
ReplyDelete