Hi everybody, I'm an openSUSE Tumbleweed user and I run a self built kernel that basically consists in openSUSE's default kernel + all of zen patches from the various branches of the zen-kernel repo. Starting from the Linux 5.3 release, if I recall correctly, I've faced a weird issue that still persists to this day: if the kernel is built enabling MuQSS, and if I log into a KDE Plasma+Wayland session, the audio output is very glitchy and it often skips and plays a very short snippet of some sound that was played a few seconds before the glitch. Seems very similar to what is described in the first paragraph of this Reddit post: [link], except that the glitches are very very frequent and seem to be triggered by any cpu load spike (even the smallest one), because they often occur when opening a program, when switching workspaces, when clicking on window titlebars, basically, whenever I interact with the desktop environment.
This doesn't happen if I apply all of zen's patches leaving out MuQSS. Kernels built using MuQSS don't cause this problem if I use Xorg. This seems to be a very weird bug and I'm not sure if you guys are the ones to whom I should be reporting it, but anyway, I hope someone can give me their opinion on this.
Thanks :)[/url]
Back to top

Are you using a port for Liquorix on OpenSuse or a stock kernel + zen patches? To take advantage of MuQSS properly, you'll want:

High resolution timeouts - this escapes the HZ granularity of the kernel tick
Forced Threaded IRQS - moves scheduling of IRQs to MuQSS

And in userspace, you'll want pulseaudio to start with the highest priority your system lets you. If you can get a niceness of -19, that's preferred. If you can get pulseaudio to start with SCHED_FIFO or SCHED_RR, that's even better.

You can from your terminal have pulseaudio run with isochronous scheduling by executing schedtool -I $(pidof pulseaudio). This can be done from your user without escalating privileges, and gets the same behavior as realtime processing without the chance of completely destroying your system with a runaway process.

Lastly, run your system with performance mode in cpufreq. A lot of distributions love to start systems with ondemand or intel-pstate's powersave, despite the kernel's preferred configuration to run in performance mode. However, MuQSS schedules processes in a way that prevents these governors from properly ramping up CPU frequency. There's a chance you're running at your processor's lowest frequency and your CPU at that speed is not capable of filling your audio buffers while multitasking. See if running your processor at max speed fixes the problem.

Can you verify that any of the above fixes your audio xruns?

EDIT: One other thing you can try considering you're running a stock kernel with zen patches + muqss, try playing with the yield value in /proc/sys/kernel/yield_type. It could be that Wayland is doing something nasty with yield (an ambiguous function call), and changing how yield behaves solves your problem.
Back to top

Thanks for the tips. I'll try them and let you know if they are of any help.
Back to top

Ok, so I've rebuilt enabling forced IRQ threading. What I am using is: stock openSUSE kernel (5.5.11) + zen patches from all branches + missing Con Kolivas patches (basically only one of them is missing in zen, i.e. the one that sets Preemptible as the recommended Preemption type for desktops, in place of Voluntary Preemption).
I've tried your tweaks and found out that running pulseaudio using that schedtool command has no effect. Playing with yield_type has no effect as well. The only thing that seems to contain the issue is runing the cpu using intel_pstate's performance gov instead of powersave, which indeed is the default governor in openSUSE. This does not fix the issue, but these audio skips definitely happen less often when using performance. The problem is that my pc is a laptop, so running the CPU at the max freq forever is definitely not an option for me, as it would lead to sky-high battery drain.

Anyway, when logging into an Xorg KDE session, audio works perfectly even with MuQSS and the powersave governor. This issue is driving me crazy...
Back to top

So, I tried using Wayland myself with KDE. I'm running Arch and the latest stable packages for all the major components.

One thing I noticed is that kwin for wayland automatically sets its own priority to SCHED_RR. As a side effect, child processes seem to also get this higher priority. Open up ksysguard and sort by niceness, you should have a lot of processes running at RR 1.

Here's the commit that changed its behavior: phabricator.kde.org/R108:7c8003f7f6212ccad7de652943f94d501365d30f

As an experiment, what happens if you reset all these processes to a nice of 0 with the normal scheduler?

Unfortunately, I'm not able to reproduce the sound skipping that you're getting. Maybe it's the version and/or implementation OpenSuse chose?

Here's my system for comparison:


Back to top

It is indeed true that in a Wayland session I have lots of processes with RR 1 niceness (kwin, plasmashell, latte-dock and several others).

You suggested that I try to reset their niceness to 0 with the normal scheduler, but I've never done such thing in the past so I'd like to ask you if this is the command I should run:

Should I run it manually for each of the RR 1 processes? And what do you mean by saying "with the normal scheduler"? No MuQSS?

My system is described here:


Thanks for dedicating some of your time to my tricky question :)
Back to top

If you don't already have schedtool, you'll want to install that since it supports changing the scheduling type per process.

As for the command, it'll look like: schedtool -N -n0 $(pidof name_of_process)

However, I'd recommend trying to reset the priorities through ksysguard if you can. Ksysguard throws up a dialog where you can change niceness, scheduling type, and IO scheduling. For what you're doing it'll probably be a lot easier than collecting all the PIDs.

EDIT:

You should get a replacement for that battery!
Back to top

Ok, so after setting normal scheduler & 0 nice level for all those RR 1 processes, and after enabling realtime scheduling with realtime prio = 3 in /etc/pulse/daemon.conf (the "0 nice level" tweak alone wasn't enough), I managed to listen to 4 minutes of music without skips or glitches, which is a good result. I'll keep testing this setup to see if the good result is confirmed.

OT: yes, the battery is old, and the level and capacity percentages are very unreliable. The capacity reported by inxi swings between 44 and 65.. I'll definitely replace it when it won't last long enough for my needs, but for now, it does.
Back to top

Ah, that's great! My suspicion is the exaggerated priority levels for kwin, and the fact that it leaks to subsidiary applications, is fooling MuQSS into thinking audio is less important.

In general, MuQSS takes priority differences much more seriously than CFS. This means running desktop applications and the window manager at SCHED_RR can completely interrupt pulseaudio, even if you're running a nice of -19 without realtime priorities. That's how you're probably getting audio skips.

Especially with your CPU, the i5-6200u, having only two physical cores doesn't give you much headroom when many applications are allowed to clobber deadlines of everything on the system.

Crossing my fingers this was the problem!
Back to top