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
Good luck with the adventure keep us posted on what you uncover with cgroups
For the systemmd approach, you could do explore something along these lines*
[Unit]
Description=Set Playback daemons's CPU tweaks
Wants=mpd.service
After=mpd.service
PartOf=mpd.service
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/bin/set_cpu_shield.sh mpd
[Install]
WantedBy=multi-user.target
*Just a rough idea, please check if it works, and then if you have time, check if it follows “best practices” 
1 Like