#81 Battery consumption

[Anonymous]

Originally created by: egcros...@gmail.com
Originally owned by: r3gis...@gmail.com

Maybe this issue is too vague to register as a "defect" but as there is no discussion forum for CSipSimple, here goes:

I was using Sipdroid for a while, but I strongly dislike their UI decisions so I am trying alternative SIP agents. I actually talk very little, maybe a few minutes per day but I have SIP agent registered at all times when under WiFi coverage. When I run Sipdroid, by the end of the day I have battery indicator at about 50%. When I run CSipSimple instead, with all other activities basically the same, by the end of the day the battery indicator is yellow or even red (< 20% I think).

This issue and loosing registration (issue #67 comment #4) are two things that makes this program less acceptable to me than Sipdroid. Otherwise, I am happy with the UI and satisfied with stability.

HTC Desire, Android 2.1, CSipSimple pre5.

[Anonymous]

Originally posted by: r3gis...@gmail.com

If settings are not saved, by default CSipSimple is configured to be started when connection comes up.

So if the app can't save its settings, you'll indeed observe that it will constantly restart as soon as a wifi hotspot notify it is running.

I think that solving the problem with settings will solve the problem with constant restarts.

In fact, when you press disconnect, it add a flag somewhere about the fact you don't want the app to start again when a connection intent is received from android OS. So without any settings saved but with a correct account database, what you observe is somehow normal.

[Anonymous]

Originally posted by: ber...@gmail.com

regis, you were right. settings can now be saved and the abnormal battery drain is gone - yepee :)

sorry for trying to make your excellent csipsimple responsible for a bug samsung introduced into froyo (2.2.1) on the galaxy s.

thank you very much for your help and patience ... (feel free to delete my comments regarding this issue if you think they are worthless for others).

[Anonymous]

Originally posted by: r3gis...@gmail.com

No problem, that's fine.

Hopefully it will help other users :).

There is never bad questions and I really prefer when an issue is raised than having frustrated users (or worse frustrated users that leave bad comments on the android market where I can't help them :) ).

[Anonymous]

Originally posted by: egcros...@gmail.com

Got this today, unprovoked. When I killed the offending process from adb shell, this did not prevent the app from working. Attaching log and top output.
(is this the right ticket? or do you have a special one for busyloop?)

[Anonymous]

Originally posted by: egcros...@gmail.com

the above is for [r886] ginger on oxygen 2.1.6

[Anonymous]

Originally posted by: r3gis...@gmail.com

Issue 1195 has been merged into this issue.

[Anonymous]

Originally posted by: chin.bil...@gmail.com

I would like to know if this is normal or not.  I have gotten rid of my stock 2.1 rom for my X8 and install a custom ROM gingerdx on it.  Everything seems to be fine.  I re-installed my csipsimple application.  Since this is a ginger rom so I take advantage of the latest nightly trunk for gingerbread.  I installed the application and reloaded my previous account info.  All was fine.  The call quality is much better than before BUT i notice my battery usage is a lot higher.  Upon examining the details, I seem to find out that during my 40 min call my partial wake lock had been on for exactly the same time.  Even though the screen was off, the CPU had been chugging along for the full call.  After the call, my battery level was 15% lower.  I have since checked the setting.  Nothing in it seem to indicate that I turn on partial wake lock at all.  Is this normal?  Could csipsimple request partial wake lock even though it is not explicitly set to have that?  In my previous market version for non-ginger edition I was not aware that this situation had happened.  What gives?

[Anonymous]

Originally posted by: r3gis...@gmail.com

It's normal that the app take a wake lock during call. It did that from the beggining and all voip apps should take a wake lock when you are in call.
The reason is that the actually really need the CPU to be available to encode/decode the call codec. If CPU goes off... you'll obviously got no sound anymore.

About the fact it take more battery now, it could be about the codec in use. Not all codecs use the same CPU. It could also be due to the fact you tried the "gingerbread" version. This one is more close to the hardware and so frame rate is higher. The bright side is that call quality is better, the dark side is that the battery usage may be higher if the opensl-es driver (the one used in gingerbread) is not implemented to ensure that battery usage remains low. If you are using a custom ROM, this driver is probably re-implemented by ROM makers and may not be totally robust about that.
It could explain what you observe and unfortunately there's nothing that could be done on csipsimple to get rid of that. I can only advise you to use the normal trunk version instead of the gingerbread one if the gingerbread implementation introduce some too much annoying battery usage.

[Anonymous]

Originally posted by: phtr...@gmail.com

I think the power consumption could be the problem of PJSIP lib. If you read their code, e.g. pjsua_core.c, you can find they are polling for timers and socket events every 10ms.
Polling is good choice for servers or desktops, but not for mobile phones. See http://www.lesswatts.org/projects/applications-power-management/device-ios.php

However on the symbian system, the PJSIP claims "zero polling", see
http://www.pjsip.org/sip_symbian.htm
and
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-March/006814.html

Maybe they should also do this for android.

[Anonymous]

Originally posted by: r3gis...@gmail.com

One of big changes of latest version is to remove this polling approach and to use the Android way for timers.  Not only it will reduce CPU usage but will also ensure that CPU is running when timer has to be fired.  So this point is fixed in CSipSimple thx to my port of the timers for android :) (as pjsip already do for symbian)

[Anonymous]

Originally posted by: chin.bil...@gmail.com

just wondering has gingerbread version been removed now from nightlies?  Has it been merged?  what happens to the native driver usage specific to gingerbread rom?

[Anonymous]

Originally posted by: r3gis...@gmail.com

It will be reintegrated soon as either a plugin or an option in the app (probably more likely to be inside the app and that could be enabled by setting).
Depending on result we can obtain with this mode it could be set as the default driver for future release (on 2.3 and upper devices) too. The big threat for now on this topic remains battery usage. I have to look what was done on google's project webRTC. When I implemented this device glue I was the first to do so and was a little bit blind on how it could work and I may have missed a couple of things about CPU consumption ;). Now that google also did something with this API, I can compare and see how they do things (they probably do that better than me).

Also, SILK, G7221, G726 and Codec2 are also now about to be re-introduced as plugin apps. A video plugin should be added too once the feature will be ok on my side.

Actually in order to integrate latest pjsip-2.0 I had to change a lot of things in code, and in build process. We are currently in the transition time. Things are landing step by step. ZRTP and TLS feature are now part of nightlies and the alternate gingerbread device implementation will follow, be patient ;).

The only feature that should be dropped will be : the armv4t support and the android 1.5 support. For these two cases, the old builds of the 0.03-xx branch will be maintained as longer as possible with lower priority for me.

[Anonymous]

Originally posted by: jerry.fi...@gmail.com

As I understand, a new timer was introduced for android in order to make a better usage of the device power.
As part of the change, no worker threads are used in pjsua.
However I don't understand where ioqueue polling is done in order to handle the network events.
Can someone please help? What am I missing?

[Anonymous]

Originally posted by: r3gis...@gmail.com

io queue is not used anymore. Don't hesitate to join developer google group for these questions, I think it valuable questions for all developers making work on the top csipsimple ;).
http://www.pjsip.org/docs/latest/pjsip/docs/html/structpjsuamediaconfig.htm#ab1ddd57bc94ed7f5a64c819414cb9f96

Maybe it would be interesting to discuss again about that, if in pjsip-2.x the thread are now started only on demand (I know that media transport are started on demand, maybe it also affects io_queue polling, and so will not be a problem to reactivate that without having high cpu usage in background mode)

[Anonymous]

Originally posted by: jerry.fi...@gmail.com

Thanks for the quick response.

I posted my previous question at the developer group, so the discussion can continue there.

However I still don't understand. The link you provided relates to media, and pjsua ioqueue polling refers to signalling. My question is how SIP signalling continues to work?

[Anonymous]

Originally posted by: ajpearc...@gmail.com

I notice that many people in this thread are not completely sure how to test battery consumption.

For reference can we print here how to measure:

- how much CPU a the cSIPsimple process is using over time
- a way to record when the cSIPsimple process wakes from a background process and consumes a little cpu

Because with version 0.03-01r1108 I noticed it coming out of sleep and wasting a little battery.

"android put things in RAM memory and the app does absolutely nothing in background"

As a user that until it is fixed I suggest using an App Quarentine when not in use and unlock it with a widget when you need to use it.

[Anonymous]

Originally posted by: egcros...@gmail.com

For lack of better ticket: this happens from time to time, CPU usage jumps to 100% and the device becomes warm, and of course the battery drains fast. The offending processes are mediaserver and csipsimple:

User 55%, System 44%, IOW 0%, IRQ 0%
User 175 + Nice 0 + Sys 143 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 318

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
   88  50% S     8  27236K   3876K  fg media    /system/bin/mediaserver
25751  35% S    16 127452K  33760K  fg app_56   com.csipsimple:sipStack
  112  11% D    67 233968K  60132K  fg system   system_server
28591   1% R     1    940K    388K  fg root     top
    5   0% S     1      0K      0K  fg root     events/0

I've shared logcat taken while this was happening with r3gis in google docs.

[Anonymous]

Originally posted by: egcros...@gmail.com

Happened again in a recent nightly build. There was an unanswered sip call, when I picked the device it was warm.

User 53%, System 46%, IOW 0%, IRQ 0%
User 168 + Nice 3 + Sys 148 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 319

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
   88  50% S    10  29636K   3128K  fg media    /system/bin/mediaserver
6502  36% S    28 140096K  34412K  fg app_56   com.csipsimple:sipStack
  112  10% S    67 248364K  58572K  fg system   system_server
14746   1% R     1    944K    392K  fg root     top
14708   0% S     8 109424K  27464K  fg app_33   com.android.packageinstaller

(packageinstaller is trying to install next nightly build and was unable to do it until I killed the process 6502.)

Shared the log with r3gis

[Anonymous]

Originally posted by: donrhum...@gmail.com

In the latest CSipSimple with pbxes, I'm getting double the battery drain of SipDroid. Is there a fix for this?

[Anonymous]

Originally posted by: donrhum...@gmail.com

I changed it to TCP and keep-alive on wifi is 180, but it's still using about 2% battery per hour. With SipDroid, I typically saw 1% per hour.

[Anonymous]

Originally posted by: jost.me...@gmail.com

Background process seems to drain the battery under Android 4.2.2. This issue is new since I upgraded to 4.2.2. Under 4.2.1, it didn't even appear in the battery stats.

[Anonymous]

Originally posted by: egcros...@gmail.com

Works fine for me on 4.2.2 (cm10.1 alpha on HTC one x)

[Anonymous]

Originally posted by: AHTOH.C

The battery drain is extremely high under Android 3.2 on my Huawei Mediapad. The tablet is warm after sleeping for hour!
It is ok if csipsimple is not installed.

[Anonymous]

Originally posted by: dpa...@gmail.com

Using the latest CSipSimple, is it possible to prevent the app from starting automatically whenever there's a WiFi network? I only want to use the client at work, I want to manually start and close it and not have it start by itself.

[Anonymous]

Originally posted by: webmas...@kitti.ac.th

Galaxy note 2, android 4.1.2.  Csip nightly build.  I click register with sip provider then unregister, go to network setting, uncheck all incoming and outgoing call, goto user interface then uncheck all phone integration, pull up menu then disconnect to home screen.  After all these, Csipsimple process still stays and takes about 5% unless I have to manually kill the process.