Problem: Currently, sxmo uses megi's call routing program written in C. https://xnux.eu/devices/feature/audio-pp.html
This approach works well for the pinephone and we can use alsa. However, with the release of the pinephone pro and Sxmo's goal to become more device agnostic, we must seek a better solution. Currently, we would have to follow in megi's footsteps for each new device and write a device specific audio routing C program for each phone.
Proposed solution:
Use pipewire and wys or callaudiod:
As always, alsa will still be supported and if users want to write a custom C program for routing their audio via alsa on other devices, they are more than welcome. However, most phone users expect audio routing with more complex setups which would work only with pipewire (ie. bluetooth headsets, multiple mics, etc.). Moreover, it's difficult to justify the massive maintenance effort we would have to undertake to write a C program for the pinephone pro, librem 5, etc. We should look to work with upstream projects (wys or callaudiod) to save work.
This we need to research for this proposed solution:
Install the latest kernel that reportadly has audio working on the pinephone pro: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2742#note_788693378
Which audio routing daemon are the other mobile interfaces using?
Do any of these audio routing daemons work on the pinephone and pinephone pro already? Which devices do each of these daemons support? How difficult is it to add device support if the daemon doesnt already support it? wys looks super simple to add device support - it's what librem 5 uses. callaudiod was made by the mobian team and it "should" work with pinephone.
The commandline interface for callaudiod is super clean and simple: https://gitlab.com/mobian1/callaudiod/-/blob/master/tools/callaudiocli.c
Related:
Hope this helps and we figure out audio routing on the pinephone pro!
pipewire sounds like a good idea as a general direction.
My cursory glance at wys seemed like it is a daemon that tries to implement audio routing policy according to some config files. I didn't see example configs though.
callaudiod seems to have a similar goal, but also has the CLI/dbus interfaces to allow a little more flexibility.
Something I appreciate about sxmo is that the policy code is very explicit, not difficult to find, and often easily overridable without ever touching a compiler via the hooks or worst-case just modifying a script or two. I don't see that flexibility with either of these daemons: they seem to mix the mechanism and policy together and hide it in a C program.
I haven't spent the time needed to understand all the audio stuff, but it seems like Megi's C code is accessing some Alsa APIs that could also be accessed via a script, or at most a small C program with the barest of mechanism that could be controlled from scripts implementing the policy. Perhaps going forward the scripts would do it the pipewire way, whatever that is.
An additional related ticket is here: https://todo.sr.ht/~mil/sxmo-tickets/414
I recommend not using wys, it's very specific to the librem 5 at the moment. there was a severely hacked up version of wys that we used in pmOS for the pinephone, but it was a hard fork of wys that didn't work with the librem 5 (and it was buggy, IIRC)
I got callaudiod and wys working. Someone on the debian matrix said:
wys does software routing on the Librem5 while callaudiod does the alsa profile switching and speaker/earpiece setup. Both wys and callaudiod are running on mobian.I got callaudiod working. It just says it's running with no modems. Same with wys - it says no inputs. I asked in mobian matrix what args I need to launch wys and callaudiod with.
From ~craftyguy on irc: you dont need wys. callaudiod should be able to handle all the audio routing iirc. On pmOS with phosh, we dont run wys at all on the pinephone. librem 5 requires wys.
Hi all, just putting in my 2c since I've messed about with pipewire's node APIs via wireplumber.
First, wireplumber already appears to have an ALSA node interface that can parse ALSA Card Profiles and Use-Case Management configurations, see the
alsa_monitor.rulessection here https://pipewire.pages.freedesktop.org/wireplumber/configuration/alsa.html#modifying-the-default-configurationI understand that postmarketos in the past has used pulseaudio and UCM to get calls working correctly https://gitlab.com/postmarketOS/pmaports/-/tree/master/device/main/device-pine64-pinephone/ucm
If we can correctly use wireplumber's functionality at runtime, we could have that as a stop-gap until a more complete solution can be tweaked. At the very least, I've tested a few PCs with wireplumber's default configuration and it can correctly configure the initial node graph every time. On some systems I've needed to disable loading Alsa Card Profiles, as it would only setup some nodes and not others, however it only takes this file in $XDG_CONFIG_DIRS/wireplumber/main.lua.d to do it
-- 51-disable-acp.lua alsa_monitor.rules[1].apply_properties["api.alsa.use-acp"] = falseWe'd probably need to do this in any case, as we only have good examples of UCM configurations anyway. However, both are available for use.
Runtime management of nodes also appears to be incredibly simplified under wireplumber, at least thru their lua scripting interface. They do have a glib/gobject API that can be hit too, but I've already done a few things like a tiny volume manager widget that controls & monitors the default sink. It might be enough to manage nodes for calls and the like with a tiny daemon written in this way.
- Wireplumber's docs on the lua scripting API https://pipewire.pages.freedesktop.org/wireplumber/lua_api/lua_gobject.html
- Volume monitor widget/control script https://github.com/jjsullivan5196/dotfiles/blob/master/.local/lib/scripts/wpvol#L60
- Example usage https://github.com/jjsullivan5196/dotfiles/blob/master/.config/sway/config.d/01-hotkeys.conf#L2
Wireplumber is still somewhat experimental, but it does appear the authors are publishing high-quality modules for it. We could either try to work with the existing modules, or even try to get one upstreamed for the purposes of managing things like phone call audio. That would probably take a significant maintenance burden off of sxmo overall.
I might be totally out there with this idea, so take what I say with a few grains of salt. However, I don't think there's too many resources indexing this information, so I wanted to write down what I know here. :-) I can try to answer clarifying questions as well, but I'm only an intermediate user of wireplumber, not working on it or anything.
Regards
-- John Sullivan https://jsullivan.cc
Ok I have callaudiod installed and I think I know how it should work. Here's what I did to get it working on my pinephone pro:
- Install
sxmo-common-bluetoothandcallaudiodpackages- add
exec pipewireandexec callaudiodto ~/.config/sxmo/swayThe command line program
callaudiodcliused to change audio routing via callaudiod doesnt have documentation from what I could find.Here is what I gathered from reading the source code: Files of interest:
- https://gitlab.com/mobian1/callaudiod/-/blob/master/tools/callaudiocli.c
- https://gitlab.com/mobian1/callaudiod/-/blob/master/libcallaudio/libcallaudio.h
callaudiocli -m 0sets call audio mode to default: Default mode (used for music, alarms, ringtones...)callaudiocli -m 1sets call audio mode to Voice call modecallaudiocli -s 0disables speakercallaudiocli -s 1enables speakercallaudiocli -u 0mutes miccallaudiocli -u 1unmutes micThe issue is I cant see this status (profile, mic, speaker status) changed in pulsemixer. I dont have a spare phone to test this configuration on, I currently wanted to document how to use
callaudiocliso I installed it on my pinephone pro which doesnt have a sim card. Ill see if I can test tomorrow. We definitely should documentcallaudiocliand add error handling if the user types incallaudiocli -m 3.
Oh thats very interesting !
Do we need those callaudiocli commands ? Or could we use pamixer or pavucontroll ? I guess if it create a loopback, we should be able to manage it
Update status :
We merged a patch to now rely on callaudiod. So now sxmo use pipewire by default and use callaudiod for call audio routing. Pinephone pro is expected to works now but I did not checked it yet.
Things to improve :
- Annoying : I received a call that initiated without setting the call audio mode so I had no sound :( Hangup and calling back worked. I remember we may had a similar code with the megi script :
Maybe we should just brute force some times the callaudiod command ?
- Not dangerous : the callaudiod that reset the modem audio mode seems to not works very well. We are basically stuck in earpiece mode and audio mode :( Opening pavucontrol to fixup the modes works.
-> We should at least be able to control those from the audio menu. I openned an issue in pamixer to be able to control ports :
https://github.com/cdemoulins/pamixer/issues/47
My last patch should make calls workflow way reliable and avoid edge cases.
https://lists.sr.ht/~mil/sxmo-devel/patches/29457
This will probably take some time to settle cause we rely on a callaudiod release that would happen in "few weeks". We should listen at this MR (current wip on their side )
https://gitlab.com/mobian1/callaudiod/-/merge_requests/15#note_834001505
Bonus point is that this MR exactly is the thing we want to have a more reliable callaudiod and avoid "stuck in earpiece" issue cause callaudiod things we already reseted to speaker
I started working on at least the bit where we want to switch the port: https://lists.sr.ht/~mil/sxmo-devel/patches/29521
The key here are the lines following lines:
get the port: pactl list sinks | grep "Active Port:" | rev | cut -d' ' -f1 | rev)
set the port: pactl set-sink-port "${SXMO_PULSE_SINK_NUMBER:-115}" "[Out] $DEV"
Not as nice as using pamixer, but could work