@praveen@social.masto.host @dos@librem.one @kannan@aana.site

I tried this solution (after testing the first time the echo in #trixie using #pipewire - it really is awfull ) and found the speaker and headset working when using paplay.

The echo on calls is gone also - like any audio during calls is gone.

I do not remember how to fix the #audio during calls not working nor do I remember the place where I read about it. Help would be appreciated!

Best would be if someone would add echo-cancellation to #pipewire which is default in trixie. There's a slowly growing bounty on Open Collectives for that.

Just donated to the effort to improve sound quality on the #Librem5 when using #pipewire: https://opencollective.com/dephcom/projects/pipewire-echo

I'd be even more happy about the approach of sponsoring development through the community if this donation would be accepted as being for an official non-profit organization accepted as such in Germany.

Giving for #OpenSource should be respected as a a benefit to the public and appreciated by the government by whatever means they do this for other purposes (in Germany it's possible to declare such donations for reducing taxes to pay).

Hey #MobileLinux community - if everybody gives a little there'll be a fair pay for someone doing this work.

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

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.