Sansа Clip Zip - Improve battery life

[Mihail Zenkov]

Yes I'll commit those shortly.

Thanks!

I can't login into gerrit though

I have same problem.


What you think about usb problem?
http://forums.rockbox.org/index.php/topic,48549.msg233822.html#msg233822

I have look deeper into this problem.
On USB_INSERTED event (in usb.c) we call:
   usb_stack_enable() -> usb_enable()
   usb_set_host_present() -> usb_configure_drivers() -> usb_attach() -> usb_enable()

On  USB_EXTRACTED event (in usb.c) we call:
   usb_stack_enable() -> usb_enable()
   usb_set_host_present() -> usb_configure_drivers()

So on USB_EXTRACTED we don't call second time usb_enable(false). Not sure how right to fix it and why we call usb_enable twice on USB_ISERTED.

[saratoga]

Sorry I have never even looked at the USB stack, but a few people on IRC do know quite a bit about it.

[LolaPalocz]

I just compiled latest git rockbox with amsv2_scaling_v8.patch for sansa clip zip.
I've just started using it, so no report on stability (it's fine for now).

Just an observation :
- when audio is playing, menu navigation is a bit slow (0.5 / 1 second lag) when browsing directories with lots of files and directories in them (> 30).
- when audio is not playing, it's fast (no lag noticed) as before when browsing the same directories.
There may also be some black screen for 0.5/1 second while activating backlight/displaying current working directory content.
(I "may" notice a lower lag if i disable some sound processing settings, so it may be related to cpu use)

So, it's no big deal, and i will probably get used to it, if battery is saved.
But if I wanted to trade a bit of power saving for a bit more responsiveness in file browsing, what would i need to change in this patch ?

Thanks (for all your work !)

[Mihail Zenkov]

But if I wanted to trade a bit of power saving for a bit more responsiveness in file browsing, what would i need to change in this patch ?

We discussed this before:
http://forums.rockbox.org/index.php/topic,48549.msg233424.html#msg233424
But we still don't have patch for this.

[LolaPalocz]

Yes, i had read this. But these reports were about clip+ or clipv2. Just thought I let you know there's still a noticable side effect with (my) clip zip.
(I also had one freeze this morning while switching tracks - will report later if it happens again).

My question was actually what I can quickly modifiy (for my own usage) in this patch.
Reading the patch, there seem to be 4 "tunables" :
  CPU_FREQ and CPUFREQ_DEFAULT      38400000
  AS3525_PLLA_FREQ        192000000
  ascodec_write_pmu(0x17, 2, 0x80 | 111);
  ascodec_write_pmu(0x17, 1, 0x80 | 19);
So, which one(s) could I increase to get a little bit more responsiveness ?

Also, couldn't cpu_boost(1) be called when backlight is activated and cpu_boost(0) called when it goes off (assuming people always have some kind of timeout for backlight) ?

[Mihail Zenkov]

(I also had one freeze this morning while switching tracks - will report later if it happens again).

You should try add this patch to your build: http://forums.rockbox.org/index.php/topic,48549.msg233958.html#msg233958
It hack (we still don't have better solution) but it critical in some case.

My question was actually what I can quickly modifiy (for my own usage) in this patch.
Reading the patch, there seem to be 4 "tunables" :
  CPU_FREQ and CPUFREQ_DEFAULT      38400000
  AS3525_PLLA_FREQ        192000000
  ascodec_write_pmu(0x17, 2, 0x80 | 111);
  ascodec_write_pmu(0x17, 1, 0x80 | 19);
So, which one(s) could I increase to get a little bit more responsiveness ?

Yes, you can rise CPUFREQ_DEFAULT and ascodec_write_pmu(0x17, 1, 0x80 | 19) but it also rise whole power consumption.

Also, couldn't cpu_boost(1) be called when backlight is activated and cpu_boost(0) called when it goes off (assuming people always have some kind of timeout for backlight) ?

Not very good solution as backlight have quite big timeout. Try attached hack for GUI_BOOST - if you press any key cpu boost for one second.

[saratoga]

I've also got some 80% complete optimizations for the mp3 decoder which would cut the CPU requirement quite a lot on ARM9/ARM11 devices, but I haven't found time in the last few years to finish them.  That might help if we want very low clock speeds, at least for MP3 (probably FLAC is already fine). 

[Mihail Zenkov]

Yes, it can help, especially with high bitrate mp3 + dsp.

P.S. We can get 40-50 hours for mono if we switch codec in mono mode, but not sure is someone need many hours on mono? Probably for audiobooks?

[saratoga]

By mono you mean both channels play the same, or just one of two speakers are powered?  I'm surprised there is that much power savings just by getting rid of one channel. 

[Mihail Zenkov]

As I mention before -  sending audio data consume too much. Once I set wrong divider and have 22050hz sample rate - power consumption was 6-7ma.
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.

Another idea - disable dma for audio: sending data with dma consume more then software mp3 decoding.

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

Mono saves power because the CPU needs to do less work.

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.

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.

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]

Now I know - why read speed was three times slower than write
http://gerrit.rockbox.org/r/#/c/1191/

Does that flip read and write?

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

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.

We do have a mono mode.  If setting the hardware to mono really helps, I don't see why not. 

Another idea - disable dma for audio: sending data with dma consume more then software mp3 decoding.

Could be some hardware bug or problem.