According to that link, the fix doesn’t work in Evergreen/Byzantium per ‘Sebastian Krzyszkowiak’:
‘it actually worked on Dogwood/amber-phone, was just super quiet. Works fine (loud and clear) on Evergreen/amber-phone. Doesn’t work on Evergreen/byzantium.’
Is this working for you?
It worked for me the last time I tried it but that was a while ago and I couldn’t say for sure which version (Amber-phone or Byzantium) I was running at the time.
Revisiting this, I am currently definitely running Byzantium and attempting to enable an external wired headset mic, as noted in the bug report, no longer works under Byzantium.
Out of the box, there does not appear to be any discernible difference in outgoing call audio quality when comparing Amber to Byzantium.
I did however workout that the top mic can be disabled with…
sudo i2ctransfer -f -y 2 w4@0x1a 0x00 0x19 0x04 0xda
After listening to numerous audio samples, I’m no longer sure if my mind is playing tricks on me or not, but it does seem to my ears that outgoing call audio is clearer after having disabled the top mic.
Good work, nice find - keep at it!
I’m surprised they have yet to have the mic switch to the audio jack or bluetooth yet. I don’t know many people who hold a phone to their head for long.
I am really at a loss with the call audio quality. People complain about poor sound from my side most of the time, sometimes it the person at the other end can’t make out what I am saying at all. Complaints vary between “you sound very distant”, “you sound muffled or like you are sitting in a box”, “are you on a construction site?”, “your mic seems to pick up every background noise” etc. etc.
The problems appear both with and without the Librem5 headphones and I just can’t seem to find any mic setting that works consistently and reliably. I tried the alsamixer suggestion in this thread, but no consistent improvement.
Shouldn’t there be a default mic setting that just works? As it is now, I am constantly experimenting with different input levels of the mic, but can’t find what produces an acceptable outgoing call audio quality.
Revisiting this once again with a couple of updates…
I do feel there is notable improvement in outgoing call audio to be gained by disabling the top internal mic. For me, disabling the top internal mic reduces or resolves the issues I have been experiencing to the extent that I feel I am now able to have a call conversation. Using the “i2ctransfer” method as previously noted in this thread to disable the top mic works but something resets/re-enables the mic from time to time and it does not survive across reboots. I have found that using pavucontrol provides an easier and more user friendly way of disabling the top mic and it appears to stick.
With use of a small USB C external DAC I am able to get the Librem 5 to recognise my wired headset, with a little bit of additional hoop jumping I am able to use the external mic of the headset for outgoing audio from Calls.
To disable the top internal mic, install pavucontrol from a terminal…
sudo apt install pavucontrol
Once installed the app will be available from the main app view (after selecting to show all apps) under the name “PulseAudio Volume Control”. After launching the app, it’s quite straight forward…
See below image for visual guide…
Setting the “Front Right” (bottom internal mic) to around 65~75% works well for me.
With a wired headset connected via a USB DAC, Calls threw up two problems…
As soon as a call is connected, the mic volume dropped to a very low level, individuals on the other end of the call could barely hear anything if at all.
Raising the volume manually to overcome issue 1, apart from being inconvenient and impractical, triggers automatic gain control which increases the volume over a short period to max or close to it resulting in outgoing call audio being heavily distorted at the receiving end.
I have two different DACs both exhibiting the same issues which leads to me to conclude the issues are more likely down to the behaviour of Calls rather than anything to do with the DACs themselves.
Although I see no need for any echo cancellation or automatic volume control when using a headset, it seems the echo cancellation module needs to be loaded and configured for the headset in order for Calls to leave it alone, my guess is by loading and configuring the module it overrides anything Calls trying to do in that regard.
With USB audio sources (Mics, DACs (and in this case ADCs) etc,.) the echo-cancellation module has to be reloaded each time the device is connected, the module appears to get unloaded each time the USB source is disconnected.
I was unsuccessful when loading the module and applying echo cancellation to the device directly (via filter.apply.echo-cancel.parameters), the filtered registered but seemed to be still getting overridden, so I’m currently just loading and configuring the module in a more global sense.
After attaching the headset and DAC, the module configuration that I am using at the moment can be entered from a terminal…
pactl load-module \
module-echo-cancel \
use_volume_sharing=1 \
use_master_format=1 \
aec_args=" \
analog_gain_control=0\ \
voice_detection=0\ \
high_pass_filter=0\ \
noise_suppression=0"
use_volume_sharing=1 appears to be the magic that stops the mic volume dropping to low levels when a call connects. Although this module creates a virtual echo cancelled source, I am using the standard headset mic source and outgoing call audio is pretty good.
If the module needs to be unloaded for any reason and you do want to detach the device, the module can be simply unloaded from the terminal with…
pactl unload-module module-echo-cancel
As it is a little cumbersome to be manually loading and configuring the module each time the headset is connected, I have set up a udev rule that loads and configures the echo cancellation module whenever it sees either of the two DACs I have connecting which makes calls via a headset quite usable now.
And, just as an aside for @dos, while working through these bits I took a couple of waveform captures (both locally on the Librem 5 and at the receiving end), I do not see any sign of a DC offset on either of the internal mics as described in Issue #348: Built-in microphone feed off-center (DC offset). Where in the signal path did you see the offset?
Wow! pavucontrol on Mobian is primitive by comparison. Too bad, because my external mic used to work tolerably, but with a recent update, it is no longer recognized by the Pinephone.
I might try a DAC, though. To make it viable for my long commute, I’ll have to buy the wireless charging back cover – so I can charge the phone while freeing the USB port for the DAC.
I like all the cross-fertilization between PureOS and Mobian. The Pinephone would be pretty useless without it.
Much of what can be done via pavucontrol can also be done via the command line with pactl and/or pacmd
If calls on Mobian has the same implementation as calls on PureOS and you use a DAC/ADC, you might run into the same issues I did with calls getting funky with the input volume control. I have solved the issue by auto configuring USB audio devices when they get attached, I detail the solution in this thread (Calls with USB headsets and other audio devices) which may be useful to you.
Nice! I’ve ordered USB A to C adapter to give it a try with my DAC.
I’ve configured exactly this and I can even see moving the audio level bar below the sliders following the noise, but when I call some other phone, for example my other mobile, only silence is sent to the other device. Why?
Do you have the pavucontrol application open while making the call? If I recall correctly, the mic signal will not be available to Calls if pavucontrol is open.
You did have a virtual mono mic configured, is that still in place or have you backed that out?
Is there any other audio configuration changes above the default?
As well as the level meter showing signal within pavucontrol, are you seeing signal within the input level meter of the sound tab in the main settings application?
Do you have the pavucontrol application open while making the call? If I recall correctly, the mic signal will not be available to Calls if pavucontrol is open.
Stopping pavucontrol does not make a difference.
You did have a virtual mono mic configured, is that still in place or have you backed that out?
Yes. The motivation of this test here was to see if the audio quality is better.
Is there any other audio configuration changes above the default?
Not that have done them with intentions.
As well as the level meter showing signal within pavucontrol, are you seeing signal within the input level meter of the sound tab in the main settings application?
Yes.
I now switched back, i.e. activated the line again:
$ tail -3 /etc/pulse/librem5.pa
.endif
.include /etc/pulse/voice-call-mic.pa
rebooted and call is working again with audio. I’m clueless.
Since my 5 year old Oneplus is doing really funky stuff recently, my need for my L5 to be a daily driver is becoming more urgent. Can someone give me an estimate whether the audio call issues - like softly swiping my finger over the phone’s physical shell creating super loud noise on the other side of the line - can and will be solved any time soon?
And if this is not going to happen (any time soon), how are the chances that a wired headset (like the one that came with the phone) will work?
Has this been reported anywhere? If not, please file an issue at https://source.puri.sm/Librem5/OS-issues/
I believe someone on the team is investigating this right now.
At the end, I moved away the existing (and perhaps) messed-up configuration with
mv ~/.config/pulse ~/.config/pulse.broken
rebooted, which created a new ~/.config/pulse clean configuration, run again the above steps 1. … 3. and audio in calls worked fine again. It’s a pity that the configuration is stored in some binary files:
$ ls ~/.config/pulse
9b43caf3619f49f8ba467ec270970f44-card-database.tdb
9b43caf3619f49f8ba467ec270970f44-default-sink
9b43caf3619f49f8ba467ec270970f44-default-source
9b43caf3619f49f8ba467ec270970f44-device-volumes.tdb
9b43caf3619f49f8ba467ec270970f44-stream-volumes.tdb
cookie
so we can’t find out with just diff what the problem was. 
python3
import tdb
t = tdb.open('9b43caf3619f49f8ba467ec270970f44-stream-volumes.tdb')
print(list(t.keys()))
or
sudo apt install tdb-tools
tdbdump 9b43caf3619f49f8ba467ec270970f44-stream-volumes.tdb
tdbdump 9b43caf3619f49f8ba467ec270970f44-card-database.tdb
{
key(29) = "alsa_card.platform-sound-wwan"
data(59) = "B\04NL\00\00\00\02tanalog-input\00r\00\00\00\00\00\00\00\00Ntanalog-output\00r\00\00\00\00\00\00\00\00NNN"
}
{
key(24) = "alsa_card.platform-sound"
data(132) = "B\04NL\00\00\00\05t[Out] Headphones\00r\00\00\00\00\00\00\00\00Nt[Out] Speaker\00r\00\00\00\00\00\00\00\00Nt[Out] Handset\00r\00\00\00\00\00\00\00\00Nt[In] Headset\00r\00\00\00\00\00\00\00\00Nt[In] Mic\00r\00\00\00\00\00\00\00\00NNN"
}
hmmmm???
Although we did identify a couple of user config settings related to the actual modem that were set at non-default values there was clearly one or more others that remained a little more elusive causing the issue to remain.
I would have preferred to pinpoint the actual user config setting(s) responsible, but, nuking the config and having pulseaudio rebuild the user config from scratch was a quick and simple fix.