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.