## page was renamed from Mobian/PhoneAudioCallsDebuggingHints ## page was renamed from MobianAudioCallsDebuggingHints <> = 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 [[https://tracker.debian.org/feedbackd|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 [[https://tracker.debian.org/feedbackd-device-themes|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 [[https://github.com/the-modem-distro/pinephone_modem_sdk|FLOSS modem firmware]] is generally considered to provide [[https://github.com/the-modem-distro/pinephone_modem_sdk#features-not-available-on-stock-firmware|several advantages]] for managing phone calls, since it is not a black box like the stock firmware. === Modem USB disconnection === In the case of the !PinePhone, the USB that joins the phone to the modem is [[https://gitlab.gnome.org/GNOME/calls/-/issues/600|known to sometimes be disconnected by the phone kernel]] on incoming calls. This [[https://gitlab.gnome.org/GNOME/calls/-/issues/600|seems to happen]] on ''some'' !PinePhones (not all). ''Workarounds'' (which hint at the causes) include [[https://gitlab.gnome.org/GNOME/calls/-/issues/605|changing from a ringing sound to an LED flashing and/or a VibraRumble]], or [[https://gitlab.gnome.org/GNOME/calls/-/issues/605|inserting a brief delay]] between the ring and the audio call itself. Having good battery condition (e.g. voltage above about 3800 mV) and either FLOSS modem firmware, or stock modem firmware that is newer than 01.002.01.002, may help. You may check your battery voltages in V with [[https://tracker.debian.org/lm-sensors|sensors]] or in μV together with current in μA with {{{ cat /sys/class/power_supply/axp20x-battery/voltage_now cat /sys/class/power_supply/axp20x-battery/voltage_ocv cat /sys/class/power_supply/axp20x-battery/current_now }}} as ordinary user. == Log files == * Analyse ''sudo journalctl'' and ''sudo dmesg'' logs on the phone itself. * If you're using the FLOSS modem firmware, analyse ''openqti.log'' and ''dmesg'' logs on the modem (with the stock firmware you might not have easy access to modem logging). * Make sure that you '''anonymise private identifying information (PII)''' from the logs before posting them to bug reports. An example script is at https://codeberg.org/boud/pinephone_hacks/src/branch/main/bug_reporting/scrub_logs, without any guarantees. Responsibility for checking for the redaction of PII before posting a log is yours. * You can post logs to https://paste.debian.net if they're shorter than about 150 kb or use other pastebins to post your logs in a bug report. * See also the ''Logging'' section for ''pipewire'' and ''wireplumber'' below. * See ReportBug for Debian-level bug reports, or [[https://www.chiark.greenend.org.uk/~sgtatham/bugs.html|Simon Tatham's guide]] for general recommendations. === 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 [[https://alsa-project.org/wiki/Main_Page|alsa]] tools from [[https://tracker.debian.org/alsa-utils|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: * The top of {{{ /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. * Compare different stored alsa files ''/my/path/to/my_alsactl_store_YYYYMMDD_this_one_works'' (e.g. with ''colordiff -ub''). You may be able to work out which parameter changes are significant. * Backup the original files, and start with a small change in ''!VoiceCall.conf''. ''Restart'' audio: * ''Minimal'': Use a series of commands such as those in [[https://codeberg.org/boud/pinephone_hacks/src/branch/main/audio_hacks/sort_of_restart_audio|sort_of_restart_audio]]. As of early September 2023, the best set of commands for a full audio restart seems to be unclear; find out what the commands do and choose a subset that you think is correct. This will give a reasonably fast test cycle. * ''Maximal'': If the minimal set of audio restart commands appears insufficient, then stop ''alsa-restore'', remove the ''asound.state'' file, and reboot instead: {{{ sudo systemctl stop alsa-restore && sudo rm /var/lib/alsa/asound.state && sudo reboot }}} This will give a slow test cycle. The ''alsa-restore'' systemd service will restart after the reboot (do ''sudo systemctl disable alsa-restore'' if you want to prevent it from restarting). === Pipewire, Gnome-Calls, and friends === See PipeWire for recommendations about installing and using pipewire. Any of * [[https://tracker.debian.org/pipewire|pipewire]] * [[https://tracker.debian.org/pipewire-pulse|pipewire-pulse]] * [[https://tracker.debian.org/wireplumber|wireplumber]] * [[https://tracker.debian.org/gnome-calls|gnome-calls]] * [[https://tracker.debian.org/callaudiod|callaudiod]] or also * [[https://tracker.debian.org/network-manager|NetworkManager]] or * [[https://tracker.debian.org/modemmanager|ModemManager]] or * [[https://tracker.debian.org/eg25-manager|eg25-manager]] or * [[https://tracker.debian.org/systemd|systemd]] 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 [[Mobian#Discuss|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''.