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/

Does that flip read and write?

Yes.

Does your patch change the timer frequency?

No. We should change it. But it hardcoded as define: if we fix it at boost clock we get 100hz at boost and 20hz at normal. I try it and have problem (5 times longer) with lcd timeout and idle/shutdown timeout.

In any case it not root of freezes. We should find why it freeze. If it freeze because we have interrupt between pmu settings we should disable irq. Or possibly we have some task (called from call_tick_tasks) that also need access to codec registers.

[Mihail Zenkov]

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

I try it today - no success. Codec don't pack two 16-bit samples in one 32-bit register (as in stereo mode). It just ignore second sample.

[LolaPalocz]

Current git version built with your 2 patches (I haven't touched any other "tunables" i asked about) :

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.

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.

Responsiveness is back ! Something like this gui_boost should be included in the final patch, otherwise it may frustrate people like it did for me.
I haven't had any freeze yet (does that irq patch still do something after your discovery these freeze problems have another cause on other clips ?).

I noticed something strange with this build only :
when i power off and power it on back after a few seconds or minutes, it's fine
but if i wait > 15 mn to power it on back, it is stuck on the 2nd boot screen (the one with the version number) for ~8 secondes - then 1 second black, then the now playing screen (Backlight timer has been started : I have it set to 10 seconds, and backlight goes off 1 second after i see the now playing screen).
If i power it off and then on early enough, it's fast. If I wait 15mn or 4 hours, it's slow, very reproducible. Didnt happen yesterday before these 2 patches.

Thanks.

[Mihail Zenkov]

(does that irq patch still do something after your discovery these freeze problems have another cause on other clips ?).

Yes. We still don't have batter solution.

I noticed something strange with this build only :
when i power off and power it on back after a few seconds or minutes, it's fine
but if i wait > 15 mn to power it on back, it is stuck on the 2nd boot screen (the one with the version number) for ~8 secondes - then 1 second black, then the now playing screen (Backlight timer has been started : I have it set to 10 seconds, and backlight goes off 1 second after i see the now playing screen).
If i power it off and then on early enough, it's fast. If I wait 15mn or 4 hours, it's slow, very reproducible. Didnt happen yesterday before these 2 patches.

This patches shouldn't have side affect like this. You can try switch off database auto update.

[LolaPalocz]

This patches shouldn't have side affect like this. You can try switch off database auto update.

(I dont have database enabled - and it's not as reproducible as i thought.)

But I figured out it's related to "dircache" (General settings/System/Disk/Directory Cache).
I had it enabled (the default).
If enabled, it's build at every boot (we can see the time taken to build in the debug menu).
With my 20141111 git build without any battery life patch), it always takes 2-3 seconds (whether I had 1500 entries or 3000 on both internal and SD storage).

With amsv2_scaling_v8, it takes either 2-3 seconds, or 8-9 seconds (I didnt find any condition that triggers one or the other).
(Without your 2 patches, i can see the message "Scanning directories" during these 8-9 seconds - with your 2 patches, it stays 8-9 seconds on the 2nd boot screen.)
I can see in apps/main.c and firmware/common/dircache.c that cpu_boost is involved during the building, so may be there's a race condition where cpu freq is reduced before the rebuild is done. I dont understand very much about this code though.
Also, one time, I got to the now playing screen in 2 seconds, and i could quickly go to the debug screen and witness the dircache being built live (took 14 seconds). It's supposed to be a background thread, but I dont know why sometimes it blocks the boot till it's done, and that time not.

I tested with dircache enabled or disabled :
- without amsv2_scaling_v8, file browsing is very responsive (no difference felt whether dircache enabled or disabled)
- with amsv2_scaling_v8 and without your GUI_BOOST patch : with dircache enabled, file browsing is a bit slow (my initial report), but with dircache disabled, it is very very slow.
- with amsv2_scaling_v8 and WITH your GUI_BOOST patch : with dircache enabled, boot may sometimes be slow, but then file browsing is very responsive - with dircache disabled, boot is always fast and file browsing is very responsive (so i'll stick to this configuration for now).

[g.orlandini]

I quickly synced that file (was only one line changed).  I can't login into gerrit at the moment, but here is the patch:

http://mit.edu/mgg6/www/amsv2_scaling_v8.patch

Thanks a lot for your patch, Saratoga. Until now it works very well.

After 3 weeks and many hours of use I can confirm the patch is working well, no freeze or errors. Sometimes it happens the cpu is boosted and it doesn't come back to power saving settings: in this case I shut down and resume playing with again the power setting on. This is the only (small) defect. Running time is very good, I didn't do a specific test but I'd say around 25-30 Hours.

Big thanks to Mihail, Saratoga and all other contributors to this useful patch

[LolaPalocz]

Sometimes it happens the cpu is boosted and it doesn't come back to power saving settings: in this case I shut down and resume playing with again the power setting on.

How do you check for this ? I tried to check, and found out that whenever i reach Debug/CPU freqs, boost_counter is 1 then gets to zero (I have Mihail gui boost patch). I always get it back to zero, even after hours playing and clicking. Except if i hit some keys on this debug screen, and for each click, boost_counter increases and then hardly gets back to zero. So it's may be only a small bug on this screen's code.

I also got some quite amazing battery life (> 20 hours), and it's quite stable, except for this :
Sometimes (happens once every other hour), while playing (track end not yet reached) it gets back to main menu (like end of playlist reached) with "nothing to resume". There, if I try to click "Files" in the main menu, it does not show the files and gets back to the main menu after 1 second of black screen, like if there was no internal memory (or it losts its handle on the directory i was in - but I also witnessed it on internal memory only with no sd card in). BUT i can still browse it from other menus (like Manage Settings/Browse .cfg or Equalizer / Browse EQ presets).
I have to poweroff then on to see it back and select a track to play.
It began to happen at 20% battery level (after 2 weeks without charging when battery went from 100% to 20%), so i thought it was related to that. I charged it back to 100, but it them happened also at 80%.
It may be related to the warm weather here (hasnt yet cool down, so can't check if it really does not happen anymore when cool...)
So, I dont know if it's a hardware/storage condition (sensitive to the lower voltages we set?) or a real code bug. Any idea ?

Edit: happened again today while playing audio from sdcard, Files was stuck as it tried to go to some directory on the sd card, but I manage to get back to /, so it was just the SD card that somehow was unavailable.
Does any of the voltage and frequency settings this patch (or the irq patch) changes may have an influence on the SD card functionning ? If no, I may just get a new sd card.

[LolaPalocz]

Does any of the voltage and frequency settings this patch (or the irq patch) changes may have an influence on the SD card functionning ? If no, I may just get a new sd card.

Definitely a SD card problem. I replaced that old Kingston by an old Sandisk SD, and I haven't had any problem over a week.

[Mihail Zenkov]

Does any of the voltage and frequency settings this patch (or the irq patch) changes may have an influence on the SD card functionning ? If no, I may just get a new sd card.

Definitely a SD card problem. I replaced that old Kingston by an old Sandisk SD, and I haven't had any problem over a week.

Can you replace ascodec_write_pmu(0x17, 2, 0x80 | 111); with  ascodec_write_pmu(0x17, 2, 0x80 | 113); in amsv2_scaling_v8.patch and test Kingston sd card again?

[LolaPalocz]

Can you replace ascodec_write_pmu(0x17, 2, 0x80 | 111); with  ascodec_write_pmu(0x17, 2, 0x80 | 113); in amsv2_scaling_v8.patch and test Kingston sd card again?

I did that, and I haven't had any problem the last 3 days. Thanks.
I'll have to wait for the next heat wave to confirm, as with 111, it was fine for some weeks till the weather got warm (dunno if temperature does have some effects on all that, but it looks like it did).

[florin]

Can you upload the build for Clip+ so that I can test too? Thanks.

[Scalpos]

Hi Mihail Zenkov & LolaPalocz + all others who worked on this subject, thank you very much for your commitment to Rockbox !

As I don't have any knowledge in Rockbox compiling, could you please provide your latest builds for Clip Zip, I would be very happy to test it too and report any issue if needed.

Does 983c808 build include any of the patches discussed here ?

[LolaPalocz]

I'll have to wait for the next heat wave to confirm, as with 111, it was fine for some weeks till the weather got warm (dunno if temperature does have some effects on all that, but it looks like it did).

Still stable after a few days of warm weather, so I guess 113 may be needed with some SD cards in specific climates

Does 983c808 build include any of the patches discussed here ?

Some of them, but not the main one.
Dunno if there's some policy regarding builds links, but here are some, from latest GIT + some of the patches given in this thread :

Clip Zip
rockbox983c808M-150808-clipzip-amsv2_scaling_v8.zip 3.41 Mo https://1fichier.com/?6pgvlgv9ic
rockbox983c808M-150808-clipzip-amsv2_scaling_v8+gui_boost+restore_irq.zip   3.41 Mo https://1fichier.com/?56k4qbrqmf
rockbox983c808M-150808-clipzip-amsv2_scaling_v8+gui_boost+restore_irq+CVDD2_113.zip 3.41 Mo https://1fichier.com/?pkzd0na1yj

The 1st one is with the latest amsv2_scaling patch.
The 2nd one adds some of Mihail tweaks for ClipZip stability and responsiveness.
The 3rd one adds CDDV2=113 needed for me for stability with some SD cards.

Clip +
rockbox983c808M-150808-clipplus-amsv2_scaling_v8.zip    3.27 Mo https://1fichier.com/?ca4hek70y1
rockbox983c808M-150808-clipplus-amsv2_scaling_v8+gui_boost+restore_irq.zip  3.27 Mo https://1fichier.com/?vr0xv2k8o2
(clip+ already has CDDV2=113, so no 3rd link)

I guess people should try them in the order given, so developpers can know how much the other patches are needed.
(I haven't tested them, so use at your own risk.)

[Scalpos]

Thank you very much ! I'll test them in suggested order and will report what I notice.

[Mihail Zenkov]

Still stable after a few days of warm weather, so I guess 113 may be needed with some SD cards in specific climates

Thanks for report!

I guess people should try them in the order given, so developpers can know how much the other patches are needed.
(I haven't tested them, so use at your own risk.)

We need all this patches to fix all know problems (you miss usb patch:  http://forums.rockbox.org/index.php/topic,48549.msg233822.html#msg233822). But some patches - dirty hack, we need better solution for them.