Rockbox

Where does this leave  FS#9800  - Zero-wait boost for PP502X ? In all my testing I never had any issues with that patch.

 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.

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.

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.

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).

No bands, simply 5 dB of cut.

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.

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.

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.

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)

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).

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.