Rockbox

Tasklist

FS#9797 - Zero-wait boost for Iriver

Attached to Project: Rockbox
Opened by Björn Stenberg (zagor) - Tuesday, 13 January 2009, 20:07 GMT
Last edited by Marcin Bukat (MarcinBukat) - Sunday, 05 June 2011, 11:21 GMT
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Coldfire-based
Severity Low
Priority Normal
Reported Version Version 3.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Currently, boosting on coldfire involves waiting for PLL lock which can take as much as 10ms.

This patch changes the boosting to just toggle the clock divider and not change the PLL frequency, and thus not having to wait for it to stabilize. This makes the boost near instantaneous.

The MCF5249 docs can be interpreted to say you're not supposed to do this, but they are not conclusive. My limited testing showed no side effects so far.

In order to get clean clock dividers, the patch also changes the operating frequencies from 124/45 MHz to 112/22 MHz. The "default" (idle) frequency is unmodified in this patch and still uses PLL bypass, but is used so rarely it shouldn't have much impact.

Zero-wait boost opens up possibilities for more efficient cpu management in Rockbox. Coldfire is the only platform where we are not sure this is possible.

Ideally, someone who uses an Iriver player as their daily player should run this patch and see if any side effects pop up.
This task depends upon

Closed by  Marcin Bukat (MarcinBukat)
Sunday, 05 June 2011, 11:21 GMT
Reason for closing:  Out of Date
Additional comments about closing:  Old, and with our current power management implementation doesn't gain much. Another point is that pll lock time stated in documentation is worst case scenario and usually pll is locked pretty fast.
Comment by Björn Stenberg (zagor) - Tuesday, 13 January 2009, 22:19 GMT
The patch actually only affects iriver currently. I'll update it for iAudio if anyone wants to test on those aswell.
Comment by Steve Bavin (pondlife) - Wednesday, 14 January 2009, 12:09 GMT
H300 here - two problems:

1) I'm getting 15.4% boost ratio playing MP3s (just CBR 128kbps). I'm using album art with default WPS if that's relevant. Will compare with SVN later today, but I don't think I had to boost at all before.
2) Atter initial boosting at boot has completed, I have a boost count of 0 but the CPU frequency is at 112MHz (both according to the debug screen).

Comment by Björn Stenberg (zagor) - Wednesday, 14 January 2009, 16:06 GMT
Neither of those are actual problems. The "normal" cpu speed is with the patch less than half of what it is in SVN, so a bit of extra boosting is to be expected.

The boosted cpu speed is changed to 112 MHz, to get clean and simple clock division. It will be optimised later if we decide this is a working solution for boosting.

What I'm really looking for is serious side effects such as crashes, freezes, misbehaving timers etc.
Comment by PaulJam (PaulJam) - Thursday, 15 January 2009, 00:20 GMT
I'm not sure if all the issues are related to the patch, but while trying the patch i noticed the following inconsistencies during playback of a shuffled playlist using crossfade:

At some point during a track transition playback began to become slow and choppy (audio seems to drop out multiple times per second). In the buffering debug menu the pcm was almmost empty (it always filled up only a little bit and ran empty again). The boost was below 20%. After some time the player froze and required a hard reset. This happened only once so far.


There are sometimes little audio dropouts shortly after track transitions (when using crossfade and a WPS with peakmeters they seem to be more obvious).
I think a quite reliable reproduction recipe is to turn on crossfade and select the rockbox_default theme (not cabbiev2). Then play a playlist/folder of mp3 files and a few seconds after a track transition skip back to the beginning of the track. Then there should be dropouts. (I was not able to reproduce this with a clean SVN build.)
attached is an audio sample of those dropouts.


Ocasionally there was a short droput after fast forwarding or when the disk spins up for rebuffering.


H300 with r19771
Comment by Marianne Arnold (pixelma) - Thursday, 15 January 2009, 01:56 GMT
The first thing that caught my eyes when trying on my M5 was the unstable time display - in the statusbar as well as in the WPS ("--:--" shows in the statusbar instead of the time; unregularly and for a different amount of time, at least during playback). Second thing is that button presses are sometimes not registered and there were two occasions where the M5 shut off after a simple button press (once "play" and the other "rec") while switching off is usually only triggered by holding "power" as on the X5. Didn't test playback long enough yet after this experience to be able to say something about it, nothing too obvious in the short time I tried (not sure that after the first negative impressions, the higher amount of "static" I thought to hear was only in my head or not...)
Comment by Jonathan Gordon (jdgordon) - Thursday, 15 January 2009, 06:19 GMT
ok, I'm running this patch on my CF modded h300 and doesn't seem to be having any real problems, what is annoying is that the default speed is too slow for browsing the filetree... If music is stopped then there is no (or almost no) acceleration in the list, and if music is playing its very obvious when the cpu gets boosted (acceleration jumps around a bit... fast then none)

I haven't noticed any problems with buttons or the time (but the time isn't on my WPS...)

the plan is to boost more often in the GUI after this patch is in yeah? so my problem will be fixed later?
Comment by Steve Bavin (pondlife) - Thursday, 15 January 2009, 07:31 GMT
I'm also noticing short audio dropouts after track transition - maybe album art loading?

How do dividers work? I suspect 22MHz is a little too slow for "unboosted", or we're going to need more forced boosting.
Comment by Björn Stenberg (zagor) - Thursday, 15 January 2009, 12:24 GMT
Yes, it could simply be performance problems causing the gaps.

I'll look into adding a flag that is set if the pcm empties unexpectedly, plus a display of this flag somewhere in the debug menu. That would show if audio dropouts are due to insufficicent processing power or it the glitches are somehow caused by the new clock manipulation.

The reason I use these slow clocks instead of higher speed is that they are directly compatible with the various timer initializations already used, and I didn't want to have to recalculate them.

Another test is to use 56MHz as the "normal" clock. It uses the same PLL speed as 112 and just divides with 2 instead of 5. I'm attaching a patch for that to this comment. (Apply instead of parent patch.)
Comment by PaulJam (PaulJam) - Thursday, 15 January 2009, 19:17 GMT
With the 56MHz version of the patch i haven't noticed any audio dropouts or other unusual behavior.
Comment by MichaelGiacomelli (saratoga) - Friday, 16 January 2009, 01:41 GMT
>How do dividers work? I suspect 22MHz is a little too slow for "unboosted", or we're going to need more forced boosting.

From the point of view of battery life, we want as slow as possible, and then to make time critical code boost as needed (GUI, buffering, etc). This way only as many clocks are used as are actually needed.
Comment by PaulJam (PaulJam) - Friday, 16 January 2009, 14:25 GMT
Not sure if this information is useful, but the dropouts with the 22Mhz version of the patch seem to only happen with mp3 files. When testing AAC and Ogg Vorbis with the first patch I haven't noticed any dropouts even though those formats are more CPU intensive than mp3.
Comment by PaulJam (PaulJam) - Monday, 19 January 2009, 14:28 GMT
Some more observations with the 22MHz version of the patch:

The following procedure* seems to produce all kinds of weird behavior when playing back mp3 files (AAC and Ogg Vorbis play back normally):
Reset settings, turn on crossfade and choose the rockbox_default theme. Then start playing a folder with (normal size) mp3 files. After buffering finishes skip to the 2nd track, let it play for a few seconds and skip back to the beginning of the 2nd track. Then slowly skip forwards through the playlist (letting every track play for ~10 seconds or so).
Doing that i have noticed the following issues:
- dropouts like described earlier.
- crossfading works incorrectly. The old track fades out and suddenly jumps to full volume again for a moment.
- playback can become slow and choppy like described earlier.
- when the disk needs to spin up to load the next track then the player sometimes freezes with the disk spinning (requiring a hard reset).

* I'm not sure if all steps are required for reproduction. I haven't done too much testing because of the occasional freezes (i doubt that this is good for the hard drive).


Since those Problems seem to only happen with mp3 files i was wondering if it is possible to make a build that runs at 22MHz normal CPU frequency using the standard frequency switching method in order to see if the problems are related to the new frequency switching method or if this is a problem with the mp3 decoder that only shows up at lower CPU frequencies.
Comment by Björn Stenberg (zagor) - Monday, 19 January 2009, 22:58 GMT
Good idea PaulJam. Here's a patch that does precisely that: Uses 22/112 MHz but uses the "proper" PLL bypass clock setting method.
Comment by PaulJam (PaulJam) - Monday, 19 January 2009, 23:26 GMT
The last patch produces the same issues (dropouts, freeze, etc) on my h300 with mp3 files.
Comment by Steve Bavin (pondlife) - Tuesday, 20 January 2009, 07:53 GMT
Some of these symptoms happen occasionally (though not reprodicibly) with SVN builds - in particular the crossfade-volume-jump one.

The MP3 dropouts are definititely associated (or increased) with this patch, however, so maybe good to look into the lack of boost there before committing this. Otherwise, go for it!

Comment by Björn Stenberg (zagor) - Tuesday, 20 January 2009, 21:25 GMT
Just to clarify: This patch will never be committed. It is merely a test to see if this method of clock switching is usable.
Comment by Johannes Linke (Jaykay) - Tuesday, 20 January 2009, 21:35 GMT
why not? it potentially saves battery power (~1h on e200, last comment in  FS#9800 )
Comment by Björn Stenberg (zagor) - Wednesday, 21 January 2009, 08:00 GMT
Consider this a "research patch", the results of which will be used in future patches.

The purpose of this boost research is to do a more general rework of the boosting system, so we can lower the normal frequency while making the GUI more responsive. This patch alone is not good enough.
Comment by Tim Biermann (tb) - Sunday, 13 September 2009, 10:40 GMT
I know I am quiet late, but maybe you can port this to iAudio as mentioned above? I would like to test it out, sounds good to me.

Loading...