Thank you, Jonas, glad to be here. I’m not sure why my reply to your post doesn’t include it in quotes, but I think there are many customers who would like to abandon Apple and Google for something like a Librem 5, without having the dedication or the experience to tinker at a deep level. How the “surface level” of using the phone helps us escape the duopoly may be a big factor in how well it sells to a larger audience.
Thank-you for that link, Eugenr. I had stumbled across that post a couple weeks back, and I did increase the Mic input level and call people back. They report the sound is still muffled and under-water sounding, just not as faint. So the amplitude went up, but the audio quality of the sound itself stayed the same.
Thank-you, JR-Fi. The fact Purism has these assembled with such care, and the SIM extractor is made large enough to have a good grip on it and with a hole you can use to hang it on a peg so you don’t lose it in a junk drawer, says a lot.
this is what I call sincere review.
Quote from one of the developers:
I’d suggest actually decreasing input level, it should make it sound better.
Anyway, yeah, it’s known, but it’s just a software thing - see also my post in Librem 5 Ready-To-Market? (although I think I’ve changed my opinion about it being “good enough” already, I’ll try to spend some time on it again soon ;))
To include a quote, highlight the phrase you’re referring to. The option to
Quote it in your reply will pop up. Select it and it will be added to your reply.
I wonder if you can the proper battery at Batteries Plus Bulbs outlets?
I can see it on ebay, so I don’t think it will take too long for Pottery and Pulps to pick it up.
We haven’t heard yet anything about suspend. we have heard that @dos has worked or he is working for the muffled-sound problem, we have heard that people have been working for cameras but I have not yet read anything about the suspend which is very important to my opinion.
Nobody is working on suspend explicitly, but there have been some power management improvements lately that will also matter for suspend, for instance https://source.puri.sm/Librem5/linux-next/-/merge_requests/279
Personally I believe that it’s way more important to keep extending runtime battery life and treat suspend as the very last thing in the chain of things needed to be done for good power management. Suspend isn’t a magical answer to all battery life problems - if you need to suspend to get reasonable battery life you’re going to be very limited with what you can do with your phone.
Well, I could just use it … as a phone? It wakes up and rings, I talk, I hangup, it goes to sleep sometimes after.
I know that there are not too many people who do not want to be bothered by their phones, but I am one of them. Fine for me if it just alerts me when a call or SMS comes in.
Anything else I want from my phone: I switch it on. Only thing that I could be missing would be if during suspend there could be no alert for appointments in my calendar. But I’d get over that, too, because I’m used to check from time to time.
I perfectly understand that and I’m looking forward to be able to suspend as well - it would match my usage pattern pretty well. That said, we’re probably in the minority and I still believe that reaching for suspend too early is just sweeping your problems under the carpet
From what I understood suspend mode would only work as a phone if you don’t follow the IP narrative. I moved with my family to a self hosted matrix instance using it to call and text each other which is basically the old phone functionality - however as far as I understand a suspended phone would not ring as it could not be woken up by the modem as the modem is only triggered by “real phone calls”.
that’s correct, suspend itself is not enough, there should also be wake timer and software optimised to use wake-timer. Eg. Nokia solved that with iphb 1o years ago which was making suspend while adjusting system monotonic timer (to become less monotonic). but that requires software which is either aware of non-monotonic wake-timers (passive) or actively using iphb timers instead.
In other words - adaptive ui is not enough for mobile pc, it also needs adaptive software.
I don’t know how purism is going to solve this, but I’m not aware of any method to solve it on a platform level (without touching the software). again - similar to ui (which also needs software changes).
Depends on the modem used. In theory, both the cellular and local wireless modems could trigger a wake event on the CPU. There are wake-on-lan protocols that will need to be supported.
You would not want to wake up the phone by any traffic. On the other hand you want your traffic to be encrypted so that only the phone knows that there has been a call or message. To decrypt the traffic the phone has been active. So the phone has to be active to notify me of an incoming call or text. So let’s sleep the phone and wake it up regularly to check if there’s a call or text. Calls are real time. No caller waits 5 minutes for other phones to check for calls. I hang up calls after 10-30s. Have in mind that accepting a call also takes some time (getting your phone out of the pocket, leaving a room, plugging in a headset …). It would be unpleasant if you always miss calls. So the phone could only sleep for second(s).
I conclude from this, that in order to use it as the ip narritive phone in everyday use for parents, CEOs and tech geeks suspend is not the solution to the battery run time problem.
But I could be wrong
Yup, but that’s okay. There is a requirement that the CPU firmware and kernel can cheaply and quickly move in and out of the suspend state. When the phone gets ready to sleep, it should disconnect everything that shouldn’t send notifications. This decreases the amount of traffic it’ll have to deal with. Then it software suspends the userspace stuff. Then it goes to sleep. When network traffic comes in, it wakes just the kernel, checks to see if something in userspace needs to be made aware (usually not, usually it’s just keepalive messages), and goes back to sleep. This wake->think->sleep cycle will happen a few times per second, but if it takes 20 μs to do one interrupt process, and does that 3 times a second, you’re talking 0.000060 seconds spent not asleep per second. Depending on the wifi card used, it might not even need to wake the kernel for simple ACK/ICMP packets.
As for the 20μs number… Assuming the CPU is running at 1GHz, 20μs is 20 000 cycles, which should be enough to see if the message is going to a userspace application.
Thanks and best regards to you. I suppose one probably must be sincere to commit the money and time we have to the phone. The world needs better choices.
Hi dos, thank you for your reply, I appreciate it. When the mic input level was at its out-of-the-box value of about 50%, my test call recipients had trouble hearing me amplitude-wise as well as intelligibility-wise. With the mic input cranked up to 100%, the sound level meters appeared below over-modulation, but I will reduce the mic input level down to 80% and try with the same test people this weekend.
In my particular case, phone call quality is the most important thing I use a phone for. Everything else is a nice to have except the hard switches, which fortunately for me already work. The camera for me is not a big deal, but others undoubtedly have different use cases. I know Purism has finite resources to accomplish many software items. If there’s any way I can help elaborate on what I’m finding, feel free to direct message me.