yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Android Development] rinigus:
audio during call: getting closer to solution

I think I found a major difference between SFOS and Androids in voice calls. Namely, in my phone, while in Android, voice-dmic-ef is used as a microphone during a call:

logcat during a call in CM that we use as a base:

03-17 19:49:25.132 V/audio_hw_primary(189): start_voice_call: enter

03-17 19:49:25.132 D/audio_hw_primary(189): select_devices: out_snd_device(1: handset) in_snd_device(29: voice-dmic-ef)

03-17 19:49:25.132 V/audio_hw_primary(189): enable_snd_device: snd_device(1: handset) is already active

03-17 19:49:25.132 V/audio_hw_primary(189): enable_snd_device: snd_device(29: voice-dmic-ef)

03-17 19:49:25.172 V/audio_hw_primary(189): enable_audio_route: enter: usecase(6)

03-17 19:49:25.172 V/audio_hw_primary(189): enable_audio_route: apply mixer path: voice-call

03-17 19:49:25.172 V/audio_hw_primary(189): enable_audio_route: exit

In SFOS, using logcat (path is given in HADK):

V/audio_hw_primary( 1256): start_voice_call: enter

D/audio_hw_primary( 1256): select_devices: out_snd_device(1: handset) in_snd_device(18: handset-mic)

V/audio_hw_primary( 1256): enable_snd_device: snd_device(1: handset)

V/audio_hw_primary( 1256): enable_snd_device: snd_device(18: handset-mic)

V/audio_hw_primary( 1256): enable_audio_route: enter: usecase(6)

V/audio_hw_primary( 1256): enable_audio_route: apply mixer path: voice-call

V/audio_hw_primary( 1256): enable_audio_route: exit

I have a feeling that SFOS takes into account build.prop (at least there are some messages regarding parameters from build.prop in dmesg) since there was some change when I set microphone type to analog. I am pretty sure that these results were obtained with the correct (as provided in the image) build.prop, maybe slightly updated audo_*.conf from later CM11. However, it would be good to get the same logs from others to see if its isolated incident or not.

Assuming that its not just mine N4, now all what has to be figured out: how to get it load the correct microphone? I guess one way would be to change the corresponding entry in mixer_path.xml, but maybe there is some better way to fix it (hybris?). Wouldn't be surprised if the same problem is on some other ports/phones.
[Nexus 4 Android Development] bolek1337:
Awesome find, rinigus!

I've looked at the source code and found the following .prop flags that change the sound device on Android level and could influence the snd device selection:

persist.audio.fluence.voicecall = true

persist.audio.dualmic.config = endfire

Could you check if setting those is enough to change the audio path that gets routed during phonecall in SFOS?

I also found some other flags in vicinity, but did not stumble upon code enforcing that:

persist.audio.fluence.voicerec = true

persist.audio.fluence.speaker = true
[Nexus 4 Android Development] rinigus:
Those we have defined in our /system/build.prop already, as in CM11. More specifically, we have

persist.audio.handset.mic.type=digital

persist.audio.dualmic.config=endfire

persist.audio.fluence.voicecall=true

persist.audio.handset.mic=dmic

persist.audio.fluence.mode=endfire

persist.audio.lowlatency.rec=false

For some reason, they are not enforced in SFOS. I wounder whether Android under SFOS reads its settings from / or some chroot path? If we could enforce build.prop settings on audio stack, we'll be fine I think. From the loading of incorrect microphone settings in SFOS, I could guess that its actually loading defaults and not the ones in build.prop.

These I haven't tried, but they are probably not for voicecall...

---------- Post added at 07:43 ---------- Previous post was at 07:22 ----------

OK, to be more specific, I think that build.prop is loaded (I've seen differences between digital and analog mic type), but is not fully applied during calls in SFOS.
[Nexus 4 Android Development] rinigus:
bolek1337, did you had any chance to look into the microphone loading issue? Cheers!
[Nexus 4 Android Development] bolek1337:
Sorry, but no. I already got a way to get in to remove the lock code, with which I couldn't ssh to the phone. I'm yet to find the dbus commands to issue a phonecall, though this should be feasible (googleable). It would be much easier with a touch screen. Also, the fact I needed to migrate away from N4 as the main driver makes it gather dust in the drawer... :(

But I will sit on this on my next free evening. There's still hope :)
[Nexus 4 Android Development] rinigus:
No worries, understood ;).

I'll try to compile some simple image and would ask for advice on how to debug the issue. Maybe someone from devs still has N4
[Nexus 4 Android Development] Kubino:
Anyone have this issue? While charging the phone I reboot it and after that it shows more % (about 20%). For example today I reboot phone during charge when it shows 45% battery and after reboot 66%.

Sometimes I have another problem - SfOS stops responding on the gesture from right/left edge to switch from app to homescreen. Didn't help terminate process "booster [silica-qt5]" and "/usr/bin/lipstick-plugin evdevt" in Crest. After reboot it's OK.
[Nexus 4 Android Development] mdjishadk:
Me too have that battery percentage issue after reboot, also the battery backup doesn't seem to be good, it discharges quickly. Didn't face the second problem u mentioned yet
[Nexus 4 Android Development] rinigus:
As for battery: yes, I have seen some strange behavior as well. Once I saw in the logs something about battery aging stats not loading, but didn't check it further at that time. Maybe you could check out your logs (journalctl and logcat, somewhere at /usr/libexec/droid.../system/bin/logcat ) and see if you have some similar in your logs

Also, are you running MultiROM or as a primary ROM?

---------- Post added at 10:27 ---------- Previous post was at 10:24 ----------

Fast discharge: yep, that seems to be an issue for me as well. Now if anyone has an idea how to debug it - that would be great. I tried to look once with powertop, but didn't do it till the end. Probably something we all have to look into and get an idea why it discharges significantly faster than in android
[Nexus 4 Android Development] mdjishadk:
An update gets for whatsup client.. Works now :)
[Nexus 4 Android Development] radbme:
I'm eagerly anticipating an update!
[Nexus 4 Android Development] andyr0ck:
Why, are you uber-desparate for NFC, hotspot and RTC alarms..? :p
[Nexus 4 Android Development] Kubino:
MultiROM. I didn't find anything related in journalctl log.

I am using it as daily-driver, it's great but:

- videos taken with camera app are without sound

- worse call quality mentioned above
[Nexus 4 Android Development] andyr0ck:
Ah, I see. I haven't tried taking videos on mine, not really something I use. Strange with the call quality. All calls I've made with this version have been really clear.
[Nexus 4 Android Development] alguien845:
Hi guys, I'm using multirom.

When the recovery attempts to install the sail zip, it throws and error (Status 7). Any idea?
[Nexus 4 Android Development] bolek1337:
Hey, for those I have fixes already. For the sound recording I fixed the problem with jusa, the voicecalls we got fixed with rinigus. Let me see how I can release that through OTA or with a gamma5 image...
[Nexus 4 Android Development] mdjishadk:
Though everything looks promising so far what we have , the battery backup is the biggest disappointment for me now, I hardly get 2 hrs of SOT . Hope an update may fix it. Also there is a slight lag is SFDroid while scrolling and swiping. An update is warmly invited :)
[Nexus 4 Android Development] rinigus:
Re battery life: I think it has been improved recently. There is certainly more to be done, but its already now at the state where its possible to get through the day without charging, at least for me. Although, note that I don't have hard data to back it regarding battery improvement as I started with measurements recently during testing
[Nexus 4 Android Development] Kubino:
Great news :) Please gamma5 image, I would like to make clean install as main ROM but if others would choose OTA, then OTA.

This is for mdjishadk, isn't it? I didn't complain about battery life. I usually got about 3-4 hours SOT and charging every second or third day with original 2.5 years old battery :). Same as on Android.
[Nexus 4 Android Development] mdjishadk:
It's great if u get that much SOT! I tried it as stand-alone ROM and Multirom, the results were same:( . I suspect my battery health now
[Nexus 4 Android Development] rinigus:
maybe its still SFOS. Check the following:

1: do you get N4 to sleep? for that, run 'mcetool --get-suspend-stats' as root/devel-su. You are supposed to get suspend time >> 0. if not, you have something keeping it alive. I have something in sfdroid doing it and will look for the cause. mcetool is in mce-tools package (or mce-tool, not sure in package name)

2. what's SOT in android? try to test it in android and see if the SOT is much larger there. I have much better performance in Chroma 6.

The devel version of SFOS is better than gamma4 in battery life terms, I think. I have seen proximity sensor using lots battery (2-4%/h or more) due to lack of suspend. So, you could also try to switch off proximity sensor and see if it helps ( mcetool provides a switch for it ). with proximity disabled, I have seen 1.5%/h battery drain on idle, down from 6%/h.

good luck and let us know if it worked. in general, there are changes coming in and I am sure that SFOS on N4 would be an excellent day driver. just have to help developers to polish the OS.
[Nexus 4 Android Development] mdjishadk:
Thanks for replying. Yes, the suspend time is 0.00 itself. I am new to these things, can you help me to figure out the command to turn off proximity sensor. I am attaching those commands i got with mcetool --help

With android rom, chroma 6.0 , I used to get 3.30-4.00 hrs of SOT. I use mobile network for data, hardly use wifi
[Nexus 4 Android Development] rinigus:
its

mcetool --set-ps-mode=disabled

Since you get good SOT with Android, problem is not in hardware, but in OS. That's good news and I am sure bolek1337 will release new version when all details are ready. And hopefully it would get better then :)
[Nexus 4 Android Development] bolek1337:
I released a new gamma5 image, and an OTA from gamma4 to gamma5. Please follow https://wiki.merproject.org/wiki/Adaptations/libhybris/Install_SailfishOS_for_mako OTA section by heart. If you're installing gamma5 as a clean image, same instructions as previously apply.

Changelog:

- Sound recording works - that is, in camera app when capturing video, in the Sound Recorder app, and in other places

- Dual mic is used for voicecalls - that improves the quality of your voice heard by the other party.

- Proximity sensor is used by mce - most visible is that the screen goes off during voicecalls and you can't press stuff with your cheek

I did not investigate the battery issue, be sure to check the troubleshooting steps outlined by rinigus.
[Nexus 4 Android Development] Crysis2:
hi!

i got a little problem:

accidentally disabled developer mod and there is no way to enable it again!

can some one guide me to how re-enable it again?

==============================================================================

the phone just hanged on and i lost all contacts and massages!

funny but all applications are still there!

i cant access backup that i made just before phone got made! :(
[Nexus 4 Android Development] vetzki:
The sed command doesn't work

devel-su sed -i -e "s#^adaptation=.*$#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#" /usr/share/ssu/repos.ini
Password:
sed: -e expression #1, char 113: unterminated `s' command

What is it supposed to do? (change adaption to http://repo... ? )

edit: without $ it seems to work

(devel-su sed -i -e 's#^adaptation=.*#adaptation=http://repo.merproject.org/obs/nemo:/testing:/hw:/lge:/mako/sailfish_latest_armv7hl/#' /usr/share/ssu/repos.ini)
[Nexus 4 Android Development] bolek1337:
There. I fixed it. Since it was in double brackets, the $ sign, which was supposed to indicate an end-of-line for sed, was substituted by shell ($#), eating the # sign. It should work without the $ sign too, so you should be fine. Nevertheless, I changed the quotes to single.
[Nexus 4 Android Development] radbme:
OTA was easy enough. I'll report back if I have issues. Thanks!
[Nexus 4 Android Development] rinigus:
Monitoring battery and CPU sleep

While debugging battery consumption on Nexus 4, I extended SysMon to show battery related stats in extended form (including rates) as well as CPU sleep %. Since SysMon wasn't showing cellular data on N4, this got fixed as well. Pull request is at https://github.com/custodian/harbour-systemmonitor/pull/14 , below I copied the text describing my changes with small changes from pull description. Code is available from https://github.com/rinigus/harbour-systemmonitor and it would take some time to review it and merge with SysMon proper. Note that changes in SysMon are generic and should work on any SFOS, as far as I can tell.

For visual description, see attached screenshot.

To debug battery charge consumption, I introduced the following changes:

1. I added new CPU sleep data stream that is calculated using the difference in CLOCK_BOOTTIME and CLOCK_MONOTONIC. This difference shows the amount of time CPU is in sleep (used by mcetool). By recording relative change in clock times, we can get how much time CPU was in sleep between two measurements. In Nexus 4, that would be between 0 (no sleep) and 98% (only 2% time active) in some conditions. Since its directly related to battery, I added plot as a part of battery detailed information.

2. I added plotting of battery charge rates (charge and discharge) as a part of battery detailed plot. While for charging autoscale of a plot seems reasonable and other settings can be specified in advance, I found that discharging rates could be interesting to study with different settings. Namely, the patch allows user to specify for discharge rate: maximal Y axis value, minimal time between data points used to calculate the rate, minimal changes in values when calculating the rate. The reasonable defaults are provided, user choices are saved as a part of configuration. User can change the parameters by clicking on discharge rate graph.

As you could see on example screenshot, something was keeping CPU from sleep from 4-7 (at the same time there was some system activity) leading to faster discharge. This process stopped as soon as I started using the phone (will have to look into it later).

For interested but not wishing to compile using Sailfish QT Creator, RPM used by myself is attached. Use at your own risk, as usual. Note that RPM has just version info altered to not get into conflict with SysMon proper (this RPM version change is not in Github).
[Nexus 4 Android Development] Kubino:
This screenshot is from night while I slept and N4 was in airplane mode. The second screenshot is more interesting, CPU usage went down after I use my N4.
[Nexus 4 Android Development] rinigus:
I have seen exactly the same. if sysmon is with my hack, you could click on battery usage graph and see extended stats.

I can confirm that in no network mode, right after charging has finished, cpu usage goes to 25%, cpu sleep is low with 25% as well, and it all drops as soon as you start using the phone.

in my case, journal is filled with

Apr 16 03:47:13 Jolla systemd[1]: Time has been changed

Apr 16 03:47:13 Jolla systemd[1063]: Time has been changed

Apr 16 03:47:14 Jolla systemd[1]: Time has been changed

Apr 16 03:47:14 Jolla systemd[1063]: Time has been changed

I haven't looked further, probably systemd timectl goes crazy. interesting that it happens after charging and airplane or no-network modes.

---------- Post added at 11:53 ---------- Previous post was at 11:06 ----------

Just a quick note: it looks that this 'time has changed' is all over the journal in huge amounts during and after 25% cpu usage. So it maybe unrelated to what Kubino reported
[Nexus 4 Android Development] radbme:
So the only thing I have to report is sfdroid wouldn't load after the OTA. A reinstall of sfdroid fixed it.
[Nexus 4 Android Development] radbme:
Any news on an update to solve battery drain? I've put the N4 away for now until then. Just too much drain to drive.
[Nexus 4 Android Development] rinigus:
Battery drain

In short: working on it.

State now: frequently I can get ~1:45-2 h of SOT, but this is not guaranteed. Note that my cellular data is poor at home, that might relate to total SOT

When I started looking into it (gamma4), the battery drain was so large that it was impossible to get through the day. Now I don't have to follow the battery % when I go to work, it easily lasts a day. So, progress has been made and I'll try to summarize it below.

1. Check whether your phone is actually sleeping at all. Mine was 100% awake. It can be checked by mcetool . However, mcetool should be relatively new. I am not sure what's the correct version in release (I'm jumping between testing and devel, on devel right now), but when I was on testing after OTA, mcetool was without sleep check (more on alternative below).

2. Mine non-sleeping N4 had sfdroid WITH google services. Now, anecdotal evidence after that -> I tried to debug it by flashing BBS on it and that made it impossible to boot SFOS. So, I made a fresh install Gamma4, OTA to Gamma5, sfdroid WITHOUT google services. <- Anecdotal part finished. Now I had a phone that was able to sleep, as reported by mcetools.

2b. During debugging of non-sleeping N4, it turned out that the proximity sensor was responsible for quite a large chunk of battery consumption [maybe ~50% in idle]. There is a bug that was opened in Mer to look into the state machines and their use of the proximity sensor. Right now, the enabling/disabling is non-automatic and can be done by user only.

3. I had the same issue as reported by Kubino, post http://xdaforums.com/showpost.php?p=66389112&postcount=470 . Mine was evident right after charging using wireless charger. Since this was easily reproducible I debugged that. Turned out that right after the phone was charged [I am using only wireless charger, not expected on USB], it entered the sleep states that were almost immediately interrupted. As a result, CPU was asleep only 25% of the time. Unfortunately, it seems that the same issue is in Android 6 [Chroma]. At least, when I tested it on Android, battery drain after charging was as large as I had in SFOS and BBS reported lots of wakelocks. Fortunately, the problem goes away when you start using the phone. So, I presume its a hardware or Android issue.

4. The current problem I am working on is related to sudden inability of N4 to get to sleeping state. This is harder to reproduce, but may occur once or more a day. Right now I am looking for possible causes.

While working on these issues I have been extending SysMon and I am planning to release my extensions via unofficial SysMon in Openrepos. There is a bug that I'd like to fix before that, but it should not take long. That extended version would allow you to check sleep time of CPU and look if suspend attempts were actually made.

In sum, there is still some work to do, but I hope to get a decent battery life on N4.
[Nexus 4 Android Development] rinigus:
As planned, an unofficial version of System Monitor is released. I hope it will be useful for debugging battery issues. If you are interested, note the incompatibility with the official version!

Available at https://openrepos.net/content/rinigus/system-monitor-unofficial-edition
[Nexus 4 Android Development] radbme:
Thanks. Grabbed it from warehouse. Cool.
[Nexus 4 Android Development] radbme:
I've been working with one of the main devs for Rockpool, the Pebble watch app for Sailfish. After a bit of log reading he determined that the issue I was having is because there are no bluetooth adapters available after bluetooth.target on start up. Basically upon first boot the app can't talk to the watch despite bluetooth having established a connection previously. Any dialogue from you guys I can point him to could help.
[Nexus 4 Android Development] radbme:
Hmm. Quiet in here.

So I noticed something that might line up with what Andy from RockPool is talking about. The Gamma 4 and 5 build have pretty good bluetooth save for audio routing but I noticed that on a fresh boot or reboot, bluetooth is off. It seems as though it doesn't remember tha bluetooth toggle state on a reboot or fresh boot. And if the rockpool service starts before bluetooth is enabled that could be causing it. I see two solutions here. 1. RockPool needs a retry upon bluetooth enable = true and 2. the next gamma build needs to remember if bluetooth was on at shutdown or reboot. Thoughts?
[Nexus 4 Android Development] rinigus:
Battery drain / cpu sleep

From the following of SFOS on my Nexus 4, I have seen only msyncd (from buteo packages) to cause the condition at which the phone is not sleeping for longer periods of time. So, if you wish to debug your battery drain issues, you could test as follows:

Use the SysMon unofficial (https://openrepos.net/content/rinigus/system-monitor-unofficial-edition or https://github.com/rinigus/harbour-systemmonitor) or check periodically with mcetool whether your phone CPU goes into deep sleep. mcetool should be relatively recent for this.

When not in sleep for an hour or more, its good to investigate the reason. For that, run wakelock.py (attached) in the terminal (or inspect /proc/wakelocks for wakelocks that are active manually). wakelock.py would check /proc/wakelocks for you and list the wakelocks that have been active for all time period between the checks (marked by *** in the beginnig of corresponding wakelock). The scripts sorts wakelocks according to the activity with the most active ones listed LAST (so it's easy to check it in the terminal). The script sleeps for 2 minutes between the checks and, if all is OK and phone sleeps as well, these 2 minutes can take significantly longer. Don't be alarmed, its a sign of the phone sleeping. When sleep is blocked, it will be refreshing every 2 minutes.

The script output would be (for each wakelock): number of times the wakelock has been allocated, number of times per minute the wakelock has been allocated between two last checks (reported as rate), the longest and the current active period of a same wakelock being active as observed by script. If the wakelock is stuck, these times will be increasing (reported in seconds).

If wakelock.py identifies mce_cpu_keepalive as a stuck wakelock (with ***), check the logs and look for the lines like these:

run in devel-su: journalctl | grep mce

...

Jolla mce[571]: modules/cpu-keepalive.c: cka_session_renew(): long session active after 239802 ms; id=359/BlockSuspend-2 name=:1.22 pid=1282 cmd=/usr/bin/msyncd

...

In this example, wakelock was caused by msyncd (from buteo packages). Notice, that in normal operation, it should be followed by

Jolla mce[571]: modules/cpu-keepalive.c: cka_session_finish(): long session lasted 655828 ms; id=318/BlockSuspend-2 name=:1.22 pid=1282 cmd=/usr/bin/msyncd

If its not then you have the same problem as me.

Please, when reporting, specify which accounts do you have (google, caldav, carddav, ...). The list is under Settings/Accounts.

I wouldn't be surprised if the issue is general SFOS one and its just more visible in N4 port. Its possible that N4 has the same bug as in https://together.jolla.com/question/126892/release-notes-201taalojarvi-released/ : Google contact sync may sometimes hang up and drain the battery . If true, for me, "sometimes" is 1-2 times a day for me. By reboot of the phone (maybe just some services would do) you could get the phone to sleep again.

There is a possibility that the issue has been resolved in newer buteo versions and I just don't know it.