yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Just added a nice improvement to the audio driver ;)

Previously I had picked up a change from Wahoo, that would allow clients to upgrade priority for pcm playback on LOW_LATENCY_PCM_MODE (this path is what any app that cares about making sure it's buffers/playback arrive on time will use... system sounds, etc don't use this path ~ proaudio apps do. Possibly apps like Duo / Voip might too, idk yet).....

However, one thing that I didn't underand (midly baffling actually); Why didn't Google Kernel Devs or Qualcomm implement this for pcm capture (recording)...wtf??? => There are definitely apps that would prefer to have less of a delay on capture....

So I decided to implement it myself; it's incredibly simple to do (it's literally copying/reusing a few functions, definitions, etc... pasting them and changing a few bits so that the functions are to be used for TX (transmit) instead of RX (recieve) - and then injecting the calls into the msm_pcm_capture* functions....

Turns out; it works really well! ;) ... For my test case - I installed an app called LoopStation. This app requires that you calibrate it, so that any delay in recording; will still be synchronized on playback with the metronome.... * before applying my changes; there was a delay and I would need to align the waveform to the metronome.... * But after making the necessary changes; I wouldn't even need to calibrate the app at all ~ It's nice and synchronized all on it's own....

This could benefit a variety of apps ~ but I'll need to find more examples. It shouldn't break anything either - as it only affects apps seeking low latency on record.... I'll give it a good round of testing before adding it to any build, for sure.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Will I have been running the test build, I don't know if it's a placebo effect but switching between the 2 kernels the test kernel my 3d games take longer to open but once running all is good and no problems with anything else.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
hmmm. so switching between causes them to take longer to load, or ton the test kernel specifically, they take longer?

if u point me to a particular game, I could have a look.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
It's any 3d games if you could point me to how to time, add I say it may just be me.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
not sure there is any point in you timing an app's startup time... what would that accomplish?. ... it wouldn't give me any useful info...

that's why I asked for a specific example. I can run the app and look at where the kernel is spending it's time, when launching the app... I'm not really inclined to teach u how to use a bunch of linux specific tools for analyzing the kernel....I could just do it myself, far quicker and my linux box and my own test build (with more debugging enabled than your test build) are setup for this kind of thing....

so if it isn't just you and u think something is up and it's not a placebo, give me something to look at specifically and I will have a look. thanks. ..
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
k. well, i'm not a gamer... but i did have that one game installed b4 dawn of the titans... i had renoved it, so i re installed it....

first startup; slow / setting up...

2nd startup and every startup after; fast...

i can check against your test build. but i haven't touched any.code on my current build that would make any difference (i'm hacking on the audio driver, that's it)...

so ya, u are going to need to point me to a good example of this slow down. obviously, i would be concerned if this is a regression.... so i'd like to have a look...

i juat don't want to be downloading a bunch of random apps/games from the play store. that's why i asked for a specific example. a good one. ?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=5502224]siheals[/MENTION]

I think I might have a clue to what the slow down might be - but I'm going to have to rollback and test certain ranges of commits ~ if the test build is giving you issues - you can always switch back to the stable release.... test builds are tricky sometimes.... and that one contained a lot of new code....

anyway, I'm going to go through some commits over the next day or two and see If i can get that sorted out.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
NEW STABLE UPDATE: * OP download link.

Changes:

- Linux3.18.84 lts

- Audio driver tweaks

- init rc no longer sets io scheduler persistently

- a few other misc cleanups in the init rc

- Dynamic Stune / Cpu-Boost Defaults:

# Cpu-boot / Dynamic Stune Boost

write /sys/module/cpu_boost/parameters/dynamic_stune_boost 15

write /sys/module/cpu_boost/parameters/input_boost_enabled 1

write /sys/module/cpu_boost/parameters/input_boost_freq "0:0 1:0 2:0 3:0"

write /sys/module/cpu_boost/parameters/input_boost_ms 1500

These are persistent on reboot, but only for the next few releases ~ I need to be able to gauge Battery usage and If I don't set defaults - people will be reporting all sorts of conflicting results.... but yeah, this is temperary. NOTE: you can still change them, but they will reset on boot && don't report BatteryStats in the thread, if you have changed them - or at least mention that fact... * because, the gist is;

the higher the Dynamic Stune Boost and input_boost_* values - the more you are biasing performance

The lower the values; the more you are biasing Battery life.... So no need to point that out (I just did. lol).

I'm still working on the test build - I've resolved a couple of issues but there are other things to address yet. This build is NOT based on the test build ~ It's the stable build with LTS and a few tweaks. I'm just pushing it, because it mainly addresses some init rc stuff and has the latest LTS.... thanks
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
Ok, so I was on the latest test build for a couple of days, and I found few areas where the phone stuttered a bit. Chrome was one that I mentioned previously. App switching through double tapping recents also caused frame drops at times. Swipe gesture to open app drawer on pixel launcher was not smooth either. Scrolling in gmail was choppy too.

But, having said that, i don't believe everyone else has also been seeing similar performance regression. No one reported, and I believe, these issued couldn't be escaped from dev's attention either. So I'm assuming it's something's from my end. Though I haven't Installed any app, or changed any settings over the kernel change, I'm planning to go for a clean flash and test your stable built first.

Again, thanks for your effort and time. Post job, I need a free evening to do clean flash :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Sorry for not replying sooner I have been really busy... The scrolling seems smoother with maple scheduler, but the initial app loading and switching are there.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
yup. there are a few places where the test build is contentious. The code merged in still needs some work. So I won't have another test update, until I get the scheduler/locking code fixed up / problems resolved... I've noticed some stuff like that, as well... but these things are tricky, so I won't be pushing another build too quickly.

That could be (on Maple). Just know, that I won't be putting any effort into hacking or testing on Maple Io Scheduler - If i do see some changes that might be worth merging in, from elsewhere _ I may look at them ~ but I'm not interested in becoming heavily invested in working on IO schedulers ~ there are smarter people who already do that upstream linux.... Maple is also very downstream and I can't afford to put much time into it. Unfortunately....

The loading times are due to lock contention (where there shouldn't be any). I'm looking at it, but it'll take a bit to resolve. Use the stable build, if it's a problem for sure... I'll let you know when I've got a new test build...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Just as an side; I decided to add a donate/Pay Pal button to my account. The reason?

Well, like so many other XDA / android kernel developers; all of the hard work and effort that I've put into this kernel is done in my free-time. While I do enjoy working on exNoShadez-eas and providing my work to others => It *is* a lot of work and at times very frustrating, especially when issues crop up -> or when I am trying to integrate new code or features touching certain parts of the kernel. (crazy amounts of hours working on it)

So, I decided that I too would add a donate button. It's definitely not mandatory to donate, by any means - but If you want to or can afford to; Go for it, as it would be very much appreciated... Having a few cups of coffee paid for (which I drink lots of, especially on late nights/early morning hacking on this kernel), contributing/donating because you feel that this Kernel is working nicely and adds value to your Pixel and/or because you feel that my development time and effort is worth something => would be great reasons to throw a buck or two in my direction....

Regardless, I will always continue to develop and work on this kernel and this will be the one and only time that I mention PayPal/donations in the thread. (I did add a ref at the very bottom of the OP though)....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
* tiny update

So I've gotten in touch with the upstream/Mainline linux mm subsystem maintainer ~ He's been kind enough to give me some advice, things to try, where to look; regarding the missing mmput_async() function that I need to implement the last few changes in Binder.

This is great because I had pretty much exhausted most other resources (mailinglists, android kernel dev groups, etc)... So hopefully, later or tomorrow - I can try to get to the bottom of it and finally get this code merged into Marlin/Sailfish... I've spent enough time on this bit - and it kind of drives me nuts - but it's something that should be put into the kernel - will improve Binder and allow some further changes / improvements... So here is me hoping it works out...

*also working on some other driver changes, for ones that hook into ION. should yield some improvements, if I get it right. few other tweaks coming to the stable build, most likely too.... next big test build won't be for a bit ~ still working on that - but focusing on getting a few bits into the stable kernel, as the next monthly firmware updates are coming and I'd like to get a few changes in for that release.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
The latest test kernel is working very well, no problems at all, running 3d games and playing music at the same time all is good. Can't crash camera. Works well very smooth.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
No, Coldplay96 - That doesn't mean something might be wrong with the kernel.... that very much has to do with EAS, scheduling and the bias towards power-saving on idle.... It's incredibly easy to demonstrate; All one has to do is put the system under load and then scroll on settings again and it will fall well- below the line...

You know, It sucks that you re-locked your phone and bricked it. But That wasn't my Kernel's fault - and I didn't appreciate you not only ignoring me and other people in this thread - when we told you that it was bricked and that you would need to contact Google. Instead, you started another thread with the title "HELP!!!!!! Locked bootloader after flashing a kernel and it doesn't want to boot" ~ but that isn't what happened, what actually happened is that YOU messed up your phone, because you are clueless => ref: https://xdaforums.com/pixel/help/help-locked-bootloader-flashing-kernel-t3708242

I suspect that you are now posting here again, suggesting that something is wrong with my kernel because you have some agenda.... But hey, go ahead and explain to me in all of your infinite android wisdom ~ as someone who locked their phone running non-stock firmware, exactly what is "wrong" with my kernel. be very specific ~ it would also be helpful, if you could point me to specific commits on my github ~ So that I can fix all of the problems you see to your liking. Thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
It was indeed my lack of research that bricked my pixel. If I sounded angry or "triggered" I would like to say that it never was in my intentions and I hope your kernel will turn out great.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I'm still waiting for you to explain what is wrong with my kernel and also for you to point to commits on my github that I should be fixing...

you can't go around shooting your mouth off and not back it up... You've suggested there is something wrong with my kernel - please back it up...

and yeah, "lack of research". sure.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
Look, I don't want this to get heated up. I made a mistake by mentioning that there might have been I problem with your kernel and I was is the wrong. Since I am no developer myself, I cannot do the things you ask from me. I deleted my previous posts.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
It's not going to get "heated up". I've explained why GPU profiling shows what it does.... It's expected behaviour at this point and a trade off.... and there's no point in deleting your posts; I've quoted them anyway. ~ so they are permanent.

While there may be kinks or bugs to iron out with my kernel ~ The same is true of any kernel, including stock... I've fixed bugs that exist in stock. An example: Stock kernel not setting the sample rate / buffers correctly with some apps... I also pointed out / fixed a bug in Kirisakura-Harmony_O recently, which is fixed in his latest release too.

and yeah, I know your not a developer.... you're a noob.

*** And just on a general note [MENTION=1007992]everyone[/MENTION] who may be reading this:

Please do not misconstrue my replies to Coldplay96 ~ He's just done a few things that rub me the wrong way (which I have cited in these last few posts)... I *strongly encourage pointing out issues*, as you bump into them. There is always room for improvement and by no means is my kernel perfect. ~ We are after all, running all sorts of code that has been ported / never intended by google to be running in Marlin's kernel.... On top of that Binder_rt is very much an experimental implementation; although, at this point - it has become very stable (unlike my initial implementations / experiments with it. LOL)...

That all said; The stable releases, should be quite stable - which is why over the last 2 releases - I've only been making incremental changes - rather than rushing to integrate some of the code that I'm running and testing that may be unstable (like in the test builds). I plan to keep the stable releases in good shape, very conservative changes ~ until new code is well vetted....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Hey, I just have a bit of an update on this (at least on the Stable build)...

I actually just did do a fresh install, yesterday (as I gave 8.1/DP2 a quick whirl, before coming back to 8.0). I can't reproduce any of these symptoms on the Stable build. ~ Pixel Launcher, Chrome, etc are all very smooth...no choppiness in Gmail, either... I've changed ZERO settings from my defaults... So I have to assume that's just the test build that was affected....

I did however, read a post recently where someone was experiencing lag with pixel launcher and it ended up being some app that they had installed that caused the issue - I should see if I can find the thread. ( I should've bookmarked it yesterday ,but wasn't thinking. Doh! ;) )

Other possibilities (of instability) might include how you update ~ OTA updates "patch" your system (differential) vs. full firmware updates which wipe your /system partition and replace it with the the new one contained in the monthly firmware images. Note: I don't use OTAs (and never would). They can introduce subtle bugs, especially on systems that are modified. TWRP has a bit of a write up on this; https://twrp.me/faq/officialota.html

and of course; the test builds can be unstable / the last one was.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So i'm getting ready to test and commit some more audio driver changes backported from Wahoo/Pixel 2 ~ these ones shoul put us in-line with Audio performance / low latency that the Pixel 2 has... I'm pulling in the remaining changes where rt scheduling is used throughout their updated driver.... by default, on Pixel 1 /stock, we have about twice the latency of Pixel 2 ~ so audio tends to glitch out quicker.

ref: https://juce.com/maq

If you look over the figures, you will notice that the Pixel 2 is closer to the performance typically found in iOS devices, while the Pixel 1 (better than most android devices - still could use some improvement). So here is hoping that these additional changes will help improve our audio driver to the point where it is closer to where I think it should be. some of these changes are requiring a bit of effort to backport ~ they need to be fixed up to match our driver, there are differences in the Pixel 2 driver... lots. ~ so this is kind of manual work for me..
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Thanks [MENTION=5502224]siheals[/MENTION]... Yeah, I haven't had any problems on the Stable build - I have an encouuntered one or two rather ancient android audio apps that I can crash - but they are corner cases, unmaintained and badly written. So not exactly anything that I care about trying to support. (and I'm not even sure the crashes are caused by any of my code - I think it may be due to some upstream ALSA code brought in recently).

Just an fyi - i _may_ end up updating the Maple IO scheduler, which obviously you would be happy about. - but *after* the december firmware update - there are patches floating around for Maple - looks like they won't be hard to merge, either.... I just don't want to introduce them on on the monthly update ~ they can be applied and tested right after....

I'm mainly focusing on ironing out the audio driver improvements (top priority) and want to apply some gcc-6/7 fixes that I just haven't gotten around to applying / fixing, due to being focused on other stuff. (When I originally rebased my kernel - I didn't bring in a few gcc fixes that I had in my old branch, plus I had revert a patch - and by doing so; introduced a few harmless warnings too.... most of the time people using gcc-6+ just turn off these kinds of warnings - but I try to fix as many as possible - there are a few that still show up during compilation (because of the warning flags that I currently have enabled), So cleaning up those bits while functionally changes zitch; still should be fixed up....

So the above is what I'm lining up for the next stable release
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION] - I'm probably going to add WireGuard (VPN) to the kernel;

https://www.xda-developers.com/wireguard-vpn-project-support-android-roms/

I've actually already added kernel support / commited in github.... and all of the userspace configs / binary are in place - just gotta find a VPN that supports WireGuard and give it a good test... Pretty cool stuff
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Nil253259:
So out of curiosity I just flashed 8.1 last night. It's slightly more polished. There are hints of micro stutters here and there (yea, I'm a performance freak, and don't care much about battery), so I'm gonna be back on 8.0 with a custom kernel real soon.

No, I don't dirty flash OTAs either. More often than not I clean flash security updates too. When I'll be back on 8.0, I'll do a clean flash, with your stable latest on top.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
cool, I was just pointing that stuff out - good for people to know the difference between differential updates VS. doing a full wipe of the system partition. (although, obviously you knew the difference).

I strive for both performance and battery life. it's just hard to do; there are always going to be tradeoffs. So it's kind of a matter of what one can live with. I don't mind a frame drop or two on idle, I'm more inclined to be concerned if the device doesn't perform well under load, or if cpu frequnecy scaling causes glitches. (in particular, this bothers me if it happens on the audio pipelines).

I'm actually testing some settings changes for Schedutil that might improve that area - I was catching up on some reading (of LKML) by the author of some of the Schedutil patches ~ and he seemed to hint that the defaults for a couple of Schedutil's sysctls may not actually be ideal for mobile use ~ So i'm testing some tweaks that might improve things, while hopefully not having a real impact on Battery life.... it'll take a few days to gauge though...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So, Audio driver hacking, some interesting results;

I'm currently testing some of my audio driver backports / improvements. It's hard to do laboratory type tests, but I can do more real world tests, that involve hitting the audio stack pretty hard on the Pixel.... The real word tests are probably more important anyway - since they also include interactivity (meaning surfaceflinger could be sucking up some cpu-time, touch inputs, etc.... For my tests, I'm using Beatonal - for two reasons;

1. I can measure xruns (buffer underrruns) in realtime

2. It is an app that uses a boatload of cpu / processing

I set my device in Performance mode with the Performance CPU governor set as the cpu governor ~ this is to avoid any cpu scaling; I'm after sustained performance and CPU scaling degrades performance, in particular for proaudio apps (and games to some degree)... Audio is very sensitive and cpu scaling causes audio glitches.... So the cpu frequencies are spiked to max (note: this obviously causes battery drain)....

Additionally, I am running an app in the background that is using "background playback" ~ to further strain on audioflinger / audio driver. The results are quite excellent, aside from a few initial xruns when loading some files, no more xruns occur. The screenshot is Monitoring in beatonal for buffer underruns

In the test, I am using the maximum amount of voices + effects that I could produce = very high load. NOTE: While the screenshot says 14 voices - it actually spikes @ 20+ voices.... The same is true of CPU spikes - they go much higher than 1.05... effects are set in such a way that they are chewing through buffers (long very reverb times, sustained delay effects, modulators, etc, etc).

* This is much better than stock
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Warrimonk:
I bet any money that it has to do with having stock recovery installed instead of TWRP. I am going to try a few things and report back.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
maybe, but I still flash it through TWRP, like so;

# adb push '/home/ninez/android/EX_NoShadez/AnyKernel2/exNoShadez_eas.zip' '/sdcard/exNoShadez_eas.zip'

# fastboot boot '/home/ninez/Downloads/twrp-3.1.1-1-fastboot-sailfish.img'

and then in TWRP -> Install -> select zips -> exNoShadez_eas.zip + magisk-14.3.zip

reboot
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Warrimonk:
Exactly. You are still using TWRP (from RAM) to install the kernel but you are not yourself actually installing TWRP which takes up additional space in the boot image and patches the boot image as well. By running it in RAM like you do, this leaves more of the partition available to write space into.

Still testing this theory though. I am downloading a few OTAs and factory images.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Keasby:
Here is the link to my bootloader.img:

https://www.dropbox.com/s/5ljs39lib3yquwz/bootloader-sailfish-8996-012001-1708111029.img?dl=0