Support and General Use > Hardware
Sansа Clip Zip - Improve battery life
[Saint]:
--- 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).
--- End quote ---
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:
--- 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?
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
You have better solution for florin problem?
[Saint]:
--- Quote from: Mihail Zenkov on January 08, 2015, 05:33:22 PM ---Also in:
sansaconnect.h
sansae200.h
sansaview.h
sansafuze.h
sansafuzev2.h
--- End quote ---
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?
--- End quote ---
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:
--- Quote from: [Saint] on January 09, 2015, 11:26:43 AM ---In practice, I'm strictly against boosting unless its absolutely necessary.
--- End quote ---
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.
--- End quote ---
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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version