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!
What would a reasonable troubleshooting of this issue look like?
Perhaps the problem can be split into some smaller ones, for example:
Does the microphone work at all, can that be tested separately?
Do the speakers work, test that separately?
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?
Can the CPU create any kind of noise from the speakers during a call? Like playing whatever audio file while a call is active.
Can the CPU access the audio coming from the cellular modem during a call? Maybe dump it to file to check that?
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.
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.
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.
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 .
