L5 call audio quality

Hardware Librem 5
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
41

To be clear about the mixing of mics, that is my personal evaluation as to why the audio quality sounds the way it does when both mics are enabled. I am not an audio expert; I have some amateur experience mixing music, but I can’t authoritatively say that’s what’s happening. It just really feels like it is what is happening.

42

They either understand you on the other side or not. I will also test it, I just have to swap the SIM from another phone.

43

I was calling from the Librem 5 to another phone I had when I was testing both ways, and I could hear/understand my voice coming from the Librem 5 both with both mics enabled and with only the bottom one enabled. It sounded more distant when I had both mics enabled, though, and much closer when I just had the bottom mic enabled.

44

Too bad you can’t just spit on the tubes and slap the back of the cabinet like Andy Griffit did in “No Time for Sergeants”.

1 Like
45

I just tried the new settings with pavucontrol. And yes there is a huge difference. This solves the issue with the audio quality on the other end and the sound is not a VoLTE issue as I thought earlier.

I think that Purism should set the left microphone to 0% until a solution is found for the proper use of the second (left) mic. For example, I guess it is trivial to null the left mic for regular calls and null the right mic and open t he left when the speaker is turned on. It is just a toggle with the speaker button when one is in a call. Is there any reason why this is not the default behavior @dos ?

Having both mics mixing their input when in a regular call the other side very often can not understand anything of what is said.

By the way I tested with Left Mic at 0% and Right Mic at 85%

Let me add here that there still problems with the modem. It took 3 reboots to make the modem work. It was dead and the HKS did not help either.

3 Likes
46

I’d have to take a closer look again, but from what I remember there was a problem that the modem seems to use random stereo channel for mic audio for each call and ignores the other one, so muting one channel randomly made some calls silent. This may need to be revisited, as I think PA is downmixing it down to single channel in echo-cancel module now, but it was a long time ago that I looked at it the last time, so my memory may be rusty there.

3 Likes
47

For an additional data point, and as I’m now on Byzantium, I placed two test calls from the L5 to an Android phone, and left a message in voice mail each time. Then I called from the Android to the L5 and left a message in voice mail.

I don’t have any additional sound/volume packages other than the default.

Call 1 (L5 to Android) internal microphone setting of L5: maximum
Call 2 (L5 to Android) internal microphone setting of L5: approximately 65%
Call 3 (Android to L5) internal microphone setting of L5: approximately 65%

For Call 1, voice quality was totally intelligible, but slightly distorted, and lacking treble/crispness.

For Call 2, voice quality was totally intelligible, but less distorted, still lacking treble/crispness.

For Call 3, voice quality was not only intelligible, but also crisp with normal treble. (This voice message was automatically emailed to me, so I first played it from my computer, not listening with the L5. Listening directly on the L5, the quality is not as good; it’s similar to Call 2.)

48

Perhaps I was just lucky and the phone was always choosing the right channel / bottom mic, as that is not something I was seeing when I evaluated the setting the left gain to 0%, I always had audio for every call.

For some time now I have been running a slightly different config which should avoid that issue if it exists. I have defined a virtual mono mic which uses the right channel only of the physical internal mic as it’s source and has the echo-cancel filter definition applied to it’s device properties. On boot, the virtual mic gets set as the default input source and consequently gets used for voice calls, as it is a mono source, there should be no issues with random channel selection.

I created the file /etc/pulse/voice-call-mic.pa with the following contents…

load-module module-remap-source master=alsa_input.platform-sound.HiFi__hw_L5_0__source channels=1 master_channel_map=front-right channel_map=mono source_name=virtual_input.voice-mic-01.mono source_properties="device.description='Voice Call Microphone - Virtual'"

set-default-source virtual_input.voice-mic-01.mono

update-source-proplist virtual_input.voice-mic-01.mono filter.apply.echo-cancel.parameters="use_master_format=1 aec_args='analog_gain_control=0 voice_detection=0 high_pass_filter=0 noise_suppression=0'"

… then I include it in the main config at boot time by placing .include /etc/pulse/voice-call-mic.pa at the end of the /etc/pulse/librem5.pa file

This also provides for a relatively straight forward method to switch inputs <-> to both mics if needs be (although, not during a call)…

librem5-virtual-voice-call-microphone
librem5-virtual-voice-call-microphone720×1440 58.6 KB

I did note that there may be an issue with default echo-cancel module parameters as defined in /etc/pulse/librem5.pa, that file defines “channels=1” but provides no 'channel_map" value and also defines "use_master_format=yes". I’m not absolutely certain but I would think that defining channels and use_master_format would present a conflict? I also wonder if it is valid to define channels without a channel_map? As it would seem to me that the config is saying “use 1 channel of the 2 channel stereo source” but it then doesn’t define which of the two stereo channels should be used? Maybe that is the source of the random channel selection issue that has been observed previously?

6 Likes
49

As it is so nice what @Loki wrote it is also complicated. I think that Purism must address this issue officially and fix the issue over the air for all users. It can’t be that purism members do not have this problem on their phones.

4 Likes
50

Loki,
Are the 2 commands load-module ... and update-source-proplist each one single line? And, does HiFi__hw_L5_0__source has two times double _?
Maybe you could break the longish command lines with \ so they fit better in the browser and makes the posting clearer. Thanks in advance.

51

Yes they are.

Yes, this is the name of the internal mics source as used by pulseaudio, you can double check it by viewing the results of the terminal command pactl list short sources.

These commands should be placed in a Pulseaudio configuration (.pa) file, the format of this configuration file does not provide a means to split a single command over multiple lines with \ or any other mechanism that I am aware of. I understand that long commands shown on a single line are difficult to read and lack clarity within the browser, however, I have sacrificed legibility in favour of validity, these commands are presented here in the same way/format they are required to written to file.

2 Likes