As the question regarding in-call audio quality has come up a few times, let me elaborate on my findings:
Most modern smartphones use two microphones when making phone calls. Dual-microphone processing can be very sensitive to the relative position of the talkers mouth and the microphone, in particular in varying background noise scenarios. Especially when the main microphone on the N5 (the one behind the grille) is far away from the mouth the local talker may be mistaken for background noise and, hence, get suppressed.
As dumb as it sounds, try to hold your phone "right" when making calls, i.e. talk directly into the microphone and try not to move the phone much.
A second very important "good practice" suggestion is to keep the loudspeaker volume as low as possible and try to talk in low background noise environments (I know that the latter one is not always possible). The reason is the rather nasty subject of double-talk.
When a phone detects a double-talk situation, i.e. a loud RX signal combined with a strong TX signal (talker + background noise), the AEC (acoustic echo canceler) will typically start "clipping" the near-end speech, which results the other end not being able to hear you.
Other than these two basic suggestions, there are a couple of things a brave soul can try to fight this issue.
Note there is no (and possibly never will be a) real fix without Qualcomm's and LG's intervention. I'm currently using what's
behind door #2 below with success...
1. Changes in build.prop (not an endorsed workaround)
========================================
consider this change
- persist.audio.dualmic.config=endfire
+ persist.audio.dualmic.config=broadside
What this does is change the dual-microphone algorithm to an alternate one. In my (limited) testing, however, "broadside" was
worse than the "endfire" configuration. Actually, I never got many complaints about other people not being able to hear me using "endfire"
However, it may work for you. If it does, great, and you don't need to move on to try other stuff, such as another change:
- persist.audio.dualmic.config=endfire
+ persist.audio.dualmic.config=none
This change turns off dual-microphone processing altogether. The big caveat is, however, is that this change seems to disable other
vital signal processing as well, in particular AEC.
Other issues I have seen with these two changes is that the first call after a reboot is often "bad", which can be fixed by quickly switching to speakerphone mode and back. Not good.
2. A very complicated workaround (which works for me)
=========================================
As I mentioned earlier in the thread, I spent a lot of time trying to fix the in-call RX distortion issue when recording from the line.
I found a workaround that works for me that may partially address the issue of occasional low TX level as well. I say partial since low TX level may be caused by both the dual-microphone processing as well as the AEC in double-talk situations. This workaround only addresses (turns off) the dual-microphone processing while still enabling AEC as well as some noise suppression. Low TX levels in double-talk situations can only be improved by Qualcomm, but somewhat alleviated by an educated user (see suggestions above).
The fix requires:
* turning off dual-microphone processing (persist.audio.dualmic.config=none in build.prop)
* custom AOSP kernel (3.4.0-gd59db4e) that allows for injecting proper (?) audio calibration data via Qualcomm's acdb interface, which enables AEC as well as single-channel noise suppression
* a bunch of Tasker scripts
* a shell script
* a binary that commits the calibration data to the kernel/CPU upon a system reboot, or when needed as determined by the Tasker and shell scripts
Ultimately, in finding a fix for this issue, I got stuck at the lack of documentation of Qualcomm's audio interface.
My solution is just a huge hack to address a problem that really can only be fixed by Qualcomm and LG (and maybe Google) as
all processing during cellular calls is done by Qualcomm deep within the MSM/DSP. It is my understanding that the signal processing within that chip is controlled by some of the proprietary vendor blobs.