Arch Linux

tam1138

Member

Registered: 2007-09-10

Posts: 240

[SOLVED] some audio applications become unresponsive

On the one hand, mpv and firefox seem to work fine.  On the other hand, cmus and (some) Steam games frequently and reliably become unresponsive.  Audio chat in Discord works fine.  I say "become unresponsive" because they don't respond to input, the UI doesn't update, but they don't exit.  I attached gdb to cmus and some of its 9 threads are blocked waiting for mutexes or condition variables.  In the case of cmus, it seems like starting playback works, but then providing any input causes it to seize up.  In the case of Warframe via Steam, it initially works as long as focus remains on Warframe itself.  After a few switches to other virtual desktops, it reliably becomes unresponsive.  All unresponsive processes can be dealt with using kill -9.  I have seen nothing in journalctl, either bare or with --user, though I am not a systemd whiz, so I might be missing some special incantation to get more information.  I have no idea how to debug this.  Any guidance would be most appreciated.

Last edited by tam1138 (Today 02:34:32)

killertofus

Member

Registered: 2025-02-10

Posts: 271

Re: [SOLVED] some audio applications become unresponsive

please post a journal of the boot

sudo journalctl -b | nc termbin.com 9999 

for the previous (-1) one.

 sudo journalctl -b -1 | nc termbin.com 9999 

also the strace/gdb log

---

I Have Linux Perl Can i Download Gnome???

seth

Member

From: Won't reply 2 private help req

Registered: 2012-09-03

Posts: 78,751

Re: [SOLVED] some audio applications become unresponsive

I attached gdb to cmus and some of its 9 threads are blocked waiting for mutexes or condition variables.  In the case of cmus, it seems like starting playback works, but then providing any input causes it to seize up.

Dump all thread backtraces at this point, https://wiki.archlinux.org/title/Core_d … _core_dump
Ideally using https://wiki.archlinux.org/title/Debuginfod

pacman -Qi cmus # it has a lot of plugins, might be useful to know which ones are installed

Generically the most common screw-up would be colliding pipewire/pulse or deprecated pipewire-media-info or actually just using the deprecated pulsenoaudio

pacman -Qs "wire|pulse"

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

tam1138

Member

Registered: 2007-09-10

Posts: 240

Re: [SOLVED] some audio applications become unresponsive

Thanks for both your answers.

I can't get journalctl to show log messages from before the user slice is started.  My reading of the ArchWiki page on journalctl is that I should be able to see them if I'm in the wheel group, which I am.

I can't get gdb to play nice with debuginfod, either: gdb itself reliably crashes a few hundred megabytes into the download.  (In case this raises concerns about corrupt disk, I also ran a zpool scrub and it came back clean.)

All that said, I think I may have resolved the issue, kind of.  I noticed in my pacman.conf that I had previously put all the pipewire-related packages in IgnorePkg: I vaguely remember having issues with pipewire a while ago (around May, according to /var/log/pacman.conf), at which point I downgraded them all to 1:1.6.5-1, threw them all in IgnorePkg, and had a happy system.  Then in late October, I removed them from IgnorePkg, they were upgraded, and I just didn't put two and two together.  So I just now again downgraded them all to 1:1.6.5-1 and everything seems stable.

In doing all this, I began to wonder whether the fact that I am using the LTS kernel might be related: perhaps pipewire is doing something with audio or related stuff that just doesn't work on 6.18.60-1-lts.

I'm going to mark this solved, and will plan to keep pipewire and friends locked at 1:1.6.5-1 until the new LTS kernel is released and we'll see how things go then.  Thanks again.