• Status New   Reopened
  • Percent Complete
  • Task Type Patches
  • Category Battery/Charging
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 1
  • Private
Attached to Project: Rockbox
Opened by freddyb - 2010-11-19
Last edited by freddyb - 2010-12-16

FS#11765 - Improve Battery Life on AMSv1 Sansa players

This patch modifies the CPU and peripheral bus clocks to hopefully gain some battery life. With this patch the CPU frequency can be either 31 or 186Mhz and the pclk is boosted from 31 to 62 Mhz while the CPU is boosted. The power draw of the CPU is proportional to the clock frequency and setting the frequency at or below what is required for playback keeps the power usage to a minimum because boosting to a frequency below 200Mhz is inexpensive. (Keeping the boosted CPU frequency below 200Mhz eliminates the need to wait for a voltage rise.)

I would appreciate feedback on battery life if anyone has the patience to run a battery bench.

Is the player still capable of playing all formats of audio and video currently supported with the decreased maximum frequency?

As well, does it negatively affect framerate in video playback, gameboy emulation, and other high-CPU areas?

Mpegplayer is getting nearly 30fps. I can play ape_c3000.ape and 64kaache.m4a from the test codec page. (ape_c4000 requires 277Mhz so it was out of reach before.) I’m satisfied with its performance. I’m not as confident about tinkering with the PCLK on the fly, though.

What does “nearly 30fps” mean? It should be able to reach a solid 29.97 fps with most/all bitrates encoded for its screen size, ideally. That means that when fps limiting is disabled it should come out somewhat above 30fps suggesting it has a bit of overhead for bitrate spikes on high motion scenes or whatnot.

Also, what about Rockboy? Can it play without frameskipping? How about while playing MP3s / other common formats?

I didn’t realize voltage scaling was not defined and it was always running at 1.2v so CVDDp is now lowered to 1.10v in system init. Also corrected a typo in the preprocessor logic.

Llorean, I cannot possibly guarantee 29.97 frames per second for every video, neither can SVN.

If SVN already has problems hitting 29.97 at all reasonable bitrates, it shouldn’t be lowered further.

Llorean, I didn’t say it couldn’t hit 29.97ps. I said it couldn’t GUARANTEE 29.97 fps for EVERY video file. Don’t twist my words.

“Mpegplayer is getting nearly 30fps.” ←- This says that it doesn’t quite get 30fps. If it doesn’t average 30fps, it’s not getting it for the majority of files. It should average a little over 30fps for most files if it’s going to perform decently over all.

I’m not trying to twist your words. I said “if” SVN already has problems hitting it. I didn’t say “since SVN already has problems hitting it.” That suggests that I don’t know, or I wouldn’t have used the word “if.” So please don’t accuse me of twisting your words, as I most certainly did not.

I presented the position that I do not know what the current status is, but *if* the current status is that it already has difficulty hitting 30 consistently, then reducing it further would be a problem.

Why don’t you just answer my questions about the real performance? With the Rockbox test video, what is the un-limited framerate before and after your patch? Rather than arguing about terminology and assumed slights you can just present the numbers clearly and be done with it.

Another thing of value would be battery benches before and after this patch. For real discussion of it you need to know what’s gained and what’s lost. If it’s 30 minutes of additional battery life vs 4 hours, it’s a very different situation.

FPS Patched: unlimited - real
30 seconds of Elephant’s Dream: 37.7 -
video: 39.2 -
Intro: 36.2 - 29.99

30 seconds of Elephant’s Dream: 44.0 -
video: 48.2 -
Intro: 45.0 - 29.98

All tests were done with dithering. Elephant’s Dream video from here: If anyone else tests this please note that Elephant’s Dream was encoded at 24fps, not 30. I had trouble testing video with unlimited frame rates with or without the patch. The video starts fast but about a minute into “Elephant’s Dream” there starts to be pauses. This problem goes away if unlimited frame rate is turned off.

That sounds like a strange bug, but it’s unrelated to the patch so I guess it doesn’t really matter here (might be worth writing a bug report on though since I don’t believe anyone’s reported it yet.)

It also sounds like there’s still a bit of overhead even with the reduced speed, so mpegplayer probably isn’t too much of a concern.

I’m getting a 27% increase in battery life.

With the original version of the patch I got 16:20 minutes vs. 14:20 minutes using SVN.

I did not test the lowered voltage version.

BTW, I wonder if its worth playing around with some of the other voltage regulators. Lowering voltages on the ipods resulted in a good bit of power savings.

Hopefully, we’re on the right track. In r24217 FlynDice made the remark that lower voltage was worth about 30 minutes. Thanks for testing.

This version incorporates some fix ups for clocks affected by adjusting PCLK: I2C & uSD. Can someone more familiar with the uSD code take a look at this?

I’ve been running the latest patch for a while with no issues. I asked funman about it and he looked at it and said that he didn’t want to remember trying to figure out how the original logic worked for uSD clocks. I say commit it and see if it breaks anything. We’re still a ways out from release so nows the time to do it.

I’m re-opening this. I got an e-mail about some micro SD problems. I can’t reproduce it but there’s a problem because the cpu doesn’t get unboosted after unplugging the USB cable.

This is the email I received:

of all i am still running r28834.

This is what i did:

- Remove uSD
Power on
Insert uSD
Connect to
Transfer file(s) onto the uSD card (the same loooong M4B audiobook i mentioned earlier)

Also i kept pushing buttons to keep the display enabled, which means i got a Data abort screen that i could see. Yay, i guess! :)


0, fault

I assume its the same problem. If i had to guess id say up to the crash the data transfer was faster, but that might just be the strange way the Windows copy files dialog sometimes calculates the transfer rate, or my messed up imagination. I double and tripple checked all adresses in the Data abort message, they should be accurate.

I repeated the actions above 3 times. After the third time it kind of messed up Windows 7’s USB interface and now my system wont accept newly connected devices and any operation on USB devices obviously dont work. :) So i sum this up before i reboot. The data aborts when they happened were all
Windows showed a mesage box that suggested no full USB 2.0 connect could be established and i guess in its place a slower fallback was used(1.1 ?). In this instance the file copy operation was completed successfully although at a snails pace (around 5mbit minus overhead;

nls commented on 2010-12-28 13:30

I noticed that copying files to my new 16GB µSDHC card failed with the sansa crashing with the display off so i tested with my old 1GB card with r28833 and
r28833 copying 1 GB flac to the card completed sucessfully (i did it 3
r28834 copying the same files failed each time, (one freeze, one undefined instruction at 00001b3c, and two data aborts identical to the above
reformatted the card between each try since the transfer failures corrupted the fs.

Sets PCLK to either 23.25 or 46.5MHz, getting closer to the proper 25/50MHz uSD
uSD divider regardless of
a little more delay in
CPU frequency is still 186MHz.

nls commented on 2010-12-29 12:36

I tested with this patch and it seems like the clock-target.h changes fixes my problem, i tested various combinations of the parts of the
clock.-target.h changes on their own fixed the crashing in the tests i made and any combination that included them but no combination in which they were not included.

microSD access on my e200v2 has been completely broken since r28834 (see  FS#11823 ).

The above patch does not improve the situation.

I reverted this patch in 28925. I think this line of optimization has promise (~30%) but some players are having uSD related problems which I cannot reproduce on my Fuze.

Here’s an updated patch with 24.8 / 49.6MHz Pclk and 186MHz boosted CPU.


I tried this on e260v2 and still get:

init failed : -2

Hi everyone!

I am the one who sent the mail to freddyb that was quoted here on the 21st. I am still running r28834 without any patches so this info isnt up to date and maybe it doesnt occur anymore.

The problem doesnt seem to be limited to the Micro SD cards. I managed to get an identical data abort (like the one in my mail from the 21st) copying files to the internal flash drive (while
SD card was present) and i got my Fuze to reboot without a displayed data abort when no Micro SD card was present. After that the USB driver went byebye again and ill have to reboot to use it again.

Personally i can easily live with the USB issues. Its not like its hard to use the OF for data transfers.

There has been some improvements to the SD driver since this patch was reverted from SVN, and variable clock speeds to be quite stable on AMSv2. Its entirely possible that its more stable now.

I recently bought an used Fuze v1 on *bay and have done a batterybench with a recent dev build vs. dev build with 24.8-186MHz.patch (15.1 KiB) applied:

Standard dev build:
3e1c8cc-170731 ——→ 10:25:17h

Patched build:
142f80fM-170905 ——> 18:20:26h

That's roughly 80% more.

I have not used the player on a regular basis in real life, i.e. I cannot tell if there are stability issues. I will post the patch on gerrit in the next days.

That was internal storage only, no SD card inserted, lame V2 MP3, album repeat includes this Sansa Fuze build.


Available keyboard shortcuts


Task Details

Task Editing