Latest gnome-calls very unstable

I am on Byzantium with the latest gnome-calls version (43.alpha.0).
Although the software being alpha, it came as an update through the app store. Unfortunately this version, and also the version before this one, has stability issues.

This morning I received a phone call with the screen off. The answer dialog showed up briefly, but the answer button was grey and did not respond to a press. Shortly thereafter, the dialog disappeared from the screen and left me with the lock screen with the phone still ringing. I unlocked the phone and opened the calls app. I briefly saw the answer dialog again before it disappeared while the phone continued to ring, this time with two simultaneous ring tones. Closing the calls app didn’t stop the ringing, so I had to restart the phone. I know I could have used killall gnome-calls in the terminal app, but restarting the phone seemed like a quicker way to handle the ruckus (I will create a desktop entry with the killall command for quick access in the future).

After the phone restarted, I again opened the calls app, which was not responding and not showing contact names in the recent list. After a few more reboots, the calls app was back to normal again.

Are there any log files I can supply to help track this issue?

1 Like

Created a desktop entry to kill gnome-calls if anybody needs the utility:

[Desktop Entry]
Version=1.0
Name=Kill Calls
Exec=killall gnome-calls
Icon=/home/purism/.local/share/icons/kill-calls.png
Terminal=false
Type=Application
Categories=Application;
X-Purism-FormFactor=Workstation;Mobile;

Here is also the kill-calls.png icon I created:
kill-calls

2 Likes

Maybe a skull and crossbones instead of the “no” symbol. The icon looks like it would function the same way the hks does.

Good point, will look into an update later.

Edit: Here goes
kill-calls

3 Likes

Check the log shown by the journalctl command. For example, to show everything from today:

sudo journalctl --since today

or to show everything from the last hour:

sudo journalctl --since -1h

Each line in the log starts with a timestamp, so you can look for error messages that appeared around the time when you noticed problems.

Ok, did a journalctl now after another hickup, which is not uncommon for my L5, i.e. ongoing phone call interrupted by an incoming phone call breaks audio in Calls. I killed Calls with my little app above and restarted it, but never got any audio back. I might add that I was using an USB headset when it happened. Haven’t been able to get a working phone call after this. Got another incoming phone call, but no answer dialog while the phone kept ringing until I killed it.

Strange things are going on here. Anything specific I should look for in journalctl?

Edit: Found the bug report for disappearing call audio here.

I guess I need to file a bug about this or comment on an already existing bug here.

For the lack of audio after killing the app, it might be worth looking at your Pulseaudio sources and sinks lists, you may have some echo-cancellation streams straggling.

The calls app creates these streams and then destroys them after a call, if you kill the app by some other means these streams may not get destroyed.

I did quite a bit of testing around call audio and, although I don’t recall the specifics, I did note it was possible to get into a situation whereby the echo-cancellation streams of a call did not get destroyed and when the next call happened additional streams were created but no audio was heard. Killing (unloading) the straggling streams resolved that issue for me.

To view the Pulseaudio sources…

pactl list short sources

…and sinks…

pactl list short sinks

You are looking for anything in the list with “echo-cancel” in the name, these should only be present during a call.

Thanks, this is what I get:

purism@pureos:~$ pactl list short sources
2	alsa_output.platform-sound.HiFi__hw_L5_0__sink.monitor	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
3	alsa_input.platform-sound.HiFi__hw_L5_0__source	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
4	alsa_output.platform-sound-wwan.stereo-fallback.monitor	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
5	alsa_input.platform-sound-wwan.stereo-fallback	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
purism@pureos:~$ pactl list short sinks
1	alsa_output.platform-sound.HiFi__hw_L5_0__sink	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
2	alsa_output.platform-sound-wwan.stereo-fallback	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED

Nothing with echo-cancel as far as I can see…

Edit: With USB headset connected I get the following:

purism@pureos:~$ pactl list short sources
2	alsa_output.platform-sound.HiFi__hw_L5_0__sink.monitor	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
3	alsa_input.platform-sound.HiFi__hw_L5_0__source	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
4	alsa_output.platform-sound-wwan.stereo-fallback.monitor	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
5	alsa_input.platform-sound-wwan.stereo-fallback	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
6	alsa_output.usb-Generic_USB_Audio-00.analog-stereo.monitor	module-alsa-card.cs16le 2 kan. 48000 Hz	IDLE
7	alsa_input.usb-Generic_USB_Audio-00.analog-stereo	module-alsa-card.c	s16le 2 kan. 48000 Hz	IDLE
purism@pureos:~$ pactl list short sinks
1	alsa_output.platform-sound.HiFi__hw_L5_0__sink	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
2	alsa_output.platform-sound-wwan.stereo-fallback	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED
3	alsa_output.usb-Generic_USB_Audio-00.analog-stereo	module-alsa-card.c	s16le 2 kan. 48000 Hz	SUSPENDED

Are the ALSA platforms supposed to be suspended? Because they still are after a reboot.

These lists look fine to me with nothing unusual. Yes, it is normal to see the sources and sinks listed as “SUSPENDED” when not in use, they will go IDLE for a short period of time and then if not being used will go to SUSPENDED.

I’m going from memory but I’m reasonably sure that if there were any straggling echo-cancellation streams they would’ve been destroyed when disconnecting the headset so that may be why you are not seeing them in the list.

Does audio get restored after a reboot? Or if using the phone’s own internal mics and speakers?

After a reboot usually, yes. This last time I didn’t get any call audio with internal mics and speakers when I tried placing a new call (before the reboot).

You might get away with killing Pulseaudio rather than rebooting…

killall pulseaudio

Pulseaudio will be restarted pretty much immediately, if that restores audio then it may help narrow down the issue.

I will try that. Also found this bug where it is suggested to run callaudiocli -m 1 to restore audio.