Rockbox

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 time
1st 30 seconds of Elephant's Dream: 37.7 - 23.96
My video: 39.2 - 29.99
Futurama Intro: 36.2 - 29.99

FPS SVN:
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: 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.

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:

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

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.

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.

Fred:

I tried this on e260v2 and still get:

*PANIC*
microSD 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 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.

I love this patch! I updated to a latter release and really miss it. Can this be included or run conditionally on Clips that don't have an SD card?

I tried this patch with the newest build for my fuze v1 it didnt work, is this normal?
Do I need an updated patch for the newes


The meyer crossfeed patch worked