Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
Mihail Zenkov:
Now I know - why read speed was three times slower than write :)
http://gerrit.rockbox.org/r/#/c/1191/
EDIT: I found why we have often freeze on fuzev2 and rarely on others AMSv2 targets (without my restore_irq hack).
In firmware/target/arm/as3525/system-target.h we have for fuzev2 "#define KERNEL_TIMER_FREQ (TIMER_FREQ/2)".
For others we have "#define KERNEL_TIMER_FREQ TIMER_FREQ".
I try set "KERNEL_TIMER_FREQ (TIMER_FREQ/2)" for clip zip (+ gui_boost.patch) and have freeze after few clicks in main menu (check several times). With my restore_irq - no freeze.
dreamlayers:
Mono saves power because the CPU needs to do less work. Downsampling in MP3 decoding can also decrease CPU work and save power. For example see the -m, -2 and -4 command line options of mpg123.
If you don't downsample in decoding but play at half the sample rate, then you're getting half the CPU load, but you're playing at half speed and with lower pitch. That may be interesting, but it's not very useful.
For me, the battery life is fine, and I wouldn't degrade music quality to extend it. Note that you can also encode in mono and at lower sample rates and bitrates. That will also save space and power usage related to reading the data.
saratoga:
--- Quote from: dreamlayers on June 04, 2015, 08:45:50 PM ---Mono saves power because the CPU needs to do less work.
--- End quote ---
You'll save a some MHz, but not a huge amount. If it really has a profound impact on battery life, something is very strange.
--- Quote from: dreamlayers on June 04, 2015, 08:45:50 PM ---If you don't downsample in decoding but play at half the sample rate, then you're getting half the CPU load, but you're playing at half speed and with lower pitch. That may be interesting, but it's not very useful.
--- End quote ---
We've disabled the downsampled synthesis filter options in libmad. Plus they're not assemblerized, so they're probably only marginally faster even if enabled. The synthesis filter can be optimized a lot more though. See FS#11759. I forget the exact speed up I calculated, but something like synth_full would be faster than synth_half if perfectly implemented. Interestingly, that implementation is also the one google independently choose for Android.
saratoga:
--- Quote from: Mihail Zenkov on June 04, 2015, 07:09:42 PM ---Now I know - why read speed was three times slower than write :)
http://gerrit.rockbox.org/r/#/c/1191/
--- End quote ---
Does that flip read and write?
--- Quote from: Mihail Zenkov on June 04, 2015, 07:09:42 PM ---EDIT: I found why we have often freeze on fuzev2 and rarely on others AMSv2 targets (without my restore_irq hack).
In firmware/target/arm/as3525/system-target.h we have for fuzev2 "#define KERNEL_TIMER_FREQ (TIMER_FREQ/2)".
For others we have "#define KERNEL_TIMER_FREQ TIMER_FREQ".
--- End quote ---
I believe funman committed that years ago because there was no interrupt on the scroll wheel for some devices, so you had to poll them relatively fast or you could miss 'ticks' on the wheel. Does your patch change the timer frequency?
saratoga:
--- Quote from: Mihail Zenkov on June 04, 2015, 06:33:06 PM ---On mono files (or on mono setting) we can switch codec to mono mode and send only one channel (half data) - codec automatically send it to right and left.
--- End quote ---
We do have a mono mode. If setting the hardware to mono really helps, I don't see why not.
--- Quote from: Mihail Zenkov on June 04, 2015, 06:33:06 PM ---Another idea - disable dma for audio: sending data with dma consume more then software mp3 decoding.
--- End quote ---
Could be some hardware bug or problem.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version