Rockbox

Next experimental version does set NORMAL_CLOCK to 15MHz (svn = 30MHz) to achieve better runtime for high efficiency codecs (like mpc and especially flac).

Remark 1: mpc-playback without WPS needs ~26.5MHz. With this patch the runtime is about 14.5h (svn = 14h).

Remark 2: flac-playback without WPS needs ~15MHz. I hope to see runtime >16h with this patch -- measurement will follow.

Remark 3: This patch is just to get an impression of the gui boost and to go ahead for the maximum possible runtime, it does not take any care about plugin-behaviour. This patch is no svn-candidate.

Remark 4: Should also work for non-iPod PP-targets.

Additional small patch attached which disabled the lineout of the WM8758 which is used in 5G (no_lineout_v01.patch). Through this another 0.5-0.6mA can be saved -- of course only if you do not need the line out at all.
--------------------------------------------------
Battery bench results with gui boost (@15MHz) and disabled lineout (details attached):

MPC:
overall = 14:24h
90%-10% = 12:09h

FLAC:
overall = 12:46h
90%-10% = 11:10h

FLAC saves a lot of current via very low CPU-usage (~4mA vs. MPC), but needs a lot of additional current for the buffering from HDD (~7.5mA vs. MPC).
--------------------------------------------------
Attached a 3rd version of gui boost with 24MHz normal clock -- as this seems to be more effective than running @15MHz normal clock (gui_boost_v03.patch).

Using the 24MHz version fo the gui boost + lineout disable:

MPC:
overall = 14:42h
90%-10% = 12:31h

(for a 5.5G 30GB of course)

updated patch against svn.

updated patch against svn.

Is this something that is intended to eventually be committed, or is it a more base work that uses techniques that wouldn't be approved in the normal builds? I'm asking because I do think this would be very useful, and it seems like you've done good work here (you know, because you NEVER do good work). Do you want/need people to test it for you? Now that I actually know how to patch and junk, I'd be glad to help out if I can. Even if it's just simple stuff (actually, that's probably all I'm capable of at this point).

Let me know!

Hi, any test efforts are welcome. Of special interest is the behaviour when using plugins (e.g. games). Is there any sideffect visible through the boost/unboost after short scrollwhell activity (unboost happens 1s after last scroll-activity)?

I'm beginning to test this now. The only thing I've noticed so far is when you start to scroll when it first boosts it tends to be a bit jerky at first. This may be just me getting used to the wheel responding so much better though. I'll make a point to put it through the motions in plugins and get back to you. I went ahead and included this in the build I put out so if there are any really negative side effects I'll know shortly. Just so you know I really will be scientific about this :-), if I have bug reports I will reproduce them in a build with only this patch first before I bother you with bugs that have nothing to do with this patch.

All right, after testing all plugins, here are a couple that were affected by this patch: Brickmania, bubbles and spacerocks were the most obviously borked games... all three became more jumpy (or maybe just erratic) when using the scroll wheel to move around. In terms of demos, many of them would speed up for a moment when I scrolled. Plasma is probably the best example of this... upon scrolling, the animation goes into overdrive for about a second (the amount of time the cpu is boosted). I wanted to test pictureflow, but haven't yet as my database isn't currently enabled. I'll test it later if tdtooke does not.

I hope this is helpful, let me know if you want any more tests run.

Thanks for testing. This leads to the assumption that I might take some time to check the possibility to only boost when in list-context... I'll be back :)

You may or may not want to also let it apply to the WPS context, as well. It might be useful in making volume changes or whatnot more robust, but I can't recall how that worked out in testing.

Pictureflow is very jerky as well with this patch so sticking to list context and maybe WPS context might be the way to go.