Tdesktop: Accepting call crashes Telegram

[mazhigali]

Steps to reproduce

1. call someone or incoming call
2. click "accept incoming call" or when opponent clicks "accept incoming call"
3. Telegram freezes, call information always on top and doesn't response

Expected behaviour

The person I call to should be heard through speakers, and the person who answers a call should hear me as well.
Basically, a standard crystal-clear call.

Actual behaviour

Telegram freezes, call information always on top and doesn't response

Configuration

Operating system:
Arch Linux/Kernel 4.10.13-1-ARCH/i3wm
Version of Telegram Desktop:
1.1.0
Used theme:
standart

Logs:

• telegram-desktop
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig error: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 72: non-double matrix element
• Fontconfig warning: "/etc/fonts/conf.d/10-scale-bitmap-fonts.conf", line 80: saw unknown, expected number
• AL lib: (WW) alc_initconfig: Failed to initialize backend "pulse"
• QObject::connect: Cannot connect (null)::oneTerminated() to SessionsBox::onOneTerminated()
• QObject::connect: Cannot connect (null)::allTerminated() to SessionsBox::onAllTerminated()
• QObject::connect: Cannot connect (null)::terminateAll() to SessionsBox::onTerminateAll()
• D/tgvoip: === Updating voip config ===
• V/tgvoip: audio_bitrate_step_decr -> 1000.000000
• V/tgvoip: audio_bitrate_step_incr -> 1000.000000
• V/tgvoip: audio_congestion_window -> 1024.000000
• V/tgvoip: audio_frame_size -> 60.000000
• V/tgvoip: audio_init_bitrate -> 16000.000000
• V/tgvoip: audio_init_bitrate_edge -> 8000.000000
• V/tgvoip: audio_init_bitrate_gprs -> 8000.000000
• V/tgvoip: audio_init_bitrate_saving -> 8000.000000
• V/tgvoip: audio_max_bitrate -> 20000.000000
• V/tgvoip: audio_max_bitrate_edge -> 16000.000000
• V/tgvoip: audio_max_bitrate_gprs -> 8000.000000
• V/tgvoip: audio_max_bitrate_saving -> 8000.000000
• V/tgvoip: jitter_losses_to_reset -> 20.000000
• V/tgvoip: jitter_max_delay_20 -> 25.000000
• V/tgvoip: jitter_max_delay_40 -> 15.000000
• V/tgvoip: jitter_max_delay_60 -> 10.000000
• V/tgvoip: jitter_max_slots_20 -> 50.000000
• V/tgvoip: jitter_max_slots_40 -> 30.000000
• V/tgvoip: jitter_max_slots_60 -> 20.000000
• V/tgvoip: jitter_min_delay_20 -> 6.000000
• V/tgvoip: jitter_min_delay_40 -> 4.000000
• V/tgvoip: jitter_min_delay_60 -> 1.000000
• V/tgvoip: jitter_resync_threshold -> 0.500000
• V/tgvoip: use_system_aec -> true
• V/tgvoip: use_system_ns -> true
• V/tgvoip: new endpoint 40007: 91.108.8.7:536
• V/tgvoip: new endpoint 40006: 91.108.8.6:535
• V/tgvoip: new endpoint 10003: 91.108.12.3:526
• V/tgvoip: new endpoint 10002: 91.108.12.2:534
• V/tgvoip: new endpoint 50002: 91.108.16.2:527
• V/tgvoip: new endpoint 50003: 91.108.16.3:538
• W/tgvoip: Set remote endpoints
• I/tgvoip: update data saving mode, config 0, enabled 0, reqd by peer 0
• W/tgvoip: Starting voip controller
• V/tgvoip: trying bind to port 26589
• D/tgvoip: Bound to local UDP port 26589
• I/tgvoip: Receive thread starting
• V/tgvoip: Call state changed to 2
• I/tgvoip: Detected IPv4 connectivity, will not try IPv6
• D/tgvoip: Received init
• I/tgvoip: Peer version is 3
• W/tgvoip: Received duplicated packet for seq 1
• W/tgvoip: Received duplicated packet for seq 1
• W/tgvoip: Received duplicated packet for seq 1
• W/tgvoip: Received duplicated packet for seq 1
• W/tgvoip: Received duplicated packet for seq 1
• D/tgvoip: Received ping from 91.108.8.6:535
• D/tgvoip: Received ping from 91.108.8.7:536
• V/tgvoip: Call state changed to 2
• D/tgvoip: Received ping from 91.108.12.3:526
• D/tgvoip: Received ping from 91.108.12.2:534
• D/tgvoip: Received ping from 91.108.16.2:527
• D/tgvoip: Received ping from 91.108.16.3:538
• D/tgvoip: Received init ack
• I/tgvoip: peer version from init ack 3
• I/tgvoip: before create audio io
• E/tgvoip: pa_context_connectfailed: Access denied
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• V/tgvoip: Call state changed to 2
• D/tgvoip: Entered VoIPController::~VoIPController
• D/tgvoip: before shutdown socket
• D/tgvoip: before join sendThread
• I/tgvoip: === send thread exiting ===
• D/tgvoip: before join recvThread
• I/tgvoip: === tick thread exiting ===

[GarikTester]

Can confirm, steps to reproduce are the same, but instead of client freezing, only call crashes and showing error message "Problems with audio playback on your computer", but I don't have any of them). After that, client continues to work as normal. Fedora 25/MATE/4.10.14 kernel/Telegram 1.1alpha

[john-preston]

@GarikTester Does audio recording and playback in app work fine? (voice message recording / voice message playback, for example)

[mazhigali]

@john-preston voice message recording / voice message playback works fine

[john-preston]

@mazhigali So for you the audio works fine for voice messages and doesn't work for calls? In the 1.1.0 version?

[mazhigali]

@john-preston Exactly.

[GarikTester]

@john-preston Voice recording/playback works flawlessly. Problem is only with calls.
P.S. If it's important, I have Pulseaudio installed).

[john-preston]

@GarikTester Please enable debug logs (in Settings type "debugmode" from your keyboard and agree to enable the debug mode) and then try a call once again. Once it fails to init the audio input / output please send the "~/.local/share/Telegram Desktop/DebugLogs/last_call_log.txt" file here or to me directly at https://t.me/preston

[GarikTester]

@john-preston No need to paste logs - it's working now without any intervention. Calls didn't work yesterday, but self-repaired somehow, and now working without issues.

[auchri]

@GarikTester That sounds really strange. Did you change anything at your computer?

[GarikTester]

@auchri Absolutely nothing, no updates, no tinkering, nothing.

[auchri]

Maybe @mazhigali has some logs for us?

[mazhigali]

@auchri logs in text of issue and i sent it directly at https://t.me/preston yet

[GarikTester]

last_call_log.txt
The log of the latest today's successful call.

[mymedia2]

I can confirm this bug. Telegram always freezes on a receiving party. I got the next stacktrace, I hope it'll be helpful. Stacktrace.txt

It looks like deadlock in libtgvoip.

[LDVSOFT]

I want to add here that this bug is not so reproducable: I am getting this issue from time to time but cannot find a reliable way to reproduce it to get the logs.

[LDVSOFT]

Here, I got some:
last_call_log.txt

[john-preston]

@LDVSOFT So, what was the problem in that specific case? How did the app behave?

[Daniel-M]

Hi everyone. I have the same issue @mazhigali initally reported, with the same steps, with both outgoing and incoming calls in Telegram Desktop v1.1.

My system information:

• ( Debian Testing ) Linux 4.9.0-2-amd64 #1 SMP Debian 4.9.18-1 (2017-03-30) x86_64 GNU/Linux
• Telegram Desktop version 1.1, last update so far. (checked updates before posting to this issue)

Enabled debug mode as indicated by @john-preston here are some logs

Outgoing call
Incoming call

Edit:
The only way to stop the behaviour is to kill Telegram Desktop I hope there's enough debug information to help.

Also, my sound layer relies only on ALSA without pulseadio or anything else. This might be important since I know first hand that audio streaming can cause crashes in other applications (like some popular web browsers). I can hear Telegram audios without problems, never have sent one since it doesn't shows the option to do so (no mic button like in the andoid app). I even hear the ring bell of the incoming call, or the call tone in outgoing calls.

[ghost]

Hi everyone. I'm having exactly the same issue like @Daniel-M. I'm running Arch Linux/Kernel 4.10.13-1-ARCH without PulseAudio. Plain ALSA. Telegram freezes on both incoming and outgoing calls.

I've tried to run Telegram via apulse wrapper (https://github.com/i-rinat/apulse) which emulates pulseaudio, this utility was used long ago with Skype as it doesn't support plain ALSA. This way calls seem to work fine and I don't experience freezes. So problem must be related to plain ALSA.

[john-preston]

@dikouzmine Please check out the latest 1.1.1 alpha version from https://desktop.telegram.org/changelog#alpha-version

It should not freeze in calls.

[ghost]

@john-preston Just built Telegram from this tag https://github.com/telegramdesktop/tdesktop/tree/v1.1.1 and it works! No more freezes with plain ALSA.

[Daniel-M]

@john-preston using Telegram Alpha v1.1.1 from the link you shared causes the application to crash
Here's the log
It's clear that the issue is related to using ALSA.

I don't have the time to try the build suggested by @dikouzmine from the indicated tag, otherwise I'd give it a try.

[grishka]

@Daniel-M ok... Do other audio-related Telegram features work for you, like music playback and voice message recording?

[Daniel-M]

@grishka Yes, the client has good sound, I can hear voice messages with no problem, also videos played on the client have sound. Sound notifications are working normal with sound, the ringing the bell of calls too.
My ALSA layer detects several cards, one associated with HDMI output (hw device 0) and the other the speakers/headphones( hw device 1) My settings point to the hw device 1, I don't know why the Telegram client crashes if it is sending sound to the card. At most it should be muted which is not.

Commentary on pulse
The last log I've referred said that pulse was detected but not working. The only pulse related packages I have are,

gstreamer1.0-pulseaudio:amd64           install
libpulse-mainloop-glib0:amd64           install
libpulse0:amd64                 install

Which is the output of dpkg --get-selections | grep "pulse". those packages are correquisites of other programs installed, so can't take them out.

[grishka]

@Daniel-M well it shouldn't crash if it failed to initialize audio, there's a specific error message it should show in UI and end the call. Did you send a crash report after it crashed?

Also, is it that "exclusive access" ALSA mode? As in, there's no mixer between the apps and the device and only one application could use a single device at a time.

[Daniel-M]

@grishka I'm mixing all sound sources via alsa's plugin dmix so it is not exclusive access. Exclusive access would prevent Telegram to sound if other programs were using the stream, like a music player for instance, or a web browser

Edit:
My alsa configurations:
/etc/asound.conf
/usr/share/alsa/alsa.conf

[grishka]

@Daniel-M ok, does that plugin include a resampler as well or I have to match the sampling rate of my input/output to that of the hardware?

[Daniel-M]

@grishka I'm not sure if it has an internal resampler, but I'm not manually resampling the plugins

My alsa configurations:
/etc/asound.conf
/usr/share/alsa/alsa.conf

the defaults point to the card 1

[grishka]

@Daniel-M looking at your configs, I don't think the sampling rate is actually the problem because you have it set to 48000 which is exactly what I use. Could you record voice messages? It seems that playback should be working fine but it's capture that fails.

[john-preston]

@Daniel-M The application crashes or just the call is terminated? If application crashes, does it offer to send a crash report on the next launch?

Also, can you record the voice messages? Are they playing clearly after being recorded and sent in some chat?

[Daniel-M]

@grishka this might sound silly, but I don't know how to record voice messages on the desktop client, it doesn't show the microphone button, but I guess this means that the client don't recognize the capture device. sorry guys, I didn't had the systemwide default capture device for ALSA configured and that was the issue. I thought I was since I tune my guitar with Lingot but I had manually putted the capture device, so my systemwide was unsetted.

Here's how I configured ALSA in /etc/asound.conf and now I can send voice messages from the client and the calls work great. I hope it helps someone with the same issue.

For the record and to answer @john-preston question, the client crashed without notice, just like that, no warnings, no nothing.

[mazhigali]

@john-preston Thanks for release. In version 1.1.2 issue fixed