I have experimented with ‘cset’ to shield music processes (mpd, spotify) in a dedicated CPU, moving most other processes to the remaining ‘system’ set of CPUs, and setting the process priority to RT.
This brings a useful improvement to audio quality. It looks pretty simple to package this up in a system plugin.
Would anyone else be interested in this?
At present I have created some bash scripts .
The ‘cset’ package has a ‘shield’ function. This separates the CPUs into two sets: ‘user’ and ‘system’. The shield command creates a ‘user’ set and moves most processes into ‘system’.
Allocating 1 CPU to ‘user’ via the shield command means that the processes running ‘user’ have fewer competing processes for that CPU.
This is the script that needs to be run once to install cset, once Volumio is installed:
apt-get update
apt-get install cpuset
This is the script that needs to be run after volumio has started, to create the shield and move mpd and vollibrespot into the ‘user’ set (allocating CPU 0 to the ‘user’ set):
cset shield -c 0-0
pids=$(pgrep -x mpd)
for pid in $pids
do
chrt -r -p 99 $pid
cset proc --move --threads --toset=user --force --pid=$pid
done
pids=$(pgrep -x vollibrespot)
for pid in $pids
do
chrt -r -p 99 $pid
cset proc --move --threads --toset=user --force --pid=$pid
done
2 Likes
I would say that if you’ve got this far then you are quite up to the job of writing a plugin! There is help aplenty out there, if they could manage to guide me (with the self-belief of a dead slug) through the process then I’m sure you’ll be fine, and find it a most rewarding process to go through, even if it doesn’t seem that way at the time!
Absolutely interested in a plug-in like that! How does this compare to processor isolation (I’ve started a thread about this a couple of months ago)?
What I did is the following:
nano /boot/userconfig.txt
Added line: isolcpus=2,3
nano /boot/cmdline.txt
Added at the end of the line: isolcpus=2,3
In order to set MPD to 2d and 3d processor:
sudo pico /lib/systemd/system/mpd.service
Password: Volumio
and changed the line: ExecStart=/usr/bin/mpd --no-daemon
to
ExecStart=/usr/bin/taskset -c 2,3 /usr/bin/mpd --no-daemon $MPDCONF
Rebooted
Check if the 2d and 3d CPU are isolated:
cat /sys/devices/system/cpu/isolated
It gives back: 2,3
It looks like your technique is doing something similar. One difference is that cset shield moves most processes away from the ‘shield’ CPU(s) so may better isolate the music replay processes.
Thanks very much for your encouragement. I’ll take a look at randomizer
2 Likes
I have created a basic plugin and submitted it for publishing with a pull request. Fingers crossed …
Interesting! Eager to try it. I see it has been uploaded already. Should I switch off my CPU isolation before I try this? Thanks in advance
1 Like
I think it would make sense to switch off your isolation first. It’ll be interesting to find out if you hear a worthwhile difference between the two approaches
1 Like
I will check it out next week Pete. Busy schedule this weekend. Will do some serious and honest comparison soon. Did you had feedback about the plug in so far?
1 Like
Excellent Vennesch. I look forward to hearing what you think.
I have not had feedback yet from anyone else.
I am considering a second plugin to allow assignment of RT priority to selected processes.
I have previously applied it to the ethernet and USB interrupts to bring a further improvement to audio quality
Hi, Pete
I have tested it and I like it! It definitely brings some improvement. Good idea on the second plugin. Perhaps you can bundle them into 1?
Cheers,
Simon
Hi Simon,
Yes, perhaps it makes more sense to extend the plugin.
I am testing a change that adds an option in the plugin settings to list the tasks allocated to the user set.
Each time the player is restarted the shield needs to be recreated, which is a bit of a pain. I haven’t figured out how to detect within the plugin that mpd or spotify connect have been restarted, so you have to manually turn the plugin on and off to recreate the shield.
At least with my latest change it’s easy to see if the shield is active or not.
Im almost certain there was another feature request today, which would need an indication that spotify connect is active/deactived(Something about autoplaying radio)
@ashthespy
If im not mistaken, spotify connect is your plugin? perhaps the plugin could be updated to indicate that its actively in use, and when not?
Greetings,
I am not sure I complete understand what exactly is “actively in use” - do you actively playing data? Then you can just use the volumio API for that.
Ah, looking a bit more at what you guys are doing, if I understood correctly, you wish to perform some actions each time the various daemons are restarted?
There are two options
– Register a callback the same way ut is done by the plugin for the parameters ([alsa.outputdevice','alsa.outputdevicemixer','alsa.device','system.name']). But this will result in a race nightmare, unless you hardcode a lowest device denominator delay.
– More elegant IMO - use systemd.
You can define a service for your plug-in the is linked using PartOf to the various other daeomns. systemd should then manage the tree of dependents during a restart of mpd/vollibrespot/tidalconnect.
This could actually be extended to a volumioDaemon.target that could be used by the core Volumio to signal daemons require reloading, without you having to fix your plugin for every new daemon added…
Ah that’s an elegant sounding mechanism. I’m not sure how to define a service or how to interact with Systemd, but I’ll have a look for examples.
My plugin could do with a more elegant way of identifying the music processes. Currently it hard codes mpd and vollibrespot
Btw, is what your trying to achieve possible using systemd’s cgroup slices?
https://www.freedesktop.org/software/systemd/man/systemd.resource-control.htm
You could then just have your plugin edit the daemon’s services and attach to the custom slice.
Out of curiosity – Do you hear a big difference w.t.r. vollibrespot?
1 Like
I’m not familiar with cgroup slices, so I’ve read some articles to get an understanding.
My understanding is that cgroup is a mechanism that the kernel uses to allocate resources (such as memory or CPU time) between hierarchical groups of processes.
For example we could allocate all music services to a ‘volumio-music’ group and define the ratio of cpu time and other resources Vs other processes.
In contrast, cset operates on a per process model and sets the CPU affinity for selected processes. Cset shield takes this a step further by allocating CPUs to either a ‘user’ or a ‘system’ group, and by default moving the affinity of most processes to ‘system’ CPUs. My plugin then allocates selected music processes to ‘user’. This has the effect of reducing the number of processes sharing CPUs with music processes.
It’s possible that Systemd cgroup slices could also have this effect, or a similar effect. I don’t really know.
I think it would need some experimentation to try and find out if one sounds better than the other.
One advantage of Systemd cgroup is that it elegantly and declaratively manages the resource allocation without the need to worry about processes stopping and starting, if all volumio music processes declared themselves part of the same cgroup.
In answer to your final question, to my ears the difference from applying cset shield for vollibrespot is similar to that for mpd. It’s a bit subtle, but I find it makes the music more engaging, with more life.
I plan to open up configuration of the plugin so that people can control all the parameters and listen to what sounds best.
In the first instance I will add configuration for:
- Which CPUs to allocate to ‘user’
- Which processes to include in ‘user’ (currently mpd and vollibrespot)
- Which processes to assign RT priority (currently mpd and vollibrespot)
I will then look at adding an optional facility to create a systemd cgroup, with parameters for resource allocation and control of the processes to include.
3 Likes
You might like to set up a new post in the ‘Plugins’ section of the forum. This would then be easily found by future interested parties, and allows you a way of keeping people updated with developments and answer any queries.
Edit: LOL, just saw the location of this post … I’d thought it was in general help. 
Would you mind changing the post title to ‘[PLUGIN] Music Services Shield’ or whatever?
Actually, a new post (with reference to this thread) might still be best, because it would enable you to describe the plugin & it’s use in a more logical sequence than above.
2 Likes