Announce: piCorePlayer 8.0.0

[Man in a van]

Thanks for the link. Before I modified the squeezelite command to add the -R hLs -u E, the Audio Information for the input was "Direct PCM 192 kHz". After the modification it is "Direct PCM 176.4 kHz".
So, for my understanding, did this command change the rate to one that that AVR accepted? ('s' increased the bandwidth range?)

This might help

https://www.pcmag.com/encyclopedia/term/dop

If I remember correctly (which is hard for me sometimes )

At some time I saw a post similar to this



I expanded the dropdowns and noted the selections available, I then went to the Squeezelite man page, scrolled down to the Sox part at the bottom and worked things out from there, by trial and error. I ignored the flags part as that represented too much trial !!

The -R -u thing is just ignorance and laziness on my part, when I get something working I often just leave it alone, and then forget what I intended to do.

I "think" that "Direct PCM 192 kHz" might mean that all streams are resampled to that value, whilst "Direct PCM 176.4 kHz" means only the DoP streams.

You can maybe check on your dac, if you want

ronnie

[stereoptic]

I expanded the dropdowns and noted the selections available, I then went to the Squeezelite man page, scrolled down to the Sox part at the bottom and worked things out from there, by trial and error. I ignored the flags part as that represented too much trial !!

The -R -u thing is just ignorance and laziness on my part, when I get something working I often just leave it alone, and then forget what I intended to do.

I "think" that "Direct PCM 192 kHz" might mean that all streams are resampled to that value, whilst "Direct PCM 176.4 kHz" means only the DoP streams.

You can maybe check on your dac, if you want

ronnie

Ah, big thanks for that. That's a lot of trial and error. And as far as the "-R -u" thing, leave that for The Department of Redundancy Dept. !

[paul-]

So with the DSDPlayer plugin installed on LMS, there is no need to install the pcp-dsdplay extension on pCP. Right?

correct. Here is the plugin, note the included binaries. https://github.com/LMS-Community/plugin-DSDPlayer

[CJS]

2) Native DSD is not supported by any I2S dac. For RPI, it must be a USB Dac.

This weekend I have done some experiments with playback of DSD audio files (with .dsf or .dff file format) via LMS to my squeezebox players, and I have read information about DSD and DoP (DSD over PCM). I agree with you that native DSD is not supported by any I2S DAC.

However from what I have read, my understanding is that there are a few DACs on the market that support native DSD playback via DoP over SPDIF. So not only via DoP over USB. And that in practice DoP over SPDIF is limited to DSD64 streams, due to bandwidth limitations of the SPDIF/TOSLINK interface. My understanding is based on what I have read on a few audio forums, and on the following whitepaper: DoP_openStandard_1v1.pdf.

Do you agree with my observation, or do you think that I have misunderstood things? When you say that native DSD playback is only supported via USB, do you mean to say that DoP over SPDIF is not supported by pCP?

[paul-]

I don’t use DSD, so I’ve never tested anything, but following things over the years, I would agree with your statements. Not sure I would ever see the value in doing DoP, since it has to be converted. DoP is supported on pCP, where there is proper hardware. It’s just pcm, to pCP.

[CJS]

LMS incorrectly reports/detects that my pCP supports native playback of DSD files

When experimenting with playback of DSD audio files (with .dff and .dsf extension) on my squeezebox players, I encountered the issue that LMS incorrectly reports that my pCP supports native playback of DSD files. My piCorePlayer is a Raspberry Pi Zero W with Hifiberry DAC+ Zero HAT. This is a standard I2S DAC with TI PCM5101A DAC chip. So it is clear that my pCP does not support native playback of DSD files. However LMS > Settings > Player > pCP > DSDPlayer incorrectly reports otherwise, see screenshot below:



Since LMS thinks that my pCP supports native playback of DSD files, it sends the DSF stream to my pCP (i.e. without transcoding), which results in garbled audio playback.

It should be noted that I almost always get the wrong message shown in the screenshot above (at least 19 out of 20 times). However 1 time I got the following screen, of which I immediately took a screenshot:




My other players (SB Boom and ESP Muse) also don't support native DSD playback. This is correctly detected by LMS. See screenshot below for my ESP Muse player:



Question that I have:
1) Why does LMS detect that my pCP with I2S DAC supports native playback of DSD files? Is this a bug in piCorePlayer?
2) Is a setting available in pCP to inform LMS that pCP does NOT support native DSD playback? On the pCP Squeezelite Settings tab there is an option to tell pCP that the audio output device supports DSD/DoP. But I can't find an option to tell pCP that DSD/DoP is NOT supported.

Any suggestions? I know that I can force transcoding of DFF and DSF to FLAC under LMS > Settings > Advanced > File Types, by disabling native playback of DFF and DSF. Drawback of this workaround is that native DSD playback is then disabled for all players, which would be a pity for people that have a player with DSD DAC.


========= EDIT 2023-04-27 =========
When I wrote the post above I did not realize that the Squeezelite version that runs on pCP has a built-in DSD decoder. So in principle it is correct that pCP supports native playback of DSD files. In practice there are multiple complications though:

1) The sample rate of the PCM signal at the output of the DSD decoder will be too high for most I2S DACs, and for all I2S to SPDIF/Toslink converter boards that I am aware of. For a DSD64 stream the PCM sample rate is 352.8kHz, and for a DSD128 the sample rate is 705.6kHz. This means that the PCM signal at the output of the DSD decoder needs to be down-sampled to a sample frequency that can be handled by DAC or SPDIF board.
2) Not all Raspberry Pi models have enough processing power to do the DSD decoding and required down-sampling. I found that my Pi Zero can only handle DSD64 streams. CPU usage is then circa 65%. When feeding the Pi Zero with a DSD128 stream, the CPU usage goes to 100%, and output signal is malformed.

In most use cases it is better to let LMS do DSD to FLAC transcoding (requires DSDPlayer plugin to be installed). This can be realized by excluding native support for dsd on the pCP Squeezelite Settings page. I also recommend to set a Max sample rate value on this page. Set a value that can be handled by your DAC or SPDIF board. In case of SPDIF also take into account the max sample rate that the SPDIF input of your external DAC can handle.

Fore more info see posts 1618 and 1620 below.
=================================

[CJS]

I don’t use DSD, so I’ve never tested anything, but following things over the years, I would agree with your statements. Not sure I would ever see the value in doing DoP, since it has to be converted. DoP is supported on pCP, where there is proper hardware. It’s just pcm, to pCP.

Thanks paul- for confirmation. With respect to your remark "Not sure I would ever see the value in doing DoP, since it has to be converted", I think the value would be that if the DAC is a native DSD DAC, DoP would enable native DSD playback (*). Although I have the impression that in practice there are very few native DSD DACs that support DoP over SPDIF/TOSLINK. And apparently there are also DACs that support DoP as input, but locally convert the DoP signal to standard PCM for playback via an I2S DAC chip. In the latter case I agree that there is no value in doing DoP.

(*) Explanation of DoP, copied from PC Magazine:

DoP = DSD Over PCM
DoP is a method for transporting DSD audio over USB ports that do not have a DSD driver. Each consecutive set of 16 DSD bits is stored as PCM bits in the lower 16 bits of a 176.4/24 sampling rate. An 8-bit DoP header is added to each sample. In order to reassemble the PCM bits into a continuous DSD stream, the DAC at the playback end must be DoP compliant. See DSD, 176.4/24 and PCM.

[paul-]

LMS incorrectly reports/detects that my pCP supports native playback of DSD files

Since LMS thinks that my pCP supports native playback of DSD files, it sends the DSF stream to my pCP (i.e. without transcoding), which results in garbled audio playback:

Question that I have:
1) Why does LMS detect that my pCP with I2S DAC supports native playback of DSD files? Is this a bug in piCorePlayer?
2) Is a setting available in pCP to inform LMS that pCP does NOT support native DSD playback? On the pCP Squeezelite Settings tab there is an option to tell pCP that the audio output device supports DSD/DoP. But I can't find an option to tell pCP that DSD/DoP is NOT supported.

Any suggestions? I know that I can force transcoding of DFF and DSF to FLAC under LMS > Settings > Advanced > File Types, by disabling native playback of DFF and DSF. Drawback of this workaround is that native DSD playback is then disabled for all players, which would be a pity for people that have a player with DSD DAC.

Squeezelite includes the dsd patches, if you have anything in the -D option on the squeezelite page, the it’s going to enable. Check the squeezelite command line to make sure -D is not there

[CJS]

Squeezelite includes the dsd patches, if you have anything in the -D option on the squeezelite page, the it’s going to enable. Check the squeezelite command line to make sure -D is not there

FYI, the "Device supports DSD/DoP" field on the Squeezelite Settings tab is empty. My squeezelite command string is as follows:

/usr/local/bin/squeezelite -n "SqueezeBerry" -o hw:CARD=sndrpihifiberry -a 80:4::1: -r 192000 -v -C 5

So there is no -D in the command string. Still LMS thinks that my pCP supports native playback of DSD. When I was experimenting with DSD playback a few days ago I temporarily have had "-D format=dop" in the command string. Maybe this has triggered something irreversible in LMS? After removing the -D option I have rebooted pCP and restarted LMS, but LMS keeps thinking that my pCP supports DSD.

Btw, DSF and DFF files play fine now, because I have disabled native playback of DFF and DSF under LMS > Settings > Advanced > File Types. So now LMS transcodes DFF and DSF files to FLAC with 176.4kHz sample rate. I am just reporting this issue because it is an indication that something goes wrong in pCP / pcp-squeezelite or LMS.

[paul-]

It’s probably saved in the lms prefs, you can add DSD to the exclude codec line, that may override the prefs. Or delete the player, the re-add it.

[CJS]

It’s probably saved in the lms prefs, you can add DSD to the exclude codec line, that may override the prefs. Or delete the player, the re-add it.

Adding dsd to the "Exclude codec setting" field on the Squeezelite Settings tab of pCP indeed does the trick. Transcoding of DFF and DSF streams to FLAC is now done by LMS, also with DFF and DSF set to Native under LMS File Types settings. My squeezelite command string is now:

/usr/local/bin/squeezelite -n "SqueezeBerry" -o hw:CARD=sndrpihifiberry -a 80:4::1: -e dsd -r 192000 -v -C 5

Thanks!

[Man in a van]

Adding dsd to the "Exclude codec setting" field on the Squeezelite Settings tab of pCP indeed does the trick. Transcoding of DFF and DSF streams to FLAC is now done by LMS, also with DFF and DSF set to Native under LMS File Types settings. My squeezelite command string is now:

/usr/local/bin/squeezelite -n "SqueezeBerry" -o hw:CARD=sndrpihifiberry -a 80:4::1: -e dsd -r 192000 -v -C 5

Thanks!

And my thanks to CJS and paul-

I quickly rejigged the test rig

/usr/local/bin/squeezelite -n "Topping" -o hw:CARD=sndrpihifiberry -a 80:4::1: -e dsd -s 192.168.1.153 -C 10

and usng the optical output I get 176.4 PCM reported on the dac and a windae to play with




ronnie

[CJS]

Some thoughts on playback of DSD audio files on piCorePlayer

Triggered by the question of stereoptic in post 1576 and the follow up posts by Man in a van (especially post 1597), I did a few experiments with playback of DSD audio files (with .dff and .dsf extension) on my piCorePlayer with I2S DAC HAT board. In this post I want to close this topic for myself by sharing some thoughts, for those who are interested:

1) pCP/pcp-squeezelite reports to LMS that the player supports native playback of DSD files, see post 1611. At first I thought that this was not correct, but now I realize that squeezelite used on PCP has a built-in DSD decoder, that decodes DSD to PCM or optionally to DoP (DSD over PCM). So in principle it is correct that pCP players supports native playback of DSD. Complication is however that in many cases the PCM or DoP output of the DSD decoder has a sample rate higher than 192kHz, that cannot be handled by the I2S DAC board or by the I2S to SPDIF/TOSLINK converter on SPDIF HAT boards. For example my low cost I2S DAC board can handle PCM sample rates up to 192kHz, and the same is true for most SPDIF boards, including the Hifiberry Digi+ Pro. Another complication is that my Pi Zero has not enough processing power to decode DSD128 and DSD256 streams. It appears that the Pi Zero can only properly decode DSD64 streams.

2) To avoid that the DAC or SPDIF board is fed with a PCM signal with too high sample rate, resampling of the PCM signal needs to be done to a sample rate not higher than 192kHz. In practice proper downsampling results in 176.4 kHz PCM streams, that can be handled by common DAC and SPDIF boards.
EDIT: Additional information about PCM sample rates at the output of the DSD decoder is given in post 1620 below.

3) In post 1597 Man in a van describes how he achieves noise free playback of DSD64, DSD128 and DSD256 files by means of DSD decoding and resampling to 176.4 kHz PCM streams on his RPI3B pCP player. Playback is done via an external Topping E30 DAC that is connected to the TOSLINK output of the Hifiberry Digi+ Pro HAT board mounted on his RPI3B. Resampling is realized via squeezelite options -R hLs -u E entered in the "Various Options" field of the pCP Squeezelite Settings page.

I found that the same resampling can also be realized by entering the resampling parameters in the "Upsampling setting" field, see screenshot below:



I have omitted the "s" parameter, because according to this SoX FAQ page (see point 5), the default bandwidth setting of 95% should not be changed to retain the highest audio quality. I have also entered a max sample rate of 192000, since this is the max sample rate that my DAC can handle. The same applies to most SPDIF boards. Btw, this max sample rate is not taken into account by LMS when sending DSD streams to the player.

4) Since DSD decoding + resampling requires significant processing power (too much for my pi Zero for streams higher than DSD64), in many cases it is a better solution to do this DSD decoding and resampling on LMS. To avoid that DSD streams are sent to a player that does not have enough processing power, enter dsd in field "Exclude codec setting" on the pCP Squeezelite Settings page. This signals to LMS that the player does not support DSD decoding, and DSD decoding, resampling and transcoding to FLAC will be done by LMS (requires that DSDPlayer plugin is installed on LMS). The player then only needs to decode FLAC with 176.4kHz sample rate, which is no problem for my Pi Zero. (Note: my ESP Muse player has even lower processing power. For this player I enforce resampling to 88.2kHz FLAC by LMS, by setting a max sample rate of 96kHz in the player).

5) I did some googling and reading, and found that DoP (DSD over PCM) over SPDIF/TOSLINK is supported by only very few DACs. For example the Topping E30 supports DoP over USB up to DSD256, but it does NOT support DoP over the Coax/Optical (SPDIF/TOSLINK) input. At least that is my interpretation when reading the specification in the User Manual of this DAC. The same may be true for the Marantz AVR of stereoptic. I would not worry about this. Normal PCM (as opposed to DoP) with 176.4kHz sample rate will also give good audio quality.

I could provide more information, but I think that this post is long enough for now .

[Man in a van]

CJS

Good one

ronnie

[CJS]

2) To avoid that the DAC or SPDIF board is fed with a PCM signal with too high sample rate, resampling of the PCM signal needs to be done to a sample rate not higher than 192kHz.

Here is some additional information about the sample rate of the PCM signal at the output of the DSD decoder that is included in pcp-squeezelite. This information was obtained by enabling squeezelite logging by selecting Log level setting "all=info" on the Squeezelite Settings page.

These are selected lines from pcp-squeezelite.log when playing a DSD64 stream, with DSD decoding done on the player:

/usr/local/bin/squeezelite -n SqueezeBerry -o hw:CARD=sndrpihifiberry -a 80:4::1: -r 192000 -d all=info -f /var/log/pcp_squeezelite.log -v -C 5
[16:12:55.795011] output_init_common:426 supported rates: 192000 176400 96000 88200 48000 44100 32000 24000 22500 16000 12000 11025 8000
[16:12:55.822533] output_init_alsa:1002 memory locked
[16:12:55.850090] sendHELO:150 cap: CanHTTPS=1,Model=squeezelite,AccuratePlayPoints=1, HasDigitalOut=1,HasPolarityInversion=1,Balance=1,F irmware=v1.9.9-1419-pCP,ModelName=SqueezeLite,MaxSampleRate=192000,dsf ,dff,alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3
Server: Logitech Media Server (8.3.2 - 1679892799)
[16:15:24.868780] output_thread:685 open output device: hw:CARD=sndrpihifiberry
[16:15:24.868914] alsa_open:354 opening device at: 44100
[16:15:24.870572] alsa_open:425 opened device hw:CARD=sndrpihifiberry using format: S32_LE sample rate: 44100 mmap: 1
[16:15:24.870860] alsa_open:516 buffer: 80 period: 4 -> buffer size: 3528 period size: 882
[16:15:24.876708] _read_header:159 DSF version: 1 format: 0
[16:15:24.876830] _read_header:169 channels: 2
[16:15:24.876876] _read_header:170 sample rate: 2822400
[16:15:24.876920] _read_header:171 lsb first: 1
[16:15:24.876961] _read_header:172 sample bytes: 81065493
[16:15:24.877004] _read_header:173 block size: 4096
[16:15:24.877048] _read_header:179 found dsd len: 162136076
[16:15:24.877092] dsd_decode:768 setting track_start
[16:15:24.877133] dsd_decode:817 DSD to PCM output
[16:15:24.892083] _output_frames:65 start buffer frames: 8192
[16:15:24.892232] _output_frames:153 track start sample rate: 352800 replay_gain: 0
[16:15:24.902536] output_thread:685 open output device: hw:CARD=sndrpihifiberry
[16:15:24.903810] alsa_open:354 opening device at: 352800
[16:15:24.905430] alsa_open:384 reopening device hw:CARD=sndrpihifiberry in plug mode as plughw:CARD=sndrpihifiberry for resampling
[16:15:24.909050] alsa_open:425 opened device plughw:CARD=sndrpihifiberry using format: S32_LE sample rate: 352800 mmap: 1
[16:15:24.910263] alsa_open:516 buffer: 80 period: 4 -> buffer size: 28224 period size: 7056
[16:16:22.555418] decode_flush:244 decode flush
[16:16:22.561837] output_flush:439 flush output buffer
[16:16:28.570883] output_thread:803 disabling output​

When carefully inspecting this log it can be seen that the incoming DSD64 stream has a sample rate of 2822.4 kHz, and the PCM signal at the output of the DSD decoder has a sample rate of 352.8kHz. There are DACs that can handle this sample rate, but it is too high for my low cost I2S DAC. So it is clear that down-sampling of the PCM signal at the output of the DSD decoder is needed for proper playback on my DAC


Below are selected lines from pcp-squeezelite.log when playing a DSD128 stream, with DSD decoding done on the player:

/usr/local/bin/squeezelite -n SqueezeBerry -o hw:CARD=sndrpihifiberry -a 80:4::1: -r 192000 -d all=info -f /var/log/pcp_squeezelite.log -v -C 5
[17:16:20.992112] output_init_common:426 supported rates: 192000 176400 96000 88200 48000 44100 32000 24000 22500 16000 12000 11025 8000
[17:16:21.114636] output_init_alsa:1002 memory locked
[17:16:21.198599] sendHELO:150 cap: CanHTTPS=1,Model=squeezelite,AccuratePlayPoints=1, HasDigitalOut=1,HasPolarityInversion=1,Balance=1,F irmware=v1.9.9-1419-pCP,ModelName=SqueezeLite,MaxSampleRate=192000,dsf ,dff,alc,aac,ogg,ops,ogf,flc,aif,pcm,mp3
Server: Logitech Media Server (8.3.2 - 1679892799)
[17:28:41.315815] output_thread:685 open output device: hw:CARD=sndrpihifiberry
[17:28:41.316019] alsa_open:354 opening device at: 44100
[17:28:41.317850] alsa_open:425 opened device hw:CARD=sndrpihifiberry using format: S32_LE sample rate: 44100 mmap: 1
[17:28:41.318178] alsa_open:516 buffer: 80 period: 4 -> buffer size: 3528 period size: 882
[17:28:41.332297] _read_header:159 DSF version: 1 format: 0
[17:28:41.334272] _read_header:169 channels: 2
[17:28:41.334371] _read_header:170 sample rate: 5644800
[17:28:41.336417] _read_header:171 lsb first: 1
[17:28:41.338448] _read_header:172 sample bytes: 193729536
[17:28:41.338521] _read_header:173 block size: 4096
[17:28:41.338574] _read_header:179 found dsd len: 387465228
[17:28:41.338626] dsd_decode:768 setting track_start
[17:28:41.338672] dsd_decode:817 DSD to PCM output
[17:28:41.360195] _output_frames:65 start buffer frames: 8192
[17:28:41.360341] _output_frames:153 track start sample rate: 705600 replay_gain: 0
[17:28:41.370577] output_thread:685 open output device: hw:CARD=sndrpihifiberry
[17:28:41.374434] alsa_open:354 opening device at: 705600
[17:28:41.376016] alsa_open:384 reopening device hw:CARD=sndrpihifiberry in plug mode as plughw:CARD=sndrpihifiberry for resampling
[17:28:41.379434] alsa_open:425 opened device plughw:CARD=sndrpihifiberry using format: S32_LE sample rate: 705600 mmap: 1
[17:28:41.380647] alsa_open:516 buffer: 80 period: 4 -> buffer size: 56448 period size: 14112
[17:28:58.943725] decode_flush:244 decode flush
[17:28:58.943848] output_flush:439 flush output buffer
[17:29:04.023009] output_thread:803 disabling output​

When carefully inspecting this log it can be seen that the incoming DSD128 stream has a sample rate of 5644.8 kHz, and the PCM signal at the output of the DSD decoder has a sample rate of 705.6kHz. There are only few I2S DACS that can handle such a high sample rate. So it is clear that down-sampling of the PCM signal at the output of the DSD decoder is needed for proper playback on my DAC.

I would say that in most use cases the DSD decoding and down-sampling is best done on the LMS server, especially when there are more players in the house. Note that with default LMS transcoding settings for .dff and .dsf files, the PCM signal at the output of the DSD decoder is transcoded to FLAC after down-sampling. The FLAC is then decoded to PCM on the player side, before sending the signal to the DAC c.q. audio output device..

Only when a combined LMS server / player is used on pCP, and this is the only player in the house, it may be better to do the DSD decoding and down-sampling at the player side. By doing so it is avoided that PCM to FLAC encoding is done on the server and FLAC to PCM decoding on the player, with server and player running on the same CPU; that would be a waste of processing power. Alternatively DSD decoding could be done by LMS, in combination with a custom transcoding rule for decoding of DSD to PCM instead of transcoding to FLAC. This would skip the PCM to FLAC and FLAC to PCM transcoding steps. Just a few thoughts.