Help please: Music Player Daemon and Real-Time Scheduling (alsa audio output)

I am using Music Player Daemon (MPD) on my Tumbleweed, outputting the audio bit-perfectly direct to alsa. Recently, I discovered a problem relating to latency, i.e. I got stuttering of the audio when MPD got loaded with some intense task (decimating DSD 256 to PCM 24/352.8). I seeked help from the MPD maintainer (Max Kellermann) and was advised about a latency problem being the probable issue. His first recommendation to increase two buffers relating to alsa output helped a bit, but not completely.

His second diagnosis was that real-time scheduling seems to be broken on my Tumbleweed. The MPD verbose log has a line like this at every start of MPD:

Dec 01 14:15 : event: RTIOThread could not get realtime  scheduling, continuing anyway: sched_setscheduler failed: Operation not  permitted

So it is true that real-time scheduling doesn’t happen for MPD.

rtkit is installed, and the rtkit-daemon reveals this status message:

# systemctl status rtkit-daemon 
**●** rtkit-daemon.service - RealtimeKit Scheduling Policy Service 
     Loaded: loaded (/usr/lib/systemd/system/rtkit-daemon.service; **disabled**; preset: **disabled**) 
     Active: **active (running)** since Fri 2022-12-02 10:40:41 CET; 2 days ago 
   Main PID: 1823 (rtkit-daemon) 
      Tasks: 3 (limit: 4915) 
        CPU: 2.331s 
     CGroup: /system.slice/rtkit-daemon.service 
             └─1823 /usr/libexec/rtkit/rtkit-daemon

The same conclusion can be drawn, following the MPD manual at https://mpd.readthedocs.io/en/stable/user.html (search for “real-time”) from the ps command:

# ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm' 
  PID   TID CLS RTPRIO COMMAND 
 1663  1663  TS      - mpd 
 1663  1735  TS      - io 
 1663  1736  TS      - rtio 
 1663  3923  TS      - player 
 1663  3924  TS      - decoder:flac 
 1663  3925  TS      - output:Cayin RU

From that, too, I conclude that nobody gets real-time scheduling.

Remark: Directly from the MPD manual, this ps command should deliver something like:

# ps H -q `pidof -s mpd` -o 'pid,tid,cls,rtprio,comm'
PID   TID CLS RTPRIO COMMAND
16257 16257  TS      - mpd
16257 16258  TS      - io
16257 16259  FF     40 rtio
16257 16260  TS      - player
16257 16261  TS      - decoder
16257 16262  FF     40 output:ALSA
16257 16263 IDL      0 update

The MPD manual also states:
This works only if the Linux kernel was compiled with CONFIG_RT_GROUP_SCHED disabled. Use the following command to check this option for your current kernel:

zgrep ^CONFIG_RT_GROUP_SCHED /proc/config.gz

On my Tumbleweed, this command doesn’t show any output. Any other way to check for that kernel compilation flag?

I am coming here to seek for help, please.
How can I get real-time scheduling for MPD?
What about that kernel compilation flag CONFIG_RT_GROUP_SCHED? Is it disabled on TW?
Any suggestions are highly welcome. Please feel free to reply and ask if the information provided is too short or not clear enough.

Thank you very much in advance!

Remark: I am running MPD as a user service, started by

systemctl enable --user mpd.service

Cantata is being used to control MPD.

To answer a probable question: The same

RTIOThread could not get real-time scheduling

is being thrown when running MPD from terminal, not as a service.

Hi
The ^ should not be there…


zgrep CONFIG_RT_GROUP_SCHED /proc/config.gz
# CONFIG_RT_GROUP_SCHED is not set

openSUSE:Submitting bug reports - openSUSE

Hi, thank you. Was copied from the manual. So that precondition is fulfilled; will check myself.

Checked, CONFIG_RT_GROUP_SCHED is not set. Good at least in that regard.

However, is there any other help available out there regarding the issue described in the top post? Thanks again for any feedback!

Oh well,self-help and a search here provided the solution I was looking for. The clue came from old thread here on the forum, https://forums.opensuse.org/showthread.php/400774-Pulseaudio-Can-t-get-realtime-or-high-priority-permissions.

In order to allow Music Player Daemon to 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

Remark: The “-” applies both hard and soft limits.

[INDENT=2]
[/INDENT]
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 file mpd.service provided in the MPD package is pre-configured for the required real-time settings; limits.conf allows MPD to that.

Actually, for MPD it would be required to put only

@audio - rtprio 40

into limits.conf.

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

Uhhh, so sorry, I was trying to get the formatting correct via editing, but I was thrown out of it by the 10-minute editing time limit. Thus the formatting isn’t nice …

Here’s my post in the formatting I intended it to be … please disregard the previous two posts!

Oh well, self-help and a search here provided the solution I was looking for. The clue came from an old thread here on the forum, https://forums.opensuse.org/showthread.php/400774-Pulseaudio-Can-t-get-realtime-or-high-priority-permissions.

In order to allow Music Player Daemon to 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, as opposed to the thread quoted above.

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 viasystemctl enable --user mpd.service

or alternatively just from terminalmpd --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.