Hi, I'm using built in mpd resampler libsamplerate and with cpu set enabled cause sound crackling stuttering, probably issue,.bacause enabling and disabling cpuset feature over and over again solve issue, cpu usage on i7 is max 10 percent, everything seems to be fine, probably cpuset fail.with some process management. After success operation, sounding perfect all time, problem is new start of snakeoil.
(11-Nov-2020, 11:27 PM)ravenman Wrote: [ -> ]Hi, I'm using built in mpd resampler libsamplerate and with cpu set enabled cause sound crackling stuttering, probably issue,.bacause enabling and disabling cpuset feature over and over again solve issue, cpu usage on i7 is max 10 percent, everything seems to be fine, probably cpuset fail.with some process management. After success operation, sounding perfect all time, problem is new start of snakeoil.
Can you share your cpuset config?
Also, are you setting any programs to run in run time? (Process priority).
(12-Nov-2020, 08:44 AM)agent_kith Wrote: [ -> ] (11-Nov-2020, 11:27 PM)ravenman Wrote: [ -> ]Hi, I'm using built in mpd resampler libsamplerate and with cpu set enabled cause sound crackling stuttering, probably issue,.bacause enabling and disabling cpuset feature over and over again solve issue, cpu usage on i7 is max 10 percent, everything seems to be fine, probably cpuset fail.with some process management. After success operation, sounding perfect all time, problem is new start of snakeoil.
Can you share your cpuset config?
Also, are you setting any programs to run in run time? (Process priority).
I had similar problems when I had mpd and upmpdcli both running as RT process priority and cpuset enabled with just one processor allocated to user
Secret Rabbit Code (libsamplerate) is pretty CPU intensive. It also sounds very good, I guess at the end of the day, trying to partition SRC in CPUsets, and/or make it run in real time will be detrimental to CPU performance.
When using a real time kernel, if a program running in realtime wants to execute an instruction, the operating system will drop everything and execute that instruction. The process to drop everything, prepare itself to execute the coming instruction is called "context switching", and this is a very expensive process... How quickly it can do this is the latency test we're doing in Cyclictest.
The overall system performance should decrease if you're trying to do too much for this.
A workaround is to increase any audio buffers, and see if that helps. At the end of the day, the idea is not to try and run everything in real time, it's all about striking a good balance to get the best audio out.