09-Nov-2020, 01:32 AM
(This post was last modified: 09-Nov-2020, 01:39 AM by PeteCallaghan.)
(11-Oct-2020, 05:25 PM)agent_kith Wrote:(09-Oct-2020, 06:22 PM)PeteCallaghan Wrote: There seemed to be multiple mpd processes, so a loop was needed to catch them all:In theory you don't have to do this, just find the main PID, and the --threads option will move all threads to the CPUSet.
Code:
pids=$(pgrep mpd)
for pid in $pids
do
chrt -r -p 99 $pid
cset proc --move --threads --toset=user --force --pid=$pid
done
But, that's really dependent on how MPD works.. e.g. if MPD fork a thread on playback, there is always a chance this script will not work.. i.e. MPD starts, and the script moves the threads to the CPU Set, and when you play, MPD fork another thread, this is not trapped by the script as it happens after the fact..
There's prob a way to fix this, but I havn't investigate deeply enough yet... The current script, while brutally simple, actually yield quite a good audio improvement.. But I've mostly tested this in LMS and Squeezelite..
Please continue to explore this and let me know your progress, I'll incorporate your work into the next release too.
Some progress. I now have a crude but reliable process for applying the script after a reboot.
I add a line to crontab that waits for 10 minutes after a reboot and then applies the script:
Code:
#crontab-e
@reboot sleep 600; sh [path to script file]/mpdpriority.sh
I have not experimented with shorter sleep times, as this seems pretty reliable.
I'll research how to follow up your point about forked threads, to see if I can find any and see if they are allocated to the correct CPU set