No audio for phone calls on Librem 5 (Birch)

Hardware Librem 5
1

I’m finally trying to switch my daily Smartphone to my Librem 5 (Birch). Unfortunately there is no working audio during phone calls. SMS and mobile network works. Also calling seems to work, but it’s just silent in both directions.
These are the logs I get using sudo journalctl -f:

May 06 09:17:19 pureos ModemManager[594]: <info>  [modem0/call0] user request to start call
May 06 09:17:19 pureos ModemManager[594]: <info>  [modem0/call0] call state changed: unknown -> dialing (outgoing-started)
May 06 09:17:19 pureos ModemManager[594]: <info>  [modem0/call0] call is started
May 06 09:17:22 pureos ModemManager[594]: <info>  [modem0/call0] call state changed: dialing -> ringing-out (unknown)
May 06 09:17:22 pureos pulseaudio[758]: Configured maximum latency is smaller than latency, using latency instead
May 06 09:17:22 pureos pulseaudio[758]: Cannot set requested sink latency of 50.00 ms, adjusting to 100.00 ms
May 06 09:17:22 pureos pulseaudio[758]: Cannot set requested source latency of 50.00 ms, adjusting to 100.00 ms
May 06 09:17:22 pureos ModemManager[594]: <info>  [modem0/call0] call state changed: ringing-out -> active (unknown)
May 06 09:17:23 pureos pulseaudio[758]: Configured maximum latency is smaller than latency, using latency instead
May 06 09:17:23 pureos pulseaudio[758]: Cannot set requested sink latency of 50.00 ms, adjusting to 100.00 ms
May 06 09:17:23 pureos pulseaudio[758]: Cannot set requested source latency of 50.00 ms, adjusting to 100.00 ms
May 06 09:17:23 pureos pulseaudio[758]: Doing resync
May 06 09:17:23 pureos pulseaudio[758]: Playback too far ahead (5250), drop source 1008
May 06 09:17:23 pureos pulseaudio[758]: ALSA woke us up to read new data from the device, but there was actually nothing to read.
May 06 09:17:23 pureos pulseaudio[758]: Most likely this is a bug in the ALSA driver 'snd_soc_simple_card'. Please report this issue to the ALSA developers.
May 06 09:17:23 pureos pulseaudio[758]: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
May 06 09:17:23 pureos pulseaudio[758]: Configured latency of 200.00 ms is smaller than minimum latency, using minimum instead
May 06 09:17:23 pureos pulseaudio[758]: Cannot set requested source latency of 60.75 ms, adjusting to 100.00 ms
May 06 09:17:23 pureos pulseaudio[758]: Cannot set requested sink latency of 50.00 ms, adjusting to 100.00 ms
May 06 09:17:23 pureos callaudiod[988]: no available input found!
May 06 09:17:23 pureos callaudiod[988]: no available output found!
May 06 09:17:23 pureos callaudiod[988]: no available input found!
May 06 09:17:23 pureos pulseaudio[758]: Doing resync
May 06 09:17:23 pureos pulseaudio[758]: Playback too far ahead (9505), drop source 1824
May 06 09:17:24 pureos pulseaudio[758]: Playback too far ahead (10858), drop source 2084
May 06 09:17:25 pureos pulseaudio[758]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
May 06 09:17:25 pureos pulseaudio[758]: Most likely this is a bug in the ALSA driver 'snd_soc_simple_card'. Please report this issue to the ALSA developers.
May 06 09:17:25 pureos pulseaudio[758]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
May 06 09:17:25 pureos pulseaudio[758]: Playback too far ahead (15379), drop source 2952
May 06 09:17:26 pureos pulseaudio[758]: Playback too far ahead (10890), drop source 2088
May 06 09:17:27 pureos pulseaudio[758]: Playback too far ahead (10396), drop source 1996
May 06 09:17:28 pureos pulseaudio[758]: Playback too far ahead (9935), drop source 1904
May 06 09:17:29 pureos pulseaudio[758]: Playback too far ahead (10256), drop source 1968
May 06 09:17:30 pureos pulseaudio[758]: Playback too far ahead (10242), drop source 1964
May 06 09:17:31 pureos pulseaudio[758]: Playback too far ahead (9936), drop source 1904
May 06 09:17:31 pureos ModemManager[594]: <info>  [modem0/call0] user request to hangup call
May 06 09:17:31 pureos ModemManager[594]: <info>  [modem0/call0] call state changed: active -> terminated (terminated)

Is this a configuration issue? Can I provide more information to debug the issue?

2

Obvious question for “last post was 2 years ago” and “Birch” is … are you running amber or byzantium? I mean have you applied any updates in those 2 years? In fairness, I think you need to run the latter. However I have no idea how simple or difficult it will be to upgrade a Birch batch phone. It will presumably involve a reflash of the phone, which could be a good thing (start from clean, known state) or a bad thing (lose all your settings etc.)

lsb_release -c

3

Oh, sorry for not mentioning it. I already did a reflash with byzantium before starting to set it up.

I also saw on https://docs.puri.sm/Librem_5/Known_Issues/Birch.html this entry:

Call audio routing is not functioning completely.

Not sure how up-to-date this information is. According to Troubleshooting phonecall problem on Librem 5 Birch, it can work on Birch.

1 Like
4

I can confirm that it works on Birch with PureOS byzantium with the latest updates now, phone call audio in both directions.

If you don’t mind losing all data on it, you could try reflashing from scratch to make sure you have the latest software and no old config lying around causing problems.

1 Like
5

Okay, I did a reflash now. After that I configured WiFi and installed the latest updates. But I still have the same problem: The call is “running” but no audio is working.

Other sounds like for the notifications work without issues.

Does someone have an idea how to debug this further?

6

I just found the following issue which looks related to my problem: https://gitlab.gnome.org/GNOME/calls/-/issues/116

It seems that I have an old firmware, my output is:

M100E_1.0.0_190426,BMC_M100E_1BAD_3117_V1.0.0.0_20190426,M100E_1.0.0_190426

Does this mean my Librem 5 won’t be able to do phone calls?

1 Like
7

OK, that can explain the difference compared to my Birch device, I have this:

M100E_1.0.0_190426,BMC_M100E_1BAD_3117_V1.0.0.0_20190426,M100E_1.0.0_190910

Maybe, but the good news is that you can replace the modem. You can ask Purism to send you a new modem, or buy a new one, then install it yourself. Or you can ask Purism to do it for you. Either way, I think a new modem now will have the newer firmware version.

8

Thanks for your answer! I asked Purism Support now to get some more clarifications on this. I hope that I can then just replace the modem.

1 Like
9

With the help of @joao.azevedo I was able to “fix” the issue. I got a replacement modem from Purism, or they updated the firmware on it :slight_smile:
I’m now able to do calls with my Librem 5 (Birch).

3 Likes
10

What version it is?

With VoLTE enabled too?

11

It is the version that allows VoLTE.

12

Well i have one modem with firmware version 2019 and VoLTE work fine, also i have one modem version 2022 and VoLTE not working on my case.

13

can you contact us via email to: support@puri.sm with your order number? And explaining the situation.

14

The version is reported as MPSS.JO.2.0.2.c1.1-00032-9607_GENNS_PACK-1 1 [Feb 25 2019 01:00:00] using the command sudo mmcli -m any | grep firmware

2 Likes
15

I don’t have the need to call purism customer service yet, i like troubleshooting :yum: so it will cool if Purism put modem firmware availables to reburning the modem, as the burner it already there but not modem firmwares yet.
At same time i know VoLTE it very troubled and controversial

16

It old. but this old worked good to me too.

1 Like