rtio priority in config file

[Konzol]

My "very audiophile" friend wish to run 'rtio' and 'output' threads with real-time priority ( git version of mpd )
I made a small patch, added "rtio_priority" config option into mpd.conf, so my friend can play with this option.

Code: Select all

diff --git a/src/config/ConfigDefaults.hxx b/src/config/ConfigDefaults.hxx
index 09380f4..4c0e491 100644
--- a/src/config/ConfigDefaults.hxx
+++ b/src/config/ConfigDefaults.hxx
@@ -22,5 +22,6 @@
 
 static constexpr unsigned DEFAULT_PLAYLIST_MAX_LENGTH = 16 * 1024;
 static constexpr bool DEFAULT_PLAYLIST_SAVE_ABSOLUTE_PATHS = false;
+static constexpr unsigned DEFAULT_RTIO_PRIORITY = 50;
 
 #endif
diff --git a/src/config/ConfigOption.hxx b/src/config/ConfigOption.hxx
index 6979095..ce25417 100644
--- a/src/config/ConfigOption.hxx
+++ b/src/config/ConfigOption.hxx
@@ -78,6 +78,7 @@ enum class ConfigOption {
 	DESPOTIFY_USER,
 	DESPOTIFY_PASSWORD,
 	DESPOTIFY_HIGH_BITRATE,
+	RTIO_PRIORITY,
 	MAX
 };
 
diff --git a/src/config/ConfigTemplates.cxx b/src/config/ConfigTemplates.cxx
index 683e30c..9c382dc 100644
--- a/src/config/ConfigTemplates.cxx
+++ b/src/config/ConfigTemplates.cxx
@@ -73,6 +73,7 @@ const ConfigTemplate config_param_templates[] = {
 	{ "despotify_user", false, true },
 	{ "despotify_password", false, true },
 	{ "despotify_high_bitrate", false, true },
+	{ "rtio_priority" },
 };
 
 static constexpr unsigned n_config_param_templates =
diff --git a/src/thread/Util.cxx b/src/thread/Util.cxx
index 5b61b62..a4336a5 100644
--- a/src/thread/Util.cxx
+++ b/src/thread/Util.cxx
@@ -29,6 +29,13 @@
 
 #include "Util.hxx"
 #include "system/Error.hxx"
+#include "config.h"
+#include "config/ConfigGlobal.hxx"
+#include "config/Param.hxx"
+#include "config/ConfigDefaults.hxx"
+#include "config/ConfigOption.hxx"
+#include "config/ConfigError.hxx"
+
 
 #ifdef __linux__
 #include <sched.h>
@@ -101,7 +108,11 @@ SetThreadRealtime()
 {
 #ifdef __linux__
 	struct sched_param sched_param;
-	sched_param.sched_priority = 50;
+	sched_param.sched_priority = config_get_unsigned(ConfigOption::RTIO_PRIORITY, DEFAULT_RTIO_PRIORITY);
+	if ( sched_param.sched_priority > 99 )
+		sched_param.sched_priority = 99;
+	if (sched_param.sched_priority < 1 )
+		sched_param.sched_priority = DEFAULT_RTIO_PRIORITY;
 
 	int policy = SCHED_FIFO;
 #ifdef SCHED_RESET_ON_FORK

[max]

What use is this option? They already run with real-time; what use is it to use a different real-time priority than the default?

Layering violation in your patch: thread/Util is a generic library which must not access the config library.

[Konzol]

I wrote, one of my friend want to test the 'rtio' and 'output' threads using different priority level.
I've seen only three possibilites. The first one create some binary with different values of the sched_param.sched_priority ( thread/Utility.cxx ). The second one add a command line parameter, and the third one add a new config file parameter. It is only a trick or hack, no more and no less.

Code: Select all

#ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm'
 PID   TID CLS RTPRIO COMMAND
22674 22674  FF     40 mpd
22674 22677  FF     40 io
22674 22678  FF     50 rtio
22674 22679  FF     40 player
22674 22680  FF     40 decoder
22674 22681  FF     50 output:I2S

#grep prio /etc/mpd.conf
rtio_priority			"50"



# ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm'
  PID   TID CLS RTPRIO COMMAND
22724 22724  FF     40 mpd
22724 22727  FF     40 io
22724 22728  FF     99 rtio
22724 22729  FF     40 player
22724 22730  FF     40 decoder:flac
22724 22731  FF     99 output:I2S

# grep prio /etc/mpd.conf
rtio_priority			"99"

Layering violation in your patch: thread/Util is a generic library which must not access the config library.

Sorry, I don't know about. Question: how can I get a value from config library without layering violation?

(sorry for my poor english )

[max]

I wrote, one of my friend want to test the 'rtio' and 'output' threads using different priority level.

Sure, but... why?

[Konzol]

Sure, but... why?

Because... mpd itself works fine, but every changes in the host system - start/stop processes, changing process scheduling priority etc. changes the 'sound quality'. I think the playback is 'bit perfect', but not 'time perfect'. It contains time fluctuations aka jitter. My 'patch' gives flexibility for the 'hardcore audiophiles' to fine tuning the system.. ( chrt -f 99 mpd /etc/mpd.conf not a good solution, because the rtio and output threads falls back to 50 ).

[max]

Not 'time perfect' ... a-ha.
Do you even know how audio playback works? Do you know that timing depends not on the CPU, but on the audio chip? That your CPU's only job is to keep the audio chip's ring buffer non-empty? And that it doesn't matter when in the time budget that happens? It doesn't make a difference, not even an extremely tiny one.
Anyway, thanks for sharing your code, but it's based on a misunderstanding and is indeed useless.

[Konzol]

Max, thank you!
Theoretically you have truth, but in practice the sound sounds different, when changing the process priority, or when user stops some generally unused processes - for example the web server, time server etc. By the way why you made standalone RT threads for outputs, when the default audio buffer large enough to store 12 seconds cd quality audio data...
We tested my code on ARM based Single Board Computer, using it's I2S output, and is indeed useless, but works.

Thank you your attention!.

[max]

why you made standalone RT threads for outputs, when the default audio buffer large enough to store 12 seconds cd quality audio data

You obviously don't know what you're talking about, and I have a feeling you don't even know what real-time really means.
The problem is not MPD's decoder buffer (the large one) - when it drains empty, nothing happens.
The only buffer which must never run empty is the DAC's ring buffer. This buffer is not in your computer's RAM, it's in the DAC. That one is usually very small; sometimes, it holds just a few tens of milliseconds.

Oh and about your alleged magical difference between "theory" and "practice" - I've heard that fairy tale so many times, it bores me already. Usually, I don't even reply, but I try hard to take people seriously who post code, which you did. But sorry, your fairy tale is bullshit. Your DAC doesn't know how many processes run that remote computer with the CPU which also happens to run MPD and happens to keep DAC's ring buffer full. The DAC has no way to even measure how many web servers, time servers etc. run on the CPU, because it's a different entity. How on earth could the DAC emit a different analog signal just because some other computer executes certain instructions?

There's so much superstition among audiophiles, and you're making a fool of yourself by posting this here.

[Konzol]

[

You obviously don't know what you're talking about, and I have a feeling you don't even know what real-time really means.

We will not collide this

The problem is not MPD's decoder buffer (the large one) - when it drains empty, nothing happens.
The only buffer which must never run empty is the DAC's ring buffer. This buffer is not in your computer's RAM, it's in the DAC. That one is usually very small; sometimes, it holds just a few tens of milliseconds.

We also totally agree with that!

Oh and about your alleged magical difference between "theory" and "practice" - I've heard that fairy tale so many times, it bores me already. Usually, I don't even reply, but I try hard to take people seriously who post code, which you did. But sorry, your fairy tale is bullshit. Your DAC doesn't know how many processes run that remote computer with the CPU which also happens to run MPD and happens to keep DAC's ring buffer full. The DAC has no way to even measure how many web servers, time servers etc. run on the CPU, because it's a different entity. How on earth could the DAC emit a different analog signal just because some other computer executes certain instructions?

I know you do not have to answer any audiophile related questions. I do not consider myself an audiophile.

Some words about the theory and pracitce (you do not have to believe it ,if you want to try it out):
foreword: I know, the "sound of the mpd" is not true, but when only the mpd changed on the system...

- sorry, but "well known fact" different mpd versions can produce different sound... for examle 0.20.10 vs 0.20.13. Building from source, on the same system, using same settings. (I know, the mpd itself has no sound quality, but in my opinion the sound of the 0.18.xx version was better than 0.19.xx, the 0.20.xx also very good )

- the "sound of the mpd" differs, when compiling with -O2 or -O3 -march=native gcc option

- the "sound of the mpd" differs, when playing wav or flac version of the same music.

I tried to list phenomena that are easy to observe, not just expensive devices. There are many similar effects, for example reducing the number of the running processes, change process priority, playing from ram etc.
I think these phenomena are caused by linux kernel timing errors / uncertainties. Maybe the task changes do not happen at the same time, process scheduler issue/properties I do not know exactly... using USB, I2S, SPDIFF the effects are the same...

From a technical point of view, the proposed amendment is in principle superfluous, but it does work practically. ( by the way a hardcoded system settings is not a really elegant solution... )

There's so much superstition among audiophiles, and you're making a fool of yourself by posting this here.

It may be audiophile foolish to think of what I wrote. Maybe that too. You may decide yourself.

[max]

I think these phenomena are caused by linux kernel timing errors / uncertainties.

Sigh. Your thought is wrong, and I already explained why. I could repeat myself now, that there is no magic telepathy between DAC and CPU, but it's pointless. You're just yet another guy who insists on his superstitious beliefs. Your explanations of differences between MPD 0.20.10 and 0.20.13 would be hilarious, but the joke already worn out long ago. Anyway, thanks for today's quick giggle, and have fun with your new real-time threads!

[Konzol]

The usual max style answer. That's what I expected. The phenomenon does not exist because I do not want it to be. True, you explained something, but apparently you did not notice the trap in your own answer. There is no word about magic, just about time.

[skidoo]

If you are afraid of operating system related timing problems get a decent audio interface with word clock input (eg RME Fireface) and a word clock generator with 10M input (eg Mutec Smart Clock). Sync word clock with GPS receiver or atomic clock.

[max]

Huh? How does synchronization with a real-time clock help? All the audio device needs is a steady/monotonic clock, and a reference clock to initialize with is not needed at all. Why would it?
Which audio device's clock can be compromised by a remote operating system, anyway? Even if the device's clock was not stable enough - that error would be unaffected by the operating system.
skidoo, is this satire to ridicule Konzol further?

[skidoo]

Maybe my earlier posting contains some traces of irony

Some audiophiles seem to be very worried about jitter. Using a very accurate and very long-term stable word clock is, in my humble opinion, an effective solution. At least a minimum deviation from the built-in clock generator is measurable, but most certainly not perceptible. However, not all motivations are rational in a hobby. So why not use a word clock for the good feeling while listening? Just to be sure...

[Konzol]

I appreciate the irony
Something I did not emphasize enough. I talked about a single board computer. ARM-based machine with built-in I2S or SPDIF interface. Mostly I use the I2S interface. SPDIF and USB output should in principle cover the remote computer timing problems. The other question is whether they are doing it or not.