Problems with DSD_U32_BE

Need help with MPD?
J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Problems with DSD_U32_BE

Post by J.L.C. »

I have been trying to get native DSD through 2 USB DAC's to work, without luck. Today I compiled the latest MPD release from source. My OS is Ubuntu 16.10 64bit.

mpd --version
Music Player Daemon 0.20.1

Both DAC's use an XMOS USB chip, but different DAC chips. The first one seems to call the DSD_U32_BE correctly, but still fails to play a DSD128 .dsf file natively.

mpdconf

Code: Select all

audio_output {
	type		"alsa"
	name		"My ALSA Device"
#	dsd_native      "yes"
	dsd_usb         "no"
#	dsd_native_type "2"
	device		"hw:1,0"	# optional
	mixer_type      "null"	# optional
##	mixer_device	"default"	# optional
##	mixer_control	"PCM"		# optional
##	mixer_index	"0"		# optional
}
Log

Code: Select all

Jan 09 17:16 : client: [0] process command "playid "2""
Jan 09 17:16 : playlist: play 1:"members%2FJL001%2FJL001+stereo%2F03_Puente-Celeste---Nama---Chiquita_DSD128_2ch128.dsf"
Jan 09 17:16 : client: [0] command returned 0
Jan 09 17:16 : client: [0] process command "status"
Jan 09 17:16 : client: [0] command returned 0
Jan 09 17:16 : decoder_thread: probing plugin dsf
Jan 09 17:16 : client: [0] process command "idle"
Jan 09 17:16 : client: [0] command returned 1
Jan 09 17:16 : client: [0] process command "playlistid "2""
Jan 09 17:16 : client: [0] command returned 0
Jan 09 17:16 : decoder: audio_format=705600:dsd:2, seekable=true
Jan 09 17:16 : alsa_output: opened hw:1,0 type=HW
Jan 09 17:16 : alsa_output: format=DSD_U32_BE (Direct Stream Digital, 4-byte (x32), big endian, oldest bits in MSB)
Jan 09 17:16 : alsa_out[code]put: buffer: size=96..131072 time=250..341334
Jan 09 17:16 : alsa_output: period: size=48..65536 time=125..170667
Jan 09 17:16 : alsa_output: default period_time = buffer_time/4 = 341333/4 = 85333
Jan 09 17:16 : alsa_output: buffer_size=131072 period_size=32768
Jan 09 17:16 : exception: PCM conversion from f to dsd is not implemented
Jan 09 17:16 : output: Retrying without DSD
Jan 09 17:16 : alsa_output: opened hw:1,0 type=HW
Jan 09 17:16 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Jan 09 17:16 : alsa_output: buffer: size=96..131072 time=250..341334
Jan 09 17:16 : alsa_output: period: size=48..65536 time=125..170667
Jan 09 17:16 : alsa_output: default period_time = buffer_time/4 = 341333/4 = 85333
Jan 09 17:16 : alsa_output: buffer_size=131072 period_size=32768
Jan 09 17:16 : output: opened plugin=alsa name="My ALSA Device" audio_format=384000:32:2
Jan 09 17:16 : output: converting from 705600:dsd:2
[/code]

This is a DSD128 file, it looks like it's trying to convert it to PCM and failing. But I don't understand why it's trying to convert.

With my other DAC it it uses S32_LE and won't play DSD files. It converts it and results in hiss/noise at a louder volume than the music

Code: Select all

Jan 09 17:31 : client: [0] process command "playid "2""
Jan 09 17:31 : playlist: play 1:"members%2FJL001%2FJL001+stereo%2F03_Puente-Celeste---Nama---Chiquita_DSD128_2ch128.dsf"
Jan 09 17:31 : client: [0] command returned 0
Jan 09 17:31 : playlist: queue song 2:"members%2FJL001%2FJL001+stereo%2F01_RICARDO-GALLEN---Fernando-Sor---Guitar-Sonatas---Study-Op.6_9__DSD256_2ch256.dff"
Jan 09 17:31 : client: [0] process command "status"
Jan 09 17:31 : client: [0] command returned 0
Jan 09 17:31 : decoder_thread: probing plugin dsf
Jan 09 17:31 : client: [0] process command "idle"
Jan 09 17:31 : decoder: audio_format=705600:dsd:2, seekable=true
Jan 09 17:31 : client: [0] command returned 1
Jan 09 17:31 : client: [0] process command "playlistid "2""
Jan 09 17:31 : client: [0] command returned 0
Jan 09 17:31 : alsa_output: opened hw:1,0 type=HW
Jan 09 17:31 : alsa_output: format=S32_LE (Signed 32 bit Little Endian)
Jan 09 17:31 : alsa_output: buffer: size=96..131072 time=250..341334
Jan 09 17:31 : alsa_output: period: size=48..65536 time=125..170667
Jan 09 17:31 : alsa_output: default period_time = buffer_time/4 = 341333/4 = 85333
Jan 09 17:31 : alsa_output: buffer_size=131072 period_size=32768
Jan 09 17:31 : output: opened plugin=alsa name="My ALSA Device" audio_format=384000:32:2
Jan 09 17:31 : output: converting from 705600:dsd:2
Jan 09 17:31 : client: [0] process command "status"
Jan 09 17:31 : client: [0] command returned 0
Any suggestions? Is there something I can do in the config to force native DSD? Do I need to specify parameters for the probed plugins?

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

Your sound chip doesn't support the input sample rate, therefore MPD attempts to resample, which requires conversion to floating point; but conversion back to DSD is not possible.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote:Your sound chip doesn't support the input sample rate, therefore MPD attempts to resample, which requires conversion to floating point; but conversion back to DSD is not possible.
The first DAC is an xduoo xd-05, the second is an Encore mDSD, both are capable of native DSD256 playback (confirmed on Windows with Foobar2000).

I tried a DSD64 track from Bladerunner with MPD and the xduoo display shows that it's being upsampled to DSD256. But at least there's no hiss.

Is there a way to inform/force MPD to just bitstream and not do any conversion or resampling?

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

J.L.C. wrote:The first DAC is an xduoo xd-05, the second is an Encore mDSD, both are capable of native DSD256 playback (confirmed on Windows with Foobar2000).
Have you also confirmed that the Linux driver can do it?
I tried a DSD64 track from Bladerunner with MPD and the xduoo display shows that it's being upsampled to DSD256. But at least there's no hiss.
MPD is incapable for resampling DSD, as I said. Therefore, if your DAC says it's being "upsampled", then your DAC is wrong.
Is there a way to inform/force MPD to just bitstream and not do any conversion or resampling?
What do you want MPD to do if that's not possible?

Currently, MPD attempts to do the necessary conversion if there is a problem. And there is such a problem in your case (for whatever reason). So what should MPD do?

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

J.L.C. wrote:The first DAC is an xduoo xd-05, the second is an Encore mDSD
Are these even supported by vanilla Linux? Or are you using some proprietary driver for it? I see no reference for either product in the Linux kernel sources.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote: Have you also confirmed that the Linux driver can do it?
With a trial version of JRiver Media Center 22, DSD64 and DSD128 files bitstream to both DAC's using the driver that is included in the 3.13.0-34 Kernel, so both devices appear to be supported.
What do you want MPD to do if that's not possible?
I'm assuming it's possible, since JRiver can do it. The Kernel driver won't stream DSD256 even with JRiver, which I assume is a limitation of the current driver. But, DSD64 and DSD128 both work perfectly. So I was wondering how I might achieve the same functionality with MPD.
Currently, MPD attempts to do the necessary conversion if there is a problem. And there is such a problem in your case (for whatever reason). So what should MPD do?
I'm trying to determine what the problem is. The error reported in the log states a PCM rate of 705600 ("decoder: audio_format=705600:dsd:2, seekable=true"), which isn't correct for a DSD128 file. I am trying to determine why MPD is reading them improperly.
max wrote:Are these even supported by vanilla Linux? Or are you using some proprietary driver for it? I see no reference for either product in the Linux kernel sources.
They are both recognized by name in "Sound Settings" and work perfectly with JRiver Media Center 22 using the drivers from Kernel 3.13.0-34

I'm just trying to determine if there is something I've configured incorrectly, of if there are additional parameters I need to specify.

DSD256 only works on Windows using Thesycon ASIO drivers, which I understand are not available on Linux. But, DSD64 and DSD128 work on both Windows and Linux using default drivers on both DAC's, but I can't seem to get either of those formats to play natively through MPD.

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

J.L.C. wrote:With a trial version of JRiver Media Center 22, DSD64 and DSD128 files bitstream to both DAC's using the driver that is included in the 3.13.0-34 Kernel, so both devices appear to be supported.
Which driver is being used?

And where can I find the source code of this trial version you're using?
I'm assuming it's possible
If it's possible, then you don't need to forbid MPD to resample. Therefore, your assumption has nothing to do with your request and my question.
I'm trying to determine what the problem is. The error reported in the log states a PCM rate of 705600 ("decoder: audio_format=705600:dsd:2, seekable=true"), which isn't correct for a DSD128 file. I am trying to determine why MPD is reading them improperly.
The 705600 you see is the number of "byte" frames per second. MPD cannot count bits; the smallest unit it can count is bytes. And anyway, in DSD, there are always 8 (bit) samples packed in a byte, even with multiple channels. It won't interleave multiple channels in one byte.

So the translation is: 705600 byte frames per second is 705600 * 8 = 5644800 bit frames per second, which is roughly 5.6 MHz - the DSD128 bit rate.
max wrote:Are these even supported by vanilla Linux? Or are you using some proprietary driver for it? I see no reference for either product in the Linux kernel sources.
They are both recognized by name in "Sound Settings" and work perfectly with JRiver Media Center 22 using the drivers from Kernel 3.13.0-34
Your answer has nothing to do with my question. But my question was important.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote: Which driver is being used?
JRiver is able to stream native DSD using the following audio device/driver selections under both Ubuntu 14.04 (Kernel 3.13.0-34) and Ubuntu 16.10 (Kernel 4.8.0-30):

XDUOO XD-05
hw: CARD=x2.0,DEV=0 [ALSA] xCORE USB Audio 2.0 USB Audio. Direct hardware device without any conversions

Encore mDSD
hw: CARD=mDSD,DEV=0 [ALSA] Encore mDSD, USB Audio. Direct hardware device without any conversions
And where can I find the source code of this trial version you're using?
I don't think JRiver is an open source project. I installed it using a .deb (https://yabb.jriver.com/interact/index. ... 749.0.html)
If it's possible, then you don't need to forbid MPD to resample. Therefore, your assumption has nothing to do with your request and my question.
Since it is possible, my question is why isn't MPD sending native DSD.
So the translation is: 705600 byte frames per second is 705600 * 8 = 5644800 bit frames per second, which is roughly 5.6 MHz - the DSD128 bit rate.
Okay, so MPD is recognizing the file as DSD128, but not recongizing that my DAC can play it. Can I specify that the devices are capable somehow?
max wrote: Your answer has nothing to do with my question. But my question was important.
Okay, then I'm not sure how to determine if either DAC is supported by vanilla linux.

I have not installed any proprietary drivers. I have simply connected them by USB and both cards work as expected - at least in JRiver.

MPD is working as expected with high resolution flac and wav files. These play back correctly and the display on the DAC's reflects the correct encoding of the tracks. But, MPD is not sending native DSD

By selecting the driver reported above from within JRiver and selecting to bitstream DSD, both DAC's are sent native DSD as indicated by their displays.


I'm clearly not an expert, so my thinking was that I've done something wrong in my setup. I was just asking if I've missed something obvious in my configuration since the documentation says that native DSD should be working.

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

J.L.C. wrote:XDUOO XD-05
hw: CARD=x2.0,DEV=0 [ALSA] xCORE USB Audio 2.0 USB Audio. Direct hardware device without any conversions

Encore mDSD
hw: CARD=mDSD,DEV=0 [ALSA] Encore mDSD, USB Audio. Direct hardware device without any conversions
No such driver exists in the vanilla Linux kernel. Therefore, I assume your kernel has a proprietary driver.
I don't think JRiver is an open source project.
... combined with a proprietary software, and that's where we unfortunately can't continue. We can't check what this proprietary software is doing with this proprietary driver. Maybe this proprietary software does have a DSD resampler, but we don't know. Maybe this would be a solution for MPD, or maybe not. That's the problem with proprietary things.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote: No such driver exists in the vanilla Linux kernel. Therefore, I assume your kernel has a proprietary driver.
Okay, thank you for your help.

My Kernel is listed as Linux 3.13.0-34-generic; is that different from "vanilla'?

My system says only my video driver is proprietary:

Image

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

I had another idea; this may be a MPD bug after all. Check out my branch "dsd_u32" on GitHub (https://github.com/MaxKellermann/MPD/tree/dsd_u32) for a potential fix. I cannot test it, because I do not own DSD_U32 capable hardware.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote:I had another idea; this may be a MPD bug after all. Check out my branch "dsd_u32" on GitHub (https://github.com/MaxKellermann/MPD/tree/dsd_u32) for a potential fix. I cannot test it, because I do not own DSD_U32 capable hardware.
Thanks!

I'll try it as soon as it's compiled.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

That did it!!

Everything is now working with native DSD streaming on the XDuoo XD-05! DSD64, DSD128, and DSD256 all streaming. A lot of hiss, but the DAC reports the file correctly.

Thank you so much for the rapid coding!

The Encore is still not working, but perhaps it's using a newer XMOS controller?

I wonder if there is a combination of mixer_type, mixer_device, and mixer_control that would let me eliminate the hiss?

Ran
Posts: 151
Joined: February 25th, 2013, 3:47 am

Re: Problems with DSD_U32_BE

Post by Ran »

Max,

Just as an FYI, these two DACs support USB Audio Class 2.0 which is part of the Linux kernel. The goal is that any UAC 2.0 DAC will work out of the box in the newer kernels.

http://www.usb.org/developers/docs/devc ... _final.zip

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

Thanks, that's great info!

Any guesses as to how I can get rid of the hiss? Although the music is there and playing, it's buried in constant hiss.

Out of curiosity, I compiled this version:
https://github.com/xxxbugxxxx/MPD

and it is streaming DSD64, DSD128, and DSD256 with no hiss

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

Ok, so the wrong sample rate was really MPD's miscalculation. I will push this change to the upcoming 0.20.2.

Can you make a short recording of what you call "hiss"? And please post a verbose log of MPD beginning the playback.

We will sort this out, thanks for feeding back so quickly, that's very helpful.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

Okay, I have captured logs and recordings for the same track, at the same settings, with both the xxxbugs build and your test dsd_u32 build.

I have labelled the flac audio files and log files to correspond with the build used to make the recording.

Volume levels and the recording interface are all identical across both recordings.

I recorded these as .flac, but the files are too large to upload, so I compressed them to .mp3 at 192kbps then zipped.

Please let me know what else I can do to assist.

As an aside, I was able to get the Encore mDSD working with the xxxbugs build, but had to set:

dop "yes"

in my .mpdconf file to get it working. Due to DoP being required, it will only play up to DSD128.
Attachments
dsd_u32_192.mp3.zip
dsd_u32 recording
(233.65 KiB) Downloaded 117 times
xxxbugs_192.mp3.zip
xxxbugs recording
(234.56 KiB) Downloaded 111 times
Log_Files.zip
Log files
(2.54 KiB) Downloaded 112 times

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

Thanks. Please try the latest "master" branch. I've written a patch which fixes the byte order, which may solve your problem.

J.L.C.
Posts: 27
Joined: January 9th, 2017, 10:12 pm

Re: Problems with DSD_U32_BE

Post by J.L.C. »

max wrote:Thanks. Please try the latest "master" branch. I've written a patch which fixes the byte order, which may solve your problem.
Thanks for that!

The latest master does allow play back of DSD64, DSD128, and DSD256 files.

However, the "hiss" that was present on the test branch is still there. The tracks sound the same as in the "dsd_u32_192" recording I uploaded.

I'm not sure of the extent of the modifications in the xxxbugs branch, but that build has no "hiss" during playback of any of DSD files.

I'm happy to do any testing and provide any logs or debug info I can.

max
Forum team
Posts: 1024
Joined: January 15th, 2013, 3:43 pm

Re: Problems with DSD_U32_BE

Post by max »

You can view the differences between that fork and official MPD with this command:

Code: Select all

git diff d0dae177cfc52410728e2257ca29132ea161d95d..f801101d5a31f2ab29e0692c3b46c55347b24625
There's a lot of crap in that fork, and obscure undocumented changes done in the wrong place in the wrong way (which is why I can't merge this, unfortunately). I went through the diff and couldn't see an obvious thing that could fix your problem. The byte order problem was a hot candidate, but that hasn't changed your problem. So the real fix must be hidden somewhere.

Post Reply