Sansа Clip Zip - Improve battery life

[Mihail Zenkov]

Early I use two zip with CPU=240MHz and PCLK=120Mhz (in boost mode). ~180 hours without any freeze in everyday use. I not try get it higher.

[Mihail Zenkov]

Fuzev2:  Lowering PCLK helps, but does not solve the problem.

64MHz still higher than 40Mhz in current rockbox and DBOP can by still very high for fuze v2 display. Maybe just try divide DBOP?

[saratoga]

Its very encouraging that such high PCLK works on the Zip.

The first lower PCLK build I posted also divided the DBOP clock by 2, but it seemed to screw up the screen.  Possibly I did something wrong.  I suppose I should try disabling all frequency/voltage scaling entirely, set the PCLK at 96MHz and divide the DBOP down and see if any combinations work.

[Mihail Zenkov]

I look at dbop-as3525.c and see "magic" delay in line 47 and 108, maybe we should check it?

[[Saint]]

I think devices with a wheel will boost whenever the wheel is used.

I just caught this looking though past posts, pretty sure GUI_BOOST was intended just for the PortalPlayer iPods, but it got into the Nano2G and Classic as well (probably cut and paste config shenanigans), neither of which necessarily require it in my testing, but I digress.


[Saint]

[Bryanhoop]

I just want to pop in and thank you guys for doing this work/testing. Really exciting stuff!

[florin]

Updated builds:

http://web.mit.edu/mgg6/www/rockbox-clipv2.7z
http://web.mit.edu/mgg6/www/rockbox-clipplus.7z

Running fine on an older Clip+ (end of 2009!). The only things I noticed:
1. pressing the submenu during playback seems to take a longer time to display the playlist (the button press is registered correctly, but after I depress the button it takes almost 2 seconds to display the playlist - ~2500 entries
2. accessing the Database (~1500 songs on the card) seems slower - I get to read the "Searching for..." text when entering letter C artists for example (~65 artists).

[404_user_not_found]

Running fine on an older Clip+ (end of 2009!). The only things I noticed:
1. pressing the submenu during playback seems to take a longer time to display the playlist (the button press is registered correctly, but after I depress the button it takes almost 2 seconds to display the playlist - ~2500 entries
2. accessing the Database (~1500 songs on the card) seems slower - I get to read the "Searching for..." text when entering letter C artists for example (~65 artists).

It's OK, in that case we need to rise voltage. The voltage settings for clip+ based from my runtime tests, where I listen music with file manager and low demand FLAC. I don't use a database and playlists. So each folder contains average 15 tracks, it's very easy for my player to handle that without a noticeable delay. But I didn't test a player with database and with big playlists.

I think that we need to implement a special setting in menu of rockbox where user can change a power consume preference:
1) Very low power consume. Good for playing music like file manager with low consume formats. Player uses a power optimization that enables frequency scaling and applies extremely lowered but stable voltages.
2) Balanced. For everyday use. Player uses a power optimization that enables frequency scaling and applies a balances values of lowered voltages.
3) High Performance. Good for very big database, playlists and for playing codecs with high power consume. Player don't uses any power optimizations.

[sancher]

Running fine on an older Clip+ (end of 2009!). The only things I noticed:
1. pressing the submenu during playback seems to take a longer time to display the playlist (the button press is registered correctly, but after I depress the button it takes almost 2 seconds to display the playlist - ~2500 entries
2. accessing the Database (~1500 songs on the card) seems slower - I get to read the "Searching for..." text when entering letter C artists for example (~65 artists).

It's OK, in that case we need to rise voltage. The voltage settings for clip+ based from my runtime tests, where I listen music with file manager and low demand FLAC. I don't use a database and playlists. So each folder contains average 15 tracks, it's very easy for my player to handle that without a noticeable delay. But I didn't test a player with database and with big playlists.

I think that we need to implement a special setting in menu of rockbox where user can change a power consume preference:
1) Very low power consume. Good for playing music like file manager with low consume formats. Player uses a power optimization that enables frequency scaling and applies extremely lowered but stable voltages.
2) Balanced. For everyday use. Player uses a power optimization that enables frequency scaling and applies a balances values of lowered voltages.
3) High Performance. Good for very big database, playlists and for playing codecs with high power consume. Player don't uses any power optimizations.

Great suggestion!

[Mihail Zenkov]

I think that we need to implement a special setting in menu of rockbox where user can change a power consume preference:
1) Very low power consume. Good for playing music like file manager with low consume formats. Player uses a power optimization that enables frequency scaling and applies extremely lowered but stable voltages.
2) Balanced. For everyday use. Player uses a power optimization that enables frequency scaling and applies a balances values of lowered voltages.
3) High Performance. Good for very big database, playlists and for playing codecs with high power consume. Player don't uses any power optimizations.

I think better add preference for boost cpu on button press. We already have GUI_BOOST, so we only need slightly rework it. In preference user be able to set  timeout for this boosting (if 0 - no gui boost).
It much easy to implement than multiple frequency/voltages for each player and not need in so careful testing.

[[Saint]]

We already have GUI_BOOST, so we only need slightly rework it. In preference user be able to set  timeout for this boosting (if 0 - no gui boost).

I am slightly confused.

When you say "We already have GUI_BOOST", do you mean "it exists for other devices and I am aware of it", or do you believe it to be enabled for this particular device?

#define HAVE_GUI_BOOST is only present on the iPods, and it was only ever intended to be enabled on the PP (PortalPlayer) based iPods, but it seems to have snuck its way in to the configs for the iPod Nano 2G and iPod Classic, almost certainly accidentally by way of copy and paste error from reusing the device configuration from another iPod as a base during the port's creation.

Neither of which, in my personal opinion, actually require this as both have fairly powerful SoCs that are more than capable of providing a smooth user experience on their un-boosted clock frequencies. In fact, if it wasn't for this define, these devices wouldn't really ever need to boost at all, except for decoding (for the sake of efficiency) or if you were to use one of the more ridiculous codecs.

Additionally, I do not believe a configurable timeout should be necessary at all.


[Saint]

[Mihail Zenkov]

When you say "We already have GUI_BOOST", do you mean "it exists for other devices and I am aware of it", or do you believe it to be enabled for this particular device?

I think it can be reworked and enabled for all target quite easy.

#define HAVE_GUI_BOOST is only present on the iPods, and it was only ever intended to be enabled on the PP (PortalPlayer) based iPods, but it seems to have snuck its way in to the configs for the iPod Nano 2G and iPod Classic, almost certainly accidentally by way of copy and paste error from reusing the device configuration from another iPod as a base during the port's creation.

Also in:
sansaconnect.h
sansae200.h
sansaview.h
sansafuze.h
sansafuzev2.h

Neither of which, in my personal opinion, actually require this as both have fairly powerful SoCs that are more than capable of providing a smooth user experience on their un-boosted clock frequencies. In fact, if it wasn't for this define, these devices wouldn't really ever need to boost at all, except for decoding (for the sake of efficiency) or if you were to use one of the more ridiculous codecs.

Additionally, I do not believe a configurable timeout should be necessary at all.

You have better solution for florin problem?

[[Saint]]

Also in:
sansaconnect.h
sansae200.h
sansaview.h
sansafuze.h
sansafuzev2.h

My mistake.

However I think you'll find that's a mix of PortalPlayer SoCs (a device which I forgot about, sansae200), and quite probably more cases of defines sneaking in to device configs from copy/paste when building new ports. It would be interesting to see how many of those non-PP devices actually require this. In practice, I'm strictly against boosting unless its absolutely necessary.

Neither of which, in my personal opinion, actually require this as both have fairly powerful SoCs that are more than capable of providing a smooth user experience on their un-boosted clock frequencies. In fact, if it wasn't for this define, these devices wouldn't really ever need to boost at all, except for decoding (for the sake of efficiency) or if you were to use one of the more ridiculous codecs.

You have better solution for florin problem?

I don't believe I need a solution, as there's no actual problem as yet. The 'solution' at this stage would be to not use a volatile experimental build. Besides, I don't really think that a singular users unmeasured observation provides any clear evidence of a problem.

I'm also unsure whether or not it was clear to you that I was talking specifically about the iPod Classic and Nano 2G or not. It doesn't seem to be the case.


[Saint]

[Mihail Zenkov]

In practice, I'm strictly against boosting unless its absolutely necessary.

Why?

The 'solution' at this stage would be to not use a volatile experimental build.

It test build, we resolve all problems with zip and clip+. If we also resolve problems with clip v2 and fuze v2, it should by good enough for main branch.

Besides, I don't really think that a singular users unmeasured observation provides any clear evidence of a problem.

You already check this problem?

[saratoga]

I don't mind enabling GUI boost for other targets if its helpful.  The original rationale was that it was needed on very slow devices.  We could still use it on faster devices that are clocked very low such that they are slow unboosted. 

However, I don't really see the point of discussing it now.  We haven't worked out the problems with boosting on half the AMSv2 devices, and I am still skeptical about how stable we are on some of the others.  At the moment, only the Clip Zip seems completely debugged.