gnome-calls does not disconnect the modem USB if the ringing event is non-audio
DESCRIPTION:
I have a PinePhone v1.2 on which incoming calls (typically the second
incoming call in a row) often have a USB disconnection event. Three
independent changes appear to remove all USB disconnection events. By
changing the phone-incoming-call
libfeedback event to either (i) a
flashing LED or (ii) a VibraRumble; or by (iii) inserting a 1-second
sleep immediately after the Feedback ended
line in gnome-calls
, I
get no USB disconnection events, with at least 7 trials in each
case. Without (i) or (ii) or (iii), a USB disconnection event for a
battery with voltage_now below about 3800 mV occurs usually on the
second of a fresh series of incoming calls, and typically on every
second or third call in a series of incoming calls.
CONTEXT:
-
PinePhone v1.2
-
Mobian/trixie
-
FLOSS modem fw 0.7.2, ADSP 01.003.01.003
-
kernels:
- modem:
Linux mdm9607 3.18.140 #1 PREEMPT Tue Jun 28 05:34:35 UTC 2022 armv7l GNU/Linux
- phone:
Linux mobian 6.1-sunxi64 #1 SMP Fri Oct 13 12:38:23 UTC 2023 aarch64 GNU/Linux
- modem:
-
all tests were done with a 2-yr old (/sys/class/power_supply/axp20x-battery/health = Good) battery; some of the tests were also run with a new battery, giving equivalent results
$ dpkg -l |grep -E "alsa|gnome-calls|gnome-setting-daemon|pipewire|pulse|callaudiod|eg25-manager|feedbackd"
ii alsa-ucm-conf 1.2.10-1mobian1 all ALSA Use Case Manager configuration files
ii alsa-utils 1.2.9-1 arm64 Utilities for configuring and using ALSA
ii callaudiod 0.1.9-1-VOLTAGE-multi arm64 Call audio routing daemon
ii eg25-manager 0.4.6-2-modem-state-persist1-monitor-udev0 arm64 Manager daemon for the Quectel EG25 modem
ii feedbackd 0.2.1-1 arm64 DBus service for haptic/visual/audio feedback
ii feedbackd-common 0.2.1-1 all Shared files for feedbackd
ii feedbackd-device-themes 0.0.r3-1 all Device specific themes for Feedbackd
ii gnome-calls 45~alpha.0-4-audio-delay arm64 Make and receive PSTN phone calls
ii gstreamer1.0-pipewire:arm64 0.3.82-1 arm64 GStreamer 1.0 plugin for the PipeWire multimedia server
ii gstreamer1.0-pulseaudio:arm64 1.22.6-1+b1 arm64 GStreamer plugin for PulseAudio (transitional package)
ii libcanberra-pulse:arm64 0.30-10 arm64 PulseAudio backend for libcanberra
ii libpipewire-0.3-0:arm64 0.3.82-1 arm64 libraries for the PipeWire multimedia server
ii libpipewire-0.3-modules:arm64 0.3.82-1 arm64 libraries for the PipeWire multimedia server - modules
ii libpulse-dev:arm64 16.1+dfsg1-2+b1 arm64 PulseAudio client development headers and libraries
ii libpulse-mainloop-glib0:arm64 16.1+dfsg1-2+b1 arm64 PulseAudio client libraries (glib support)
ii libpulse0:arm64 16.1+dfsg1-2+b1 arm64 PulseAudio client libraries
ii libpulsedsp:arm64 16.1+dfsg1-2+b1 arm64 PulseAudio OSS pre-load library
ii pipewire:arm64 0.3.82-1 arm64 audio and video processing engine multimedia server
ii pipewire-alsa:arm64 0.3.82-1 arm64 PipeWire ALSA plugin
ii pipewire-audio 0.3.82-1 all recommended set of PipeWire packages for a standard audio desktop use
ii pipewire-audio-client-libraries 0.3.82-1 all transitional package for pipewire-alsa and pipewire-jack
ii pipewire-bin 0.3.82-1 arm64 PipeWire multimedia server - programs
ii pipewire-jack:arm64 0.3.82-1 arm64 PipeWire JACK plugin
ii pipewire-pulse 0.3.82-1 arm64 PipeWire PulseAudio daemon
rc pulseaudio 16.1+dfsg1-2+b1 arm64 PulseAudio sound server
ii pulseaudio-utils 16.1+dfsg1-2+b1 arm64 Command line tools for the PulseAudio sound server
-
gnome-calls
is the Debian45~alpha.0-4
version for methods (i) and (ii); for (iii) it is45~alpha.0-4-audio-dela
, see method (iii) below for the Debian-level fork -
eg25-manager
andcallaudiod
are hacked to be more verbose and (in the case ofcallaudiod
) print out voltage/current values -
my
alsa-ucm-conf
install differs strongly from Mobian out-of-the-box; outgoing calls currently seem to be consistent between calls and (at a minimum) audio is sent from the PP to the remote phone; see https://salsa.debian.org/Mobian-team/packages/alsa-ucm-conf/-/issues/8; now that USB disconnections seem to be under control, I should be able to see if I have a truealsa-ucm-conf
bug, orthogonally to the audio mess caused by USB disconnections -
eg25-manager
settings, per https://github.com/the-modem-distro/pinephone_modem_sdk/blob/kirkstone/docs/SETTINGS.md, matrix discussion at https://matrix.to/#/#pinephone_modem_sdk-issue-9:matrix.org and discussion at https://github.com/the-modem-distro/pinephone_modem_sdk/issues/213-
ATTR{power/persist}="1"
is set in/usr/lib/udev/rules.d/80-modem-eg25.rules
-
manage_udev = false
is set in/usr/share/eg25-manager/pine64,pinephone-1.2.toml
-
REPRODUCE:
(0) Obtain a PP that has USB disconnections on incoming calls. Wait until the battery power is weak enough for USB disconnections to be frequent; a value of /sys/class/power_supply/axp20x-battery/voltage_now
below about 3800000 (i.e. 3800mV) seems to be low enough. Check that you get USB disconnections.
You can grep for USB.*disc
in journalctl
. The line that first refers to the USB disconnection should be a kernel line: "kernel shuts down USB connection to modem on incoming call #213", such as
Sep 05 17:30:40 mobian kernel: option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Either reboot or run an audio restart script such as sort_of_restart_audio , since the USB disconnection has very likely messed up your audio parameters.
(i) FLASHING LED
First do
fbcli --event=phone-incoming-call
to do the libfeedback
equivalent of what normally happens during an incoming call. This should give a phone ringing sound.
- Combine the full and silent parts of the generic
/usr/share/feedbackd/themes/default.json
with the PP-specific file for quiet mode/usr/share/feedbackd/themes/pine64,pinephone.json
into a single file using a text editor. Do not add #-style comments. Modify the full mode section forphone-incoming-call
to:
{
"event-name" : "phone-incoming-call",
"type" : "Led",
"color" : "green",
"frequency" : 3000,
"_comment" : "frequency in mHz"
},
so that the phone-incoming-call
sound file is no longer used, and place the file at ~/.config/feedbackd/themes/custom.json
(Mobian case).
- Check the file validity with
fbd-theme-validate
. - Set the
custom
theme withgsettings
, - restart
feedbackd
(killall feedbackd
works in more cases thankill -HUP <PID of feedbackd>
), and - check with
fbcli
. Now
fbcli --event=phone-incoming-call
should flash the green LED three times a second instead of make a phone ringing sound.
See https://wiki.debian.org/Mobian/Tweaks#Haptic_and_other_feedback and 'info fbcli' or 'info fbd-theme-validate' or 'info feedback-themes` for more details on how to do these steps.
Do a series of incoming calls. You should have no more USB disconnections.
(ii) VIBRARUMBLE
Same as for (i), but change the phone-incoming-call
section to
{
"event-name" : "phone-incoming-call",
"type" : "VibraRumble",
"duration" : 4000,
"count" : 4,
"pause" : 300,
"_comment" : "the pauses are *within* the duration"
},
and again
- Check the file validity with
fbd-theme-validate
. - set the
custom
theme withgsettings
(orget
it to check) - restart
feedbackd
, and - check with
fbcli
. Now
fbcli --event=phone-incoming-call
should give you four vibrations over four seconds.
Do a series of incoming calls. You should have no more USB disconnections.
(iii) INSERT 1-SECOND SLEEP INTO GNOME-CALLS
Revert (i) or (ii) (e.g. gsettings reset org.sigxcpu.feedbackd theme
or use symbolic links between different theme files, and killall feedbackd
).
- Check that you get the normal ringing sound again:
fbcli --event=phone-incoming-call
Insert a 1-second sleep immediately after the Feedback ended
line in gnome-calls
.
See https://salsa.debian.org/boud-guest/gnome-calls/-/compare/debian%2Fmaster...audio_delay?from_project_id=48009 for a proof of concept. The main change is
on_feedback_ended (LfbEvent *event,
CallsRinger *self)
{
+
+ /* According to the 'usleep' man page, the delay on typical systems
+ must be strictly less than one second. So use deciseconds
+ instead. */
+ useconds_t decisecond = 100000;
+ int i, feedback_callaudio_delay_deciseconds = 10;
+
g_assert (LFB_IS_EVENT (event));
g_debug ("Feedback ended");
+ /* Wait for e.g. 1000000 microseconds before continuing, in order to
+ reduce the likelihood of modem USB diseconnections. */
+ g_warning ("Feedback-audio delay: will wait for %d deciseconds",
+ (int) feedback_callaudio_delay_deciseconds);
+ for(i=0; i<feedback_callaudio_delay_deciseconds; i++){
+ usleep(decisecond); /* wait a decisecond */
+ };
+
+
if (!CALLS_IS_RINGER (self)) {
g_warning ("Feedback stopped, but ringer is gone");
return;
Compile; install; restart gnome-calls
(e.g. kill
the PID number of the process).
A section of a journalctl file with this method is
oct. 21 21:41:06 mobian gnome-calls[18393]: Stamping call `answered'
oct. 21 21:41:06 mobian callaudiod[1068]: Select mode: 1
oct. 21 21:41:06 mobian callaudiod[1068]: card has voice profile, using it
oct. 21 21:41:06 mobian gnome-calls[18393]: Ended feedback 'phone-incoming-call' successfully
oct. 21 21:41:06 mobian gnome-calls[18393]: Feedback ended
oct. 21 21:41:06 mobian gnome-calls[18393]: Feedback-audio delay: will wait for 10 deciseconds
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery voltage_now = 3587000
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery voltage_ocv = 3715800
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery current_now = -128700
oct. 21 21:41:06 mobian callaudiod[1068]: set_card_profile: nothing to be done
oct. 21 21:41:06 mobian callaudiod[1068]: operation returned 1
oct. 21 21:41:06 mobian callaudiod[1068]: Select mode: 1
oct. 21 21:41:06 mobian callaudiod[1068]: card has voice profile, using it
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery voltage_now = 3587000
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery voltage_ocv = 3715800
oct. 21 21:41:06 mobian callaudiod[1068]: axp20x-battery current_now = -128700
oct. 21 21:41:06 mobian callaudiod[1068]: set_card_profile: nothing to be done
oct. 21 21:41:06 mobian callaudiod[1068]: operation returned 1
oct. 21 21:41:07 mobian gnome-calls[18393]: Setting ring state to 'inactive'
oct. 21 21:41:07 mobian gnome-calls[18393]: Successfully updated call record in database
oct. 21 21:41:19 mobian ModemManager[705]: <info> [modem3/call20] call state changed: active -> terminated (unknown)
oct. 21 21:41:19 mobian gnome-calls[18393]: MM call '/org/freedesktop/ModemManager1/Call/20' changed state to `TERMINATED': Unknown reason
oct. 21 21:41:19 mobian callaudiod[1068]: Select mode: 0
oct. 21 21:41:19 mobian callaudiod[1068]: cad_pulse_mute_mic: nothing to be done
oct. 21 21:41:19 mobian callaudiod[1068]: operation returned 1
oct. 21 21:41:19 mobian callaudiod[1068]: card has voice profile, using it
Thus, there is a 1-second delay between oct. 21 21:41:06 mobian gnome-calls[18393]: Feedback ended
and oct. 21 21:41:07 mobian gnome-calls[18393]: Setting ring state to 'inactive'
.
Callaudiod
is still active in between (it's a daemon; the battery voltage/current
outputs are from my hack), but presumably it does not do audio actions that lead
to the USB disconnection.
Do a series of incoming calls. You should have no more USB disconnections.
Without this 1-second delay, a journalctl example is
oct. 21 13:21:39 mobian gnome-calls[3563]: Feedback ended
oct. 21 13:21:39 mobian gnome-calls[3563]: Setting ring state to 'inactive'
oct. 21 13:21:39 mobian gnome-calls[3563]: Ended feedback 'phone-incoming-call' successfully
oct. 21 13:21:39 mobian gnome-calls[3563]: Successfully updated call record in database
oct. 21 13:21:39 mobian wireplumber[803]: <WpNode:0xXXXXXXXXa0> ignoring set_param on already destroyed objects
oct. 21 13:21:39 mobian wireplumber[803]: <WpNode:0xXXXXXXXXa0> ignoring set_param on already destroyed objects
oct. 21 13:21:39 mobian wireplumber[803]: <WpNode:0xXXXXXXXX70> ignoring set_param on already destroyed objects
oct. 21 13:21:39 mobian wireplumber[803]: <WpNode:0xXXXXXXXX70> ignoring set_param on already destroyed objects
oct. 21 13:21:39 mobian callaudiod[1000]: new sink 690
oct. 21 13:21:39 mobian callaudiod[1000]: new source 690
oct. 21 13:21:39 mobian callaudiod[1000]: new source 691
This suggests that callaudiod
actions such as setting a new sink
and a new source
are done too soon after the phone-incoming-call
sound file has finished playing.
WORKS FOR ME:
- (i) led flashing - 7 successive incoming calls worked fine with audio going from the PP to the remote phone; there were no modem USB disconnections
- (ii) VibraRumble - 7 successive incoming calls worked fine with audio going from the PP to the remote phone; there were no modem USB disconnections
- (iii) 1-second gnome-calls delay - out of 9 successive incoming calls, 8 had audio going from the PP to the remote phone (audio from PP to remote failed on the 7th call); there were no modem USB disconnections; battery
capacity
was down to about 40%
INTERPRETATION:
Presumably what causes the USB disconnection event is that callaudio
starts setting audio parameters (such as sinks and sources) or
doing Select mode: 1
or switching to voice profile
(the VoiceCall.conf configuration) too quickly after
libfeedback finishes with playing a sound file in the audio system.
SUGGESTIONS:
Find an explanation for why these three methods avoid the USB disconnection. Find a more robust, sustainable alternative to a 1-second delay in gnome-calls to method (iii) for avoiding USB disconnection events.
RECOVERING FROM A USB DISCONNECTION EVENT:
The USB disconnection event messes up the audio system. More
specifically, it leaves the debus AudioMode
at 1, and leaves/resets the
alsa
settings at/to values that are not those normally done in
PinePhone.conf or in the Disable sections of VoiceCall.conf (files
from alsa-ucm-conf
).
So in the following call, callaudiod
does not run the line
switching to voice profile
; the reasoning is presumably that if the alsa parameters
have already been set up, as indicated by AudioMode == 1
, then there's no
point doing that again.
A crude hack to fix this situation for the call that follows a modem-USB-disconnected call is here:
https://salsa.debian.org/boud-guest/gnome-calls/-/compare/debian%2Fmaster...reset_AudioMode?from_project_id=48009
It's a bad hack, because it uses a system call. Moreover, it requires some
of the PinePhone.conf parameters to be added to VoiceCall.conf (probably because activating
VoiceCall mode does not run through the FixedBootSequence
section of PinePhone.conf).
However, something similar to it might be useful if USB disconnections still
occur (rarely?) with the above three methods. Without a fix like this, the
USB disconnection will almost always make two successive calls ineffective rather
than just one (and the PP user will only see mobile network icons flashing on/off during
the first call).