Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] Audio stuttering on Pipewire (Read 7417 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

[SOLVED] Audio stuttering on Pipewire

Greetings,

I have been using Artix for almost 3 years now and I'm really happy with it, even though I've used the distro for this long I'm new on this forum.

I have a really annoying issue when it comes to audio: in certain situation the audio tends to drop/skip/glitch. This has been happening for a while now and I couldn't find a real solution on the Pipewire GitLab (where I opened an issue).

The configuration is completely vanilla (unless there is some rogue configuration file I'm not awake of).

I have found a couple ways to reproduce this issue:

1. Play a song using MPV
2. While the song is playing, open pavucontrol

Or

1. Play a song using Music Player Daemon
2. Open any kind of WebRTC call (Discord, Telegram, Jitsi Meet...)

Pipewire Logs will report that XRuns and "Client too slow!" messages. If I try to record anything using Tenacity (Audacity fork) while these issues are going on, the software will report dropouts.

I have tried:

- Using an external USB Mixer (Behringer XENYX QX1002USB) doesn't help with the issue
- The issue doesn't seem to present itself on Ubuntu Linux Live (had to try it to exclude an hardware issue)
- Forcing the quantum to higher values (like 2048) mitigates the issue, but comes with a lot of other issues (like not being able to hear people in calls after a while or echo-cancel modules breaking down)
- Incrementing alsa headroom doesn't seem to help

I'm attaching:
- Inxi -GSC -xx output
- pipewire log while the issue is happening (log level 5)
- screenshot of pw-top showing errors in MPV, Pavucontrol and hardware
- pw-dump output

I also have the output of pw-dump from the Ubuntu Live session, but quickly going through it with Meld didn't give me much information. Let me know if you want a copy of that too.

Let me know if you need any information, I'll do my best to provide you with anything that could help diagnosing the issue.

Thank you Kindly for your attention.

Re: Audio stuttering on Pipewire

Reply #2 –
Hello,

I have been using alsa only for several years.
I removed all pulse packets except libpulse and libcanberra.

I use alsa and the nice and very practical qastools mixer on different pc:
https://forum.artixlinux.org/index.php/topic,4318.msg27848.html#msg27848

Note: I don't play games and don't use wine or steam.
But I have sound in all my apps.

Re: Audio stuttering on Pipewire

Reply #3 –
I never used pulseaudio for non-systemd reasons, but did use pipewire for a while. One of the peculiar things about Alsa is it totally lacks any form of graphic equaliser or even tone control app for the output as far as I could find, which is really amazing something like that doesn't exist. Then I got better headphones and didn't need really need a graphic equaliser so much, so I uninstalled it. Another reason for that was the audio level would often get set lower then I had to go into alsamixer, then go past the first pipewire control page that only had one slider and into the real background page with all the sliders and adjust it, but then it would somehow get set low again in that background original ALSA page on some other boot, and wouldn't go up fully with the desktop or keyboard controls. That was a while back so it might not still do that.
 Anyway back on topic, it's a long shot, and probably isn't the problem here, but have you tried the linux-rt kernel? It's described as being a "real time" kernel that avoids dropouts when recording music by using a different scheduling priority to the regular kernel.

Re: Audio stuttering on Pipewire

Reply #4 –
Quote from: tintin – on
I have been using alsa only for several years.
I removed all pulse packets except libpulse and libcanberra.

Sadly that is not possible for me, some programs I use in my job have a dependency on Pipewire (Telegram-desktop is one of them), so I'm forced to keep it around and deal with this issue.

Quote from: ####### – on
it's a long shot, and probably isn't the problem here, but have you tried the linux-rt kernel? It's described as being a "real time" kernel that avoids dropouts when recording music by using a different scheduling priority to the regular kernel.

Thank you kindly for the suggestion: I tried the linux-rt kernel with no improvements.

I also installed sof-firmware and alsa-ucm-conf as suggested in the ALSA section of ArchWiki (I'm using a laptop), again with zero improvements. I also removed my user from the "audio" group, (as suggested by the ArchWiki) since I don't need remote users to access ALSA.

I ran the alsa-info.sh script to gather as much info as possible, and it is located here: http://alsa-project.org/db/?f=7e147515a6601390fac6a8841baf6f61af67352b

Re: Audio stuttering on Pipewire

Reply #5 –
I may have found the culprit.

I decided to try and terminate everything that wasn't vital for the system to see if something running was the issue.

Turns out that while running on this "manually induced minimal mode", Pipewire works perfectly.

After starting back up services and programs one by one, I found the culprit: Conky was giving the laptop a hard time for some reason.

After that I went and commented my config until I found the problematic module: i8k_cpu_temp.

Further investigation brought up that I could trigger the issue by the following command: cat /proc/i8k, which means there is something wrong with i8k.

Even further investigation brought me to the following github page: https://github.com/lochotzke/i8k which describes i8k as a "Kernel Driver to access the SMM Bios on Dell Laptops", after speaking with a Pipewire contributor, it seems that SMM is the bane of audiophiles' existance.

I will raise the issue with Conky (to discourage the usage of i8k by users) and may do the same with Kernel, to see if this could be somewhat fixed or deprecated.

Thank you everyone kindly for your help, I'll wait a couple of days to be sure no further issues arise, then I'll mark this thread as solved.

Re: Audio stuttering on Pipewire

Reply #6 –
i8k is mostly for older Dell laptops, if you look at the list of known supported models on your linked page, most are 32 bit except some early 64 bit ones like D series latitudes. Unless you have some specific reason to use it on a newer Dell then you can probably safely blacklist the module or something. The name comes from the "i8k" bug where those keys would often stop working on late 1990's Pentium 3 Dell's, because the metal keyboard base was used for additional heatsinking for the CPU which was located under those keys, and the BIOS thermal control was inadequate too. I think there are other ways to get temperature readings from the BIOS on newer (than D series, ie nearly all 64 bit model) Dell's without using that so it could be just a Conky issue using an old interface - but I don't know for sure.

Re: Audio stuttering on Pipewire

Reply #7 –
This goes to show that kernel overhead/intrerrupts are just as important for performance as the apparent cpu load :)

There is an option in the Pipewire config that is set a bit low if you started on older versions
Code: [Select]
    #link.max-buffers                      = 64
    link.max-buffers                       = 16                       # version < 3 clients can't handle more
also setting priority/rt settings and forcing higher buffer size by default could've helped too, and still can, give it a try

Re: Audio stuttering on Pipewire

Reply #8 –
Quote from: ####### – on
i8k is mostly for older Dell laptops, if you look at the list of known supported models on your linked page, most are 32 bit except some early 64 bit ones like D series latitudes. Unless you have some specific reason to use it on a newer Dell then you can probably safely blacklist the module or something. The name comes from the "i8k" bug where those keys would often stop working on late 1990's Pentium 3 Dell's, because the metal keyboard base was used for additional heatsinking for the CPU which was located under those keys, and the BIOS thermal control was inadequate too. I think there are other ways to get temperature readings from the BIOS on newer (than D series, ie nearly all 64 bit model) Dell's without using that so it could be just a Conky issue using an old interface - but I don't know for sure.

Thank you for this insight, this is something I didn't know. This will teach me to avoid mindlessly using stuff meant "for Dell laptops" blindly .

Quote from: Hitman – on
This goes to show that kernel overhead/intrerrupts are just as important for performance as the apparent cpu load :)

There is an option in the Pipewire config that is set a bit low if you started on older versions
Code: [Select]
    #link.max-buffers                      = 64
    link.max-buffers                       = 16                       # version < 3 clients can't handle more
also setting priority/rt settings and forcing higher buffer size by default could've helped too, and still can, give it a try


I tried forcibly increasing the buffer size as a first-trial to solve this issue, but that came with a lot of other issues, including not being able to hear other people in conversations anymore after 10 or so minutes.

I am now running a completely stock Pipewire configuration (which I reset, considering I adopted it just before the v0.3 switch) with no issues as far as I can hear (and see, with the help of pw-top).

Thank you everyone for your help, I will mark this thread as solved!

Re: [SOLVED] Audio stuttering on Pipewire

Reply #9 –
Quote from: Penaz – on
I may have found the culprit.
>...<
I decided to try and terminate everything that wasn't vital for the system to see if something running was the issue.
>...<
After that I went and commented my config until I found the problematic module: i8k_cpu_temp.
Some remarkable debugging there, kudos for doing it and also sharing. This had also affected me, for I run a self-written fan-control script on my M4800 laptop, written long ago to make use of the i8k interface, and I'd given up investigating the cause of cracking sound.

Quote from: ####### – on
The name comes from the "i8k" bug where those keys would often stop working on late 1990's Pentium 3 Dell's, because the metal keyboard base was used for additional heatsinking for the CPU which was located under those keys
Γηράσκω ἀεῖ διδασκόμενος.
 

Re: [SOLVED] Audio stuttering on Pipewire

Reply #10 –
There doesn't seem to be an i8k module in the kernel as standard, from a quick search on my system, although there is an i8k.h header file with some magic numbers to feed to the memory port. You don't actually need to use a kernel module to access the SMM BIOS interface, it can be done with superuser privileges from user space - so potentially any app could do this, which is something to watch out for. On my M4400 the fan speed can be set by that but immediately reverts back to the BIOS set speed, unlike earlier models. The BIOS cooling seems OK. On my M4500 the standard cooling is really powerful, I can run 8 threads at 100% for hours doing video conversions or large builds and the CPU gets cooler than when it's idling as the fan automatically hits full power controlled by the BIOS, just don't leave any chocolate on the left side or it gets melted by the hot air coming out!
lmsensors will give a cpu temp from the sensors command, not sure exactly how it gets it. On both these machines there is a dell_smm-isa field showing the CPU temp, but also a coretemp-isa field showing it too, for the separate cores, so perhaps that is from the ACPI interface.

Re: [SOLVED] Audio stuttering on Pipewire

Reply #11 –
Quote from: ####### – on
There doesn't seem to be an i8k module in the kernel as standard, from a quick search on my system, although there is an i8k.h header file with some magic numbers to feed to the memory port.
I run the last true CK-patched kernel, 5.12, I think i8k has been removed in the later series.

Re: [SOLVED] Audio stuttering on Pipewire

Reply #12 –
No, I was wrong, I thought when Penaz mentioned the module i8k_cpu_temp, it was referring to the name of a kernel module, but that's the name of a conky module. The name of the kernel module is dell_smm_hwmon which still is in the kernel, and it can be blacklisted like this if desired, to ensure it doesn't get loaded so nothing can use it and possibly disturb any audio:
Code: [Select]
$ cat /etc/modprobe.d/blacklist.conf 
blacklist dell_smm_hwmon
It also looks like there is a hex code to disable auto BIOS fan control on at least some newer models although I seem to remember on my M4400 something about that not working quite as expected and disabling all thermal management including the auto CPU speed control as well, leaving it running at minimum speed.
With that blacklisted I just get one set of CPU temperatures reported by "sensors" from lmsensors. Everything seems fine so far without it, and when it was loaded lsmod showed nothing using it, I think it's perfectly safe to blacklist unless you were actually using it for something:
https://github.com/torvalds/linux/blob/master/drivers/hwmon/dell-smm-hwmon.c

Re: [SOLVED] Audio stuttering on Pipewire

Reply #13 –
Quote from: nous – on
Some remarkable debugging there, kudos for doing it and also sharing. This had also affected me, for I run a self-written fan-control script on my M4800 laptop, written long ago to make use of the i8k interface, and I'd given up investigating the cause of cracking sound.

Hopefully this helped you getting closer to the cause. I try to always share the solutions I find, just in case someone else happens to be in my same situation.

I think having someone express an issue and just go "Oh I solved it" is not nice.

Quote from: ####### – on
No, I was wrong, I thought when Penaz mentioned the module i8k_cpu_temp, it was referring to the name of a kernel module, but that's the name of a conky module.
>...<
With that blacklisted I just get one set of CPU temperatures reported by "sensors" from lmsensors.

My bad, probably I should have made it clearer. For the sake of completeness, I just decided to use the ${hwmon ...} conky command that takes information from /sys/class/thermal/thermal_zone*/temp, but I have no idea what actually detects the temperature.