[SOLVED] some audio applications become unresponsive

tam1138 · 2026-11-06 02:13:40

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 (2026-11-07 02:34:32)

killertofus · 2026-11-06 07:40:23

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

seth · 2026-11-06 08:22:18

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"

tam1138 · 2026-11-07 02:34:09

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.

V1del · Today 15:16:13

Hmm does pipewire even run on that old of a state? The conflicts seth mentiones are very reminiscent of the problems you are seeing and many people are using the current packages without issue, if you are actually bypassing the pulse/pipewire conflict by retaining pipewire at a version it doesn't run at anymore due to dynamic libs then you can basically wait forever for this to get fixed. What's the output of seth's second command? As for the journalctl logistics in doubt using elevated priviledges should show journalctl contents regardless of group assignment but the fact it's that drastically cut off, have you ever done system level journal configuration or are perhaps running (/run)/var/log et.al. on a non persistent storage?

Arch Linux

#1 2026-11-06 02:13:40

[SOLVED] some audio applications become unresponsive

#2 2026-11-06 07:40:23

Re: [SOLVED] some audio applications become unresponsive

#3 2026-11-06 08:22:18

Re: [SOLVED] some audio applications become unresponsive

#4 2026-11-07 02:34:09

Re: [SOLVED] some audio applications become unresponsive

#5 Today 15:16:13

Re: [SOLVED] some audio applications become unresponsive

Board footer