[Bug] Switching ambience triggers constant CPU usage on voicecall-ui process [released]
asked 2018-11-01 11:49:11 +0200
When a user switches between ambiences in SFOS 3.0.0.5 the voicecall-ui process starts to constantly use 1 to 1.6 percent CPU. Normally voicecall-ui is quite dormant, using CPU only occasionally (unless the voicecall UI is actually used).
Voicecall-ui can be restarted with a command: systemctl --user restart voicecall-ui-prestart
This behavior is similar to this previous case but triggered differently: https://together.jolla.com/question/188325/sailfish-x-voicecall-ui-prevents-deep-sleep/
Update 2018.11.10
It seems that this not so much of a problem of the voicecall-ui directly, but a problem of voicecall-ui-prestart.service or how it is run or started in the background.
When the service is stopped with the command systemctl --user stop voicecall-ui-prestart, and then started again manually with /usr/bin/voicecall-ui, or by starting it from the GUI (the Phone app), the problem is not triggered.
When active, it seems that the condition can be cured without restarting voicecall-ui-prestart service simply by starting the Phone app manually. After this has been done once, the CPU usage settles to normal levels. Also the consequent switches of ambience do not trigger the bug anymore after launching the app once.
The bugged condition can be reproduced again by running systemctl --user restart voicecall-ui-prestart (or booting the phone), and then switching between the ambiences normally.
So this bug seems to be directly related to on how the ambience change process tries to operate with voicecall-ui when the latter hasn't previously been started by anything else than its preload service.
Update 2019.01.08
Fixed in 3.0.1.11. Case closed.
Thanks for the post, it is reported now.
jiit ( 2018-11-01 14:03:49 +0200 )editUsing SysMon, I have also seen problems with CPU sleep / suspend, but couldn't relate it to some process.
btw and probably not related: Whatsapp's background process seems to use > 1%.
wosrediinanatour ( 2018-11-10 14:41:47 +0200 )edit@wosrediinanatour I think Whatsapp has to be constantly on (and to prevent deep sleep) for it to be able to poll and get messages, so that may be by design. Unless it polls, say once in every minute, after which it could let the phone go back to sleep.
I don't personally use Whatsapp, but if you do, you can try to measure how long it takes for Whatsapp deliver the message from the other phone when you have your phone screen off and (hopefully) sleeping. If it is every time instant or greatly under a minute, then Whatsapp practically does not let the phone go to sleep at all.
This is also my experience from Android phones these days; Google has done a great job at bunching up services to do their communication at certain "heart rate" which helps quite a lot, but if you have a phone (rom) that does not have google framework installed or Whatsapp or any other instant messaging clients on it at all, you can achieve uptimes of up to 2 weeks with them, compared to just regular 1 to 3 days.
Manatus ( 2018-11-10 15:40:11 +0200 )edit