L5 call audio quality

Hardware Librem 5
21

What you are seeing is representative of the current state of Librem 5’s audio hardware and handling.

I think this is quite common and presents an issue, if most people who try calling give up on it due to call quality then it’s unlikely to see much if any developer time and will remain in an unusable state for quite some time. It also means that if there are not many people using Calls there could be a number of other underlying usability and stability issues not being picked up on or addressed, it’s a bit of a catch 22.

There has been some recent updates to some open issues regarding external microphone/headset support so may be you’ll see some improvements in that area sooner rather than later. There was a comment regarding a recent merge that suggests selecting the external mic from the drop down will now enable it (albeit with a low volume and no auto sensing so the input won’t auto switch back when the headset is disconnected). I don’t think that merge has made it to a release as yet but may be available in a week or so.

On the positive side of things, with a little workaround you can use headsets for Calls, and the audio quality is decent (quality of headset/hardware dependent of course) so it seems that for audio call quality the current root cause is all down to the source.

1 Like
22

I can think of a few more reasons why call audio quality is still a problem:

  • It is not a clear-cut bug because call audio is working to an extent, it’s just very poor. It’s always easier to get things fixed when it’s a question of working vs not working at all.
  • Call audio is bad for the other person, not for the one holding the Librem 5. So, in many cases the problem is there but you don’t know it, it depends on whether the person you are talking to complains or not.
  • I suspect that Purism’s developers who are themselves using Librem 5 for calls have tweaked some microphone settings making things work better for them, so they do not notice the problem.

Anyway, I have the problem too and it’s quite severe, I hope it can get fixed somehow. Will try to do some kind of systematic testing when I have time.

3 Likes
23

Yes, very true, bugs and issues that can be reliably reproduced do tend to get more attention.

Yes, although for me, there would be a complaint with most calls, and if not, there was certainly more requests from the recipient to “repeat that” as they could not quite understand what I was saying.

This is an easy one to workaround, swap phones with someone for a few calls. When doing that, there are two main things I have heard, words can become muffled or the audio stream becomes garbled (it sounds like muffled talking underwater, I don’t know if that description is helpful or not). To me it has all the hallmarks of signal processing getting massively confused, I have come close to being able to reproduce it by really forcing an echo feedback loop.

I would hope that if they were aware of any configurations that help at least reduce the issue that those configs would be rolled into the release. Although, may be not, I have found that for standard calls using just the phone’s internal mics, disabling the top microphone has made a very noticeable improvement.

I haven’t had too many calls with the phone since disabling the top microphone and I tend to use a headset if I can, but of the ones I have had, there hasn’t been any complaints and I don’t recall any excessive requests to repeat myself. It’s early days but it does seem promising, for me at least.

I found testing to be problematic, I attempted to grab some audio captures, leaving messages with an answer service leads to an exaggerated false sense of poor audio quality, I suspect this is down to the answer service recording messages at very low bit rates.

I tried capturing the audio of a call directly but my audio capture setup produces captures that sound better than they should. I suspect some conversion under the hood is trying to fill in the blanks of the low bandwidth/bit rates and doing too good a job.

24

Where should we watch for that change?

Does the meter in the settings show the input level from external source? If so the necessary workaround sounds manageable.

25

The comment I was referencing is near the bottom of this issue (Need headphone and microphone support), I was sure that comment was in reference to a code merge but looking at it again, it does not appear to be the case, it merely says “headphone microphone will be available to manually select soon”. So while it may be available soon, it’s probably not as soon as within the week.

I have no idea, I have not been following the issue too closely or trying out any proposed changes.

The workaround I have is to connect the wired headset via a USB DAC/ADC, with this approach it’s almost “plug ‘n’ play” the phone OS sees the headset and auto switches both input and output to the headset’s mic and cans respectively, there is no issue with volume input or output. The only issue is that Calls gets a little funky with the input volume to such an extent that it’s unusable. I have a fix for that which I’ll write up in a separate thread later.

FWIW, I’ve been using a couple of different DAC/ADCs (a UGREEN USB C to 3.5mm adapter and a THX Onyx) providing connectivity for a couple of different headsets (Beyerdynamic MMX 300 and Beyerdynamic DT 790 (retro fitted with an electret condenser for mobile device compatibility)) these are all working well and providing good call audio quality.

If you decide to go down the DAC route ensure the feature set lists microphone support or calling or some such similar, particularly if looking at UGREEN, they manufacture an almost identical looking product but it is a basic converter with no internal DAC. Power consumption is also a factor, I don’t have exact figures but I suspect the THX unit would decimate the Librem 5’s battery after a very short period of use.

I have also tried a dedicated USB headset (Beyerdynamic MMX 150 can you see and pattern forming?) and a standard telephony headset (Jabra Evolve 65 with Jabra Link 360) these both work fine, the Jabra unit is limited in bandwidth in comparison to the others and you can definitely tell that, although, it still produces clear and legible audio.

1 Like
26

I was affected by the poor audio at the remote end too. After applying the changes from a post in the forum, all is very fine now:

Internal Mic Fix?

sudo apt install pavucontrol
start the app and do:
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%
3 Likes
27

So I guess its a noise canceling issue?

28

I could be wrong, but after testing the steps @guru linked to, I don’t think it is a noise cancellation issue. I think that when the microphones on both ends of the Librem 5 are enabled, the Librem 5 is mixing both mics in equal proportions. Thus the mic at the bottom (where one would normally talk) is getting it’s input and mixing it with the input from the mic at the top of the Librem 5 (which is farther away from the mouth of the one speaking and thus a lower volume input), which means the end result mixed microphone input is a bit low and sounds like it’s a bit distant (because half of the mixed input is coming from a mic at the other end of the phone). When you disable the “left” microphone (i.e. the one at the top of the Librem 5), the input is solely from the bottom of the Librem 5 (where you usually talk into when you’re talking on a cell phone), so it sounds better.

1 Like
29

Ah, I thought the whole point of the second microphone was for noise canceling, but maybe not. If not, though, I don’t see its purpose if the call isn’t on speakerphone?

1 Like
30

I agree. I would assume Purism will have to find a way for both microphones to be enabled when speakerphone is on and only the bottom/“right” microphone is on when it’s a regular non-speakerphone call.

31

Related issue:

Citing one of the comments there:

not only possible echo but also noise when you don’t hold the phone very still is produced to the top mic.

1 Like
32

Need to test some more, but I think this helped also for me.

Can that change be done from the command-line?

The following works to show current mic volume settings:

pacmd list-sources

where the relevant part of the output I think it the following:

[...]
  * index: 1
	name: <alsa_input.platform-sound.HiFi__hw_L5_0__source>
	driver: <module-alsa-card.c>
	flags: HARDWARE DECIBEL_VOLUME LATENCY 
	state: SUSPENDED
	suspend cause: IDLE
	priority: 9005
	volume: front-left: 0 /   0% / -inf dB,   front-right: 65536 / 100% / 0.00 dB
	        balance 1.00
	base volume: 65536 / 100% / 0.00 dB
[...]

where I think the “front-left: 0 / 0% / -inf dB” means that front-left has been set to zero. But what about changing the setting via command-line, how to do that?

33

Yes it can, in this case the basic syntax is…

pactl set-source-volume <cardname or index> <leftvolume> <rightvolume>

So from your sources list, it’s index 1 so from command line you can do…

pactl set-source-volume 1 0% 75%

You can also apply relative adjustments for example…

pactl set-source-volume 1 -200% +0%

Would drop the left volume to 0% while keeping the right volume unchanged, I use -200% just in case the input has had some digital gain applied in which case it’s level would initially be greater than 100%

2 Likes
34

This works great, thank you!

purism@pureos:~$ pactl set-source-volume 1 100% 100%
purism@pureos:~$ pacmd list-sources | grep -A7 "index: 1"
  * index: 1
	name: <alsa_input.platform-sound.HiFi__hw_L5_0__source>
	driver: <module-alsa-card.c>
	flags: HARDWARE DECIBEL_VOLUME LATENCY 
	state: SUSPENDED
	suspend cause: IDLE
	priority: 9005
	volume: front-left: 65536 / 100% / 0.00 dB,   front-right: 65536 / 100% / 0.00 dB
purism@pureos:~$ pactl set-source-volume 1 0% 75%
purism@pureos:~$ pacmd list-sources | grep -A7 "index: 1"
  * index: 1
	name: <alsa_input.platform-sound.HiFi__hw_L5_0__source>
	driver: <module-alsa-card.c>
	flags: HARDWARE DECIBEL_VOLUME LATENCY 
	state: SUSPENDED
	suspend cause: IDLE
	priority: 9005
	volume: front-left: 0 /   0% / -inf dB,   front-right: 49152 /  75% / -7.50 dB

I rebooted to check, and it looks like the change is persistent, still there after reboot. Good.

So, for the “right” mic you think 75% is better than 100%?

1 Like
35

Around 75% works for me, but I guess everybody has a different natural voice level, experiment with different levels to find what works for you.

I feel at 100% it is too loud on the recipients end.

1 Like
36

I set right to 85% and called my landline phone which autoanswers and record the message. Seems to be fine.

What I do miss in the Dialer app, is audio feedback when pressing the dial keys.

1 Like
37

Just so, that everyone can find it from here, see @Loki’s more permanent solution:

1 Like
38

There are extreme circumstances where it might be desirable to have silent dialing. So whatever is done, there should be user control.

1 Like
39

Ofc, this must be one of the sound settings values ([v] on [.] off), like:

[.] Vibrate on ring
[v] Vibrate in Silent Mode
[v] Dialpad tones
...

(to avoid a screen shot of my Ubuntu mobile)

1 Like
40

If pavucontrol fixes the audio problem (have not tried yet, but I will) I do not understand why purism has not done this with some update until a better use of the second mic is found. It is a year now that people complain about this. I even temporarily abandoned L5 for this reason. Others the same.

It does not make sense. So many (or all) developers read this forum. None knew that the problem was the equally mixing second mic? I wonder.

3 Likes