How about a little community effort to solve the phone call audio routing problem?

So some Librem 5 Birch phones have been delivered and you can call but there is no sound. Todd wrote yesterday that it “will be a few days until the bug is fixed”:

I was thinking, why don’t we just go ahead and solve the problem here in this forum? If some of the lucky Birch owners are willing to run some tests, others can suggest troubleshooting steps, someone runs new tests, and so on. We could solve it before Purism does! :smiley:

What would a reasonable troubleshooting of this issue look like?

Perhaps the problem can be split into some smaller ones, for example:

  1. Does the microphone work at all, can that be tested separately?
  2. Do the speakers work, test that separately?
  3. Can the CPU get access to the output from the microphone during a call? Maybe dump a recording to file, to check if that is working?
  4. Can the CPU create any kind of noise from the speakers during a call? Like playing whatever audio file while a call is active.
  5. Can the CPU access the audio coming from the cellular modem during a call? Maybe dump it to file to check that?
  6. Can the CPU generate some noise at the other end of the phone call, by somehow pushing data to the cellular modem while the call is active? Listen at the other end of the call to hear if any noise comes out on that end?

What do you think, does the above make sense? If so, how could such testing be done in practice? Are there other, better ways to troubleshoot?

Any Birch owners who would volunteer to do some testing?


Aye, I was thinking about that. Start by installing the alsa-utils package, and run aplay -L and aplay -l. If the drivers work, that should spit out a list of audio devices. You can then use speaker-test -D hw:$device to test output, and arecord -D hw:$device to test input. If it complains about channel counts, -c 1 will probably resolve that.

If no audio devices are listed, lspci -vvv and lsusb -vvv might give some insight, but the solution is probably more difficult.

From something mentioned elsewhere (bug tracker I think), the modem exposes a USB mic and speaker, and they plan to have pulseaudio route the modem speaker to the external (or headphone) speaker and the external mic to the modem mic during a call.

This should be obvious if aplay shows more than one sound card. If that is the case, you can bridge the sound cards via something like

arecord -M --period-time=0 --buffer-time=0 -f cd -D plughw:$EXTDEVNAME -t raw - | aplay -M --period-time=0 --buffer-time=0 -f cd -D plughw:$MODDEVNAME -t raw

And the same command with the devices reversed to bridge the other way. Obviously not a good long term solution, but would be a decent demo.

Also, you can hit #alsa on the freenode IRC and I’m sure there’d be someone willing to help.


What are related issues?
Is this one about the same problem ?

1 Like

Maybe this is related:

But the last comment there is 5 months old and says “With the latest kernel and update, call audio is working.” It seems to be about the devkit, like they had such a problem for the devkit and it was solved, but now there is another problem for the real phone.

The phone doesn’t use the same modem than the devkit. Maybe the problem is related to the modem’s driver.


@mixim They are using the BroadMobi BM818 in birch


They said routing. I assume they already know where the problem is and that it’s above driver level.

Maybe this?


Angus said in the chat room that it will likely be fixed today, unfortunately it requires a kernel update to fix this.


Here is something related, a new issue created 8 hours ago by Angus:

If I understand that correctly, it means that call audio (at least inbound voice) works now, until some messed up reconfiguration happens. It should start working again after reboot, after rebooting you should be able to make an outbound call and hear the other person’s voice.

Most chips have a MCLR or a nMCLR pin (master-clear or not-master-clear pin). If there is no pin like this, there should be a way to reset the device from firmware or by interrupting the supply voltage to it. Could they not simply reset the audio chip after each call? That seems preferable to a whole device reboot.

you could just open pulse audio plugin set to input only and see if there is a signal routing through the gpu .

that means pulse audio configuration profile is being set from stereo duplex to output only upon incoming call . If one could figure away to lock that profile as duplex sans someone unlocking it to change the config profile . Shouldnt be too hard if thats all it is . I wonder what is triggering the config change specifically .

Perhaps Demsg command may give a clue into what specifically is happening after an inbound call .

This issue “Outputting ringtone disables incoming audio” ( is apparently fixed now, instead there is this new issue: