Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#11765 : Improve Battery Life on AMSv1 Sansa players



FS#11765 - Improve Battery Life on AMSv1 Sansa players

Attached to Project: Rockbox
Opened by Fred Bauer (freddyb) - Friday, 19 November 2010, 16:51 GMT
Last edited by Fred Bauer (freddyb) - Thursday, 16 December 2010, 22:33 GMT
Task Type Patches
Category Battery/Charging
Status New   Reopened
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Release 3.6
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 1
Private No


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.
This task depends upon

Comment by Paul Louden (Llorean) - Friday, 19 November 2010, 21:02 GMT
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?
Comment by Fred Bauer (freddyb) - Friday, 19 November 2010, 22:18 GMT
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.
Comment by Paul Louden (Llorean) - Friday, 19 November 2010, 22:32 GMT
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?
Comment by Fred Bauer (freddyb) - Saturday, 20 November 2010, 22:43 GMT
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.
Comment by Paul Louden (Llorean) - Saturday, 20 November 2010, 23:48 GMT
If SVN already has problems hitting 29.97 at all reasonable bitrates, it shouldn't be lowered further.
Comment by Fred Bauer (freddyb) - Sunday, 21 November 2010, 05:22 GMT
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.
Comment by Paul Louden (Llorean) - Sunday, 21 November 2010, 05:31 GMT
"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.
Comment by Paul Louden (Llorean) - Sunday, 21 November 2010, 05:35 GMT
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.
Comment by Fred Bauer (freddyb) - Sunday, 21 November 2010, 17:45 GMT
FPS Patched: unlimited - real time
1st 30 seconds of Elephant's Dream: 37.7 - 23.96
My video: 39.2 - 29.99
Futurama Intro: 36.2 - 29.99

1st 30 seconds of Elephant's Dream: 44.0 - 23.98
My video: 48.2 - 29.98
Futurama 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.
Comment by Paul Louden (Llorean) - Sunday, 21 November 2010, 20:22 GMT
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.
Comment by Fred Bauer (freddyb) - Monday, 22 November 2010, 13:59 GMT
I'm getting a 27% increase in battery life.
Comment by MichaelGiacomelli (saratoga) - Monday, 22 November 2010, 15:45 GMT
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.

Comment by Fred Bauer (freddyb) - Monday, 22 November 2010, 17:03 GMT
Hopefully, we're on the right track. In r24217 FlynDice made the remark that lower voltage was worth about 30 minutes. Thanks for testing.
Comment by Fred Bauer (freddyb) - Wednesday, 01 December 2010, 19:17 GMT
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?
Comment by MichaelGiacomelli (saratoga) - Tuesday, 14 December 2010, 19:55 GMT
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.
Comment by Fred Bauer (freddyb) - Thursday, 16 December 2010, 22:36 GMT
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.
Comment by Fred Bauer (freddyb) - Tuesday, 21 December 2010, 18:12 GMT
This is the email I received:

---Begin Quote---
1st of all i am still running r28834.

This is what i did:

- Remove uSD Card
- Power on Fuze
- Insert uSD Card
- Connect to USB
- 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! :)

Data abort
at 30052D08
FSR 0x8
(domain 0, fault 8)
address 0xEA00008B

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 identical.
Once 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; 620Kb/s)
---End Quote---
Comment by Nils Wallménius (nls) - Tuesday, 28 December 2010, 13:30 GMT
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 r28834
with r28833 copying 1 GB flac to the card completed sucessfully (i did it 3 times)
with r28834 copying the same files failed each time, (one freeze, one undefined instruction at 00001b3c, and two data aborts identical to the above post)
I reformatted the card between each try since the transfer failures corrupted the fs.
Comment by Fred Bauer (freddyb) - Tuesday, 28 December 2010, 17:24 GMT
Sets PCLK to either 23.25 or 46.5MHz, getting closer to the proper 25/50MHz uSD frequencies.
Adjusts uSD divider regardless of sd_enabled.
Give a little more delay in dbop.
Top CPU frequency is still 186MHz.
Comment by Nils Wallménius (nls) - Wednesday, 29 December 2010, 12:36 GMT
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 patch.
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.
Comment by Michael Chicoine (mc2739) - Wednesday, 29 December 2010, 12:51 GMT
microSD access on my e200v2 has been completely broken since r28834 (see  FS#11823 ).

The above patch does not improve the situation.
Comment by Fred Bauer (freddyb) - Thursday, 30 December 2010, 02:50 GMT
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.
Comment by Fred Bauer (freddyb) - Thursday, 30 December 2010, 04:28 GMT
Here's an updated patch with 24.8 / 49.6MHz Pclk and 186MHz boosted CPU.
Comment by Michael Chicoine (mc2739) - Thursday, 30 December 2010, 13:58 GMT

I tried this on e260v2 and still get:

microSD init failed : -2
Comment by Michael König (mkoenig) - Monday, 10 January 2011, 16:25 GMT
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 a
Micro 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.
Comment by MichaelGiacomelli (saratoga) - Monday, 19 January 2015, 22:03 GMT
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.
Comment by Johannes Rauh (johnbtracker) - Saturday, 09 September 2017, 08:50 GMT
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.

Comment by Johannes Rauh (johnbtracker) - Saturday, 09 September 2017, 10:12 GMT
That was internal storage only, no SD card inserted, lame V2 MP3, album repeat
Comment by Johannes Rauh (johnbtracker) - Saturday, 09 September 2017, 18:42 GMT includes this Sansa Fuze build.