yashsingh1/xdaforums huggingface dataset:
[Desire HD Android Development] mad-murdock:
about the workaround: well - i am a bit lazy atm - i think i got the solution, but did spend yesterday working on other stuff and also watching tv shows... a lot crowding up my hard drive...

about part time / full time. well - being 36 years old, i cannot work anymore. i never discuss why except to close friends - but its a fact: i got pretty much time. as long as there isnt anything going on in reallife, i spend that time with cm7.
[Desire HD Android Development] Chezbel:
Thanks for confirming what I suspected, but wasn't sure about. Oh and sorry to interrupt during your important activities of TV and searching for new cat pictures...
[Desire HD Android Development] c_felge:
Actually I am worried about the inconsistence. Like I said on #5 I had a consistent drain of about 5mA, with smaller jumps of 1 or 2 mA up or down. That got me a consumption of 4 to 5% in 8 hours of standby. I know, maybe I'm just nitpicking. And actually I can't prove it, cause I don't have the log files anymore.

As for background apps: I don't have other apps running in the background than on #5.

Here is the plan!

1. I'm going to flash nightly #21 and fix #5 now and log the consumption.

2. I'll flash fix #7 and log again, then we'll see if there's a difference.

Maybe I didn't mention that, but I don't want to criticize anyone or anyones work here. murdock you're doing a great job here and I highly appreciate your engagement in pushing forward development and improvement of cm. Thanks a lot for that!

Best regards
[Desire HD Android Development] mad-murdock:
no worries - your feedback is very welcome! dont let the discussions here fool you into thinking feedback isnt welcome (:

i like your idea about #21 and #5+#7 very much - since we would have valid proof then. the spikes might also result from something in #21.

i just checked the kernel config of #21 and my kernel (which uses kali's latest default settings) - and the differences are minor.
[Desire HD Android Development] mad-murdock:
i create them - its just some clicks and some few minutes... but tv shows rock - watching fringe right now while taking breakfast...
[Desire HD Android Development] c_felge:
Great!

I'll be back with the results in about 3 hours. Have to charge my device first.

BTW, home office days a great! ;)
[Desire HD Android Development] EmptyArea:
Everything is good with bat#7 with nightly#21, except the patch would not worth at all until after using voice search even though I had no calls.

Swyped on transparent XDA app.
[Desire HD Android Development] deconfrost:
#7 was drawing 14 to 15mA for me with cm7 #13 on idle,#5 draws 4 to 5mA on idle. Gonna flash cm #21 and try #7 again shortly
[Desire HD Android Development] EmptyArea:
Around 14ma suggests it wasn't working. I have steady<4ma after making a call and starting voice search.

Swyped on transparent XDA app.
[Desire HD Android Development] robertus3d:
Great work mad!;)

With cyano rc2 and patch #5 i got less 1% in standby in airplain mode and 1% with normal mode.

I'll go to try last nightly and your last patch and report result here!

Here my log about last 3 days of cm rc2!:D

View attachment 543956
[Desire HD Android Development] vinnieminnie:
Today my wifi woudn't work. Whenever I tried starting it up, it would say "fout" (or "error" in english). I tried rebooting a couple of times, fixing permissions, taking out the battery, wiping cache, but nothing worked. I was on Killer Lama PNK and then did a nandroid to PNK I-J. I was happy to see that wifi still worked on PNK I-J, but I don't know what ****ed it up on K-L.

I don't think I've seen anyone else with this problem, right?
[Desire HD Android Development] mad-murdock:
i dont see how this i connected to this thread to be honest.
[Desire HD Android Development] c_felge:
Result comparison mad#5 | mad#7

Hi,

As announced this morning I tried to compare mad#5 and mad#7 batt fix. Therefore I updated my device to newest nightly #21 and installed batt fix #5, first.

I logged the current consumption for about 2 hrs. Afterwards I flashed fix #7 and logged the consumption again for about 2 hrs. And now, here's the result:

And the winner is ...... BUILD # 7

Unfortunately this result is not very meaningful, because it's only a 2 hrs testrun, so you can't even calculate something like an overall average consumption per hour thingy... you know what I mean.

Anyway you can check out the log. Build #7 looks better and obviously is.

@mad-murdock

You were right! And convinced me of your 7th build! Maybe I just had one closer look too mouch ;). Thank you! Great job!

Best regards

felge
[Desire HD Android Development] vinnieminnie:
Ah, let me tie the loose strings together.

I flashed your batfix #7 over K-L, so I figured it might have something to do with my broken wifi. I can't imagine it being something else then PNK K-L, or your batfix, so I decided to check if anyone else had the problem with your batfix, so I could narrow down the cause.
[Desire HD Android Development] mad-murdock:
i just got a pm of someone mentioning that using fm radio screws up dsp power down again. its too late to look into it for me - but it maybe true.
[Desire HD Android Development] Chezbel:
@Mad, I've attached an interesting log that was taken overnight. There was no activity by me except when I woke up about 05:45 and turned the wifi off and went back to sleep.

From 02:10 to 05:45 with wifi on there are no current spikes.

From 05:45 to 09:09 with wifi off there are a lot of spikes.

However, even with the spikes it looks like the battery percentage decrease is very similar. A longer test would have been better, unfortunately work and sleep don't always play nicely with each other.

This was taken with #21 nightly and #7 battery.
[Desire HD Android Development] Chezbel:
I know someone will ask this.... Yes, you still need to flash mad #7 after flashing nightly #22. I tested this experimentally.

Also, my very "scientific" test of 10 minutes shows the current draw to be similar to that of the last few nightlies.

EDIT: The part about "scientific" test was kind of a joke. However, 1 hour of testing shows current in the 3-5mA range when the phone is idle, same as previous nightlies with #7
[Desire HD Android Development] alind_:
Hi! I'll just add that I've seen this as well. However, I've also seen this on stock htc roms. So I'm leaning more towards it being due to data traffic (which consumes less power on wi-fi). Happy investigating :)
[Desire HD Android Development] Chezbel:
I'm guessing that the spikes are not so important since my battery percentage decrease was not noticeably affected. It's entirely possible that the spikes always occur, but they are hidden due to the timing of the spikes vs the logging interval. That seems plausable, but I have no proof. I guess you could tell with a scope or logic analyzer that was able to record a large history, but I don't have that.
[Desire HD Android Development] mad-murdock:
interesting findings...

i like the idea about the spikes beeing hidden over the measure interval. i am 99% sure, those spikes are not connected to the drain fix, which is about dsp. its much more likely, that

a) people didnt notice those spikes before, because the overall drain was high

b) people didnt notice those spikes before, because i bet not 1% of the attention currently payed to battery consumption was payed to it before (:

c) it might all be connected to some apps running wild - it might even be cm-included apps.

my work here - focusing on the dsp chip - shouldnt be connected to those spikes - but maybe we find out whats that all about...

lets investigate this newly reported fm-radio-issue now
[Desire HD Android Development] mad-murdock:
tested it - its not true. maybe its the same as with first call - first time needs a workaround (doesnt matter if first time is a call, fm radio, something else), and after that workaround no other problems....

neat... so after 3 days only one (fixable) issue...
[Desire HD Android Development] Fihlvein:
People shouldn't focus on a) spikes or b) little drain level variance in my opinion.

a) A momentary spike in short, is normal, to my experience. I've had those with Sense based roms as well. During this observation, I always have at least 2G available for basic phone calls. All other relevant (BT, WIFI, Mobile data) disabled. Spikes occur, and I belive it's just the radio network (2G causing them).

If spikes come during airplane mode, then it's the Android itself, or maybe some offending application trying e.g. to connect somewhere without realizing network is not available.

In any way, the consumption during spike is just momentary, so it really doesn't affect battery level much at all.

Since nobody has proven that DSP would suddenly turn on & off repeatedly, and itself be the cause of these spikes, I don't see any reason for us to continue discussing about these spikes in this topic. It's useless and distracts from researching the real issues, like keeping the DSP swiched off.

Of course, if someone can prove us wrong and show that DSP was actually active during a consumption spike, please do that. :)

b) If your phone average consumption is constant 3-7mA and mine is 1-4mA, why would you report it here? Do you think the DSP is somehow "partially" switched off and causing a worse performance for you than for me? How that could even be possible?

If DSP would switch on and off itself, that would mean we would see a lot more variance in min & max levels in our log files, such as 1mA to 14mA, because the difference is almost 10mA whether DSP is on or off. So if you get constant 3-7mA, DSP cannot be on in any measurement moment, because it will drain minimum ~9mA when active.

The difference comes for example from the active wireless services (2G/3G, BT, WIFI, Mobile data) and the strenght of your radio network. It may also come from applications that try to do something when sleeping. It can be basically anything doing something for some unintentional reason.

But it really cannot happen because of this DSP off fix as far as I can see, so again I find it useless to discuss about it again and again.

We should focus our findings in a) having the DSP switched off in all occasions when phone is sleeping or sound is not used, and b) having all applications working as expected when this fix is applied, and report if there are any strange application behaviors.

Right? No? :D
[Desire HD Android Development] mad-murdock:
well, like i said, its not the dsp.

but i dont see any reason why not to discuss it here. if we find the solution, we can maybe extend the live of the battery some percentages... perhaps half an hour or an hour.

discussion cannot hurt (:
[Desire HD Android Development] zepretender:
Hi Mad-Murdoch,

Just one word to says that #7 build doesn't seem to work correctly. I don't know how to repeat things, but after listing music (sometime, not each time), DSP doesn"t seem to stop. #5 was better for my usage.

Sorry for my english, I try to do my best... and I don't have many informations for you. Perhaps I should go back to RC2, to avoid spikes...
[Desire HD Android Development] kshting:
I just feel that if the spikes (referring to anything greater than 100mA) occurs every now and then; it may just undermine any 1-7mA that is attained within certain time intervals. Unless we accumulate alot more 1-7mA, otherwise I feel that it may affect battery life i.e. no significant difference.

E.g.

If we get two 100mA spikes (total 200mA) and only twenty say, 6mA, (total 120mA), then we would still have an additional drain of 80mA (instead of savings) in any certain time frame. And it may get worse depending whether the phone woke up on the wrong side of the bed and we may just go back to the beginning where drain could be 2-2.5% an hour (It happened to me).

Yes, I believe apps and network would probably play a role in producing the spikes which there is nothing we could do about in everyday use.

Just sharing. Nothing more, nothing less :)
[Desire HD Android Development] EmptyArea:
You're both right. At first I couldn't see why mad said it was okay to discuss spikes that clearly aren't related to the dsp, but then if you check the thread title this is the cm7 battery drain fix thread.

At the same time, everybody carries a different setup on their phone so pointing out you have drain is like pointing out trees in a forrest, "yep that's a big one, not sure if it's as big as the one we saw yesterday..."

Noticing patterns, assuming their origins, testing, concluding and evaluating (scientific model) is often the key to achieving aims, giving a half arsed report is often useless and always annoying.

My 2 cents.

Swyped on transparent XDA app.
[Desire HD Android Development] kshting:
Hmmm.....:rolleyes:
[Desire HD Android Development] flo90:
Fix works on CM6 Greats job THX ;)
[Desire HD Android Development] alind_:
Just to clarify; two spikes of 100mA and 20 at 6mA would translate to ~14.5mA average. Still bad just not as bad as it sounded.

On the note that it's due to timings I would not draw that conclusion from my measurements. I'm personally a battery usage nerd and the first thing I did after getting the phone was run currentwidget. After runs of 2 days with wi-fi off and then 2 with wi-fi on It was clearly visible that the number of spikes were higher with wi-fi off. Note that I'm not saying it affects the overall consumption. Unless of course wi-fi itself changes the timings :)

Technically I don't know how long time intervals the hardware averages over or how often the kernel fetches a new measurement or if too large changes (spikes) makes the averaging algorithm reset in order to be responsive. All I know is it's damn interesting to measure and optimize it :P

Peace!
[Desire HD Android Development] EmptyArea:
Hey nerd :p, have you tried Droidwall (free from market) it definitely reduced my spikes, with wifi on or off. ( I also use PermReq for guidance.)
[Desire HD Android Development] kramerty88:
Not entirely true. Because we all share a lot of apps. So if anyone suggests anything others can compare these outcomes. Most likely the spikes are from standard apps most of us have and thus are easy to test.

The first thing I'd say to compare is the use of 3g to wifi overnight. Since there are a lot of comments in this thread already at the moment. So I'm going to try this out now and see what's better for me.
[Desire HD Android Development] mad-murdock:
your english is fine - language is a form of communication - as long as people understand what you wanna say, it serves the purpose (:

but i cannot believe what you say. from many many replys here, the only issue is after first call. once you start voice dialer/sound recorder after first call, your dsp always goes to off. i am pretty sure about that now...

good to know! changing the topic subject after that feedback.

i dont really understand how the spikes are connected to dsp. not saying not to discuss it, but do you say, there are no spikes without the patch? so without it 11-14ma without any spikes? hard to believe looking at what changed.
[Desire HD Android Development] mad-murdock:
i really really really need to finish the firstboot fix. 4 days now, that i dont get to it, since i always end up working on something else or i just realize i wont have 2 hours of quiet time to get it done.... suxx2beme... i somehow owe you this (and also myself) - so tomorrow is fix day... flame me, if i dont have any progress in 24 hours!

updated first post - for status command now use:

dmesg | grep -i aic | grep -v suspend | grep -v resume | tail -n 25

it stops showing you suspend and resume output, and you only see the last interesting stuff about dsp status
[Desire HD Android Development] Chezbel:
There are 2 reasons I suggested that the presence or absence of spikes in the CurrentWidget log might be due to the logging interval.

1) Regardless of whether or not the spikes show up in the log my battery percentage drain per hour is roughly the same. For a 7 hour idle test the percent lost is the same. That's why it thought it might be possible that the spikes always occur, but were in sync with the logging interval.

Of course that isn't proof, it may be that certain things (e.g. wifi off) do cause spikes, but the impact is not noticeable on an overnight run. However, I'm not willing to test this by letting my phone do nothing for 24 hours :)

2) I don't know exactly how CurrentWidget monitors the battery. I have mine set to log every 120 seconds. Does that mean CurrentWidget sleeps for 110 seconds, wakes up, watches the current for 10 seconds, logs it and goes back to sleep? If so that would easily miss spikes that occurred for a few seconds or even longer if they always occurred at the same frequency as the logging.

Anyway, it's somewhat interesting to discuss, but unless someone's experience shows that the battery usage is significantly different with or without the spikes it doesn't look like it will lead anywhere.
[Desire HD Android Development] Fihlvein:
I'm interested too to know whether CurrentWidget / Battery Monitor Widget (prefer much more) initiates measuring only at configured intervals and takes the current ampere flow as I suspect, or does they measure some kind of average consumption, which I highly doubt.

@mad-murdock: to motivate finishing this to be included in CM7, I'll donate you a beer when it happens!
[Desire HD Android Development] alind_:
Hee hee... being the nerd that I am the first thing I did when I first downloaded CurrentWidget was check the source code. :) All it does is dump the kernel's report of battery current (depending on platform) so no averaging on CurrentWidget's side. That's why pushing refresh repeatedly gives the same answer in the widget.

...
// htc desire hd / desire z?
if (Build.MODEL.toLowerCase().contains("desire hd") ||
Build.MODEL.toLowerCase().contains("desire z")) {
f = new File("/sys/class/power_supply/battery/batt_current");
if (f.exists())
return OneLineReader.getValue(f, false);
}
...
[Desire HD Android Development] mad-murdock:
current widget (and the battery monitor widget i use) just read logcat, which logs the consumption each 5 minutes. dividing the value by 5 -> tadaa... you got a 1 minute consumption
[Desire HD Android Development] mad-murdock:
most likely happening soon, as i build #8 right now. fixed the boot issue, wrote AicBootFix.apk

i like beer (:

edit: build 8 is uploaded
[Desire HD Android Development] Chezbel:
Cool, that's what I wanted to know, but had discovered yet. That means that for these experiments the only useful measurement is: (% battery lost) / time. And time should be "long", like overnight.

Great.
[Desire HD Android Development] Chezbel:
I did the following because I don't think it would be a valid test to just flash #8 battery fix by itself:

- Wipe cache

- Wipe Dalvik

- Re-install nightly #23

- Install battery fix #8

- Verify the aic3254 power down occurs

- Make a phone call

- Verify that another aic3254 power down occurs

For me it works, no need to use voice search after a phone call now! Thank you!
[Desire HD Android Development] p2pjack:
Thank you mad-murdock for your work on this fix got you a Bratwurst :)
[Desire HD Android Development] AdrianM:
What is AicBootFix and why is it visible in AppDrawer?
[Desire HD Android Development] mad-murdock:
gnah! okay, build #9 incomming - only difference: aicbootfix NOT in app drawer anymore...
[Desire HD Android Development] AdrianM:
That's the answer I was hoping to get. Thanks. :)
[Desire HD Android Development] alain57:
lol and i reinstall CM nigthly + patch #7 yesterday .... i can do it again :D

once again thanks a lot for your work :cool:
[Desire HD Android Development] mad-murdock:
just put #9 over your nightly - its a matter of 3 minutes...
[Desire HD Android Development] mad-murdock:
lol! you changed you signature in the last 5 minutes...

Build #9 uploaded.

change: hide AicBootFix from app-drawer and list of applications
[Desire HD Android Development] Chezbel:
Yep, works just like #8 (good) and no AicBootFix in app-drawer.

Just for fun I did the complete, wipe, re-install nightly, install #9
[Desire HD Android Development] AdrianM:
Yep, just saw that it was OLD... :D
[Desire HD Android Development] Smedo:
Is it possible that you keep a small changelog in first post mad? Because ik like your psychische, like to use the newest version, but i dont like to read the compleet topic when the versionnumber is +1 :-)
[Desire HD Android Development] mad-murdock:
there is a changelog - i moved it to top of 2nd post...
[Desire HD Android Development] maddler:
There is already a changelog in the OP.
[Desire HD Android Development] mad-murdock:
in case you made your old signature graphics yourself, make such a nice graphic for cm7 - and i will add it, too... maybe a bit smaller (:
[Desire HD Android Development] AdrianM:
I will, when i will get back home. :)

Sent from my Desire HD
[Desire HD Android Development] hama2:
i´ve done

start script and results stderr: thats right?
[Desire HD Android Development] Smedo:
Stupid...didnt see that! Thanks!
[Desire HD Android Development] zepretender:
Must I use Voice Recorder after first call or is it definitly over ?
[Desire HD Android Development] LorD ClockaN:
no, you don't!

And YES, this is final! Looking and working good!
[Desire HD Android Development] Chezbel:
It's possible that so many dmesg events have occurred that you can no longer see the message for "aic3254_powerdown: power off AIC3254". Try making a phone call, wait about 15 seconds and then run your script again. You should see the power down message.
[Desire HD Android Development] frottage:
Ok so basically I've tried every edition of this - #5 worked but occasionally broke

#7 didn't work at all for me whatever I tried

#9 is fabulous works perfectly straight from the flash.

I hope it gets incorporated into nightlies soonest!

Thank-you mad murdock for your efforts with this - I will send you a beer via PayPal
[Desire HD Android Development] TimeTurn:
Danke @mad-murdock - coole Arbeit! Gleich mal raufschieben :D

Great work!
[Desire HD Android Development] FredRaid:
Thanks a lot for your time and your work... My battery life is great know! :D
[Desire HD Android Development] g.lewarne:
thanks Mad Murdock, can confirm myself that battery drain has been perfect all day, on a clean flash, without using anything microphone or taking calls :)

i have integrated your kernel into my release rom, hope you dont mind :)

g
[Desire HD Android Development] mad-murdock:
thanks for all the thanks - i also feel pretty happy now after we seem to have solved the problem in all affect. drinking "hefeweißbier" right now (:

i should also thank you for all your feedback - without it, it would have been much harder to solve it!

well said mate! phone call or anything what triggers speaker or microphone. even the "beep" from changing ringer volume is enough to trigger it.
[Desire HD Android Development] zepretender:
Perfect for me ! Great job ! Now that Superpower is Gingerbread compatible, all is perfect !!
[Desire HD Android Development] cursordroid:
Just gotta ask then...

If I reboot my phone, and leave it alone without letting it beep, voice search or dialing a call, will the DSP be on the whole time?
[Desire HD Android Development] mad-murdock:
no - its off... that "play something" is only forcing the status to show up in logs again - it works without beeing in the logs...

i monitored the behavior a while before uploading #8 - if there is no hidden bug, its perfect now!
[Desire HD Android Development] Chezbel:
If you wait about 10 or 20 seconds after your phone is running after a reboot and then run the script that Mad posted you should see the aic3254 powerdown message showing that the DSP is off.

EDIT: Sorry, posted at the same time as Mad
[Desire HD Android Development] sonydesouza:
Thanks Murdock ! Build 9 works like a charm !!!!!!!!!!!!!

YEAHHHHHHHHHHHHHHHHHHHHHHHHHHH ;)

CHEERS !
[Desire HD Android Development] cursordroid:
Nevermind... Confirmed that this is not the case.

Rebooted my phone and immediately afterwards checked the dmesg stuff, noticed that the last thing it did was power down.