Contents

  1. Mobian audio call debugging hints
    1. Package separation
    2. Log files
    3. Alsa, alsa-ucm-conf, pipewire, pipewire-pulse, wireplumber, callaudiod

Mobian audio call debugging hints

Audio phone calls on a PinePhone or other smartphone running Mobian involve several different processes, configurations and software packages. Here are some hints that may help you to fix problems yourself and/or file bug reports that are sufficiently complete and clear for others to help solve the bugs. If you cannot place phone calls in which you and the person on the remote phone hear each other reasonably well (with maybe a little echo and a little background noise), then debugging is needed.

Package separation

Separate out these different aspects of phone calls to isolate which problem(s) you still have.

Proximity sensor

If your proximity sensor is not calibrated, then it might keep the screen blank during a phone call (whether failed or successful), even though you have taken the phone away from your ear and are trying to see what is on the touchscreen of your phone. See Mobian/Tweaks#Proximity_sensor for a guide on how to calibrate your proximity sensor.

Feedback daemon

You can adjust the feedbackd "theme" configuration if sound/vibrations/leds during passed/failed phone calls are confusing your analysis of alsa/pipewire/pipewire-pulse/wireplumber issues. Use fbd-theme-validate and fbcli to check/experiment with these and adjust the theme if that can help you separate out different events. Debian distributes feedbackd-device-themes as a default out-of-the-box theme. Do 

kill -HUP 123456

where 123456 is the process ID of your feedbackd process after modifying the theme. Do 

man fbcli
man fbd-theme-validate

for more hints and further documentation, including 

gsettings get org.sigxcpu.feedbackd theme

to check your current theme.

FLOSS modem firmware

As of September 2023, the FLOSS modem firmware is generally considered to provide several advantages for managing phone calls, since it is not a black box like the stock firmware.

USB disconnection from low charge/old battery

In the case of the PinePhone, the USB that joins the phone to the modem is known to sometimes be disconnected by the phone kernel. This seems to happen when the battery is old and the voltage is low (around 3500 to 3600 mV). Workarounds include keeping your phone charge higher or buying a new battery; or you may participate in the discussion of other possible solutions. Check your battery voltage in V with sensors or in μV with 

cat /sys/class/power_supply/axp20x-battery/voltage_now

as ordinary user.

Log files

mmcli

You might find that running 

mmcli -m any --output-keyvalue > /path/to/mylogfile.$(date +%Y%m%d_%H%M%S)

before, during and after a failed call may give useful diagnostic information (choose a valid path; the timestamp is optional).

Package list for bug reporting

A good list of packages that might be relevant for others to check in analysing your bug report includes the output of: 

dpkg -l |grep -E "phosh|phoc|alsa|gnome-calls|gnome-setting-daemon|pipewire|pulse|wireplumber|wys|modemmanager|network-manager|libnm|eg25-manager|callaudiod|systemd"

Alsa, alsa-ucm-conf, pipewire, pipewire-pulse, wireplumber, callaudiod

Alsa

You can use alsa tools from alsa-utils such as alsamixer interactively, or amixer on the command line. Learn how to store a full set of alsa parameters that works for you, by doing 

sudo alsactl store -f - > /my/path/to/my_alsactl_store_$(date +%Y%m%d_%H%M%S)_this_one_works

before, during or after a call, with an appropriate file path and name. Choose filenames that will remind you of their meaning later. Later you will be able to restore that particular set of parameter settings with 

sudo alsactl restore -f /my/path/to/my_alsactl_store_YYYYMMDD_HHMMSS_this_one_works

where /my/path/to/my_alsactl_store_YYYYMMDD_HHMMSS_this_one_works is the actual path and file name. The number of parameters is big: trying a few well-chosen parameters might fix things; trying many parameters randomly is very unlikely to give you a valid setting.

alsa-ucm-conf

In principle, a workaround for audio call problems might be to write your own script that you run immediately after an phone call has started. This is probably impractical, but should work.

However, during a call, the settings in VoiceCall.conf, e.g. 

ls -l /usr/share/alsa/ucm2/Allwinner/A64/PinePhone/

for the PinePhone, are intended to override existing alsa settings. Initially the file is used to give settings for the ringing sound, and then settings for the call itself are invoked.

As of early September 2023, the Debian approach follows the upstream approach of modularity: only some of the settings are changed during call.

You should start with the recommended out-of-the-box alsa-ucm-conf files that you should find in /usr/share/alsa/ucm2/Allwinner/A64/ before experimenting.

Experimenting with the parameters: 

/usr/share/ucm2/Allwinner/A64/PinePhone/PinePhone.conf

(or similar for other phones) gives you some URLs where you can try to understand the audio connection diagrams in order to guess which parameters might need to be changed.

Restart audio:

Pipewire, Gnome-Calls, and friends

See PipeWire for recommendations about installing and using pipewire. Any of

or also

might be involved in disrupting a phone call. Check if there are relevant bugs at the Debian level or at upstream level, and feel free to discuss your issue first if you're unsure about where to post a bug report.

Logging

In addition to the log files above, some useful pipewire and wireplumber outputs that you can store to analyse audio call related events include: 

pw-dump > /my/path/to/my_pw_dump_$(date +%Y%m%d_%H%M%S)
wpctl status > /my/path/to/my_wpctl_status_$(date +%Y%m%d_%H%M%S)

using whatever output file names you wish. Read these and compare differences of files at different times with diff or colordiff.