Please don’t do things like that, unless you enjoy having to dig into configuration files on updates to see what has been broken by partially applied changes.
The default configuration already uses only a single microphone (bottom one) for call audio, there’s no need to apply any changes to achieve that.
I’m not advising to do that, I’m telling how to do something. It is up to the reader to use that knowledge, or not use it.
I’m a firm believer in educating people, not shielding them from power that might bring them into trouble. Librem 5 and Linux give people the capability to tinker with both hardware and software. If people are stimulated to experiment we all benefit from the knowledge they share back with the community.
I absolutely agree, but experience just tells me that if you don’t stamp big fat disclaimers on your education, people will do what you advice unaware of consequences, and then we have more work troubleshooting obscure issues that turn out to be nothing else than the customer shooting themselves in their foot 
The quality of the audio in calls has significantly changed down. I called our Cisco Voice Mail system in my company and let it record my counting from 1 to 10. The result could be checked here:
http://www.unixarea.de/L5-20230320.wav
After saying “10” the call and record keeps ongoing because I can’t hang-up the call due to a bug in the kernel’s threshold value for the proximity sensor which let the gnome-calls app thinking that the L5 is always near my ear even when it sits on the table with dark display and unresponsive touch screen (with display up, ofc). But this is another story, unrelated to the audio quality.
Just make your own idea listening the above URL. You can also contact me by PM, I will give you the number and let you record your call. Then I send the wav file to you by PM.
Update: Just to make sure: I’m using the pulse configuration as distributed, see below. I did experiments with this in the past, but for many months no more. I don’t know what the quality degradation has caused:
purism@pureos:~$ ls -l /etc/pulse/librem5.pa*
-rw-r--r-- 1 root root 2311 Nov 16 06:24 /etc/pulse/librem5.pa
-rw-r--r-- 1 root root 2311 Nov 16 06:24 /etc/pulse/librem5.pa.dpkg-dist
-rw-r--r-- 1 root root 2292 Sep 8 2021 /etc/pulse/librem5.pa.orig
-rw-r--r-- 1 root root 2333 Feb 16 2022 /etc/pulse/librem5.pa.wasworking
I agree with you, but your solution is not good 
.
Without thinking much I’d advice that monitoring the files content for changes would be better. Maybe put it into a git or something like that or setup a cron that diffs to a copied reference.
sudo rm -rf /var/lib/alsa/*.state ~/.config/pulse
sudo reboot
Could you please explain the background of the existence and removal of these files. Should such a removal be done from time to time?
Btw: I found a way to hang-up the call when the screen is black and unresponsive: I switch off the modem with the HKS. The disadvantage is, that I have to reenter the PIN and I still can’t use any automated system where I would have to enter numbers from the dial pad. Any chance that this proximity issue could be fixed soon?
This simply removed any volume adjustments you must have done in the past and forgot about. You won’t have to do it again if you don’t change things 
See, that’s what I was talking about in my previous post 
Should be fixed already, the updated kernel migrated to byzantium today.
Yes, it came down and now the proximity works as expected. Thanks
Hurrah, I can do and hangup phone calls again and others don’t blame me for my bad audio
@dos, I have an additional question:
I used my script to read the proximity sensor and the tool monitor-sensor at the same time and see that with the value of 8 the monitor-sensor says “near: 1”, i.e. something around 8 seems to be the threshold for monitor-sensor and for the app gnome-calls to shutdown display and sensitivity of the touchpad.
When I bring the L5 near my ear and face, the proximity sensor shows 50++.
This let me ask, why is this threshold value set so low to 8?
Density maybe? Try with something like a tissue or something that’s porous and see what it says.
Give it to someone with long dark hair and observe the values
I recall when my company had video conferencing the quality was poor. We had dedicated circuits (leased lines). We finally convinced our ISP to stop optimizing packets and it cleared up. Same thing with one of our GUI applications.
The net effect of optimizing packets means that some newer packets get there than the older ones and are supposed to be reassembled in order at arrival time in the box in the circuit room. If you don’t do that they arrive in the same order sent. (I may not be techically correct here but that is how I would describe it in layman’s terms.)
My wife has long black hair. I gave her the L5 with the instruction to put it to her ear (covered by hair) and take it away again. I was watching via SSH the sensor value:
16:25:53: 6
16:25:54: 7
16:25:55: 6
16:25:56: 6
16:25:57: 39
16:25:58: 29
16:25:59: 31
16:26:01: 31
16:26:02: 32
16:26:03: 33
16:26:04: 38
16:26:05: 38
16:26:06: 38
16:26:07: 7
16:26:08: 6
...
A value of 8 is definitely to low.
Wow! This improved the call quality very, very much for me. Thanks!
Now we are two with big improvement with those removals. Spock would have said “Fascinating!”
@dos, I haven’t touch any audio files for months and have reset my changes many months ago. Call audio was always fine until February, and then from one (kernel?) update it went bad.
Any way. Good that you could help us with the deletion of some files. Thanks
It’s actually still too high to reliably detect proximity to ear during calls, but unfortunately the existence of devices like yours that have their resting values elevated does not allow us to go lower.
If I put my Evergreen phones directly against my hair, their proximity sensors barely notice anything
There were no relevant updates since November, and that one was already resetting user settings on its own. You may have accidentally moved the microphone volume slider in system settings perhaps?
