On my testing #Librem5 running #Mobian I had obviously installed a workaround to get echo cancellation for calls by using #pulseaudio for audio. I had forgotten about it and after some update or hardware tinkering sound just didn't work anymore.

I found out that I knew not much about sound and while trying to understand how it is supposed to work I wrote some of my findings on the Librem5 community wiki.

I'd be thankful for corrections and additions to be able to move the page soon out of the work in progress section.

Using #pipewire for screen sharing alongside #pulseaudio for audio hasn't been a great experience and complicated stuff a lot. I had it working by disabling all audio in pipewire, but I switched back to a complete pipewire setup.

I enabled #Debian #backports and installed the newer packages from there. I hope this'll improve the situation in one of two ways:

• solve the issue with open memfd or at least let it take longer to occure
• give me a version of pipewire and #wireplumber that is not that much outdated that even the official online documentation doesn't cover it anymore

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056383

No comment, yet. Videoconferencing becomes more and more important in my work and I can't effort to not be able to connect on short notice, because I'd have to fix my sound system first.

To mitigate the problem I just switched back to #pulseaudio.

I tried to stop #Thunderbird/#Firefox from using the #pulseaudio socket of #pipewire because of a bug in Debian that renders the audio daemons useless after some time: sockets do not get closed and the only way to get audio back when there are no sockets left is to restart.

The way I tried to do it didn't work completely. #Firefox still opens sockets to the pulseaudio daemon - even though the processes show that they run in an environment containing PULSE-SERVER=unix:/dev/null.

Any ideas how I stop firefox using that pulseaudio socket? Mount namespace - does it include sockets? A restriction on a systemd slice (cgroup) I could use?

Sometimes listening isn't enough. Had to go into a video conference yesterday. Listening to music on my #Librem5 worked fine, but when I tried to get audio in the conference I remembered that my desktop is broken, because of this #Debian #Bookworm #Pipewire issue I wrote about.

I had to ask the other participants to wait, because I'd need to restart my desktop to get sound. Not funny if connected with people partly working on Apple devices.

#Workaround time: the major problem at the time being in my use case seems to be #Mozilla #Firefox and #Thunderbird leaving sockets to pipewire-#pulseaudio open.

I now run them using PULSE-SERVER=unix:/dev/null <program> and it seems they really do not connect to pipewire-pulse anymore and therefor can't leave its sockets open.

No sound in #Mozilla apps is o.k. - I can always run #ungoogled-#chromium if I need a page deliver sound.