I cannot even find this information on the Arch wiki or stack exchange. I already know how to change the storage scheduling, it has made my audio pausing worse if idle times are too high, or if the nr_requests is too high, and low latency, which overrides many of these settings, also doesn’t fix it.
So, how do I change the kernel CPU scheduper to one that can handle audacity or even a simple music player and opening firefox, without the audio pausing during playback?
I have tried -20 nice value on both audacity and pipewire, and still get audio pausing. Is this the lowest possible setting, or how do I set rt priority to these tasks?
That said, there is some kind of problem that pops up, causing audio/video to be a horrible mess. I ran into this with fedora on a desktop a while ago, and most recently with Nobara (fedora based) on a lenovo legion laptop, but this isn’t exclusive this this distro or hardware from my earlier search, but seems to only hit rarely so it’s hard to find a solution for… I have no idea what the underlying cause or how to debug it.
I don’t know your problem, but as I see it, it’s a bigger issue.
Let me ask you. What is happening to your CPU that you are having such performance problems? Stuttering voices or longer pauses when performance is lacking are nothing unusual, but stopping in the sense of “stop”?
Playing with priority per process is a bit like playing the lottery sometimes. Not every process likes being degraded.
A lower priority does not always mean that overall performance will improve. If there is an extreme lack of CPU resources, even -20 will not help much.
Personally, I set the governor to performance.
But if you have a large process that takes up your CPU and you want to limit this process a bit, you can always run it on a limited number of cores (taskset -c 0,1,2), and lighter processes only on released cores. For me, this always gives better system/application responsiveness than changing the priority.
To change the governor, you can use cpupower and if you use gui, additionally cpupower-gui. Also make sure that the CPU always runs at the appropriate clock speed and does not go to a lower clock speed.
If the core of the problem is running Firefox, and it overloads the machine so much that the sound stops, then you either have extremely old hardware or something very wrong with the OS.
Maybe you have other processes that are loading your CPU/disk, or you’re low on RAM?
Restore FF to factory settings, new profile, maybe some component generates load.
Are you on the stable version of FF? Check how the ESR behaves.
Run ff limited to the last core taskset -c X firefox (X the number of your last core counting from 0) and watch what happens…
PS
I read your other thread about this matter and… look what happens to the resources when the anomaly starts. Although with HDD it’s not that impossible.
When you run out of free RAM and swap comes into play or it doesn’t exist at all in the case of the hdd, it’s theoretically possible that something is lagging.
Contrary to appearances, the lack of swap with a small amount of memory on a loaded machine with a modern OS can be very lagging. I would rather use a small amount of swap. Also remember that FF eats some memory.
Or it’s time to invest in an SSD.
PS2
You can also experiment with FF variables and try to limit hdd usage mainly for cache. Personally, however, I have never noticed the difference.
Then consider if this is even a solution. If you can use an autonomous frequency governor (the cpu decides) and have the ability to install kernel 6.4 and above. Id test that out. Its the easiest way to see if the governor really is the issue
There are mainly two things when talking about the kernel scheduler: a thread scheduler, and a CPU governor.
The default scheduler on Linux is called CFS. However, kernel 6.6 will include a new thread scheduler implementation based on the EEVDF algorithm (sched/eevdf), effectively replacing CFS.
There were many attempts at implementing the EEVDF algorithm in the past, namely Brain Fuck Scheduler (BFS), and later Multiple Queue Skiplist Scheduler (MuQSS). These are not mainlined and require patching the kernel. There is no real reason to try to use them anymore in 2023, given all the work is largely superseded by EEVDF (which is mainlining soon).
Then under this scheduler, there’s Scheduling Policies. As noted by the poster above in man 7 sched, these are: SCHED_FIFO / SCHED_RR / SCHED_NORMAL / SCHED_BATCH / SCHED_IDLE. Scheduling Policies provide information to the scheduler on how to schedule tasks. These are meant to be set by a process. By default, Linux uses SCHED_NORMAL if unset.
There are tools such as schedtool that can be used to change this on the fly.
Then there’s the frequency scaling governor, which is used to control how to scale up and down the CPU clock. On Intel, this is intel_pstate (which is controlled mostly by the hardware), and on AMD schedutil is the current default (which uses hint from CFS to scale up/down the frequency). There’s also amd_pstate driver that is similar to intel_pstate, i.e., controlled by the hardware.
Under the scaling governor, there’s also a governor policy. These are the familiar names such as powersave, performance, etc. On the Intel side, there are two more knobs that control the governor:
/sys/devices/system/cpu/cpu*/power/energy_perf_bias (the EBF, 0 = powersave; 15 = performance)
/sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference (the EPP, 0 = performance, 5 = power)
For the OP, it may make sense to try running audio related stuff with SCHED_RR with schedtool. And if you’re running on AMD, try switching to amd_pstate.
So deep tuning of the system so that the machine does not interrupt the music.
Only the OP should ask themselves why this is happening in the first place. What is the OP doing that causes such a situation to occur and will such tuning change much if the PC chokes even when it runs Firefox.
OP states that the machine is
quad-core, hyper-thread Intel Xeon 3.7 Ghz max but it usually stays below 1 Ghz when not utilized.
2 GB 1600 Mhz DDR3.
7200 RPM hard disk, and another with a swap partition at the beginning of the disk, max speed is around 110 MB/s.
Yes, deep tuning may force the system to manage processes better, but such a load on such a machine should not cause such problems.
It would be good to find out where the bottleneck is first before we turn the settings upside down.
This seems to be a Fedora 38 related issue. I do not have this issue on Debian 11 on an older pc. I have upgraded pipewire on the Fedora system and it still has this issue. If anyone here runs Fedora 38 could please test this, as I also don’t remember ever having this issue on Linux, even when screen recording and having many desktops in expose display in Cinnamon. I had over 100 desktops all displayed at once while playing music and I don’t recall the audio ever pausing.
This is a new issue in Fedora, and I’d like to bring awareness to it. I don’t think it matters the audio source, so whether it is internet streamed or locally stored, if any Fedora users could please test this, I’d be grateful.
To minimize load, I am running Window Maker, it is extremely light. Sometimes, just browsing the menu is enough for the audio to pause and resume. Opening steam, by using the command line or run program, makes it pause and resume multiple times, as does opening just about any program.
When I launch a game in steam, and all the loading is finished and I start playing, with audacity playing, the audio is stable. I can play for 10 or 15 minutes without the audio pausing. But when I close the game, I then close steam. Closing steam or opening a program again, or even ooening and running windowmaker magnify program is enough for the audio to pause.
This happens much less if I use the Elisa music player, but it still happens. It happens in audacity with both ALSA and JACK. Pipewire is not an output option, even though it is installed and upgraded, so maybe a component is missing. I’d like to understand pipewire better, whether it should be an output option or audio server option. I know I can modify pipewire setttings as I can edit the config file and see the sample rate change in audacity.
I also know it’s running because it shoes in top. Giving both audacity and pipewire -20 nice values does not solve the ossue. Changing the pipewire quantun to 4096 also doesn’t help.
Sage advice. Don’t try to fix an issue until you’ve identified the cause. OP mentioned Arch. Not overly familiar with that OS, but it must have a system monitor. Would love to know what his CPU - RAM %'s are after a reboot with nothing active and the system idle. If it’s going to swap then that will interrupt things. Says it will run on as little as 512MB and OP has 2GB. Still, curious.
Does the problem happen with other audio devices as well? For me this sounds like it might be a bug in an really old driver and not matter what you change in other parts of the kernel will fix it. It’s just a thought I have, you’ll have to do the testing.
I am using Fedora, and the cpu use is quite low. I haven’t studied cpu use when opening programs, but I had top running when having the audio pauses. It is as if no matter what, Fedora’s scheduler is going to get everything completed, even if it means overriding my set priority/nice values. The CPU use is not more than 4% or so, even with the pauses.
Another bit of information is pw-top, which is seemingly useful context switches data, so the voluntary vs involuntary context switch data would be useful, I can add that. The number for involuntary context switches after maybe 10 minutes or so, is in the thousands, far greater than the number of audio pauses, which might be like 30-40 or so over that time.
I bet I could record low bitrate line in, with mono, low sample rates, just to record how many silences / pauses there are in the audio playback to help explain the issue.
You said Audacity is giving issues, try OBS and record audio. See what the results are. If the same, then it’s probably system, potentially drivers. If not, Audacity itself could be the culprit. Really hard to say.
Sorry for random question, but the pausing / stuttering audio, is it a playback issue, like an issue with the app/program itself (hence CPU sched/freq) or a reading from source issue (opening other apps/items causes hitches)
I presume playback is buffered, so any hitches would be offset from loading spikes, even on spinning rust, but as you mention storage, could it have an effect?
Separately, I have used the performance setting as Refed in Log’s link for gaming, which has helped
#cpupower frequency-set -g performance
And later in the link, it describes how to set it permanent, if it helps
I do not have the cpu power command, but am set to intel p-state using concatonate command on the /sys/devices/system/cpu directory.
In fact, with just audacity and konsole open, audacity just closed without warning, and I have completely removed oomd because I do not want programs to close unless I enter a command to do so. Without oomd, what recent update in fedora causes a program to close?
The project I have loaded is an hour duration, and using 124MB res, 63MB shared and 1.2GB virtual according to top.
Just something as opening konsole causes the audio to pause three times (quick 1/16 or 1/8 seconds) until konsole was finished loading.
I have a much smaller swap partition at 1.1G with 893M used and swappiness set to 60 as I thought going back to defauots and having buffers would help.
audacity just closed again, after just three minutes or so playback.
Memory use doesn’t look like it changed much. With audacity closed, memory stats are:
Mem, 1810 924 403 11 482 699
swap 1149 893 256
Reopening audacity and playback file of same project
mem 968 389 13. 452 646
swap 917 232
re-running free -m:
mem 967 327 13 516 647
swap no change
rerunning command about a minute later, buffers /cache continues to go up
975 215 13 619 639.
Audacity just closed again, after only five minutes or so of playback, I reran the command immediately:
979 101 27 729 620
swap no change
After a minute:
914 379 10 516 702
So, not only does Fedora have an audio issue, it now also has a new bug where programs using higher memory than what some programmer determines is acceptable, and closes that program. This did not happen, until I updated recently, thinking it would help the audio / scheduling issues.
