Latest gnome-calls very unstable

[tomoqv]

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?

[tomoqv]

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:

[Gavaudan]

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

[tomoqv]

Good point, will look into an update later.

Edit: Here goes

[Skalman]

@tomoqv

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

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.

[tomoqv]

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.

[tomoqv]

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

[Loki]

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.

[tomoqv]

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

[tomoqv]

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

[Loki]

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?

[tomoqv]

@Loki

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).

[Loki]

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.

[tomoqv]

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

[antonis]

The latest calls (44.alpha.0) is very unstable. Sometimes it does not stop the ringing although the call has been answered and is in progress. Sometimes it crashes. Sometimes it answers a call and its window dissapears, the call continues but you have no access to controls (like hangup) unless you re-click on calls to restart.

Very annoying. How do I revert to previous version which was very stable?

[antonis]

I cd to /var/cache/apt/archives and
sudo apt-get install ./gnome-calls_43~beta.0-1pureos1_arm64.deb

Did not find another way (no option in package manager to downgrade)

[guru]

I have as installed 44-alpha too, but in /var/cache/apt/archives only 41.1, 41-rc and 42-alpha, but no 43-beta. Why?

[irvinewade]

@antonis

no option in package manager to downgrade

sudo apt install packagename=version

and use

apt list -a packagename

in the first place to find what versions are available.

[antonis]

No it does not work. apt list -a gnome-calls shows only the installed version and the versions available for upgrade. Not the possible installable versions. Not older versions.

@guru most probably you did not install the 43 version. You skipped from 42-alpha to 44-alpha.

I do not know in this case where from you could get the 43~beta which is good.

[guru]

@antonis

@guru most probably you did not install the 43 version. You skipped from 42-alpha to 44-alpha.

I can’t imagine. I do every day, sometimes more than one time, a sudo apt update && sudo apt full-upgrade. The last modification time of the gnome-calls files in the archive a somewhat crazy:

-rw-r--r-- 1 root root 281216 Oct  4  2021 gnome-calls_41~rc-1pureos2_arm64.deb
-rw-r--r-- 1 root root 211652 Nov  9  2021 gnome-calls_41.1-1pureos1_arm64.deb
-rw-r--r-- 1 root root 227824 Dec 15  2021 gnome-calls_42~alpha.0-1pureos1_arm64.deb

purism@pureos:/var/cache/apt/archives$ ls -ld /var/cache/apt/archives
drwxr-xr-x 3 root root 73728 Dec 19 09:25 /var/cache/apt/archives

The modification time of the dir /var/cache/apt/archives is correct (yesterday).