Help needed on ”allowed_formats“, in particular DSD as DoP - Solution turns to alsa buffers and real-time scheduling

[111MilesToGo]

Please, I need help for my mpd.conf file in ~/.config/mpd/ on Linux (openSUSE Tumbleweed). Tumbleweed provides mpd version 0.23.10. I am using audio_output type "alsa".

I have a USB DAC dongle (Cayin RU6) hooked up to my Linux laptop. This device can play PCM up to 32/384kHz, and it can play DSD natively up to DSD256. Currently, I am limiting myself to audio files up to 24/384 and DSD 256.

However, this DAC doesn‘t work properly with mpd, unless I specify allowed_formats in its audio_output section.

First, bit depth changes from track to track (both 16 to 24 and 24 to 16) are hit or miss. Reason unknown. The remedy is
allowed_formats ”*:24:*“
Works well, whatever PCM up to 384kHz I throw at mpd.

Second, on my Linux Tumbleweed, native DSD doesn‘t work with this dongle DAC. DoP does work, though, at least in part.
However, although this device can technically do native DSD256, DoP of course works up to DSD128 only, since that is using the fake PCM wrapping at 352.8kHz. DoP from DSD256 is out of the DAC range. Thus, I need to amend my allowed_formats specification:
allowed_formats ”*:24:* dsd64:*=dop dsd128:*=dop“
Works well for any PCM and the two DSD‘s 64 and 128.
However, throwing DSD256 at mpd with that allowed_formats statement still generates terrible noise.
It does not matter whether I have a
dop ”yes“
statement in the audio_output section or not.

My question is: What allowed_formats statement do I need in order to
(1) either forbid DSD256 entirely, or to
(2) somehow force mpd to decimate DSD256 to PCM at 352.8kHz, or
(3) maybe even make it play DSD256 as a sample-rate changed DoP128?

Solution (1) might be preferred, followed by (2). Solution (3) would involve two steps, changing DSD256 to PCM, and changing the latter to DSD128 and send that as DoP.

Thanks a lot in advance.

[MaxKellermann]

(1) either forbid DSD256 entirely, or to

What does that mean, exactly?

(2) somehow force mpd to decimate DSD256 to PCM at 352.8kHz, or

That's what MPD does with your configuration. See https://www.musicpd.org/help/ if you need help with that.

(3) maybe even make it play DSD256 as a sample-rate changed DoP128?

MPD can't resample DSD, and it can't convert PCM to DSD. It can only play back DSD as-is, or convert DSD to PCM.

[111MilesToGo]

Thank you for replying swiftly!

Let me reply to your questions and remarks in turn.

Solution (1) "forbid DSD256 entirely" would mean to not output anything, just skip any DSD256 track.
But I understand this is probably not possible. NO PROBLEM!

Solution (2) "decimate DSD256 to PCM at 352.8kHz" indeed then would be the best solution. And indeed, from reading the manual, I had expected it to do exactly that with my configuration.
However, it doesn't do that. MPD generates terrible noise when trying to play DSD256 !
Why does that happen? And how could I get it to work?

Solution (3) is not needed. It was inspired by what Roon does on my Windows machine.

Do you have any ideas regarding Solution (2)?

[MaxKellermann]

Why does that happen? And how could I get it to work?

Please don't make me repeat myself. "See https://www.musicpd.org/help/ if you need help with that."

[111MilesToGo]

[MaxKellermann]

"When you do request help, post the following data"

[111MilesToGo]

Dear Max, sorry for engaging you more than you like. I DID READ the manual/help up front, in particular the chapters on Direct Stream Digital (DSD), Audio format settings > Global output format and > Resampler, Plugin reference > Output plugins > alsa. Unfortunately, that did not help beyond what I have now. I keep getting stuttering noise when trying to play DSD256, which should automatically be turned into PCM with my configuration as you say.

So, please let me continue to try to find a solution.

Please forgive me for the moment, I will soon provide the usual information on my setup - MPD version is 0.23.10; I use Cantata to control it; and I will enter verbose logging soon.

Anyway, for now, here is the relevant portion of my ~/.config/mpd/mpd.conf file:

# Cayin RU6
audio_output {
	type                "alsa"
	name                "Cayin RU6 - USB Audio"
#	device              "hw:2,0"
	device              "hw:CARD=RU6,DEV=0"
	auto_resample       "no"
	auto_format         "no"
	auto_channels       "no"
	allowed_formats     "*:24:* dsd64:*=dop dsd128:*=dop"
	dop                 "yes"
#	thesycon_dsd_workaround "yes"
	replay_gain_handler "none"
	mixer_type          "none"
}
# end of Cayin RU6

which is followed by

# general settings for all output devices
resampler {
	plugin              "libsamplerate"
	type                "0"
}
replaygain                  "off"

The auto_resample, auto_format, auto_channels statements were introduced since I understood that MPD should be doing these things, but not alsa / libasound. Correct?

The remainder of the config file is concerned with other devices and the general settings like files, paths, which are not relevant here.

Please, I hope to be allowed to ask for further help: Could you take a look at that full config, please, and check whether there is anything offending in it.

As you can see, I had also experimented with the thesycon_dsd_workaround, IF my device Cayin RU6 would be handled by that driver. However, such statement crashes MPD when trying to play anything. I will be digging into this later when time allows. Going to my Windows machine, I did check the Cayin-supplied driver (ASIO), but couldn't find out who the software manufacturer is (i.e. can't see whether it is Thesycon).

[111MilesToGo]

Here are two text files, one is the mpd --version output, the other is the verbose logging. Sorry for not cleaning the verbose logging file ...

Verbose logging was done for playing a few tracks:

1. Loussier Play Bach, Italian Concerto (16/44.1) - Works fine
2. Bill Evans, Hilversum, You're Gonna Hear From Me (DSD64) - As DoP, works fine
3. Bill Evans, Hilversum, You're Gonna Hear From Me (DSD128) - As DoP, works fine
4. Bill Evans, Hilversum, You're Gonna Hear From Me (DSD256) - Converted by libsamplerate to 24/384, but IT STUTTERS AND PRODUCES NOISE
5. Loussier Play Bach, Partita No. 1 (16/44.1) - For checking, works fine
6. Bill Evans, Hilversum, Nardis (DSD256) - Converted by libsamplerate to 24/384, but STUTTERS AGAIN
7. Loussier Play Bach, Wachet auf ruft uns die Stimme (16/44.1) - Works fine

I am finding some alsa_output: Decoder is too slow; playing silence to avoid xrun log lines. Funny, overall CPU usage never gets above a few percent. My laptop is an HP 8570w EliteBook, with i7 CPU (8 threads) and 16 GB RAM, SSD - old (from 2012), but very reliable. So my next step will be to play an original PCM 32/384 track for a check, but I'll do that in my next post.

Attached files:
mpd_version.txt
mpd_verbose.log

[MaxKellermann]

This is a problem of latency, not of CPU usage. My guess is that MPD could be optimized to fulfill the latency constraints required by your setup, but unfortunately I don't have any hardware that can reproduce your problem, so I can't optimize the code.
A few things you can try, with a good amount of luck, it may make your problem go away:

• allow MPD to do real-time scheduling - on your computer, real-time scheduling is broken (MPD is not allowed)
• the buffer and period size chosen by your sound driver is small; it could be larger; see https://mpd.readthedocs.io/en/stable/plugins.html#alsa-plugin - according to your log, your driver can to buffer_time up to 2000000 and period_time up to 1000000; the actual values are only 500000 and 125000
• try disabling 24 bit playback; only allow 16 bit
• maybe try forcing MPD into a smaller sample rate

[111MilesToGo]

Thank you, Max, for taking a deeper look and for giving these recommendations - highly welcome. I'll check into them later.

For now, I still owe a test with an actual high-rate PCM track. Here is what happens when playing a so-called DXD 32/352.8 .wav file. It is
Patricia Barber, Clique!, Trouble Is A Man (32/352.8, float).
It plays fine, gets sent out as 24/352.8. No audible problems at all.
But I think MPD / alsa have to do much less in this case as compared to the previous DSD256 case - .wav instead of .dsf, no resampling, just reducing the bit depth.

Verbose log attached:
mpd_verbose_2.log

Remark: I have another laptop, HP 8560w, from 2011, i5 CPU (4 threads), 16 GB RAM, SSD; thus, a bit "smaller" and what I called "slower". It runs Windows 10, players are foobar2000 and Roon. Until now, I have no problems at all with any DAC of mine and with any audio file. The Windows machine plays anything up to 768kHz and DSD512 fine.
It is a matter of preferences: The Windows machine seems to be the "better" audio computer, but the Linux machine is the better "FOSS" machine ... Always being drawn back and forth ...

So, thank you again for your help! I will dig deeper into your recommendations and see what I can achieve.
Let's put this thread on hold for the time being, if you agree. I will report back, but that might take some time.

[111MilesToGo]

Dear Max, good morning,

Out of your recommendations, I tried the easiest one now: Setting buffer_time and period_time to the device's max values. Cf. the new mpd.conf file:

#### Cayin RU6
audio_output {
	type                "alsa"
	name                "Cayin RU6 - USB Audio"
##	device              "hw:2,0"
	device              "hw:CARD=RU6,DEV=0"
	auto_resample       "no"
	auto_format         "no"
	auto_channels       "no"
	allowed_formats     "*:24:* dsd64:*=dop dsd128:*=dop"
	dop                 "yes"
	buffer_time         "2000000"
	period_time         "1000000"
	replay_gain_handler "none"
	mixer_type          "none"
}
#### end of Cayin RU6

#### general settings for all output devices
resampler {
	plugin              "libsamplerate"
	type                "0"
}
replaygain              "off"

With these settings, everything (PCM, DSD up to DoP128) that worked before keeps working fine. For DSD256 as DoP, the stuttering and noise are greatly reduced now, but unfortunately do not disappear completely. There is a stutter every second or so.

So you were on the right track, my problem looks like a latency problem - thank you so much for that help.

I will keep on trying to check your other recommendations. Real-time scheduling looks to be promising, but I have to find out whether and how I could enable this on openSUSE Tumbleweed.

[111MilesToGo]

Dear Max, I turned to the "get real-time scheduling correct" recommendation of yours now. I would like to publish my solution here, although it merely is a lesson for me in Linux real-time scheduling. Please forgive me for this write-up, but I think such settings are not in the common working knowledge for quite some Linux users.

Up-front, here is my MPD result now:

• As mentioned above, increasing alsa buffer sizes helped, but only in part.
• Getting real-time scheduling to work properly for my MPD does NOT improve the problematic replay of DSD256 as automatically decimated PCM any further - unfortunate, but it is as it is.

So, thanks a lot for your help. I am happy to have improved my MPD setup a lot.

Dear Max, I have two more items for you regarding the MPD documentatin:

• Maybe you could consider adding a short paragraph to the Real-Time Scheduling item on how to in fact enable real-time scheduling for MPD. Something like an abridged version of my guide below. I feel that might help others, too.
• In the manual, the line zgrep ^CONFIG_RT_GROUP_SCHED /proc/config.gz contains an erroneous ^ character. It should read zgrep CONFIG_RT_GROUP_SCHED /proc/config.gz instead.

Thanks in advance!

---

Now, here are the basics:

In order to allow Music Player Daemon to properly acquire real-time scheduling, I did the following:

1. Add my user who runs MPD to the audio group.

2. Edit /usr/etc/security/limits.conf (on today's Tumbleweed, the Linux standard is /etc/security/limits.conf) to have two (more) lines:

@audio - rtprio 99
@audio - nice   -19

Remarks: The "-" applies both hard and soft limits. Setting nice to -19, one notch below the top-most value.

With these settings, MPD - at least in my per-user configuration - gets real-time scheduling, as evidenced by

$ ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,nice,comm'
PID   TID  CLS RTPRIO  NI COMMAND
1639  1639  TS      -   0 mpd
1639  1711  TS      -   0 io
1639  1712  FF     40   - rtio
1639  2282  TS      -   0 player
1639  2283  TS      -   0 decoder:flac
1639  2284  FF     40   - output:Internal

while playing. The two important threads get FIFO real-time scheduling. The file mpd.service provided in the MPD package is pre-configured for the required real-time settings; limits.conf allows MPD to do that.

Actually, for MPD it would be required to put only
@audio - rtprio 40
into limits.conf. nice doesn't apply to real-time scheduling, thus it need not be changed.

Final remark: Myself, I normally run MPD in a per-user configuration, done via
systemctl enable --user mpd.service
or alternatively just from terminal
mpd --stderr --no-daemon --verbose
for debugging purposes. The previous stuff works for both of these, but I cannot speak for other ways to run MPD.

---

Thanks for your patience and help.

[MaxKellermann]

* In the manual, the line `zgrep ^CONFIG_RT_GROUP_SCHED /proc/config.gz` contains an erroneous ^ character. It should read `zgrep CONFIG_RT_GROUP_SCHED /proc/config.gz` instead.

No, the ^ is correct.

[111MilesToGo]

Oh, no debate please. This is my openSUSE Tumbleweed output on a terminal (bash):

[~]$ zgrep ^CONFIG_RT_GROUP_SCHED /proc/config.gz
[~]$ zgrep CONFIG_RT_GROUP_SCHED /proc/config.gz
# CONFIG_RT_GROUP_SCHED is not set
[~]$ 

With the ^, nothing comes out of the command. Without it, the answer is supplied. Maybe the effect is due to bash.

[MaxKellermann]

If the output is empty, it means the option is not there, thus disabled. Works as designed. There's no point in showing the commented line, because it has no effect on the kernel configuration.

[111MilesToGo]

Ah, thanks!

[111MilesToGo]

Addendum:

• I rewrote the thread title to reflect the two items "alsa buffers" and "real-time scheduling".
• I marked the post that has your recommendations as "Answer", even though it shows "Answered by 111MilesToGo" now.
  Hope you agree.