Yes. Mic 1 (the bottom one) works fine. Mic 2 and 3 do not provide any feedback. I was trying to tap on all of them, but all I can hear is silence. But as I said, using the video recording and loud calls, I can in fact confirm they’re working and the volume is roughly the same for all of them. So the main issue is the tests behave weirdly and that audio gain in general is too low to my taste (especially in video and audio recording, calls are acceptable).
Hi folks,
Can someone reproduce this?
I could, and found an approach for a workaround:
- unlock your bootloader and get root access for your FP4 (Magisk works fine)
- on a PC with
adbconfigured, executeadb shell 'su -c "tinymix TX_DEC0\ Volume" 100'
That’s it. This raises the ALSA control “TX_DEC0 Volume” from 81 (default in stock ROM) to 100, and for me it was enough to get good audio recording level in Signal Messenger app.
The setting is lost after a reboot. To make it persistent, we could probably edit /system/vendor/etc/mixer_paths_lagoon_fp4.xml. To edit it “system less”, we could do it by means of a simple Magisk module. Will try and publish if it works. No matter what, we’ll have to root our phone to fix the issue, unless Fairphone compiles the fix into an official update.
@UPPERCASE In another thread you quote the Fairphone support
I’ll bring this to the attention of our developers and they’ll adjust the calibration for Signal and Voice recorder in upcoming updates.
I think what they mean is they’ll use Qualcomm’s QACT tool to edit the audio calibration database that gets dynamically loaded via HAL and Qualcomm’s proprietary ACDB Loader mechanism. While my method simply raises gain (amplifying both signal and noise), I’d suppose they can do smarter adaptions. But it’s difficult to reason about it, afaik tool and specs are only handed to OEMs after signing a NDA.
7 Likes
Hi,
when performing the mic test, try to wipe over the microphone holes. I heard a hissing sound in every case.
1 Like
Yeah, I’ve tried that, but only mic 1 seems to work. Mic 2 test is silent and mic 3 test sometimes results in horrendous screeching noises (like a typical audio feedback - File:Acoustic Feedback.ogg - Wikipedia). From my point of view, something is horribly wrong with the tests, because as I’ve mentioned, I can confirm that all mics actually work just fine (using stereo audio recordings and loud phone calls). And what’s even funnier is the fact that I wouldn’t have probably found out about this if it wasn’t for the overall low microphone gain. 
Additionally I noticed that:
- mic 1 is routed to the receiver (mic 1 to receiver)
- mics 2 and 3 are routed to the “bottom speaker” (mic 2/3 to bottom speaker)
Is this right? Shouldn’t all mics be routed to the same speaker in the test? For a moment I suspected the bottom speaker to be faulty, but that’s not the case. When I try to play a stereo clip, both speakers work just fine.
So far the support offered me to replace the phone. This might fix the failing tests (I don’t know, maybe there is really some HW problem), but it deffinitely won’t fix the problem with low volume of recordings and calls.
1 Like
UPDATE: Globally raising "TX_DEC0 Volume" is not a good fix, because it badly affects normal phone calls (where we’re typically much closer to the mic).
During a Signal Messenger audio recording, the audio HAL selects input device "handset-mic" for use case “audio-record”, where "handset-mic" is defined as
<path name="handset-mic">
<ctl name="TX_CDC_DMA_TX_3 Channels" value="One" />
<path name="amic1" />
</path>
During a normal phone call (non-hands-free), the audio HAL selects input device "dmic-endfire" for use case "audio-record-voip", where "dmic-endfire" means dual mic (amic1 for bulk input, amic3 feed into noise cancellation)
<path name="handset-dmic-endfire">
<ctl name="TX_CDC_DMA_TX_3 Channels" value="Two" />
<path name="amic1" />
<path name="amic3" />
</path>
And during hands free calls (and probably video calls, haven’ t tested) we have use case "audio-record-voip" with input device "speaker-mic", which solely uses "amic3" for bulk input.
I.e., for both Signal recordings and non-handsfree phone calls we use "amic1" for the bulk input, which is controlled by "TX_DEC0 Volume".
I wonder why "handset-mic" is selected for Signal recordings at all, and which software component does this decision. Wouldn’t be "speaker-mic" (as in hands-free calls) more appropriate?
EDIT: The decision taking code is select_devices() and platform_get_input_snd_device().
6 Likes
Just published fp4-low-volume-fix. It fixes the low volume issue by raising TX_DEC0 Volume locally in <path name="handset-mic">. This tells the audio HAL to automatically raise bottom mic level when a recording starts, and to revert it back to default when the recording is finished. Thus we don’t break regular phone calls.
No guarantee for anything. I’ve not even tested the Magisk module installer procedure, but copied the repo content to /data/adb/modules/fp4-low-volume-fix manually. If some of you are willing to try it anyway, I’d be happy to receive feedback.
3 Likes
Any change with the January update? I can’t test it, I already returned my Fairphone.
No, problem still exists after the update.
Worse, I’ve now encountered another issue that I previously only saw when running rooted: Regular phone calls randomly fail in a way where I hear the callee, but the callee doesn’t hear me. After about 10s the call is automatically terminated.
This happened randomly, but often enough (once a day probably, independent from whom I called) to be able to record logs while it happend. I thought it could be a side effect of tweaking TX_DEC0 Volume, so I’d better not complain. Now it happened right after booting the unmodified January update.
Did anybody of you experience a similar issue?
2 Likes
Thanks for your reply! This doesn’t look great for FP, usually a phone manufacturer fixed major issues within 6 months after a release. I really want to use this phone, but they make it hard to stay happy with it. Kind of misses the point of their mission.
For the issue below it might be better to create a new topic.
2 Likes
I have the same problem also with FP4. Calls use the bottom mic which is fine because you are really close to it when calling but hands-free uses the side microphone which doesn’t pick up enough sound. Also the sound recorder only uses the bottom mic which has the same problem, doesn’t pick up enough sound. I hope they fix this or start using all 3 mics for hands free and voice messaging.
3 Likes
This is so frustrating! Why is it taking so long to fix this, especially when the problem has already been identified by people in here?! I’m ready to make sacrifices and tinker with the phone to make it work better but this is such a basic thing. I shouldn’t have to root my phone to make the microphone work.
5 Likes
Haven’t had that happen myself
I agree, to help Fairphone decide what’s a priority it may help to tell Fairphone you have this issue as well. Please #contactsupport for that.
1 Like
Hi, I have the same problem and just opened a support request.
5 Likes
Thanks for the pointer. Meanwhile I’ve tried deactivating VoLTE as suggested by @yvmuell in another thread and until now I’ve not seen failing calls again, nor rooted neither stock. It makes also sense as my provider is not listed in Fairphones VoLTE support page.
3 Likes
Hello Razem
Thank you for your feedback. I just have the same issue with my phone. When starting the internal test app, microphone 2 and 3 do not recorde any sound. Today I got a replacement from the reseller and this phone does have the same behavior like the first one. Now I did the test by recording a movie and knocking the microphones. The sound of both (top and bottom microphone) has been recorded. Additionally I did a test by using the loud speeker during a phone call, as well the one on the side works too. In my opinion, FP does have a huge SW bug in there test app. I don’t think that I will go for a second replacement. How did you proceed?
THX and Greetings Ueli
Hello and welcome to the forum. The solution is actually to disable the microphone permission for Google app:
I would say, don’t worry about the failing tests if everything else works. (Although I hope they fix it eventually. I’ve already informed support about this.) But if you experience problems with phone calls, consider disabling the microphone permission for Google.
4 Likes
It’s a nice workaround if it consistently works. I do use the Google Assistant, so I wouldn’t consider it a solution. I really hope they are able to fix these issues as well.
1 Like
This did not help for me, however when I did the sound test all 3 mics worked for me. Its just way too quiet and quality is abysmal
2 Likes