Details

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.

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?

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

All tests were done with dithering. Elephant's Dream video from here: http://download.rockbox.org/mpeg/elephantsdream-q6-224x176-469kbps.mpg. 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.

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.

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

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.

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.

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.

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.