yashsingh1/xdaforums huggingface dataset:
[X Style (Pure) Android Development] dirtyhank:
Question for you guys...

I'm researching sound control and it's being quite a PITA since this device uses not so common DSP and amp. I haven't been able to use any of the solutions out there (ie: faux sound control) so I guess I'd have to start almost from scratch.

What I'd like to know is, which of the usual kernel sound control settings do you use the most? So I don't waste my time working on stuff nobody will use ;)
[X Style (Pure) Android Development] Rocketval:
This is sound control for moto g but it can be enabled on ghost and htc one m8 too. I don't know which amp clark uses.
[X Style (Pure) Android Development] unitz0mbie:
my phone is starting to freeze up everytime i install an app, or i move an app to my sd. it never happened before, i have the latest build with truepure 2.6.3
[X Style (Pure) Android Development] gpz1100:
Have double tap to wake enabled in kernel auditor.

After a reboot, if kernel auditor is not allowed to apply its settings before the screen goes blank, double tap to wake doesn't work. In fact, neither does the power button. Instead, the phone reboots.

This is easily reproducible on every boot. If kernel auditor is allowed to apply its settings, then there's no issue. All moto display functions are disabled.
[X Style (Pure) Android Development] agam1308:
Amazing battery life, thanks for your work.

Enviado desde mi XT1575 mediante Tapatalk
[X Style (Pure) Android Development] gpz1100:
In reference to my reboot issue 1 post up, it appears to be tied to Kernel Adiutor's apply at boot. Tried different startup delays too, similar result. If apply at boot is not enabled, then it boots fine.

The only options set to apply at boot include: cpu, hotplug, thermal, gpu, i/o, and wake.

So for now, just need to remember to unlock it after it's done booting, let it settle, then it's fine.
[X Style (Pure) Android Development] unitz0mbie:
what settings?6
[X Style (Pure) Android Development] dirtyhank:
Yep, if you enable DT2W when screen is off and Moto Display is active I can see how things can get messy. For the record, I don't have Moto Display enabled and it works fine.

I'll take a look and see what I can do.
[X Style (Pure) Android Development] gpz1100:
^^Moto display is disabled here too. In fact all the moto* apps are frozen in titaniumbackup.

Edit: Disabling the touch2wake enabled at boot doesn't seem to make a difference. I'm going to mess with other options to try to narrow it down.

---------- Post added at 03:31 PM ---------- Previous post was at 02:32 PM ----------

Update:

So rather than disabling each module I just wiped data for kernel auditor.

Then introduced changes into each module (cpu, hotplug, gpu, etc..).

It didn't take long. The issue occurred within the hot plug module.

I deviated from default in attempting to set the following.

min cpu online: 1

max cpu online: 6

max cores screen off: 1

This is the combination that caused the reboot issue if KA was not allowed to run after a reboot while the screen was still on.

Changing to

min cpu online: 2

max cpu online: 6

max cores screen off: 1

Result: Same, reboot

--------------

Changing to

min cpu online: 1

max cpu online: 6

max cores screen off: 2

Result: No reboot. Min cpu online gets reverted back to 2 . So for whatever reason, issues are caused when only 1 cpu is set for both min online and max cores screen off.

Question becomes, why is this behavior not present if screen is left on while KA is launching its apply at boot processes. The initial hotplus settings of

min cpu online: 1

max cpu online: 6

max cores screen off: 1

then stick successfully.
[X Style (Pure) Android Development] dirtyhank:
Thanks for the detailed report. I'll try to reproduce it on my device and take a look.

EDIT: I think I've found the bug. When the system goes into suspend mode and min_cpus_online_susp=1 the hotplug work is cancelled, but it's not if min_cpus_online_susp>1. In this case the default min_cpus_online_susp=2 keeps the hotplug work running but if you set min_cpus_online_susp=1 while the system is suspended (and that's what Kernel Adiutor does) next time you resume it'll try to resume work that was already running and freaks out.
[X Style (Pure) Android Development] gpz1100:
Got it. So is there a way of applying min_cpus_online_susp=1 and min_cpus_online_susp=1 at boot time without waiting for the system to fully boot/settle before suspending (screen off)?

I tried setting the KA delay to 80sec but same issue. Maybe some other method to implement this?
[X Style (Pure) Android Development] dirtyhank:
I guess you could do it via init.d scripts but don't worry I've already found a way to fix the issue, it'll be on next release. In the meantime I recommend that you either set the min_cpus_online_susp to 2 or make sure the screen is on when you set it to 1.
[X Style (Pure) Android Development] Fast_Zombie:
Hey, [MENTION=2400758]dirtyhank[/MENTION]. Have you seen this:

https://plus.google.com/+FranciscoFranco1990/posts/hK6VLVdCbwB

https://plus.google.com/+ArtemRussakovskii/posts/f1AyMaCTXQp ?

Could you look through the changes Google have made to 5x kernel please? Maybe there is something useful for our device as well.
[X Style (Pure) Android Development] dirtyhank:
Yep, I've already been testing some of those changes for a few days ;)

To be honest I haven't noticed much of a difference...
[X Style (Pure) Android Development] Fast_Zombie:
That's a bummer. :(

I really hoped, that this monstrous lag can be beaten at last.
[X Style (Pure) Android Development] dirtyhank:
What's you setup? I don't have have such a huge lag, although it's true my usage pattern is pretty light.
[X Style (Pure) Android Development] Fast_Zombie:
It doesn't depend on my usage, there are several places and cases, that will always lag:

1) scrolling through my timeline in Fenix twitter app, Play Store, Play Music and a lot of other apps with continuous scrolling.

2) if something is loading on the screen (circle progress indicator is shown) and I try to pull down notification bar, there will be a lot of stuttering, frames are dropping massively.

3) sometimes, apps are opening with a delay. I.e. Play Music may open for 5-7 seconds either without anything happening on the screen or with play music splash screen logo. Sometimes they don't lag and open instantly.

I'm using stock MM build, your kernel and testing different tunables for governors, including those mentioned in oppost and nexus 5x optimization scripts, but these parameters don't seem to do anything to above-mentioned issues.

I've been using Nexus 5 alongside with MXPE for a while and it was noticeably faster. As well as any device with Krait architecture, before Qualcomm began to experiment with big.LITTLE and reference Cortex design. :(
[X Style (Pure) Android Development] dirtyhank:
Mmm, I don't get lag in those situations you mention. All I've noticed is some minor stuttering when images are being downloaded while you scroll but not much else.

Definitely there's something wrong there. I recommend you do a factory reset and test a clean environment with just the basic apps. Use the performance profile in OP and play with ZRAM and UKSM if you notice apps reloading very often.
[X Style (Pure) Android Development] Fast_Zombie:
Welp, I've wiped it last week, when I was trying to install latest security patch. It didn't help either. Maybe, I'm just paying too much attention to all of this stuff. :)
[X Style (Pure) Android Development] saidmsb:
I noticed case no.2 along time ago and with different kernels
[X Style (Pure) Android Development] argenteloup:
Do you notice heat during that time? This phone does throttle sometimes, not the level like s810, but it is there.

Also, check your memory usage, if you have more than 1.7Gb usage, do a reboot.

Monitor your cpu usage, see if your setting is relying on little cluster too much. Lower your i/o read ahead value (I'm on 256kB).
[X Style (Pure) Android Development] Fast_Zombie:
No, no noticeable heat. I've owned Nexus 6p for a month or so, but there was no overheat as well. Comparing to Nexus 4 or Galaxy SII, those heat generators could heat up to 65°C just from Twitter scrolling on 2G. :D

I can't consider myself as a heavy user, I don't game on my phone, don't shoot 4K video, the only things I do day to day are Twitter, IM, light browsing and that's pretty much it. The results of memory usage are following:

Spoiler content hidden.

I am not sure, what's using that much RAM. :(
[X Style (Pure) Android Development] argenteloup:
From my using experience, this phone starts to throttle at around 43C. When it hit 45C, you will notice lags (the big cluster would only have maximum frequency: 900Mhz or 1200Mhz).

For the memory usage, I don't know what's going on over there, can it be memory leak?
[X Style (Pure) Android Development] Luhccas-X10:
There's a 0.9 version on android file host.

Anybody tested?

https://www.androidfilehost.com/?fid=24459283995297047
[X Style (Pure) Android Development] dirtyhank:
Don't bother, it was just a test, not ready for prime time yet ;)
[X Style (Pure) Android Development] dirtyhank:
Using a Nexus 6P can spoil any other device. I used a N6P for a while too and when I switched to the MXPE it was kind of a bummer. Actually that was my main motivation to start playing with the kernel, I wanted this device to be smoother. After 3 months I've come to love it, sure, it's still not as fast as the N6P but I like many things better. Not to mention it was way cheaper :)
[X Style (Pure) Android Development] Fast_Zombie:
Yeah, well, there was still some lagginess in 6p, compared to Nexus 5. I've ditched N6p because of its AMOLED screen. Just after a week of very moderate use, there were already some signs of burn-in, especially in the area of navbar. And there was this strange issue, when some dark elements on black background would have clearly visible "trails" when scrolling these elements (for example, someone's dark-grey round avatar in Twitter with black background would go "wobble-wobble" around the screen if you scroll). I just didn't want to figure out what would happen to that screen in a year or so, so I've sold it. :D

But, of course, compared to N6p, MXPE is way too laggy.

Sure, I see many bright sides of MXPE, it's build quality and materials used are just the next level, for instance.
[X Style (Pure) Android Development] dirtyhank:
Yep, I gave up on the N6P after 3 RMA over screen with pink tone areas. I noticed the tear and ghosting too. Pictures looked terrific but menus and solid color areas not so much.
[X Style (Pure) Android Development] gpz1100:
Battery Drain

For a while now I'm fighting with screen off battery drain. Even with powernap and not whitelisting google play and framework, I'd see 8-9% loss over a 7 hour period. For the type of usage my phone sees, I should easily get 3 days of battery with a good 30% or more remaining.

At whits end, I decided to try the stock optimized kernel in the rom in my sig. It lacks a number of features of this kernel but revealed a lot. The battery drain over a similar period was barely 2%.

This got me thinking, what settings were actually different. After much consideration, the most likely culprit was the double tap 2 wake setting. I disabled it, reverted back to moto display and performed more testing. The sleep drain was now very similar to the stock optimized kernel.

To make sure I had a good baseline, I disabled dt2w after restoring a backup image. Still need to retweak powernap and amplify settings for those didn't get saved.

So, it appears while this dt2w is really handy (more useful that moto display or ambient display IMO), the battery draw is unacceptable. Perhaps dirtyhank can further optimize it to be more battery friendly, but for now, I'm glad to have made some sense of all this.
[X Style (Pure) Android Development] elite001mm:
I have/had the same problem (scrolling in apps was painful to look at, etc.), but I eventually got it fixed.. Mostly. Here's what I am doing for anyone else who's interested:

OP I am truly not very knowledgeable about kernels but I am trying so please correct me if I say something dumb :).

First thing is I am using the "Butterfly" profile from ElementalX for the Nexus 5x (we share the 808 so it works quite well). EX Kernel manger (which is what I'm using) supports simply loading profiles from a file but you can manually input the data into other kernel mangers. This profile helps a lot of things with general performance and battery life (for me) has been great.

Second thing is to set the minimum and maximum CPU frequencies as far as they will go either way. So minimum would be 302mhz and Max will be different depending on which cluster you're setting it on. You'll have to change the governor to performance in order to change the settings for the big cluster most likely.

After that I would set the governor back to interactive for both clusters as interactive seems to run really well here. Hotplug options can be left alone. Disable input boost on all cores. For thermal I have msm_thermal enabled. Sync threshold frequency is 960mhz.

Now, after you've made sure your settings aren't going to cause a crash or something weird, set everything you changed to run on boot. Then reboot& let it settle a few minutes like twice. I don't know why but after I rebooted, it helped the smoothness out a lot. It still isn't One M8 smooth... But it's a hell of a lot better. Hopefully this works for others.. If not, I tried :D
[X Style (Pure) Android Development] dirtyhank:
That's weird, last night I lost just 4% over an 8h period with DT2W and S2W both enabled. Can you test it overnight and let me know the results?

Unfortunately there's not much I can do to reduce power consumption, the touchscreen must be always-on in order for DT2W/S2W to work. The are a couple of hacks that could help:

Implement some kind of timeout so the panel can be turned off when the screen has been off for X minutes

Turn the panel off if the power button has been used to suspend the device

What do you guys think about that?
[X Style (Pure) Android Development] jason2678:
My experience matches yours. I see 3 - 4% battery loss overnight. Enabling DT2W doesn't have a perceptible effect on it. It is working perfectly for me as implemented. I wouldn't really like changes that make it less useful.

There's something funny going on with idle battery life lately. The custom ROMs all lose 15 - 20% overnight. Now some folks are complaining about stock too. Personally I haven't let any apps update in a long time, and my battery life has been very consistent.
[X Style (Pure) Android Development] gpz1100:
I'm not sure what to say. My syncing processes are very limited, 2 email accounts (1 folder each), and googlevoice (for texts). I even left the phone in airplane mode so only wifi was active over night. Wifi signal is plenty strong, phone is less than 20ft away from the router.

Last night over a 7hr period it only lost 2%.

I'll do some further testing once I establish a good sleep baseline with the current optimizations - mainly powernap with google play and framework both *NOT* whitelisted but googlevoice and email whitelisted (k-@ mail). There's a few things I want to add to amplify that should help even more. Once satisfied and without making any further changes I can re-enable dt2w to compare.

Btw, interestingly enough, BBS is not indicating any dozing time. I think doze is part of the google frame work and is being blocked by powernap. Not a big deal as powernap gives much better granular control. If I don't need it to sync there's no reason for it to be running when screen is off.
[X Style (Pure) Android Development] HikingMoose:
Kernel has been pulled? The link isn't working.
[X Style (Pure) Android Development] SpasilliumNexus:
Open the post in a browser then try the link again. Tapatalk seems to be breaking most AFH links when opened from the app.
[X Style (Pure) Android Development] jason2678:
Have you considered not trying all that battery tweaking? I'm serious. This phone sleeps like a baby on mm if you just let it do it's own thing.

I've seen others say that amplify, greenify, etc. do more harm than good on mm, so I've never even tried then. They kill services and cause activity that just gets in the way of doze. The only app / mod I'm using is naptime. It tries to bypass the sensor timeout and get into doze as soon as you turn the screen off. Other than that 100% stock idle/doze configuration. I average around 0.3% - 0.4% / hr idle battery draw and that is with dt2w enabled.
[X Style (Pure) Android Development] ffejy462:
I have to agree. I was doing nearly the same thing as him, but battery drain was worse than plain stock. Foolishly I kept trying other battery saving modules/apps/kernel adjustments. Finally from frustration I just got rid of every battery saving method and, imo, you just can't beat doze (at least very much).

mxpe 6.0
[X Style (Pure) Android Development] guile50:
Yeah, I have seen that greenify does more bad than good, the hibernation mechanic makes the apps wake more the phone (I've collected some data from bbs, the number of wakelocks have doubled). But I have a question. Greenify has an aggressive doze feature,is it any good? Or power nap does it better?

Enviado de meu XT1572 usando Tapatalk
[X Style (Pure) Android Development] iprabhsingh:
After flashing this kernel, does it install any application? Because i can't see any app to change governer or underclocking the device.
[X Style (Pure) Android Development] guile50:
Download kernel adiutor.

Enviado de meu XT1572 usando Tapatalk
[X Style (Pure) Android Development] gpz1100:
@jason2678

Your suggestion is easy enough to test too. Just a matter of disabling amplify and powernap in xposed framework.

For now, it's being fairly consistent at .3% over night and minimal loss during the day. I'll give that a shot in a few days. I want to test out the ambient display first. Moto display is way too sensitive and triggers the display on at times when not needed.
[X Style (Pure) Android Development] dirtyhank:
Nope, use a kernel control app. See the OP for links to a couple.
[X Style (Pure) Android Development] dirtyhank:
Yep, I mostly agree. I used to run Amplify+Greenify with pretty aggressive settings and never got stellar savings. I ditched Greenify and switched to a milder Amplify settings and I'm happy with it. Now you mention I might even disable Amplify for a few days and see how it goes.

Have you noticed any side effects from using naptime?
[X Style (Pure) Android Development] jason2678:
Naptime will stop Pandora playback after the first song if aggressive doze is enabled. Sometimes it kills rbrowser downloads if i forget about it. Other than that, no trouble with it.

It's pretty quick to toggle on/off so it's not too much hassle.
[X Style (Pure) Android Development] gpz1100:
@jason2678,

What sort of difference did you notice by using naptime's aggressive mode?

http://xdaforums.com/member.php?u=5927992
[X Style (Pure) Android Development] jason2678:
It will depend on how you use your phone. Unless you've tweaked the settings doze takes 30 minutes with no movement and sensor activity to kick in.

My phone spends a lot of time on my desk during the day and in my pocket in the evening. Without naptime my phone would really only go into doze overnight because I either can't leave it alone for long enough or its always moving. With naptime I rack up some doze idle time even during the day.

I can't honestly comment on how much good it does. I've ran it almost the whole time I've been on mm, and I only had lp on this phone for a week or so. I do know I rack up a lot more doze idle time than I would by using it, and that can't be a bad thing.
[X Style (Pure) Android Development] dirtyhank:
Time for an update:

v0.9 (2016-03-20)

Update to Linux Kernel 3.10.101

Bug fixes

Changes from Google update to N5X and N6P

I've tried to cherry-pick the most relevant changes from the recent update Google made to Nexus 5X and Nexus 6P, and while most of the changes are pretty straightforward, one of them can potentially have undesired effects. I'm talking about the increased kernel clock from 100Hz to 300Hz, which in theory can help in making the system a bit smoother, especially under load. The problem is there could be some kernel bits that hardcode an assumed value of 100Hz and could malfunction with the new clock, yes, Google tried to patch such code as much as possible but we can't be 100% sure.

I've tested it for a few days and haven't faced any weird behavior but I'm not comfortable making it the default. This is why I'm releasing two kernel flavors, both are identical except v0.9 ticks at the default 100Hz and v0.9-300hz at, you guessed, 300Hz.

I recommend you install v0.9 first and only go for the v0.9-300hz if you feel adventurous. In such a case I'd appreciate your feedback about it, I have my own opinion but I don't want to influence your perception ;)
[X Style (Pure) Android Development] unitz0mbie:
Does battery drain increase?
[X Style (Pure) Android Development] dirtyhank:
You tell me ;)

Seriously, I'd rather have people feedback without any prejudice. All I'm saying is Google started experimenting with 1000Hz then switched to 300Hz.
[X Style (Pure) Android Development] urimevs509:
you mean 100Hz ?
[X Style (Pure) Android Development] dirtyhank:
No, 100Hz is the default for Android but Google decided to increase it and started testing 1000Hz internally (take a look at the linked commit).
[X Style (Pure) Android Development] Rocketval:
I think the question was Hz or MHz? :D
[X Style (Pure) Android Development] dirtyhank:
Ok, let me clarify then. We're not talking about the CPU/GPU/bus clock here, this is the system timer. This is used by the kernel to handle periodic tasks, so default 100Hz tick rate means that every 10ms the kernel will check for pending periodic work to be done (i.e. task scheduler). As you can imagine increasing this tick rate allows for quicker response.

For the technical inclined here's more detailed info: http://www.makelinux.net/books/lkd2/ch10lev1sec2
[X Style (Pure) Android Development] gpz1100:
Re: Tick rate. Sounds like this will improve smoothness and UI response. The question is, what effect will this have on battery - short term (while screen is on), and long term (screen off). Will be interesting to test.

@DH, Does this new .9 kernel have the hotplug change that was in the .9 that got pulled?
[X Style (Pure) Android Development] dirtyhank:
Afirmative
[X Style (Pure) Android Development] gpz1100:
Great. Thanks for confirming.

Was just reading about another google security patch a few days ago - https://source.android.com/security/advisory/2016-03-18.html

Is that what you meant by the google updates?
[X Style (Pure) Android Development] dirtyhank:
That security patch is already included in v0.9 ;)

The Google update I mentioned is the latest ROM+kernel update to Nexus 5X and 6P. Unfortunately many of the enhancements are at the ROM level so we can only benefit from some kernel changes.
[X Style (Pure) Android Development] gpz1100:
Always on the bleeding edge around here :)
[X Style (Pure) Android Development] somecro:
Noob question,but if I'm on v0.8 I just load this onto my phone,boot in TWRP then install the new version?
[X Style (Pure) Android Development] urimevs509:
yup...
[X Style (Pure) Android Development] Note 3 Chicago:
I downloaded 0.9 and it was the snappiest version yet. Downloaded 0.9-300 and it was actually laggier. I switched on GPU rendering and it's nice and smooth for the most part, but still a bit of lag here and there. Haven't noticed any adverse battery effects either. That said, it's only been a couple of hours and I want to give the kernel time to settle. However, if it stays like this after a couple of days, I may go back to 0.9.
[X Style (Pure) Android Development] Fast_Zombie:
Welp, after update to 0.9 with 300 Hz clock rate and it actually works better for me, than v0.8. I haven't tested with usual clock rate yet. Maybe I won't any way. As for battery life, I can't judge after 1 day, but it seems pretty average, I've got 2h45m of screen-on time on one charge to 13%. That's about the same SoT as I got on earlier versions of this kernel.