Internal Mic Fix?

The mic works but everyone tells me it’s echoey, they hear themselves, and if I move my finger along even the back of the phone it’s very loud. Seems like it picks up everything.even minor.

I tried using the included headphones, but the mic doesn’t work. I tried using a Bluetooth headset and the mic doesn’t work. Did a forum search and found that this is in fact the case.

So next I tried to use alsamixer, but that didn’t seem to fix the issue either.

Has anyone figured out how to make the internal mic actually usable without giving the person I’m speaking with a bad experience? Is anyone currently working on fixing the internal mic sensitivity or getting an external mic to work?

Thanks everyone!


The current quality of outgoing voice call audio via the internal mic(s) is quite poor. I have given up on calls for the moment as most conversations would have the other end asking if I could “repeat that” multiple times.

The internal mics do seem to pick up everything, they should have echo cancellation running on them (unless it’s been disabled in recent updates?) which would prevent or at least greatly reduce the possibility of the other end hearing themselves, has anyone given you any indication as to what sort of delay is on the echo, milliseconds, seconds?

Wired headsets with mics do sound significantly better (although I’d guess that also depends on the quality of the headset) but enabling/disabling them at the moment is a little cumbersome (see bug for method) and not well suited to everyday use.

1 Like

This bug already fixed.
You are on Byzantium or Amber?
You can custom the Mic under alsa ucm voicecall.conf.

Which bug is “This bug”?

The bug I linked to is currently showing as “Open”, the OP mentions echoey calls and external mics (both wired and Bluetooth) not working.

I say the bug for ’ echo cancellation ’ @dos

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.

1 Like

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…

  1. 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.

  2. 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…

  1. Choose the “Input Devices” tab
  2. Unlink the Left/Right gain controls to give independent control of each
  3. Disable top internal mic by setting “Front Left” gain to 0%

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…

  1. 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.

  2. 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\ \

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.

1 Like

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?


I now switched back, i.e. activated the line again:

$ tail -3 /etc/pulse/

.include /etc/pulse/

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