Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#10180 - Better runtime for PP502x target through running at 24MHz

Attached to Project: Rockbox
Opened by Andree Buschmann (Buschel) - Friday, 01 May 2009, 14:59 GMT+2
Last edited by Andree Buschmann (Buschel) - Sunday, 27 September 2009, 21:21 GMT+2
Task Type Patches
Category Drivers
Status Closed
Assigned To No-one
Player Type PortalPlayer-based
Severity Low
Priority Normal
Reported Version Version 3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

This is a very old idea which was discussed a lot. One of the major issues with running at lowered normal clock was the perceived GUI slowliness even at 30MHz -- especially the iPod Video was affected. After a fix / optimization by amiconn in r20242 I would like to have some opinions about how to proceed.
- Do you feel the GUI is fast enough even at 24MHz now?
- What target do you use?

The advantage of this change is that we will save ~2mA during playback when using highly efficient codecs like mp3, mpc or flac. This gives up to 10% more runtime (depending on target and settings).
   24MHz_v01.patch (1.2 KiB) 
 firmware/target/arm/system-target.h |    4 ++--
 firmware/target/arm/system-pp502x.c |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

This task depends upon

Closed by  Andree Buschmann (Buschel)
Sunday, 27 September 2009, 21:21 GMT+2
Reason for closing:  Rejected
Additional comments about closing:  Needs GUI boost which is already handled in  FS#8668 .
Comment by MichaelGiacomelli (saratoga) - Friday, 01 May 2009, 17:56 GMT+2
Where does this leave  FS#9800  - Zero-wait boost for PP502X ? In all my testing I never had any issues with that patch.
Comment by Andree Buschmann (Buschel) - Friday, 01 May 2009, 18:43 GMT+2
 FS#9800  has the advantage of zero-wait. This will be needed if we decide to boost/unboost with high frequency (several time per second). For the current concept it is not needed -- but of course not harmful. The disadvantage is that  FS#9800  just changes the clock post dividers -- which ties us to a 1:2, 1:4 or 1:8 relation between normal and boost clock.
I am in favor of keeping the freedom for using whatever clocks I like. At least until frequent boosts/unboosts need the zero-wait.

But independent of the difference of both this and  FS#9800  the general question is: Is the GUI fast enough now on unboosted PP-targets with lowered clock.
Comment by Thomas Martitz (kugel.) - Saturday, 02 May 2009, 16:41 GMT+2
Well, scrolling through lists feels *very slightly* slower, but that may just be my impression (since normally don't pay attention to that). But it's definitely not slow enough to reject 10% more battery life. So yes, I think the GUI is fast enough.

I think the most critical target on this issue is (and will always be) the ipod video. If these are considered fine, all other targets with a smaller screen can be considered as fine too.

Edit: forgot to mention, e200 here.
Comment by David Hall (Soap) - Sunday, 03 May 2009, 06:17 GMT+2
FWIW I can still stutter (mp3) playback when scrolling large lists with current SVN on my 5G. This is with dircache enabled and using the defaults when it comes to theme (font size), clock (30 unboosted), etc. The only additional CPU overheads on my 5G 60 GB are replaygain, crossfeed, and a -5 dB EQ pregain, all quite processor unintensive to the best of my understanding.
I'll try the 24 Mhz patch when I get home, but if current behavior is not what I would consider ideal.
That said, I love battery life, but would trade 10% to remove this (stuttering) behavior, as I think it gives a (false) perception to the masses that Rockbox is glitchy.
Comment by Thomas Martitz (kugel.) - Sunday, 03 May 2009, 06:52 GMT+2
Crossfeed and EQ aren't unintensive at all in my experience. Crossfeed can add 10MHz (no mp3 file runs unboosted with replaygain and crossfeed on my e200).

The EQ is even worse, particularly if you have all bands activated. Using all bands can easily get you to 80-100% boosted in some cases (observe the system->viewbuffering thread screen).
Comment by David Hall (Soap) - Sunday, 03 May 2009, 07:18 GMT+2
No bands, simply 5 dB of cut.
Comment by MichaelGiacomelli (saratoga) - Sunday, 03 May 2009, 16:28 GMT+2
Stuttering is probably just it not yielding enough in whatever code handles list drawing and update. I don't think it should be related to the core clock speed, though lowing that may make it worse (because theres less clocks at times) or better (because we'll boost more frequently). On a side note, this annoying inter-dependence between CPU clock, codec performance and GUI performance is a great reason to keep looking at zero wait boosting and maybe boost on gui in the future.
Comment by Andree Buschmann (Buschel) - Sunday, 03 May 2009, 17:19 GMT+2
Yes, we should still find the golden GUI boost solution -- with or without zero wait boost. But until then we should not hesitate to take an intermediate step and simply change the normal clock on PP. Of course we should only do so if the GUI performance is acceptable.
Comment by Thomas Martitz (kugel.) - Sunday, 03 May 2009, 17:21 GMT+2
Stuttering is a common problem if you use the eq extensivly (at least I'm noticing it too). The EQ is quite CPU intensive so that even mp3 tends to not be 120% real-time anymore.
Comment by MichaelGiacomelli (saratoga) - Sunday, 03 May 2009, 17:32 GMT+2
At least for soap, I don't think using the EQ precut or replaygain is CPU intensive though. Looking at the code, both are implemented as a single 64 bit multiply. Although I'll look into asssemblerizing it for speed later. Crossfeed is probably a bit slower, looks like 8 fixed muls per sample pair, plus adds memory operations, probably about 3-3.5 MHz total cpu use. (for ARM7/9tdmi)
Comment by Boris Gjenero (dreamlayers) - Friday, 08 May 2009, 00:55 GMT+2
When a list fills the screen with text (both horizontally and vertically), scrolling feels too slow at 24 MHz on my 5G 30 GB iPod. It certainly usable, but the delay between what I do and the display is bothersome, and it slows me down a bit.
When the lines are shorter and/or there are only a few lines on the screen, I can't complain. For example, the main menu is fine.
When an MP3 is playing, Rockbox boosts soon after I start scrolling, and so scrolling becomes fast. It certainly isn't much easier to cause stuttering; I'm not sure if it's a bit easier.

I like  FS#8668  (gui boost).
Comment by MichaelGiacomelli (saratoga) - Friday, 08 May 2009, 01:01 GMT+2
Perhaps a better approach to this problem would be to build on  FS#9800  (which defaults to 20/80MHz) and then simply add a few boost calls to list drawing so that its responsive enough.

Loading...