Most of us who use strange (or new) technology are familiar and comfortable with considering tradeoffs. In the Linux phone space, I feel it’s important to be intentional about considering tradeoffs and choosing the right option for myself. After all, I use my phone a lot! Some examples:
- Do I want the ultra-locked-down thing that I can’t touch but works great (iOS), the mostly-locked-down thing I can touch if I really want to but mostly works (Android), or the ultra-open thing that makes it easy to do whatever I want but requires light engineering work (Linux phone)?
- Do I want a rolling release that gets the very latest stuff but could break my device, a more curated rolling release, or a stable release that runs old code (with old bugs)
- To the point of this post: Do I want to use pipewire so the camera app works, but in exchange have trouble getting phone calls and playing sound on smart speakers, or do I want to use pulseaudio and have the sound stuff work but only CLI tools for the camera
Clearly I have already come down on the crazier side of these tradeoffs, since my phone runs Linux on a rolling release. I’m sure there are people crazier than me but most are probably less crazy. Still, I really do need a working camera. And working phone calls.
For awhile, I was using qcam
, a libcamera debugging app, but a config change broke its ability to save images and rendered it extremely slow.
I recently heard about a new app called GNOME Snapshot: repo link, flathub link. It consumes a camera stream over pipewire, which can in turn be fed by libcamera, which supports my PinePhone Pro. The only trouble is, as I’ve written above, a standard pipewire install explodes my audio stack. I can’t use my smart speakers due to these bugs, and worse, it pretty much breaks the ability for my PinePhone Pro to make audio calls (forum discussion with details). I chalk this up to the PinePhone Pro-specific UCM2 jankiness and complexity interacting with pipewire’s newness. Hopefully enough gets fixed that this works in the future, and this blog post can just serve as a neat historical artifact :-).
A Solution: Run Both with Careful Configuration
I was able to find a solution that allows me to have both a working camera app and a working sound stack, thanks to Barnabás Pőcze (@pobrn), who responded with this advice while asking for pcaps to help fix the smart speaker issues (which I submitted). Broadly, it’s this:
- [prerequisite] Pipewire should be installed with wireplumber
- Tell pipewire not to try to bother with on-device audio:
- Disable ALSA monitor (I’m not sure what this is)
- Disable bluze monitor (Not sure about this either, but I suspect it listens for bluetooth connections and tries to set up audio for them)
- Remove pipewire-pulse (pulseaudio-compatible audio API for pipewire IIUC)
- Reinstall pulseaudio
- Force systemd to start pulseaudio on startup
- As a bonus, start the PulseAudio RAOP module automatically for easy smart speaker support
Roughly, these instructions should help you reproduce my configuration.
First, I created a local copy of the main.lua.d and bluetooth.lua.d from my system-wide wireplumber configuration on Manjaro-ARM:
mkdir -p ~./config/wireplumber
cp -r /usr/local/share/wireplumber/main.lua.d/ ~/.config/wireplumber/
cp -r /usr/local/share/wireplumber/bluetooth.lua.d/ ~/.config/wireplumber/
Next, I disabled the alsa and bluez monitors:
echo "alsa_monitor.enabled = false" > ~/.config/wireplumber/main.lua.d/70-disable-alsa.lua
echo "bluez_monitor.enabled = false
bluez_midi_monitor.enabled = false" > ~/.config/wireplumber/bluetooth.lua.d/70-disable.lua
Remove pipewire-pulse (you may have to use a break-glass option like Rdd to force your package manager to allow this) and install pulseaudio:
Optionally, consider updating with pacman -Syu first
sudo pacman -Rdd pipewire-pulse
sudo pacman -S pulseaudio
Re-enable pulseaudio systemd unit and reboot:
systemctl --user enable pulseaudio
reboot
If you have sound, great! You can stop here. Otherwise, though, you are probably running into the issue of pulseaudio not starting automatically on boot like me (enable --now
fixes it for the current session but does not survive a reboot). I found that the extremely-janky approach of creating a oneshot systemd unit to tell systemctl to start pulseaudio works great. I hate it, but it works:
echo "[Unit]
Description=Fix Sound Service
ConditionUser=!root
[Service]
Type=oneshot
RemainAfterExit=true
StandardOutput=journal
ExecStart=/usr/bin/systemctl --user start pulseaudio
[Install]
WantedBy=default.target" > /usr/lib/systemd/user/initpulseaudio.service
While I was at it, I also created a systemd unit to initialize RAOP with pulseaudio, because adding this to /etc/pulse/default.pa breaks all pulseaudio sound for some reason. I’ll just chalk this up to pulseaudio being on the way out, long-term:
echo "[Unit]
Description=Fix RAOP config enablement not working by starting adhoc instead of using the pulse config
ConditionUser=!root
[Service]
Type=oneshot
RemainAfterExit=true
StandardOutput=journal
ExecStart=/usr/bin/pactl load-module module-raop-discover
[Install]
WantedBy=default.target" > /usr/lib/systemd/user/initairplay.service
Enable the systemd units and reboot to verify our changes survive a reboot:
systemctl --user enable initpulseaudio
systemctl --user enable initairplay
reboot
That’s it! Try a few things, call a test number and play a video in Firefox to verify that sound works. If you have trouble, reply to that forum post or look for me in the PinePhone Matrix chat. Enjoy having a decent camera app while still having working sound!
Leave a Reply