https://gitlab.com/postmarketOS/pmaports/-/issues/1091
Bluetooth audio devices fail to connect with alsa.
Should we switch audio to pipewire?
I'm using pipewire from some time but I got lot of issues. I dunno if we should move today
Audio works with pipewire, bluetooth audio as well, however, https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1069 (possibly caused by misconfigured polkit, if rtkit is even installed) this may cause the audio to stutter on high load (perhaps for short load bursts, too).
I'm skeptical of switching to pipewire, if someone want's to take up the work and can demonstrate it works reliably.. ok but ALSA + dmix + dsnoop is a nice reliable solution. That said I don't use bluetooth.
Anyone who uses bluetooth try with bluez -> apulse -> alsa? Or, bluez -> bluez-alsa -> alsa?
No it sucks. Bluetooth on linux require pulseaudio or pipewire.
I honestly tried to rely on bluez-alsa for months and months. It is either sound desync with image or only one audio source at the same time. And in either cases it is hard to manage, to switch setups or to use.
Did you try apulse? Looks like bluealsa doesn't support dmix directly, https://github.com/Arkq/bluez-alsa/wiki/Using-bluealsa-with-dmix
I'd love to see pipewire on 1.5, together with pulseeffects and a convolver plugin it would make audio sound so much better - both for music and for calls, but especially music
Edit: To get a2dp protocol working on bluetooth headsets, bluez and bluez-libs need to be downgraded to 5.58-1, the latest version as of writing breaks it and only gives you the low quality HSP/HSF protocols - which don't work either, just creating a sabertooth waveform like buzzing.
Here are some notes on how to configure audio over bluetooth with pipewire in a fresh install :
apk add bluez bluez-openrc apk add pipewire pipewire-media-session pipewire-pulsesudo -e /etc/bluetooth/main.conf AutoEnable=truerc-update add bluetooth rc-service bluetooth startstart pipewire somehow (in .config/sxmo/xinit by example)
bluetoothctl pair XXXXXX trust XXXXXOr use the bluetooth sxmo menu
If Pipewire is installed, does the audio still change properly if you answer a phone call or use the Audio menu?
If Pipewire is installed, does the audio still change properly if you answer a phone call or use the Audio menu?
No cause the phone call use explicit alsa interface iirc. It still works well with pipewire running but do not embrace it.
Ah yeah I tried it and had my boyfriend call me, and the sound from my Flatpak game went over the phone network and he could hear it. I think using Pipewire in the future by default might be good though, as apulse doesn't work with Flatpak and no Flatpak apps have sound with plain ALSA
I have an idea. Why not have an optional sxmo-pipewire package that would add Pipewire for those who want to use it?
I have an idea. Why not have an optional sxmo-pipewire package that would add Pipewire for those who want to use it?
I'd like not to add any chaos to this already chaotic pipewire package ecosystem. Sxmo should just just works with and without it.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Just throwing in my 2 cents, I installed pipewire on both ArchArm and PMOS with no issues, and it let me use my USB DAC on the pinephone without having to deal with alsa. Didn't notice any cpu usage spike from pipewire too.
Yes it works. Our menu and voice call just need to be adaptative and handle it :)
(dunno what you did ~pinephoneuser01 but you spammed your last message)
~craftyguy via irc on pipewire as default on pmOS:
I think what I was getting at is, we're open to enabling pipewire by default, but it needs to 1) support echo cancellation, and 2) work reasonably well and be at least as stable as pulseaudio
Hi all, if you are testing pipewire, make sure you install
rtkitpackage from the testing repository and enable/start the rtkit service. If you are running stable, you can install rtkit from the testing repo by pinning the testing repo:https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management#Repository_pinning
What remaining issues are stopping Sxmo from using Pipewire? Also, why not use Pulseaudio until Pipewire is ready?
What remaining issues are stopping Sxmo from using Pipewire?
- performance
- instability
- our scripts are not compatible
- our voice calls are not compatible
- we got no easy way to manage it in sxmo (yet)
Also, why not use Pulseaudio until Pipewire is ready?
Why should we ?
It's definitely not a necessity, but besides bluetooth not working, sound in Flatpak applications doesn't work without it. But if it's not manageable, then that's a pretty good reason not to switch, yeah.
I have audio controls mostly working: https://lists.sr.ht/~mil/sxmo-devel/%3C20211013014700.10018-1-anjan%40momi.ca%3E
We just need to fix audio routing now: https://xnux.eu/devices/feature/audio-pp.html