Is there any information about the sound quality on Librem5?
2,5 years later I do have the same question to all of you possessing a Evergreen device.
According to this review posted in a different thread, sound quality is just not sufficient to have a conversation.
In other threads (I think it was @amarok) iirc people were talking about “muffled” sound.
So, what is the matter? Really unsuable for phone calls?
I think some confusion (and maybe inaccuracies) arose because with “normal” phones you don’t have to worry about adjusting specific microphone settings. With the L5, since it uses the same audio packages as most any Linux computer, it’s necessary to set the “Internal Microphone” volume to an optimum level. At first I thought it should be set to maximum, but now I feel it’s best at about 50% level. This microphone captures a lot more ambient noise (in my opinion) than most other phones on the market, which sounds like it might be a good thing, but I think it can detract from the overall quality if it’s set too high.
The best way to judge for yourself is to listen to @dos’s recordings which he posted in one of those early threads about sound quality.
In my opinion, it’s a non-issue, now that I understand how sound settings are treated differently from Androids or iPhones. Others with the phone can chime in here and say whether they agree or not.
Edit: And I think that many reviewers probably don’t realize they can adjust the mike to get better quality.
Thanks so far. What is meant by “internal microphone”?
That is what I was looking for…
Look at the bottom of this shot, under “Input”:
That’s the volume of the mike used during calls. And I think there’s an additional input at the top of the phone, maybe.
If you listen to @dos’s recordings, you can see what I mean about the ambient capture:
(He’s not using an Evergreen, but the sound hardware is the same.)
Sound quality is fine. I have already had numerous phone conversations. Evergreen.
Rigorous testing is difficult since I can’t know what the other end is hearing. I can only judge by whether the phone call is progressing normally, and that seems to be the case.
In fact I’ve had so many calls that I am wondering how to clear out the call log other than by deleting one by one … at the risk of a hijack.
Thank you for your input.
A negative feedback from your conversation partner like “hey, is something wrong with your phone or headset, 'cause sound quality is worse than usual”, could serve as an indicator here. But since you obviously did not encounter issues like that, this is a positive (at least not negative) sign.
Software can improve sound quality a lot. Noises can be reduced, echo can be decreased and so on. I wouldn’t panic if something doesn’t sounds good right now.
But for input volume it could be good to have a preset value that sounds best for now. Sound should be good out of the box and not just after tweaking some settings by every user himself or herself.
Is there already action(s) in progress? Such as newly released usage of PGP smart card, or running activities to use camera(s).
Not that I read about it. But as far as people say, sound quality is okay (at least after changing settings). If so, I guess there are more important things on the to do list.
The following worked for me:
sudo apt install sqlite3
- close calls app just to be safe
pkill -HUP calls# kill daemon that caches
DELETE FROM CALLS WHERE start < '2021-02-01';
calls --daemon &
disown %%# detach daemon
Cute but seriously? We aren’t expecting regular users to know how to do that?
Define regular users for the L5
Thanks for sharing. Since you were posting audio files in an other thread: Do you experience sound as “muffeled” or can you generally state your personal opinion on sound quality (maybe compared to other devices e.g. your “old” N900)?
I have spent some time recently playing with various phones, calling them back and forth and comparing audio quality. I’d say - it depends on what you look at.
The incoming audio quality is IMO perfect, so you as the L5 user don’t notice that anything is wrong with it. What’s less than perfect is outgoing audio - but I’d say the remaining problems are minor. Generally, what I found out boils down to:
- Mic gain is set to a too high value, leading to a bit of distortion. The currently set value was needed to get to comfortable levels when using the microphone for local sound recording. When I set the volume to lower level the distortion during calls is gone and volume there is fine, but local recordings are way too quiet. I suspect that the modem applies some gain by itself, so we need to take a closer look at it; maybe it can be reconfigured so we can get a single mixer configuration that works well for both cases. That said - I only noticed this distortion when I compared the recordings from L5 and N900; my ear didn’t really pick it up by itself over the GSM codec quality.
- Audio processing in PulseAudio is too strong. Its echo cancellation filter does also noise filtering and bunch of other kinds of processing meant to improve audio, but that aren’t necessarily best suited for the use case of mobile phone - hence the commit I linked above that disabled everything that isn’t echo cancellation itself. This was resulting in things like word endings getting cut off too soon and the general impression of the sound being muffled; with updated settings I find the voice on the other end to sound much clearer.
- We’re unconditionally mixing input from both microphones (one at the top and one at the bottom), so we’re unnecessarily grabbing audio from the microphone you’re not directly talking to in addition to the correct one (which also forces echo cancellation algorithm to work harder since we catch output from the speaker with its neighboring microphone). Ideally we would switch between both microphones depending on whether the earpiece or loud speaker is enabled (and keep them in stereo for local recording and other apps), but some quirks of the BM818 modem prevent us from implementing that cleanly. Of course it can already be hacked to work, but I’m still hopeful that I may find a proper working configuration before we have to resort to ugly hacks (current status is “why does PulseAudio not obey my will” and “where the hell does that channel mapping come from” :D)
- There’s a bit of additional latency imposed by how PulseAudio’s module-loopback works internally, which is used to transfer audio back and forth between our audio codec and the modem. The latency is small enough that it’s not a real issue for humans, but I found out that it’s high enough to prevent us from using some better suited audio processing algorithms than the WebRTC defaults. I don’t know if that will be the case at this point, but I’m hopeful that this may get resolved by itself when we switch from PulseAudio to PipeWire in the future, since PipeWire is meant to fit into JACK use-case as well and my experience is that JACK can achieve much lower latency than PulseAudio loopbacks.
- We need to extend the audio codec driver a bit in order to let it switch between internal and wired (plugged to the audio jack) microphones: https://source.puri.sm/Librem5/linux-next/-/issues/215
- Enabling the internal microphones generates a loud pop at the beginning of the audio stream (see https://source.puri.sm/Librem5/linux-next/-/issues/270), which trips automatic gain control algorithms in module-echo-cancel - so we keep them disabled at the moment.
This is of course coming from a perspective of someone who spent some time trying to configure it to be perfect, just so you know the technical challenges left to be resolved From the user perspective I’m already pretty happy with call audio quality when using the patch from https://source.puri.sm/Librem5/librem5-base/-/merge_requests/216, which I hope will reach the repositories soon.
Also with Jack you don’t usually have irritating questions like
Thank you for taking time to respond in a very detailed manner. For my knowledge a bit too deep.
But for others around here maybe very helpful.
As I can see you already have a clear picture on cause and effect situation and also measures running to work against them. That is very promising, since for me a smartphone’s primary use case is still talking. With that in mind I was not too happy reading the above linked article.
But, as said, your response draws a different picture especially when it comes to improve audio quality in different use cases.
Hah; FWIW JACK works fine on the Librem 5 - I’ve used it already to participate in online jam session using Jamulus and was able to achieve much better latency than when using my laptop’s integrated card That said, while it works, it’s also unsuitable for mobile use case since it doesn’t really care about such uninteresting stuff like power consumption or CPU utilization