Rockbox.org home
Downloads
Release release
Dev builds dev builds
Extras extras
themes themes
Documentation
Manual manual
Wiki wiki
Device Status device status
Support
Forums forums
Mailing lists mailing lists
IRC IRC
Development
Bugs bugs
Patches patches
Dev Guide dev guide
Search




Rockbox Technical Forums


Login with username, password and session length
Home Help Search Staff List Login Register
News:

Rockbox Ports are now being developed for various digital audio players!

+  Rockbox Technical Forums
|-+  Support and General Use
| |-+  Hardware
| | |-+  Sansа Clip Zip - Improve battery life
« previous next »
  • Print
Pages: 1 ... 7 8 [9] 10 11 ... 22

Author Topic: Sansа Clip Zip - Improve battery life  (Read 81892 times)

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #120 on: January 03, 2015, 03:09:03 PM »
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.
Logged

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #121 on: January 03, 2015, 03:30:07 PM »
Quote from: saratoga on January 02, 2015, 05:32:53 PM
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?
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 8770
Re: Sansа Clip Zip - Improve battery life
« Reply #122 on: January 03, 2015, 04:22:06 PM »
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.
Logged

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #123 on: January 03, 2015, 04:35:59 PM »
I look at dbop-as3525.c and see "magic" delay in line 47 and 108, maybe we should check it?
Logged

Offline [Saint]

  • Rockbox Expert
  • Member
  • *
  • Posts: 1662
  • Hayden Pearce
    • Google+
Re: Sansа Clip Zip - Improve battery life
« Reply #124 on: January 03, 2015, 07:58:06 PM »
Quote from: saratoga on January 02, 2015, 11:17:01 AM
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]
Logged
Using PMs to annoy devs about bugs/patches is not a good way to have the issue looked at.

Offline Bryanhoop

  • Member
  • *
  • Posts: 21
Re: Sansа Clip Zip - Improve battery life
« Reply #125 on: January 07, 2015, 05:47:12 PM »
I just want to pop in and thank you guys for doing this work/testing. Really exciting stuff!
Logged

Offline florin

  • Member
  • *
  • Posts: 10
Re: Sansа Clip Zip - Improve battery life
« Reply #126 on: January 08, 2015, 04:58:20 AM »
Quote from: saratoga on December 29, 2014, 02:52:58 PM
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).

Logged

Offline 404_user_not_found

  • Member
  • *
  • Posts: 52
Re: Sansа Clip Zip - Improve battery life
« Reply #127 on: January 08, 2015, 05:51:47 AM »
Quote from: florin on January 08, 2015, 04:58:20 AM
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.
« Last Edit: January 08, 2015, 06:13:29 AM by 404_user_not_found »
Logged

Offline sancher

  • Member
  • *
  • Posts: 2
Re: Sansа Clip Zip - Improve battery life
« Reply #128 on: January 08, 2015, 06:17:49 AM »
Quote from: 404_user_not_found on January 08, 2015, 05:51:47 AM
Quote from: florin on January 08, 2015, 04:58:20 AM
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!
Logged

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #129 on: January 08, 2015, 07:06:09 AM »
Quote from: 404_user_not_found on January 08, 2015, 05:51:47 AM
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.
Logged

Offline [Saint]

  • Rockbox Expert
  • Member
  • *
  • Posts: 1662
  • Hayden Pearce
    • Google+
Re: Sansа Clip Zip - Improve battery life
« Reply #130 on: January 08, 2015, 05:18:50 PM »
Quote from: Mihail Zenkov on January 08, 2015, 07:06:09 AM
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]
Logged
Using PMs to annoy devs about bugs/patches is not a good way to have the issue looked at.

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #131 on: January 08, 2015, 05:33:22 PM »
Quote from: [Saint] on January 08, 2015, 05:18:50 PM
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.

Quote from: [Saint] on January 08, 2015, 05:18:50 PM
#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

Quote from: [Saint] on January 08, 2015, 05:18:50 PM
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?
Logged

Offline [Saint]

  • Rockbox Expert
  • Member
  • *
  • Posts: 1662
  • Hayden Pearce
    • Google+
Re: Sansа Clip Zip - Improve battery life
« Reply #132 on: January 09, 2015, 11:26:43 AM »
Quote from: Mihail Zenkov on January 08, 2015, 05:33:22 PM
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.


Quote from: Mihail Zenkov on January 08, 2015, 05:33:22 PM
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]
Logged
Using PMs to annoy devs about bugs/patches is not a good way to have the issue looked at.

Offline Mihail Zenkov

  • Developer
  • Member
  • *
  • Posts: 374
Re: Sansа Clip Zip - Improve battery life
« Reply #133 on: January 09, 2015, 01:05:59 PM »
Quote from: [Saint] on January 09, 2015, 11:26:43 AM
In practice, I'm strictly against boosting unless its absolutely necessary.

Why?

Quote from: [Saint] on January 09, 2015, 11:26:43 AM
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.

Quote from: [Saint] on January 09, 2015, 11:26:43 AM
Besides, I don't really think that a singular users unmeasured observation provides any clear evidence of a problem.

You already check this problem?
Logged

Offline saratoga

  • Developer
  • Member
  • *
  • Posts: 8770
Re: Sansа Clip Zip - Improve battery life
« Reply #134 on: January 09, 2015, 01:20:32 PM »
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. 
Logged

  • Print
Pages: 1 ... 7 8 [9] 10 11 ... 22
« previous next »
+  Rockbox Technical Forums
|-+  Support and General Use
| |-+  Hardware
| | |-+  Sansа Clip Zip - Improve battery life
 

  • SMF 2.0.6 | SMF © 2013, Simple Machines
  • XHTML
  • RSS
  • WAP2

Page created in 0.125 seconds with 65 queries.