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.
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.
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.
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
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
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
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.)
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)…
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
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
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.
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
The problem is that cut&paste the long lines into a vim running on the L5 (while SSH’ed to it from an urxvt running on a KDE on a laptop) made of each of the two long lines, three pieces. I.e. I’ve had to join them in vim taking care of resulting additional blanks, i.e. removing them.
I think, I didn’t any mistake and all works fine as designed by you. Thank you!
Hopefully the change in /etc/pulse/librem5.pa will not be blown away by one of the next updates.
Ah, I see, thank you for pointing that out. It looks like something went wrong with the original formatting, I have edited it now and all it appears to be formatted correctly so should now be possible to simply cut & paste as normal.
Your welcome, happy to hear it is working for you. It is the type of configuration that either works or it doesn’t, if there were any mistakes it would be immediately obvious.
Just for your reference, I have not encountered any issues with this configuration and I have made and received many test and real world calls with no problems, however, if it subsequently turns out that the virtual mono mic has an issue and it must be a stereo input source, it is trivial to redefine the virtual input to be a stereo source where both left and right stereo channels use only the physical right (bottom) mic channel as their source. Simply change…
channels=1 master_channel_map=front-right channel_map=mono
to…
channels=2 master_channel_map=front-right,front-right channel_map=front-left,front-right
It will only be blown away by an update specifically for pulseaudio, and hopefully that update would be to officially address this issue. It is only one line so relatively easy to maintain tho.
1 Like
I called my son at home and he reported some kind of echo of his own voice… will check later by my own.
It’s true. I called my other mobile and when I talk there I have an echo 
Interesting, Have you rolled out the change (you can comment out (place a # in front of) the .include line from librem5.pa file then reboot to restore to default) and compared?
Looking at my end I can see the echo-cancellation filter being loaded (you can see this with terminal commands pactl list short sources and pactl list short sinks, you should see some in the list with “echo-cancel” in their name).
I’m by myself at the moment which makes it pretty difficult to test and compare as any audio config will likely pickup some echo when two phones are so close together.
It occurred to me that all I needed to do in the first instance was to call someone from the Librem 5, have a chat and ask them if they were hearing any echo.
I did that, and they said, nope, no echo.
Then it occurred to me that having a couple of phones here I could confirm this myself by establishing a call connection between the Librem 5 and another phone, then isolating the Librem 5 in another room while I chat to myself down the other phone and see if I end up echoing back to myself.
I did that, and I was unable to detect any echo.
The only time I could produce echo was with both phones in the same room and in that situation echo is pretty much inevitable.
I would check two things, first that the echo cancellation filter is being properly defined on the virtual mic source and secondly, assuming the filter is being defined properly, that the echo cancellation filter is being activated/loaded when a call is connected.
You can check that the filter has been defined properly by looking at the sources list, from the command line enter…
pactl list sources
This will list all sources, you are looking for the one named “virtual_input.voice-mic-01.mono” in particular you should see a “filter.apply.echo-cancel.parameters”, below is the output from my list sources output isolated to the virtual_input.voice-mic-01.mono…
Source #4
State: RUNNING
Name: virtual_input.voice-mic-01.mono
Description: Voice Call Microphone - Virtual
Driver: module-remap-source.c
Sample Specification: s16le 1ch 48000Hz
Channel Map: mono
Owner Module: 24
Mute: no
Volume: mono: 49152 / 75% / -7.50 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor of Sink: n/a
Latency: 18880 usec, configured 100000 usec
Flags: DECIBEL_VOLUME LATENCY
Properties:
device.master_device = "alsa_input.platform-sound.HiFi__hw_L5_0__source"
device.class = "filter"
device.description = "Voice Call Microphone - Virtual"
device.icon_name = "audio-input-microphone"
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'"
Formats:
pcm
This was taken during a call hence it states “RUNNING” but it makes no difference if it’s running or not only that the “filter.apply.echo-cancel.parameters” line is there with the same parameters as listed above and that it is quoted correctly.
If the filter parameters are there and defined/quoted correctly, the next thing to check would be that the echo cancellation filter is being loaded. The filter is loaded dynamically when a call is connected so you will need to have an active call established, then from the command line enter…
pactl list short sources
The short list should be enough, and you should see an echo-cancel module for the virtual-call-mic-01-mono.echo-cancel. Below is my short sources list, the 6th (number 5 in the list) entry is what you should be looking for…
0 alsa_output.platform-sound.HiFi__hw_L5_0__sink.monitor module-alsa-card.c s16le 2ch 48000Hz IDLE
1 alsa_input.platform-sound.HiFi__hw_L5_0__source module-alsa-card.c s16le 2ch 48000Hz RUNNING
2 alsa_output.platform-sound-wwan.stereo-fallback.monitor module-alsa-card.c s16le 2ch 48000Hz IDLE
3 alsa_input.platform-sound-wwan.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz RUNNING
4 virtual_input.voice-mic-01.mono module-remap-source.c s16le 1ch 48000Hz RUNNING
5 virtual_input.voice-mic-01.mono.echo-cancel module-echo-cancel.c float32le 1ch 48000Hz RUNNING
6 alsa_output.platform-sound.HiFi__hw_L5_0__sink.echo-cancel.monitor module-echo-cancel.c float32le 2ch 48000Hz IDLE
If you can check and confirm these two points hopefully that will provide some clues as to where the issue lies.
1 Like
I’m at home, called from the L5 my land line phone (it’s ISDN service), put the L5 together with some radio playing the news in some other root and closed the door. Back to my land line phone, I can hear the news. I went to the L5, shutdown the news, and back to my land line, I have no echo while talking into it. I.e. could not reproduce the problem of yesterday evening. The output of the commands during a call are:
pactl list sources
...
Source #4
State: RUNNING
Name: virtual_input.voice-mic-01.mono
Description: Voice Call Microphone - Virtual
Driver: module-remap-source.c
Sample Specification: s16le 1ch 48000Hz
Channel Map: mono
Owner Module: 24
Mute: no
Volume: mono: 65536 / 100% / 0.00 dB
balance 0.00
Base Volume: 65536 / 100% / 0.00 dB
Monitor of Sink: n/a
Latency: 22215 usec, configured 100000 usec
Flags: DECIBEL_VOLUME LATENCY
Properties:
device.master_device = "alsa_input.platform-sound.HiFi__hw_L5_0__source"
device.class = "filter"
device.description = "Voice Call Microphone - Virtual"
device.icon_name = "audio-input-microphone"
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'"
Formats:
pcm
...
pactl list short sources
0 alsa_output.platform-sound.HiFi__hw_L5_0__sink.monitor module-alsa-card.c s16le 2ch 48000Hz RUNNING
1 alsa_input.platform-sound.HiFi__hw_L5_0__source module-alsa-card.c s16le 2ch 48000Hz RUNNING
2 alsa_output.platform-sound-wwan.stereo-fallback.monitor module-alsa-card.c s16le 2ch 48000Hz IDLE
3 alsa_input.platform-sound-wwan.stereo-fallback module-alsa-card.c s16le 2ch 48000Hz RUNNING
4 virtual_input.voice-mic-01.mono module-remap-source.c s16le 1ch 48000Hz RUNNING
13 virtual_input.voice-mic-01.mono.echo-cancel module-echo-cancel.c float32le 1ch 48000Hz RUNNING
14 alsa_output.platform-sound.HiFi__hw_L5_0__sink.echo-cancel.monitor module-echo-cancel.c float32le 2ch 48000Hz IDLE
1 Like
If the echo was present on just one call I would have dismissed it as probably a network glitch.
As the echo was present on two separate calls, I am more inclined to think it was most likely something on the Librem 5.
However, the output from list sources looks good, it shows the filter to be defined correctly and that it is loaded and running during the call. With no echo being present on subsequent calls there is not anything else I could suggest to look at or investigate at the moment.
If it happens again, and you are able to, I would check the output of pactl list short sources during the call to check if the echo cancellation filter is loaded and running.
We run in our company a Cisco phone system which is able to record a message from the caller and send it as email attachment. I have here more or less the same message, once called from the L5 to my land line office number and from an iPhone:
http://www.unixarea.de/L5.wav # with virtual mic
http://www.unixarea.de/L5-right.wav # with Left 0% / Right 100%
http://www.unixarea.de/iPhone.wav
1 Like
Please do!
It’s an important issue, if the Librem 5 is to work decently as a phone with its default settings. Mine works fine now after changing mic settings, but I think the majority of users will not dive into experimenting with various microphone settings on their own, they will expect the device to work as a phone by default.
4 Likes