~mil/sxmo-tickets#436: 
Call audio routing on the pinephone pro and other devices

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:

  1. Install the latest kernel that reportadly has audio working on the pinephone pro: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2742#note_788693378

  2. Which audio routing daemon are the other mobile interfaces using?

  3. 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:

Status
RESOLVED FIXED
Submitter
~anjan
Assigned to
No-one
Submitted
6 months ago
Updated
4 months ago
Labels
high-priority

~anjan 6 months ago*

Hope this helps and we figure out audio routing on the pinephone pro!

~rbrewer 6 months ago

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

~craftyguy 5 months ago

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)

~anjan 5 months ago*

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.

John Sullivan 5 months ago · edit

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.rules section here https://pipewire.pages.freedesktop.org/wireplumber/configuration/alsa.html#modifying-the-default-configuration

I 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"] = false

We'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 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

~anjan 4 months ago

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:

  1. Install sxmo-common-bluetooth and callaudiod packages
  2. add exec pipewire and exec callaudiod to ~/.config/sxmo/sway

The command line program callaudiodcli used 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:

  1. callaudiocli -m 0 sets call audio mode to default: Default mode (used for music, alarms, ringtones...)
  2. callaudiocli -m 1 sets call audio mode to Voice call mode
  3. callaudiocli -s 0 disables speaker
  4. callaudiocli -s 1 enables speaker
  5. callaudiocli -u 0 mutes mic
  6. callaudiocli -u 1 unmutes mic

The 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 callaudiocli so I installed it on my pinephone pro which doesnt have a sim card. Ill see if I can test tomorrow. We definitely should document callaudiocli and add error handling if the user types in callaudiocli -m 3.

~stacyharper 4 months ago

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

~stacyharper 4 months ago

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 :

https://git.sr.ht/~mil/sxmo-utils/tree/c309751b33b8fcce7a95bd90e5c6243793d5c7e5/item/scripts/modem/sxmo_modemcall.sh#L137

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

~stacyharper 4 months ago

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

~stacyharper 4 months ago

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

~phartman 4 months ago

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

~phartman REPORTED FIXED 2 months ago

Register here or Log in to comment, or comment via email.