Rockbox Technical Forums

Support and General Use => Hardware => Topic started by: Mihail Zenkov on September 27, 2014, 05:28:21 PM

Title: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 27, 2014, 05:28:21 PM
I measure current between player and battery and try tweak power consumption.

Current in mA (less is better):
(http://kreator.at.tut.by/KnK/current.png)

You can convert current to hours:
battery capacity (mAh) / mA = hours

For example rockbox with patch consume 10.9 mA when play flac, battery capacity in Zip - 300mAh.
300 / 10.9 = 27.5 hours

In reality it would be less - battery capacity degraded over time.

Some interesting results:
1. Original firmware have problem with flac (double power consumption).
2. Themes can significantly differ in power consumption when screen on.
3. Radio consumes too much (but I didn't try to optimize it).
4. We have room to improve battery life ;)


rockbox-improve_battery_life.patch:  set master clock to 48 MHz, undervolting CVDD1, CVDD2, PVDD1. WARNING: this patch may cause instability, freeze or sound quality degradation.

rockbox-backlight.patch: disable DCDC15 when screen off (save 1mA), like we already do in Clip Plus. Good for inclusion in main branch.

rockbox-usb.patch: prevent USB power consumption (additional 5 mA in all modes) after it disconnected. Also good for inclusion in main branch.


I try many other clocks/voltages without any significant difference.


Link for binary build: http://forums.rockbox.org/index.php/topic,48368.0.htm
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 27, 2014, 05:42:51 PM
I measure current between player and battery and try tweak power consumption.

Current in mA (less is better):
(http://kreator.at.tut.by/KnK/current.png)

Awesome thanks, no one has looked at power on the sandisk players in years.  I knew more improvements were possible but haven't looked into them.

1. Original firmware have problem with flac (double power consumption).
2. Themes can significantly differ in power consumption when screen on.
3. Radio consumes too much (but I didn't try to optimize it).
4. We have room to improve battery life ;)

Yes, the sandisk firmware uses the official flac decoder, which is VERY slow.  We used it too for a bit, but quickly switched to ffmpeg's much faster one, which was then heavily optimized.  It can decode a file using less than 10 MHz of CPU.

rockbox-improve_battery_life.patch:  set master clock to 48 MHz, undervolting CVDD1, CVDD2, PVDD1. WARNING: this patch may cause instability, freeze or sound quality degradation.

We did tests years ago of lower clock speeds (and also lower memory bus speeds), and found that they made relatively little difference.  This is actually why no one has bothered to get CPU frequency scaling running, it was believed to only have a very small impact on battery life.  These results are therefore very interesting. 

Do you know how much of the change is from the voltage settings and how much is from the CPU frequency?  Or is it that lower clock means you can more safely use a lower voltage?  Perhaps this will motivate enabling CPU frequency scaling.

rockbox-backlight.patch: disable DCDC15 when screen off (save 1mA), like we already do in Clip Plus. Good for inclusion in main branch.

I'll try this out and commit if it works ok for me.

rockbox-usb.patch: prevent USB power consumption (additional 5 mA in all modes) after it disconnected. Also good for inclusion in main branch.

These needs to be tested, but looks like a big oversight on our part.  I suppose this may help with other AMS devices too.

I try many other clocks/voltages without any significant difference.

We did a lot of testing years ago, I will try to find the results and forward them to you.  I found that increasing PCLK (the memory bus is on this) greatly increased performance but also power draw.  At lower speeds, the player was slower, but more efficient.  Running the memory faster massively improved how fast some of the decoders were (far fewer MHz needed for realtime playback) but decreased battery anyway. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 27, 2014, 06:29:37 PM
http://gerrit.rockbox.org/r/#/c/988/
http://gerrit.rockbox.org/r/#/c/989/

Will commit in a day or two if no one sees any problems.  Note that I changed the backlight current sink on value to be 91 (its previous value) rather than 90.  Probably doesn't matter but I was unclear on why it was changed.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 27, 2014, 06:47:39 PM
Some comments about the voltage patch:

1)  Reducing the main CPU frequency is fine for FLAC and for people who don't use much DSP effects, but probably even mp3 + EQ would skip that low.
2)  If you change any of the registers related to supply voltages, make sure that you don't reduce the device's maximum volume.  0dB should be the max without distortion if the audio hardware has the correct voltages.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 12:36:00 AM
Patch with work in progress frequency scaling:  http://www.rockbox.org/tracker/task/11297

As you can see we never figured out why dynamically scaling the frequency reduced battery life.  Possibly this was a mistake or oversight if you found that lowering the clock improved battery life.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 10:17:21 AM
Do you know how much of the change is from the voltage settings and how much is from the CPU frequency?
I check on playing flac:
mod PLLA save 3.5 mA
mod CVDD1 save 2.2 mA
mod CVDD2 save 1 mA
mod PVDD1 save 1 mA

Or is it that lower clock means you can more safely use a lower voltage?
Yes, it also allows use lower voltage.

We did a lot of testing years ago, I will try to find the results and forward them to you.  I found that increasing PCLK (the memory bus is on this) greatly increased performance but also power draw.  At lower speeds, the player was slower, but more efficient.  Running the memory faster massively improved how fast some of the decoders were (far fewer MHz needed for realtime playback) but decreased battery anyway. 
I try check PCLK. Any idea what also I should check?

I try change PVDD2 and have worst result, even if I try disable it (write 0x80 to it).

Note that I changed the backlight current sink on value to be 91 (its previous value) rather than 90.  Probably doesn't matter but I was unclear on why it was changed.
As datasheet say it shouldn't change any thing. Clip Plus and Clip v2 set it to 0x90. I set it to 0x90 and don't see any changes. I think 0x91 just mistake.

1)  Reducing the main CPU frequency is fine for FLAC and for people who don't use much DSP effects, but probably even mp3 + EQ would skip that low.
Right, we need dynamically scaling. But it more complicated to test and tune.

2)  If you change any of the registers related to supply voltages, make sure that you don't reduce the device's maximum volume.  0dB should be the max without distortion if the audio hardware has the correct voltages.
Ok. You already have this problem with a patch?

Patch with work in progress frequency scaling:  http://www.rockbox.org/tracker/task/11297

As you can see we never figured out why dynamically scaling the frequency reduced battery life.  Possibly this was a mistake or oversight if you found that lowering the clock improved battery life.
I try check it.

My first patch have problem - it change core voltage in bootloader, fixed in new version.

I also think we should set CPUFREQ_DEFAULTA and CPUFREQ_NORMAL to FCLK, as we don't have dynamically frequency scaling. With current value we have wrong udelay.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 01:37:03 PM
I check PCLK - try 12MHz and 6Mhz - no significant difference.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 01:45:04 PM
I think that is too low.  The maximum is 60MHz, and we found acceptable performance down to about 20MHz (lowering it too much means the CPU wastes a lot of power waiting for memory loadds).

By the way, can you join use in #rockbox?  We are discussing these patches. 

Edit:  Testing the USB and backlight changes increased my Zip runtime by 32%. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 03:38:26 PM
To help with testing, I've added new debug menus that show the current SOC voltage regulator outputs (using an on board A/D to read the voltages).  You can see then under System -> debug -> view io ports and then hit the down button to scroll through all the voltages.

Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 03:44:55 PM
I think that is too low.  The maximum is 60MHz, and we found acceptable performance down to about 20MHz (lowering it too much means the CPU wastes a lot of power waiting for memory loadds).
I just test it. In patch I don't change it (24Mhz).

By the way, can you join use in #rockbox?  We are discussing these patches. 
I don't use IRC, sorry.

Edit:  Testing the USB and backlight changes increased my Zip runtime by 32%. 
Good.

To help with testing, I've added new debug menus that show the current SOC voltage regulator outputs (using an on board A/D to read the voltages).  You can see then under System -> debug -> view io ports and then hit the down button to scroll through all the voltages.
Great! What I want add today :)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 03:53:55 PM
I think the current build now shows all (about 20) voltage channels on the device.

Regarding pclk I don't mind to tell you what to use, but somewhere between 20-40 is likely optimal.

By the way one user testing the lower CPU clocks found that they break most formats other then flac.  So if we want to lower them much frequency scaling will be needed.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 04:06:41 PM
Have you taken any measurements of AVDD17 or AVDD27?  Looking at the voltages, we run AVDD17 a little higher because it determines the maximum headphone output.  I was thinking raising it might be useful, but I won't do that if it uses a lot of power.

Edit:  If I understand correctly, AVDD17 is the analog voltage used for almost everything but headphone amplifiers (line out, mixers, etc) while AVDD27 is the headphone output.  I wonder if AVDD17 could be lowered since we do not use the line out. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 04:36:09 PM
By the way one user testing the lower CPU clocks found that they break most formats other then flac.  So if we want to lower them much frequency scaling will be needed.
I also use it with mp3, but without any postprocessing. Frequency scaling should by next step.

Have you taken any measurements of AVDD17 or AVDD27?  Looking at the voltages, we run AVDD17 a little higher because it determines the maximum headphone output.  I was thinking raising it might be useful, but I won't do that if it uses a lot of power.
I measure it at first - no significant difference at low volume. I don't test it at high volume. I try check it again.

Edit:  If I understand correctly, AVDD17 is the analog voltage used for almost everything but headphone amplifiers (line out, mixers, etc) while AVDD27 is the headphone output.  I wonder if AVDD17 could be lowered since we do not use the line out. 
When I try disable AVDD17 I don't hear any sound :) And save 1 mA  - we can use this on pause, but not sure if it have sense.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 05:06:53 PM
Checked -  no significant difference at pause, low volume (-35dB) and high (0dB).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 05:08:51 PM
The volume mixers are still needed for playback, so AVDD17 can't be disabled.  It might be possible to lower it (although that might require adjusting the volume mixer gains too to avoid clipping), but if it only uses 1 mA its probably not worth it.

AVDD27 is at 2.7v right now according to the A/D, so even if we raised it to its maximum of 3.3, that only gains ~ 1dB in maximum output.  Maybe not worthwhile.

Testing CVDD2, it seems that PVDD1 is derived from it, and furthermore that the SD cards run off it, as 1.8v gives an ATA error trying to read storage :)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 28, 2014, 05:10:51 PM
Checked -  no significant difference at pause, low volume (-35dB) and high (0dB).

AVDD17 or 27?  I think 17 is the line out and mixer, 27 is the headphone. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 28, 2014, 05:25:52 PM
AVDD17 or 27?  I think 17 is the line out and mixer, 27 is the headphone. 
For both.

Testing CVDD2, it seems that PVDD1 is derived from it
AVDD17 derived from AVDD27.

If someone interesting: SD card 32GB class 10 eat 0.6mA  :)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on September 28, 2014, 05:40:03 PM
Freenode offers an IRC web-client, as linked on the left hand side of the page (https://webchat.freenode.net/?channels=rockbox).


[Saint]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 29, 2014, 01:38:52 PM
I tested battery life on some builds:

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU (no change to other clocks): 15h 0min
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on September 29, 2014, 03:07:45 PM
rockbox-backlight.patch: disable DCDC15 when screen off (save 1mA), like we already do in Clip Plus. Good for inclusion in main branch.

Thanks;
is that so special to the Clip Zip, or is it easy to adapt to other Sansa devices?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 29, 2014, 03:32:26 PM
is that so special to the Clip Zip, or is it easy to adapt to other Sansa devices?
I suppose we need check each device for optimal frequency/voltage for best result and stability, but it should by mostly same. In any case at first we should check and fix frequency scaling and push it in to main branch. Then we can adapt it to other device.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on September 29, 2014, 03:34:59 PM
Current git + 1.1v CPU (no change to other clocks): 15h 0min
Is 1.1V lower stable voltage on 240Mhz?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on September 29, 2014, 03:37:50 PM
is that so special to the Clip Zip, or is it easy to adapt to other Sansa devices?
I suppose we need check each device for optimal frequency/voltage for best result and stability, but it should by mostly same. In any case at first we should check and fix frequency scaling and push it in to main branch. Then we can adapt it to other device.
I was about the backlight-patch. I thought that it was clear because I cited just that part.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on September 29, 2014, 03:46:23 PM
Current git + 1.1v CPU (no change to other clocks): 15h 0min
Is 1.1V lower stable voltage on 240Mhz?

Yes, but 1.0 was not.  I was mostly curious to see how important voltage was to runtime.

is that so special to the Clip Zip, or is it easy to adapt to other Sansa devices?
I suppose we need check each device for optimal frequency/voltage for best result and stability, but it should by mostly same. In any case at first we should check and fix frequency scaling and push it in to main branch. Then we can adapt it to other device.
I was about the backlight-patch. I thought that it was clear because I cited just that part.

The backlight patch is already committed, and (as per the first post), specific to the Zip. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 01, 2014, 05:30:22 PM
New version with frequency scaling based on as3525v2-cpufreq-v11.patch.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 01, 2014, 06:00:42 PM
I'm curious how stable frequency scaling is for you?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 01, 2014, 06:38:33 PM
Few hours playing APE (switch freq each second). I try find way switch PCLK to master clock or PPL but no success. Have any idea on how we can do this?

If you have freeze with this patch first try remove set CVDD1.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 04, 2014, 07:47:09 PM
I try new solution - don't switch PCLK. In this case at normal frequency we have FCLK 40MHz / PCLK 20MHz, at boost - FCLK 240MHz / PCLK 120MHz. It very stable for me: 12 hours of APE and two day of ordinarily use without any freeze. Possible it slightly less effective, but not sure - decoding at PCLK 120MHz work faster and we need less time in boost mode.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 04, 2014, 07:53:22 PM
I try new solution - don't switch PCLK. In this case at normal frequency we have FCLK 40MHz / PCLK 20MHz, at boost - FCLK 240MHz / PCLK 120MHz.

Are you sure about that?  Max PCLK is 60 MHz IIRC, and when we tested, raising PCLK increased power consumption a lot more than raising FCLK (because many things on the chip also increase in frequency).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 04, 2014, 08:52:46 PM
Are you sure about that?
Yes.

Max PCLK is 60 MHz IIRC, and when we tested, raising PCLK increased power consumption a lot more than raising FCLK (because many things on the chip also increase in frequency).
It increase power consumption a lot (+4.3mA) if we compare idle and much less difference if we have load: +2.5mA on light load (playing mp3). At full load I suppose (no measure it) it have no significant difference or may have better result than low PCLK.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 02:50:41 PM
Benchmarking average clock speed needed for realtime playback:

Vorbis 128k stock:  49.81 MHz
Above patch:  20.93 MHz.

So yes, it would appear to have massively increased the memory subsystem performance.  I will do more testing.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 02:57:01 PM
Unfortunately, my player has only a 50% chance of booting with that patch applied, and most of the menus will freeze the player (although interestingly test_codec seems to be able to benchmark ok, perhaps because it forces boost or keeps the playback hardware off?). 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 03:00:07 PM
Can you try increase CVDD1?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 03:02:40 PM
I'm testing that right now, < 1.0 volts may not be safe.  This is an older 130 nm chip. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 03:10:44 PM
I use for test two player, both manufactured 9 months ago.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 03:21:17 PM
I removed most of the voltage changes, except for the one that scales voltage during CPU frequency change.  I changed this to 1.1 and 1.2v to be conservative.   I'll see if I can do a battery bench. 

Edit:  Device hard locked after 1 song. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 03:30:11 PM
Better test CVDD1 for boost and normal mode separately. I force one mode in set_cpu_frequency, do test for stability and then check another mode.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 03:39:56 PM
Going into the debug menu and manually boosting hard locks the player, so I suppose that is the problem. 

Edit:  1 time hard locked, the next corrupted the display, and the third worked correctly but crashed shortly there after when I tried to play a song. 

Maybe a better approach would be to confirm that frequency scaling is really working, and then try to adjust PCLK? I think 120MHz is probably far outside of the device spec. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 03:49:55 PM
AFAIK we don't have datasheet for this chip, so we don't know maximum frequency for it.  But you right better try set FCLK lower, maybe 180/90MHz? 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 03:53:20 PM
AFAIK we don't have datasheet for this chip, so we don't know maximum frequency for it.  But you right better try set FCLK lower, maybe 180/90MHz?

We have a datasheet for the AMSv1, which is pretty close (although the CPU core and memory amounts are different).  That one was limited to 60MHz. 

I don't think a lower FCLK will help.  My guess is that 120MHz isn't entirely stable on my player, and that there are some race conditions or other glitches when switching the F or P clocks.  Years ago we actually disabled frequency scaling because it caused a lot of random crashes. 

Edit:  Unfortunately the tracker is down so I can't check fs#11297, but as I recall, funman added quite a lot of additional code to the frequency switching functions to try and make them more stable.  Perhaps something there is needed?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 03:56:41 PM
Sorry, I mean change PLLA and have FCLK 180 / PCLK 90.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 03:58:49 PM
Maybe just seeing if FLCK switching from 240 to 24 at constant PCLK works would be best?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 04:00:18 PM
Edit:  Unfortunately the tracker is down so I can't check fs#11297, but as I recall, funman added quite a lot of additional code to the frequency switching functions to try and make them more stable.  Perhaps something there is needed?
My patch V3 based on this code, but it not totally stable as was mention in tracker.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 04:02:25 PM
Maybe just seeing if FLCK switching from 240 to 24 at constant PCLK works would be best?
We can't set PLCK constant, datasheet say we should switch PLCK to master clock, but we can't do this in AMSv2.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 05, 2014, 04:06:25 PM
Maybe just seeing if FLCK switching from 240 to 24 at constant PCLK works would be best?
We can't set PLCK constant, datasheet say we should switch PLCK to master clock, but we can't do this in AMSv2.

Didn't funman's old code set the PCLK to 24MHz and just change the multiplier? 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 05, 2014, 04:14:59 PM
Code in master branch do this. But when we switch FCLK to normal we have very low PCLK then we try set good PCLK, but sometimes we have memory corruption.
So in latest version FLCK and PCLK switching step by step. It work much better, but not totally stable.

EDIT: for AMSv2 PLCK always based on FLCK - this root of problem with switching frequency.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on October 07, 2014, 04:26:26 AM
A maybe stupid question -- when I try to compile with patch V3 or patch V4, I get an error "‘CVDD1_BOOST’ undeclared" and "‘CVDD1_NORMAL’ undeclared" in "firmware/target/arm/as3525/system-as3525.c":

Code: [Select]
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c: In function ‘set_cpu_frequency’:
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: ‘CVDD1_BOOST’ undeclared (first use in this function)
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: (Each undeclared identifier is reported only once
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:526: error: for each function it appears in.)
/tmp/rockbox/source/rockbox/firmware/target/arm/as3525/system-as3525.c:565: error: ‘CVDD1_NORMAL’ undeclared (first use in this function)
/tmp/rockbox/source/rockbox/tools/root.make:414: recipe for target '/tmp/rockbox/source/build-FuzeV2-firmware/firmware/target/arm/as3525/system-as3525.o' failed
make: *** [/tmp/rockbox/source/build-FuzeV2-firmware/firmware/target/arm/as3525/system-as3525.o] Error 1

.. Do you operate with another patch in the background?

I use the actual git checkout.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 07, 2014, 05:53:18 AM
This patch for Sansa Clip Zip only. You should add CVDD1_BOOST / CVDD1_NORMAL / PVDD1_DAC / PVDD1_ADC in config for your player. Also you should fix #ifdef SANSA_CLIPZIP in patch.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 06, 2014, 12:03:42 PM
Changes in V5:

WARNING: this patch may improve battery life and sound quality :)

Sound quality checked with RMAA and emu-0204.

Load 22 om, -6dB.
Without patch      With patch
Dynamic range, dBA:   92.193.6
THD, %:0.0460.037
IMD, %:0.0610.041


No load, 0dB.
Without patch      With patch
Dynamic range, dBA:   93.395.0
THD, %:0.0160.0037
IMD, %:0.0190.0065


Original firmware show same result as rockbox without patch.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 06, 2014, 04:32:05 PM
I'm testing this now.  One note though, with typical VBR MP3, it won't even boost (38MHz is fast enough), so to test stability I recommend either a slower format or turning on the EQ just to make sure the CPU actually changes. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 06, 2014, 04:59:43 PM
Yes, for testing stability frequency scaling better use APE - in this case CPU switch to boost and back to normal each second.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 06, 2014, 05:31:25 PM
http://mit.edu/mgg6/www/rockbox-clipzip.zip
http://mit.edu/mgg6/www/rockbox-clip+.zip

If anyone wants to try the above patch (I enabled it for the clip+ as well).  Tested and working on my devices, but I'm curious if they're good for everyone else.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 07, 2014, 03:03:28 PM
I tested battery life on some builds:

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU (no change to other clocks): 15h 0min

Testing the frequency scaling patch on the Zip gave me 12h 45min, which is less than I would expect.  I will retest to be sure that nothing went wrong.  Have you done a battery test?

On the other hand, frequency scaling seems stable.  I put probably 36 hours on a pair of AMSv2 devices with zero crashes. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 07, 2014, 03:54:57 PM
I tested battery life on some builds:

Last spring: 10h 14min
Current git: 13h 35min
Current git + 1.1v CPU (no change to other clocks): 15h 0min

Testing the frequency scaling patch on the Zip gave me 12h 45min, which is less than I would expect.  I will retest to be sure that nothing went wrong.

Probably you force boost mode. Check frequency.

Quote
Have you done a battery test?

No. But I measure power consumption. Subjectively player work two times longer. Not sure if it have sense - in system menu I have top ruining time 23h 11m.

Quote
On the other hand, frequency scaling seems stable.  I put probably 36 hours on a pair of AMSv2 devices with zero crashes.

Good!

EDIT: Have you added cpu_boost(0) to usb-as3525.c?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 07, 2014, 07:19:02 PM
I started a new test, and this time confirmed after 30 minutes that the system was not stuck in a boosted state.  Will report the results in the morning.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 04:46:58 PM
21 hours 29 minutes.

Not bad. 

Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 08, 2014, 04:59:43 PM
You can get slightly better result by accurate tuning CVDD1. Other voltage better leave as in my last patch - it show best result with RMAA.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 05:16:54 PM
I am slightly concerned about the lower cpu voltage when unboosted.  I think we would need to get a fair amount of people to test that before we are sure its safe.  I'm tempted to commit the frequency scaling first, and then follow up with voltage once we are sure its stable.  I tend to think theres probably a wide distribution of voltages that are safe between devices.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 05:33:06 PM
http://pastebin.com/tTXpLSsj

Patch with cleaned up USB.

One question though, is the voltage reset in rolo.c even needed?  The header for that function isn't included, so I'm not even sure if its linked. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 08, 2014, 05:40:26 PM
I am slightly concerned about the lower cpu voltage when unboosted.  I think we would need to get a fair amount of people to test that before we are sure its safe.  I'm tempted to commit the frequency scaling first, and then follow up with voltage once we are sure its stable.  I tend to think theres probably a wide distribution of voltages that are safe between devices.

Yes, you right. I mean for you personal record :) My two devices can stable work on slightly less voltages.

Quote
One question though, is the voltage reset in rolo.c even needed?  The header for that function isn't included, so I'm not even sure if its linked.
Yes, it linked and work. I just was lazy fix warning. Without it player freeze on booting another firmware though rolo. Also I think better disable frequency scaling if we build bootloader.


In my researches I see two strange behavior:
1. playing wav (16/44.1) consume  mostly same power as low bitrate mp3 - is it expected?
2. in test_mem I have read speed much lower than write speed - is it normal?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 08, 2014, 05:45:40 PM
http://pastebin.com/tTXpLSsj

Patch with cleaned up USB.
You can also remove  frequency_lock.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 05:56:34 PM
One other strange thing I noticed, on the clipv2, the player was not able to read button presses with this patch (but scaling still disabled).  Will look into that as well.

Edit:  rebuilding seems to have fixed it, maybe just a bad binary. 

Edit2:  http://gerrit.rockbox.org/r/#/c/1062/
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 08, 2014, 06:02:05 PM
Good.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 06:15:02 PM
Test builds:

http://mit.edu/mgg6/www/rockbox-clipzip.zip
http://mit.edu/mgg6/www/rockbox-clipplus.zip
http://mit.edu/mgg6/www/rockbox-clipv2.zip
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 08, 2014, 09:38:06 PM
Does this patch set the PCLK correctly on the Fuze v2?  The ifdef in clock-target.h is a little confusing to me (isn't the base PCLK 19.2 MHz?)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 09, 2014, 05:50:04 AM
No. We should remove special define for  fuze v2 and leave only #define AS3525_DRAM_FREQ 96000000.

About rolo: if we move reseting CVDD1 to system-as3525.c we cannot boot old stable firmware as they don't (re)set CVDD1.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: nick_p on December 10, 2014, 12:05:07 AM
Would this patch also be effective on a Sansa e200v2?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 10, 2014, 12:11:40 AM
Would this patch also be effective on a Sansa e200v2?

No, different AMS (v1 not v2) processor.  Although frequency scaling was never quite worked out on that chip either, so a similar approach might work. 

Edit:  See http://www.rockbox.org/tracker/task/11765

Edit2:  SD has been improved some since those days.  It might not be too hard to work out frequency scaling on the AMSv1 devices if anyone is interested. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 13, 2014, 01:43:25 AM
If anyone wants to try the above patch (I enabled it for the clip+ as well).  Tested and working on my devices, but I'm curious if they're good for everyone else.
I tried the latest version of patch (http://www.rockbox.org/tracker/task/11765) (misprint) patch (http://gerrit.rockbox.org/r/#/c/1062/) on my sansa clip+. Works without an any crashes after some hours of listening FLAC (CD Audio quality) with disabled DSP but I don't noticed any changes of remaining time (before 10 hours and after 10 hours) and I don't remember how quickly without a patch player drains a battery. I fully sure that I successfully applied a patch because I noticed a new menu (System>Debug>CPU Frequency) that absent in stable 3.13 version. So, to be fully sure I will try a battery test.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 13, 2014, 05:55:57 AM
You try old patch - look at date, try patch from this topic or gerrit: http://gerrit.rockbox.org/r/#/c/1062/
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 13, 2014, 07:49:06 AM
You try old patch - look at date, try patch from this topic or gerrit: http://gerrit.rockbox.org/r/#/c/1062/
Misprint. Of course I used that patch (Patch set 5) from gerrit, not from abandoned rockbox tracker. That old patch just don't compatible with ASMv2 it's for AMSv1. Fixed previous post.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 13, 2014, 09:27:06 AM
Strange - patch look good, but probably we have problem with boost/unboost in some another place. You can try my last patch in this topic - it have slightingly different way for boost/unboost for usb. And in any case check frequency in System>Debug>CPU Frequency as saratoga mention (http://www.anythingbutipod.com/forum/showpost.php?p=650941&postcount=635).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 13, 2014, 10:39:20 AM
Strange - patch look good
I think my sansa clip+ just wrongly shows a remaining time. After 8 hours charge drops to 50%, remaining time is around 8:00 hours. Sometimes remaining time jumps to random values.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 13, 2014, 01:57:30 PM
We haven't updated the time remaining calculation show it won't change.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 15, 2014, 01:17:12 PM
Looks strange, but "improve_battery_life.patch" improves sometimes decode time and lowers MHZ needed for decoding (look for example vorbis_500.ogg). I can't understand, why player decodes sometimes faster with energy saving patch.

Sansa Clip+, Untouched rockbox version 3.13 without "improve_battery_life.patch"
Code: [Select]
a52_stereo_192.ac3
176325 of 176000
Decode time - 13.85s
File duration - 176.00s
1270.75% realtime
18.88MHz needed for realtime

ape_c1000.ape
175906 of 175906
Decode time - 35.94s
File duration - 175.90s
489.42% realtime
49.03MHz needed for realtime

ape_c2000.ape
175906 of 175906
Decode time - 48.55s
File duration - 175.90s
362.30% realtime
66.24MHz needed for realtime

ape_c3000.ape
175906 of 175906
Decode time - 69.65s
File duration - 175.90s
252.54% realtime
95.03MHz needed for realtime

ape_c4000.ape
175906 of 175906
Decode time - 169.07s
File duration - 175.90s
104.03% realtime
230.70MHz needed for realtime

ape_c5000.ape
175906 of 175906
Decode time - 694.27s
File duration - 175.90s
25.33% realtime
947.49MHz needed for realtime

applelossless.m4a
175906 of 175906
Decode time - 26.95s
File duration - 175.90s
652.69% realtime
36.77MHz needed for realtime

atrac3_lp2_132.oma
174294 of 176360
Decode time - 26.16s
File duration - 176.36s
674.15% realtime
35.60MHz needed for realtime

cook_mono_32.ra
177449 of 175904
Decode time - 12.30s
File duration - 175.90s
1430.08% realtime
16.78MHz needed for realtime

cook_mono_64.ra
176431 of 175904
Decode time - 13.63s
File duration - 175.90s
1290.53% realtime
18.59MHz needed for realtime

cook_stereo_32.ra
176431 of 175904
Decode time - 12.07s
File duration - 175.90s
1457.33% realtime
16.46MHz needed for realtime

cook_stereo_64.ra
176431 of 175906
Decode time - 27.10s
File duration - 175.90s
649.07% realtime
36.97MHz needed for realtime

cook_stereo_96.ra
176431 of 175906
Decode time - 27.88s
File duration - 175.90s
630.91% realtime
38.04MHz needed for realtime

flac_5.flac
175906 of 175906
Decode time - 6.47s
File duration - 175.90s
2718.70% realtime
8.82MHz needed for realtime

flac_8.flac
175906 of 175906
Decode time - 6.92s
File duration - 175.90s
2541.90% realtime
9.44MHz needed for realtime

lame_096.mp3
175951 of 175968
Decode time - 17.40s
File duration - 175.96s
1011.26% realtime
23.73MHz needed for realtime

lame_128.mp3
175909 of 175960
Decode time - 22.68s
File duration - 175.96s
775.83% realtime
30.93MHz needed for realtime

lame_192.mp3
175909 of 175960
Decode time - 23.78s
File duration - 175.96s
739.94% realtime
32.43MHz needed for realtime

lame_256.mp3
175909 of 175960
Decode time - 24.07s
File duration - 175.96s
731.03% realtime
32.83MHz needed for realtime

lame_320.mp3
175909 of 175960
Decode time - 25.02s
File duration - 175.96s
703.27% realtime
34.12MHz needed for realtime

mpc_096.mpc
175906 of 175906
Decode time - 16.94s
File duration - 175.90s
1038.37% realtime
23.11MHz needed for realtime

mpc_128.mpc
175906 of 175906
Decode time - 17.91s
File duration - 175.90s
982.13% realtime
24.43MHz needed for realtime

mpc_170.mpc
175906 of 175906
Decode time - 18.40s
File duration - 175.90s
955.97% realtime
25.10MHz needed for realtime

mpc_224.mpc
175906 of 175906
Decode time - 18.80s
File duration - 175.90s
935.63% realtime
25.65MHz needed for realtime

mpc_300.mpc
175906 of 175906
Decode time - 19.06s
File duration - 175.90s
922.87% realtime
26.00MHz needed for realtime

mpc_350.mpc
175906 of 175906
Decode time - 19.38s
File duration - 175.90s
907.63% realtime
26.44MHz needed for realtime

nero_096.m4a
175906 of 175966
Decode time - 31.36s
File duration - 175.96s
561.09% realtime
42.77MHz needed for realtime

nero_128.m4a
175906 of 175966
Decode time - 32.43s
File duration - 175.96s
542.58% realtime
44.23MHz needed for realtime

nero_192.m4a
175906 of 175966
Decode time - 33.87s
File duration - 175.96s
519.51% realtime
46.19MHz needed for realtime

nero_256.m4a
175906 of 175966
Decode time - 35.22s
File duration - 175.96s
499.60% realtime
48.03MHz needed for realtime

nero_320.m4a
175906 of 175966
Decode time - 36.56s
File duration - 175.96s
481.29% realtime
49.86MHz needed for realtime

nero_400.m4a
175906 of 175966
Decode time - 37.53s
File duration - 175.96s
468.85% realtime
51.18MHz needed for realtime

nero_he_64.m4a
175906 of 176017
Decode time - 106.71s
File duration - 176.01s
164.94% realtime
145.50MHz needed for realtime

nero_hev2_64.m4a
175906 of 176034
Decode time - 129.92s
File duration - 176.03s
135.49% realtime
177.13MHz needed for realtime

opus_128k.opus
176786 of 175914
Decode time - 54.45s
File duration - 175.91s
323.06% realtime
74.28MHz needed for realtime

opus_192k.opus
176786 of 175914
Decode time - 60.93s
File duration - 175.91s
288.70% realtime
83.13MHz needed for realtime

opus_256k.opus
176786 of 175914
Decode time - 66.69s
File duration - 175.91s
263.77% realtime
90.98MHz needed for realtime

opus_32k.opus
176786 of 175914
Decode time - 40.33s
File duration - 175.91s
436.17% realtime
55.02MHz needed for realtime

opus_64k_5ms.opus
176811 of 175910
Decode time - 74.68s
File duration - 175.91s
235.55% realtime
101.88MHz needed for realtime

opus_64k_20ms.opus
176786 of 175914
Decode time - 46.99s
File duration - 175.91s
374.35% realtime
64.11MHz needed for realtime

pegase_l1_192.mp1
175908 of 175908
Decode time - 15.06s
File duration - 175.90s
1167.99% realtime
20.54MHz needed for realtime

pegase_l2_128.mp2
175897 of 175908
Decode time - 15.09s
File duration - 175.90s
1165.67% realtime
20.58MHz needed for realtime

pegase_l1_256.mp1
175908 of 175908
Decode time - 16.31s
File duration - 175.90s
1078.47% realtime
22.25MHz needed for realtime

pegase_l2_192.mp2
175897 of 175908
Decode time - 17.49s
File duration - 175.90s
1005.71% realtime
23.86MHz needed for realtime

pegase_l1_352.mp1
175908 of 175908
Decode time - 16.88s
File duration - 175.90s
1042.06% realtime
23.03MHz needed for realtime

pegase_l2_256.mp2
175897 of 175908
Decode time - 17.72s
File duration - 175.90s
992.66% realtime
24.17MHz needed for realtime

pegase_l1_448.mp1
175908 of 175908
Decode time - 17.17s
File duration - 175.90s
1024.46% realtime
23.42MHz needed for realtime

pegase_l2_384.mp2
175897 of 175908
Decode time - 17.42s
File duration - 175.90s
1009.75% realtime
23.76MHz needed for realtime

true_audio.tta
175000 of 175000
Decode time - 26.85s
File duration - 175.00s
651.76% realtime
36.82MHz needed for realtime

vorbis_500.ogg
175906 of 175906
Decode time - 54.09s
File duration - 175.90s
325.19% realtime
73.80MHz needed for realtime

vorbis_350.ogg
175906 of 175906
Decode time - 48.30s
File duration - 175.90s
364.18% realtime
65.90MHz needed for realtime

vorbis_096.ogg
175906 of 175906
Decode time - 36.59s
File duration - 175.90s
480.73% realtime
49.92MHz needed for realtime

vorbis_128.ogg
175906 of 175906
Decode time - 37.78s
File duration - 175.90s
465.59% realtime
51.54MHz needed for realtime

vorbis_192.ogg
175906 of 175906
Decode time - 41.19s
File duration - 175.90s
427.04% realtime
56.20MHz needed for realtime

vorbis_256.ogg
175906 of 175906
Decode time - 44.43s
File duration - 175.90s
395.90% realtime
60.62MHz needed for realtime

wmapro_271k.wma
174248 of 178941
Decode time - 25.56s
File duration - 178.94s
700.07% realtime
34.28MHz needed for realtime

wmapro_55k.wma
174248 of 178941
Decode time - 21.77s
File duration - 178.94s
821.95% realtime
29.19MHz needed for realtime

wmapro_80k.wma
174248 of 178941
Decode time - 22.59s
File duration - 178.94s
792.12% realtime
30.29MHz needed for realtime

wmapro_141k.wma
174248 of 178941
Decode time - 23.71s
File duration - 178.94s
754.70% realtime
31.80MHz needed for realtime

wmapro_173k.wma
174248 of 178941
Decode time - 24.23s
File duration - 178.94s
738.50% realtime
32.49MHz needed for realtime

wma_128.wma
174294 of 177504
Decode time - 23.89s
File duration - 177.50s
742.98% realtime
32.30MHz needed for realtime

wma_192.wma
174294 of 177504
Decode time - 24.39s
File duration - 177.50s
727.75% realtime
32.97MHz needed for realtime

wma_256.wma
174294 of 177504
Decode time - 24.95s
File duration - 177.50s
711.42% realtime
33.73MHz needed for realtime

wma_320.wma
174294 of 177504
Decode time - 25.47s
File duration - 177.50s
696.89% realtime
34.43MHz needed for realtime

wma_96.wma
174294 of 177504
Decode time - 23.67s
File duration - 177.50s
749.89% realtime
32.00MHz needed for realtime

wv_fastx3.wv
175900 of 175906
Decode time - 18.31s
File duration - 175.90s
960.67% realtime
24.98MHz needed for realtime

wv_normx4.wv
175900 of 175906
Decode time - 21.78s
File duration - 175.90s
807.62% realtime
29.71MHz needed for realtime

Sansa Clip+, Rockbox version 3.13 with "improve_battery_life.patch" (Patch set 5)
Code: [Select]
a52_stereo_192.ac3
176325 of 176000
Decode time - 15.65s
File duration - 176.00s
1124.60% realtime
17.07MHz needed for realtime

ape_c1000.ape
175906 of 175906
Decode time - 44.23s
File duration - 175.90s
397.69% realtime
48.27MHz needed for realtime

ape_c2000.ape
175906 of 175906
Decode time - 59.83s
File duration - 175.90s
293.99% realtime
65.30MHz needed for realtime

ape_c3000.ape
175906 of 175906
Decode time - 86.02s
File duration - 175.90s
204.48% realtime
93.89MHz needed for realtime

ape_c4000.ape
175906 of 175906
Decode time - 209.06s
File duration - 175.90s
84.13% realtime
228.21MHz needed for realtime

ape_c5000.ape
175906 of 175906
Decode time - 860.23s
File duration - 175.90s
20.44% realtime
939.33MHz needed for realtime

applelossless.m4a
175906 of 175906
Decode time - 31.99s
File duration - 175.90s
549.85% realtime
34.91MHz needed for realtime

atrac3_lp2_132.oma
174294 of 176360
Decode time - 23.98s
File duration - 176.36s
735.44% realtime
26.10MHz needed for realtime

cook_mono_32.ra
177449 of 175904
Decode time - 10.17s
File duration - 175.90s
1729.59% realtime
11.10MHz needed for realtime

cook_mono_64.ra
176431 of 175904
Decode time - 11.57s
File duration - 175.90s
1520.31% realtime
12.62MHz needed for realtime

cook_stereo_32.ra
176431 of 175904
Decode time - 10.18s
File duration - 175.90s
1727.89% realtime
11.11MHz needed for realtime

cook_stereo_64.ra
176431 of 175906
Decode time - 21.88s
File duration - 175.90s
803.93% realtime
23.88MHz needed for realtime

cook_stereo_96.ra
176431 of 175906
Decode time - 22.75s
File duration - 175.90s
773.18% realtime
24.83MHz needed for realtime

flac_5.flac
175906 of 175906
Decode time - 6.58s
File duration - 175.90s
2673.25% realtime
7.18MHz needed for realtime

flac_8.flac
175906 of 175906
Decode time - 7.12s
File duration - 175.90s
2470.50% realtime
7.77MHz needed for realtime

lame_096.mp3
175951 of 175968
Decode time - 18.15s
File duration - 175.96s
969.47% realtime
19.80MHz needed for realtime

lame_128.mp3
175909 of 175960
Decode time - 23.35s
File duration - 175.96s
753.57% realtime
25.47MHz needed for realtime

lame_192.mp3
175909 of 175960
Decode time - 24.43s
File duration - 175.96s
720.26% realtime
26.65MHz needed for realtime

lame_256.mp3
175909 of 175960
Decode time - 24.78s
File duration - 175.96s
710.08% realtime
27.03MHz needed for realtime

lame_320.mp3
175909 of 175960
Decode time - 25.87s
File duration - 175.96s
680.17% realtime
28.22MHz needed for realtime

mpc_096.mpc
175906 of 175906
Decode time - 14.59s
File duration - 175.90s
1205.62% realtime
15.92MHz needed for realtime

mpc_128.mpc
175906 of 175906
Decode time - 15.57s
File duration - 175.90s
1129.73% realtime
16.99MHz needed for realtime

mpc_170.mpc
175906 of 175906
Decode time - 15.95s
File duration - 175.90s
1102.82% realtime
17.40MHz needed for realtime

mpc_224.mpc
175906 of 175906
Decode time - 16.30s
File duration - 175.90s
1079.14% realtime
17.79MHz needed for realtime

mpc_300.mpc
175906 of 175906
Decode time - 16.58s
File duration - 175.90s
1060.91% realtime
18.09MHz needed for realtime

mpc_350.mpc
175906 of 175906
Decode time - 16.92s
File duration - 175.90s
1039.59% realtime
18.46MHz needed for realtime

nero_096.m4a
175906 of 175966
Decode time - 21.41s
File duration - 175.96s
821.85% realtime
23.36MHz needed for realtime

nero_128.m4a
175906 of 175966
Decode time - 22.57s
File duration - 175.96s
779.61% realtime
24.62MHz needed for realtime

nero_192.m4a
175906 of 175966
Decode time - 24.23s
File duration - 175.96s
726.20% realtime
26.43MHz needed for realtime

nero_256.m4a
175906 of 175966
Decode time - 25.80s
File duration - 175.96s
682.01% realtime
28.15MHz needed for realtime

nero_320.m4a
175906 of 175966
Decode time - 27.47s
File duration - 175.96s
640.55% realtime
29.97MHz needed for realtime

nero_400.m4a
175906 of 175966
Decode time - 28.79s
File duration - 175.96s
611.18% realtime
31.41MHz needed for realtime

nero_he_64.m4a
175906 of 176017
Decode time - 66.34s
File duration - 176.01s
265.31% realtime
72.36MHz needed for realtime

nero_hev2_64.m4a
175906 of 176034
Decode time - 83.76s
File duration - 176.03s
210.15% realtime
91.36MHz needed for realtime

opus_128k.opus
176786 of 175914
Decode time - 49.59s
File duration - 175.91s
354.72% realtime
54.12MHz needed for realtime

opus_192k.opus
176786 of 175914
Decode time - 57.25s
File duration - 175.91s
307.26% realtime
62.48MHz needed for realtime

opus_256k.opus
176786 of 175914
Decode time - 63.91s
File duration - 175.91s
275.24% realtime
69.75MHz needed for realtime

opus_32k.opus
176786 of 175914
Decode time - 33.42s
File duration - 175.91s
526.36% realtime
36.47MHz needed for realtime

opus_64k_5ms.opus
176811 of 175910
Decode time - 55.54s
File duration - 175.91s
316.72% realtime
60.62MHz needed for realtime

opus_64k_20ms.opus
176786 of 175914
Decode time - 41.08s
File duration - 175.91s
428.21% realtime
44.83MHz needed for realtime

pegase_l1_192.mp1
175908 of 175908
Decode time - 18.09s
File duration - 175.90s
972.36% realtime
19.74MHz needed for realtime

pegase_l2_128.mp2
175897 of 175908
Decode time - 17.95s
File duration - 175.90s
979.94% realtime
19.59MHz needed for realtime

pegase_l1_256.mp1
175908 of 175908
Decode time - 19.59s
File duration - 175.90s
897.90% realtime
21.38MHz needed for realtime

pegase_l2_192.mp2
175897 of 175908
Decode time - 20.88s
File duration - 175.90s
842.43% realtime
22.79MHz needed for realtime

pegase_l1_352.mp1
175908 of 175908
Decode time - 20.24s
File duration - 175.90s
869.07% realtime
22.09MHz needed for realtime

pegase_l2_256.mp2
175897 of 175908
Decode time - 21.07s
File duration - 175.90s
834.83% realtime
22.99MHz needed for realtime

pegase_l1_448.mp1
175908 of 175908
Decode time - 20.53s
File duration - 175.90s
856.79% realtime
22.40MHz needed for realtime

pegase_l2_384.mp2
175897 of 175908
Decode time - 20.57s
File duration - 175.90s
855.12% realtime
22.45MHz needed for realtime

true_audio.tta
175000 of 175000
Decode time - 32.59s
File duration - 175.00s
536.97% realtime
35.75MHz needed for realtime

vorbis_500.ogg
175906 of 175906
Decode time - 29.16s
File duration - 175.90s
603.22% realtime
31.82MHz needed for realtime

vorbis_350.ogg
175906 of 175906
Decode time - 25.20s
File duration - 175.90s
698.01% realtime
27.50MHz needed for realtime

vorbis_096.ogg
175906 of 175906
Decode time - 18.22s
File duration - 175.90s
965.42% realtime
19.88MHz needed for realtime

vorbis_128.ogg
175906 of 175906
Decode time - 18.70s
File duration - 175.90s
940.64% realtime
20.41MHz needed for realtime

vorbis_192.ogg
175906 of 175906
Decode time - 20.51s
File duration - 175.90s
857.63% realtime
22.38MHz needed for realtime

vorbis_256.ogg
175906 of 175906
Decode time - 22.71s
File duration - 175.90s
774.54% realtime
24.78MHz needed for realtime

wmapro_271k.wma
174248 of 178941
Decode time - 23.57s
File duration - 178.94s
759.18% realtime
25.29MHz needed for realtime

wmapro_55k.wma
174248 of 178941
Decode time - 19.01s
File duration - 178.94s
941.29% realtime
20.39MHz needed for realtime

wmapro_80k.wma
174248 of 178941
Decode time - 19.84s
File duration - 178.94s
901.91% realtime
21.28MHz needed for realtime

wmapro_141k.wma
174248 of 178941
Decode time - 21.19s
File duration - 178.94s
844.45% realtime
22.73MHz needed for realtime

wmapro_173k.wma
174248 of 178941
Decode time - 21.83s
File duration - 178.94s
819.69% realtime
23.42MHz needed for realtime

wma_128.wma
174294 of 177504
Decode time - 16.36s
File duration - 177.50s
1084.96% realtime
17.69MHz needed for realtime

wma_192.wma
174294 of 177504
Decode time - 17.05s
File duration - 177.50s
1041.05% realtime
18.44MHz needed for realtime

wma_256.wma
174294 of 177504
Decode time - 17.70s
File duration - 177.50s
1002.82% realtime
19.14MHz needed for realtime

wma_320.wma
174294 of 177504
Decode time - 18.29s
File duration - 177.50s
970.47% realtime
19.78MHz needed for realtime

wma_96.wma
174294 of 177504
Decode time - 16.00s
File duration - 177.50s
1109.37% realtime
17.30MHz needed for realtime

wv_fastx3.wv
175900 of 175906
Decode time - 21.09s
File duration - 175.90s
834.04% realtime
23.02MHz needed for realtime

wv_normx4.wv
175900 of 175906
Decode time - 25.29s
File duration - 175.90s
695.53% realtime
27.60MHz needed for realtime
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 15, 2014, 01:41:49 PM
Looks strange, but "improve_battery_life.patch" improves sometimes decode time and lowers MHZ needed for decoding (look for example vorbis_500.ogg). I can't understand, why player decodes sometimes faster with energy saving patch.

Faster PCLK means that the memory is running faster even when the CPU is running slower.

By the way, I'm assuming those builds aren't really 3.13?  Probably that patch wouldn't apply to it. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 16, 2014, 09:30:01 AM
By the way, I'm assuming those builds aren't really 3.13?
It's a really the old stable 3.13, not a development build. Downloaded from http://download.rockbox.org/release/3.13/rockbox-3.13.7z

Probably that patch wouldn't apply to it.
Applies without any problem.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 18, 2014, 10:47:28 AM
So, to be fully sure I will try a battery test.
Finally, I completed the battery runtime test.
Sansa Clip+ with a connected headphone sony mdr-zx300. Repeat track, flac -q8, stored in internal memory, SD card not connected, default settings.
10h 36m - Untouched rockbox version 3.13 without "improve_battery_life.patch"
17h 44m - Rockbox version 3.13 with "improve_battery_life.patch" (Patch set 5)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 18, 2014, 11:32:59 AM
Good!
Can you check how your player work with sd card? We have report from one user clip+  - it have problem with stability only when sd card inserted. In all other report from clip+/zip user all ok (with and without sd card).

Also if you want you can try on CVDD2 setting on clip+ - just remove #ifdef SANSA_CLIPZIP before it and #endif after it. This should slightly improve battery time on hour or two.

EDIT : better use git version rockbox as 3.13 have problem - usb controller consume quite match if you disconnect player without restart.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 18, 2014, 12:04:55 PM
Good!
Can you check how your player work with sd card?
I just performed a runtime test without SD card for a new fresh sansa clip+.
For an old player, I tried from 13 December with 64 GB SD card up to today.  Works fine without any crash. May be it can help to trace a problem. I don't use a database. Most files contains a FLAC with CD Audio quality, rarely a lossy files. DSP is not turned on except volume. Volume is about -40db. SD Card formatted with MBR with huge cluster size available for FAT32.

Also if you want you can try on CVDD2 setting on clip+ - just remove #ifdef SANSA_CLIPZIP before it and #endif after it. This should slightly improve battery time on hour or two.
I will try that option.

usb controller consume quite match if you disconnect player without restart.
It's good to know. For runtime test I just for case performed a restart.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 18, 2014, 12:19:30 PM
Its also a waste of time to test 3.13 in general since its so old.  That's why I assumed you weren't actually using it before.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 18, 2014, 01:19:02 PM
Quote
Its also a waste of time to test 3.13 in general since its so old.
That version is stable, so I used 3.13 as a check point. May be because of that I don't have a problems with SD card. Will try also a git version and yours test builds.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 18, 2014, 03:29:39 PM
For rockbox stable just means that its an old build, not actually that its likely to work better or have less problems. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 21, 2014, 01:22:00 PM
saratoga:
I received a positive response from the user with problematic clip+. To resolve this we should slightly rise CVDD1 in normal mode -  (0x80 | 20).
Also I receive report about CVDD2 on clip+ - no problem, all work, but user not measure battery time.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 21, 2014, 09:31:00 PM
I tested a lot on the clip + and once I had it get in such a state where the UI lagged quite a lot such that it seemed like buttons weren't working for a bit. Pausing playback fixed it. I guess it was some problem with thread scheduling.  Otherwise its been fine.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 22, 2014, 09:43:10 AM
For rockbox stable just means that its an old build, not actually that its likely to work better or have less problems. 
But why it's called stable instead of old? For me stable means less likely to crash.

I tested a lot on the clip + and once I had it get in such a state where the UI lagged quite a lot such that it seemed like buttons weren't working for a bit.
I can confirm this in my old and new sansa clip+ after changes on CVDD2. For me it's unusable.

saratoga:
Also I receive report about CVDD2 on clip+ - no problem, all work, but user not measure battery time.
I started a new runtime test with SD card. Need two days to complete (before and after changes on CVDD2).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 22, 2014, 01:02:11 PM
Stable meaning unchanging not free of bugs. We fixed lots of stuff since 3.13 which is why its not useful to test it.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 24, 2014, 11:14:22 AM
Also I receive report about CVDD2 on clip+ - no problem, all work, but user not measure battery time.
I can't complete the runtime test. My sansa clip+ just freezes after some hours because I found several times that my device is turned off with full battery and total time with some hours.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 24, 2014, 12:38:38 PM
404_user_not_found:
Can you try slightly rise CVDD2 (change 111 to 112 or 113) and test runtime again?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 25, 2014, 08:37:55 PM
404_user_not_found:
Can you try slightly rise CVDD2 (change 111 to 112 or 113) and test runtime again?
Yes, I can try.

Slightly increased CVDD2. Now player just don't play a music after some hours and I can't navigate in menu. Pressing a button just enables an OLED display but nothing else. Will try to continue increasing a CVDD2.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 28, 2014, 09:34:54 AM
Successfully completed the runtime test. Amazing results. :o

Sansa Clip+ with a connected headphone sony mdr-zx300. Repeat track, flac -q8, stored in SD card, default settings.

16h 45m - with "improve_battery_life.patch" (Patch set 5) without lowering CVDD2.
29h 19m - with "improve_battery_life.patch" (Patch set 5) with applied CVDD2 (113 value).

Not sure about stable number of CVDD2 but for me 113 value in my old and new sansa clip+ plays normally on low demand FLAC without a delay in menu.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 28, 2014, 11:30:55 AM
Fantastic result!

Can you try rise CVDD1 to 20 (in patch it 19), set CVDD2 to 112 and check battery runtime again?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 28, 2014, 02:41:10 PM
I've split out the audio changes:

http://gerrit.rockbox.org/1089

If this looks ok I can commit. 


----

Another thought:  if changing the voltages is easy, I wonder if increasing the audio supply voltages at higher volume settings would enable higher volumes without decreasing battery life. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 28, 2014, 03:48:33 PM
Another thought:  if changing the voltages is easy, I wonder if increasing the audio supply voltages at higher volume settings would enable higher volumes without decreasing battery life.
I measure many variants for audio voltages but can't get better result for volume/THD/power consumption. IMHO DAC limit output voltage and  we can't influence on this.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 28, 2014, 04:42:46 PM
Another thought:  if changing the voltages is easy, I wonder if increasing the audio supply voltages at higher volume settings would enable higher volumes without decreasing battery life.
I measure many variants for audio voltages but can't get better result for volume/THD/power consumption. IMHO DAC limit output voltage and  we can't influence on this.

The 0dB voltage should be referenced to some supply voltage, probably avdd1 or 2, or maybe something else.  But the difference will be small, maybe only 1 or 2 dB volume increase so it might be hard to notice without measuring.  I might try testing this when I get chance. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 28, 2014, 05:04:47 PM
Output stage based on op-amps (https://en.wikipedia.org/wiki/Operational_amplifier). For change gain we should change negative feedback. If we rise supply voltage we don't have gain change. If we set voltage lower than op-amp have need, we have limit volume with huge distortion.

Another variant - get louder signal from DAC, but IMHO we get all possible from it (+6dB).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 28, 2014, 05:44:33 PM
Output stage based on op-amps (https://en.wikipedia.org/wiki/Operational_amplifier). For change gain we should change negative feedback. If we rise supply voltage we don't have gain change. If we set voltage lower than op-amp have need, we have limit volume with huge distortion.

Thats true for a class AB amp, but do the class D amps in these devices work like that?  My understanding is that the gain is proportional to the supply voltage (since they're really just switching the supply on and off).

Another variant - get louder signal from DAC, but IMHO we get all possible from it (+6dB).

You can do this by increasing the gain in the mixer stage, but it simply distorts due to the limited rail voltage on the headphone amplifier. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 28, 2014, 06:36:05 PM
Thats true for a class AB amp, but do the class D amps in these devices work like that?
Are you sure about D class in this player?
I not familiar with class D but in this case we shouldn't have DAC and LDO. Also I not sure is phantom ground possibly on class D.

Quote
You can do this by increasing the gain in the mixer stage, but it simply distorts due to the limited rail voltage on the headphone amplifier.
I test this mode before and it have some problem but not sure about clipping. In any case this not have real sense as mixer worse audio quality.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on December 29, 2014, 12:18:10 PM
Can you try rise CVDD1 to 20 (in patch it 19), set CVDD2 to 112 and check battery runtime again?
Crashed after some hours of runtime test.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 29, 2014, 12:23:14 PM
404_user_not_found:
Ok. Thanks!

saratoga:
Can you provide new test build for clip+ users with CVDD1=20 and CVDD2=113 ?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 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
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 29, 2014, 07:17:59 PM
Clip v2 seems fairly stable unboosted with that patch, but as soon as the clock increases the buttons stop working and the player shuts down (detects power as being held).  Increasing voltages has no effect so I do not think its related.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 30, 2014, 04:32:50 AM
saratoga:
Can you check clip v2 without CVDD1 and CVDD2 mod? And without sd card.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: sancher on December 30, 2014, 05:20:11 AM
Updated builds:

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

I've tested clipplus version (radio, mp3, FLAC, MPC)
Everything is OK!
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 30, 2014, 07:32:34 PM
saratoga:
Can you check clip v2 without CVDD1 and CVDD2 mod? And without sd card.

I tested with both set much higher and it made zero difference so I do not think the problem is voltage. Instead the button driver seems to fail whenever the CPU is boosted, I suspect because one of the delays is set wrong at high pclk.

By the way, has anyone tested the fuze v2 ? Its the only target I don't have.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on December 31, 2014, 04:54:48 AM
If you could provide a build for the fuze v2, I could do the testing.

Cheers
johnb
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on December 31, 2014, 01:02:15 PM
You could try this:

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

Its untested though. 
Title: Re: Sansа Clip Zip - Improve battery life -> Fuze v2 testing
Post by: johnb on January 01, 2015, 05:15:21 AM
I did a clean install, i.e. removed the existing .rockbox.
It is practically unusable for me. I usually end up with one of the two situations:

For the freezing I have the impression, that as long as I keep going (scrolling through the main menu) it's ok, but as soon as I pause for a few seconds and try to scroll again, then it get's stuck. Going into the file menu then usually freezes.
Starting from the recent bookmarks I was able to listen to music (flac, Opus 64 & 220, mpc , mp3, aac), no issue audio wise, but no exhaustive testing.
Once I managed to get to the Debug->Frequency page and noticed that the boost level stayed at 1.


All the above was when doing a fresh boot. Coming from USB mode it at least once was way more stable: going through menus, picking other songs, changing settings.
Looking at the boost level I saw it switching.
It then finally stopped with one of the 'undefined instruction' errors.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 01, 2015, 06:24:13 AM
johnb:
Thanks for report!

saratoga:
I think we should try remove CVDD1 for normal mode in build for fuze v2.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 01, 2015, 06:27:34 PM
Constant CVDD1:

http://web.mit.edu/mgg6/www/rockbox-fuzev2.7z
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 01, 2015, 10:26:53 PM
Looking at the as3525 datasheet, I think we are clocking the DBOP too high due to increased PCLK, and the DBOP is accessed during LCD update, so lets try lowering it:

http://web.mit.edu/mgg6/www/rockbox-fuzev2_2.7z
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 02, 2015, 01:36:56 AM
Setting PCLK to 64MHz fixes the problem on my Clipv2. 

Edit:  Heres a Fuze v2 build with the lower clock.  Would also be interesting to know if this one works:

http://web.mit.edu/mgg6/www/rockbox-fuzev2_64MHz.7z
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 02, 2015, 04:24:51 AM
Setting PCLK to 64MHz fixes the problem on my Clipv2. 

Good. Did you try set bigger divider for DBOP with PCLK=96MHz?

Quote
Edit:  Heres a Fuze v2 build with the lower clock.  Would also be interesting to know if this one works:

If I understood right, fuze v2 have problem only when boost = 0.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 02, 2015, 04:49:41 AM
Constant CVDD1:

http://web.mit.edu/mgg6/www/rockbox-fuzev2.7z
Same behavior: scrolling through the main menu the screen freezes (to be more precise about 'freezing': screen doesn't change anymore, but could also be that the scroll wheel doesn't respond anymore. However, no other timeout kicks in, e.g. screen backlight or wheel light).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 02, 2015, 04:53:40 AM
Quote

If I understood right, fuze v2 have problem only when boost = 0.

For me, I have never seen it go to 0. In my report above in one case it always stayed at 1; when I saw the switching it was between 1 and 3.
frequency always at 192.


Edit: I just retested the 'Constant CVDD1' version: coming from the USB unplug, I am able to start a song from the Files menu. Going to Debug-> Frequency it is at 384 MHz and boost changes in a range from 0 to 5, but then after a while a crash with
SWI at 301c465c
pc: 301c465c  sp: 300A6728
bt end
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 02, 2015, 05:01:39 AM
Looking at the as3525 datasheet, I think we are clocking the DBOP too high due to increased PCLK, and the DBOP is accessed during LCD update, so lets try lowering it:

http://web.mit.edu/mgg6/www/rockbox-fuzev2_2.7z
That was a quick test:
Firmware update, USB unplug, Rockbox asks if it should reboot due to the new firmware -> yes:flickering display, stays in rolo-> screen goes white


Restart, stays in Rockbox boot screen: Boot Vers. 4.0, display turns off due to timeout, moving wheel ->  Boot screen blends into grey screen

Restart by plugging USB  ->screen goes grey/ white

USB connection sometimes works, sometimes doesn't. At least I was able to replace the .rockbox folder without booting into the original firmware.

In short: even worse than the first build, since I don't get out of the boot screen.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 02, 2015, 05:40:15 AM
Setting PCLK to 64MHz fixes the problem on my Clipv2. 

Edit:  Heres a Fuze v2 build with the lower clock.  Would also be interesting to know if this one works:

http://web.mit.edu/mgg6/www/rockbox-fuzev2_64MHz.7z
Reboot question: yes. Stays in 'Rolo executing'. Screen timeout.Scroll wheel -> white screen.

Power down. Fresh reboot: Stays in Rockbox logo/ Boot Ver. 4.0 screen.  Need to power down.

Connecting to USB: USB symbol appears, drive mounts. Screen timeout, moving wheel turns on grey screen or fades from Rockbox logo to grey screen. USB still works.

Edit: Since I just noticed that I had created some recordings in the root dir, I figured that navigation somehow was possible even though I was still in the logo screen.
So new trial: I prepared a track that I could easily navigate to blindly. Rebooting, I can navigate to the song eventhough I still see the Rockbox boot screen. After starting the song, volume change and skipping to the next song is possible. The screen is alive though distorted. Moving the wheel - thus changing volume- every now and then the screen updates and I can see an undistorted WPS screen. Triggering any further update it distorts again.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 02, 2015, 11:17:01 AM
I think devices with a wheel will boost whenever the wheel is used.  Here is one more build:

http://web.mit.edu/mgg6/www/rockbox-fuzev2_64MHz_2.7z
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 02, 2015, 01:12:02 PM
I was about to say this is the most stable one. Tried the following:

1. Boots properly into the main menu. Browsing the main menu  with the wheel for a while, it freezes.

2. Reboot, go immediately to Files and select the first song, it plays. From WPS trying to go to Main Menu/ System it crashes:
undef. instr. @ 300C7BF8 sp: 308049E0

3. Again going directly to Files and play a track, in WPS I am fine: screen updates (long title scrolling, track time counting), FF, pause, resume, screen turns off and on again on activity, track skipping back and forth.
From WPS going to the file browser (center button), playback stops with some crackling noise, then freezes and silence.

4. Boot into main menu, just scrolling for a while, going into the settings menu.
The wheel is very sensitive, don't manage to select the General Settings for a while, cursor rather jumps. Finally I manage to hover over the General Settings, but neither middle button nor right click does anything.
Finally freezes.

5. Again happily in the WPS. Using the Home button to invoke the Playlist, selecting the next track it crashes:
undef. instr. @ 30804A6C sp: 308049A4
Screen turns off.

And this is where I take back the 'most stable' statement. I am not able to power down or reboot (>30s power button; USB connection, ....)

Inserting the headphone I hear two clicks, so I hope it's just not responding and will wait for the battery to drain :-(

Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 02, 2015, 05:32:53 PM
Usually if it crashes bad like that it will eventually reboot if you keep holding power, although it can take a while.

To summarize testing:

Zip:  Works fine.
Clip+:  Seems to be working, but needs slightly higher voltages on some devices.
Clipv2:  Will not work at PCLK = 96MHz, but 64 MHz works fine (verified on skips device as well).
Fuzev2:  Lowering PCLK helps, but does not solve the problem.

Since 64MHz works, but 96MHz seems limited to newer models, I wonder if some of the earlier revisions of the 3525v2 had the v1's limit of 65MHz for the PCLK.    Would be interesting to know how much highe PCLK can go on the Zip too, in case we are already out of spec.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov 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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 03, 2015, 03:30:07 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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga 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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov 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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on January 03, 2015, 07:58:06 PM
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]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Bryanhoop 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!
Title: Re: Sansа Clip Zip - Improve battery life
Post by: florin on January 08, 2015, 04:58:20 AM
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).

Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on January 08, 2015, 05:51:47 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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: sancher on January 08, 2015, 06:17:49 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!
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 08, 2015, 07:06:09 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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on January 08, 2015, 05:18:50 PM
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]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 08, 2015, 05:33:22 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.

#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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on January 09, 2015, 11:26:43 AM
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]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 09, 2015, 01:05:59 PM
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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga 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. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on January 09, 2015, 09:19:50 PM
In practice, I'm strictly against boosting unless its absolutely necessary.
Why?

I'm somewhat surprised that a person who goes to the lengths you have for the sake of efficiency would need to ask this question.

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.

So...experimental, then. Right.

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. 

Viola.

Some sanity. I'm glad someone gets it. There really is no public facing issue here at all, and at best it seems to be sidestepping issues with buggy scaling.


[Saint]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 09, 2015, 09:33:19 PM
I don't think boosting is all that inefficient.  Compared to keeping the screen on the cost is negligible, so I don't see it as an efficiency problem.

I'd just like to focus on one thing at a time.  Having multiple experimental changes at once makes testing complex.  And I still haven't gotten around to committing the audio stuff . . .
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 10, 2015, 06:23:16 AM
In practice, I'm strictly against boosting unless its absolutely necessary.
Why?
I'm somewhat surprised that a person who goes to the lengths you have for the sake of efficiency would need to ask this question.

Without this patch all AMSv2 players always in boost mode :) But I agree, we can discussing it later.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 19, 2015, 03:44:15 PM
saratoga:

oid_maps can help with testing fuze v2. Can you create new build for fuze v2?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 19, 2015, 04:44:14 PM
What do you think should be tested?  Maybe 96MHz PCLK with no other changes? 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 19, 2015, 05:28:57 PM
Yes, we should check 96Mhz PCLK with divided DBOP as you mention early.

Also I think we should try same but with increased delays in dbop-as3525.c.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 26, 2015, 10:07:10 AM
I think devices with a wheel will boost whenever the wheel is used.  Here is one more build:

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

I just put this on the fuze v2 -- since it seems to be the latest build -- but then, when switching to "hold" and coming back, device _sometimes_ does not come back. Reset by holding power-button for several seconds is necessary.

Hangs also on keypress in file browser. Seems to _completely_ hang, since sometimes LCD gets blurred, like when you just leave electrical LCD-contacts open.

Hm ..

By the way: The up to date patches? Since I usually build from source and don't use precompiled images. (I also add one very small minor patch, which has to do with radio tuner region settings.)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 26, 2015, 12:32:58 PM
The latest patch is here:

http://gerrit.rockbox.org/r/#/c/1062/

Here is one other build, which is similar to the others (clock changes) but no boosting:

http://mit.edu/mgg6/www/rockbox-fuzev2.7z

Title: Re: Sansа Clip Zip - Improve battery life
Post by: keyb_gr on January 27, 2015, 06:51:13 PM
I can basically confirm the effect of the sound patch on my new Clip+ (made late 2014):

WARNING: this patch may improve battery life and sound quality :)

Sound quality checked with RMAA and emu-0204.
[...]

No load, 0dB.
Without patch      With patch
Dynamic range, dBA:   93.395.0
THD, %:0.0160.0037
IMD, %:0.0190.0065

A SB Audigy FX said 0.015% THD with a Jan 9 build, with one from Jan 23 (the sound patch was checked in at Jan 19) it's 0.0038%. (Volume +3 dB, RG pre-gain -3.0 dB, no RG tags on files.) IMD+N is noise limited but I don't see any discrete components above -90 dB, pretty good. DR showed about 93 dB(A). Curiously, crosstalk is now up to -70 dB across the band, while it reached 90-ish dB before with some increase towards the highs. If that's purely internal and has nothing to do with headphone xtalk levels, I can live with that.

Oddly enough, my old (late-2010 production) Clip+ already showed fairly low distortion with the "old" build, but its noise was much higher (by 12-13 dB). Shouldn't be when both are using the same RB build and configuration, right? Old results show 0.016% THD though, so possibly the chip incurred some damage in the meantime (maybe the poor thing got zapped one time too many). Output volume isn't any quieter than it should be, it's just noisier.

BTW, RMAA results in 48 kHz mode look like crap because the pitch is way off... almost +0.8%, that's close to classic Clip pitch bug territory. Looks like the PLL settings for that one could still use some tweaking. (I was using 48k because I found that both the Audigy FX and my old onboard ALC262 would catch an unduly amount of extra noise recording in 44.1k, easily 7-8 dB more even when compared to 16/48. I suspect some jitter or aliasing issues. Ultimately I ended up resampling the 48k test files in software so I could play them at 44.1 while recording at 48.)

Has the "turn off USB while not connected" patch been checked in yet (or how well does that part work)? I can't really tell from this thread. Saving 5 mA which are basically being wasted would seem quite attractive.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 27, 2015, 10:17:14 PM
Yes, that is committed. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 28, 2015, 02:36:49 PM
As I mention before - zip consume to much for transferring PCM to DAC. I check DMA - we can use burst mode for better efficacy. Setting burst size to 16 save 1mA. It should be much batter for bigger size, but it don't work correctly for I2SO. Not sure why - I2SO have FIFO 128x36 bit, so bigger burst size should work. IMHO DMA transferring with burst size 16 consume 2mA - it still very much: decoding mp3 consume 2mA.

In any case we very close to 30 hours of mp3 ;)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 28, 2015, 04:26:34 PM
I think I found why we have problem with unboost after usb disconnected.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 29, 2015, 07:43:42 AM
Useful info about DMA:
https://lkml.org/lkml/diff/2010/7/21/498/1
http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka12660.html
http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka11898.html
Title: Re: SansA Clip Zip - Improve battery life
Post by: music_lover001 on January 29, 2015, 06:55:21 PM
Yes, that is committed.
It is very possible that I am unusually dense, but what what committed?  I checked, but did not find anything mentioned in the change log.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 29, 2015, 07:24:46 PM
It is very possible that I am unusually dense, but what what committed?
http://git.rockbox.org/?p=rockbox.git;a=commit;h=02414bf286e4ff6a08d19e951bff1e0905d330b4
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 30, 2015, 06:20:17 AM
The latest patch is here:

http://gerrit.rockbox.org/r/#/c/1062/

Here is one other build, which is similar to the others (clock changes) but no boosting:

http://mit.edu/mgg6/www/rockbox-fuzev2.7z

Hi saratoga,

I am testing this (Version: 64f4518M-150126) at the moment and haven't found any problems so far.

Is there anything particular I should test or look out for? Anything where you would expect potential problems?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 30, 2015, 11:55:19 AM
Is there anything particular I should test or look out for? Anything where you would expect potential problems?

No, just having it work at all is interesting.  Here is one more, this time with frequency scaling enabled:

http://mit.edu/mgg6/www/rockbox-fuzev2-3.7z

Probably it won't work. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Bryanhoop on January 30, 2015, 05:12:21 PM
I'm a little confused about the new patches. Are they in the gerrit yet? Also can
Code: [Select]
Enable frequency and voltage scaling on the AMSv2 devices.
Change-Id: I41a15351a418677fabf1fd2578afc948b3837682
be rebased so I can cherry pick it easily? Something is conflicting.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 30, 2015, 05:19:45 PM
I didn't push any of the clock settings that didn't boot, so the version on gerrit is the most current.

It doesn't merge because the audio changes were already committed separately.  Just ignore those. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 31, 2015, 10:15:00 AM
The latest patch is here:

http://gerrit.rockbox.org/r/#/c/1062/

Here is one other build, which is similar to the others (clock changes) but no boosting:

http://mit.edu/mgg6/www/rockbox-fuzev2.7z

Hi saratoga,

I am testing this (Version: 64f4518M-150126) at the moment and haven't found any problems so far.


This is pretty stable for me. Only once the UI froze while skipping at a fast pace through the current playlist, but I could not reproduce this.
Apart from this single occasion, no problems found.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 31, 2015, 10:22:03 AM

No, just having it work at all is interesting.  Here is one more, this time with frequency scaling enabled:

http://mit.edu/mgg6/www/rockbox-fuzev2-3.7z

Probably it won't work.

Starting from recent bookmarks I can play songs without a problem, FF,  skip through the current playlist.

But walking through the menus or using the file browser, the player either freezes (e.g. at selection of an item) or crashes ( Undef. instruction @ 300C7BF8 ...).

FWIW: mine is a Fuze V2, AMSV2  variant 0
Title: Re: Sansа Clip Zip - Improve battery life
Post by: PagaN on February 04, 2015, 11:52:40 AM
Hello saratoga.
I want to try using LATEST (Improved battery life) firmware on my Clip Zip please give me download link.
p.s. i don't know how to use patches.
Thank You.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 04, 2015, 12:28:16 PM
If you don't want to compile yourself you can use the download link I posted above. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Bryanhoop on February 04, 2015, 02:37:02 PM
Hello saratoga.
I want to try using LATEST (Improved battery life) firmware on my Clip Zip please give me download link.
p.s. i don't know how to use patches.
Thank You.

This is 8aa72f0 for the Clip Zip, plus:

1. voltage/frequency scaling
2. context-sensitive backlight setting patch

https://www.dropbox.com/s/gjjvfk3kkz72dcd/rockbox.zip?dl=0
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 04, 2015, 02:40:34 PM
Or that, although it has the unrelated backlight patch as well.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 04, 2015, 03:54:38 PM
One more fuzev2 patch:

http://mit.edu/mgg6/www/rockbox-fuzev2-4.7z

Same as the above, but this one disables all voltage scaling in case that was the reason it froze on menus. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: PagaN on February 07, 2015, 04:09:32 AM

This is 8aa72f0 for the Clip Zip, plus:

1. voltage/frequency scaling
2. context-sensitive backlight setting patch

https://www.dropbox.com/s/gjjvfk3kkz72dcd/rockbox.zip?dl=0

Well I tested firmwares on my 2 year used ClipZip 4gb 100% charged,
16gb MicroSD full of mp3 files on standard sansa headphones volume (-15dB)

rockbox-KnK_battery_save_v5 [19f4e39M-141206] (16:38h) by Mihail Zenkov
http://forums.rockbox.org/index.php/topic,48368.msg230716.html#msg230716 (http://forums.rockbox.org/index.php/topic,48368.msg230716.html#msg230716)

8aa72f0-150203 (11:36h - official dev build)
8aa72f0-150203 (9:28h by Bryanhoop) seems broken build  :'(

rockbox-clipzip_8be93b7M-141208(16:40h by saratoga) not so stable 3 times gives error and shutdown player
http://forums.rockbox.org/index.php/topic,48549.msg230749.html#msg230749 (http://forums.rockbox.org/index.php/topic,48549.msg230749.html#msg230749)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 07, 2015, 06:17:41 AM
PagaN:
Latest build with all patches for clip zip: http://gdurl.com/c_OQ/download
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 07, 2015, 02:24:45 PM
One more fuzev2 patch:

http://mit.edu/mgg6/www/rockbox-fuzev2-4.7z

Same as the above, but this one disables all voltage scaling in case that was the reason it froze on menus.
thanks, I get no crashes with this build.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 07, 2015, 02:35:09 PM
Thats good to know. I'm traveling so I cannot put up test builds for a few days. Does anyone want to try raising the voltages one by one and see which one was set too low?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 07, 2015, 03:04:50 PM
Does anyone want to try raising the voltages one by one and see which one was set too low?
OK, but it would be helpful, if I had your source code changes.
I tried setting CVDD2 and CVDD1 by changing two lines in system-as3525.c and I still had crashes.
Here's what I tried:
Code: [Select]
/* Set CVDD2 power supply for fuzev2 */
ascodec_write_pmu(0x17, 2, 0x80 | 116);
Code: [Select]
/* Set CVDD1 power supply for fuzev2 */
ascodec_write_pmu(0x17, 1, 0x80 | 47);
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 07, 2015, 04:22:20 PM
All I did was comment out the voltage reduction on unboost.

Edit CPU voltage, cvdd1.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: PagaN on February 08, 2015, 04:23:14 AM
Latest build with all patches for clip zip: http://gdurl.com/c_OQ/download

tested this (f65baf9M-150129) firmware on my 2 year used ClipZip 4gb 100% charged,
16gb MicroSD full of mp3 files on standard sansa headphones volume (-15dB),

I get best result 18:29h and no errors! very unstable (next day I walk on street 1:30h and it freeze and give error 5-6 times) reverted on last devbuild.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 08, 2015, 10:00:54 AM
All I did was comment out the voltage reduction on unboost.

Edit CPU voltage, cvdd1.
I can't set CVDD1 on unboost without crashing my fuzev2 in main menu.
But if I comment that line out, everything works fine.

I tried most voltages between
Code: [Select]
ascodec_write_pmu(0x17, 1, 0x80 | 20);and
Code: [Select]
ascodec_write_pmu(0x17, 1, 0x80 | 47);
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 08, 2015, 11:08:41 AM
Very strange. What clock setting you have in "system > debug >  view hw info" ?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 08, 2015, 11:57:03 AM
Very strange. What clock setting you have in "system > debug >  view hw info" ?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 08, 2015, 12:44:28 PM
rbert:
Can you try force normal (unboost) mode - replace  if(frequency == CPUFREQ_MAX) to if(0) and try find lower stable CVDD1?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 09, 2015, 08:09:31 AM
still no luck, if I try to set CVDD1 during unboosted mode
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 09, 2015, 10:50:37 AM
Even if you set ascodec_write_pmu(0x17, 1, 0x80 | 47); ?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 09, 2015, 11:03:42 AM
Even if you set ascodec_write_pmu(0x17, 1, 0x80 | 47); ?
yes, exactly
something's strange
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 09, 2015, 11:17:38 AM
Yes, very strange. Can you try  0x80 | 47 + attached patch?

EDIT: wrong patch, reattached.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 09, 2015, 11:39:23 AM
Yes, very strange. Can you try  0x80 | 47 + attached patch?
Thank you very much, it works.
Now I can test lower voltages.

EDIT:
no problems with 0x80 | 20
I can now confirm, that my fuzev2 variant0 works like a charm with
- Patch Set 7 471ced2d0f1df1f6e53824197c93e52563fdac3a
- rockbox-restore_irq.patch.txt
- the same changes in firmware/export/config/sansafuzev2.h as in the other config files

EDIT2:
for anyone else to test:
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 13, 2015, 06:20:06 PM
Yes, very strange. Can you try  0x80 | 47 + attached patch?

EDIT: wrong patch, reattached.

That looks like an interesting race condition indeed. 

Edit:  Does it make sense to also protect the ascodec_read_pmu call from an IRQ?  Seems like both could be corrupted.

Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 14, 2015, 09:47:15 AM
I read IRC and I agree with jhMikeS - we should try fix it deeper.  But it to hard for me :(

Zip also have problem with ascodec_write_pmu - I do this changes in patch V4, but I could not reproduce this behavior again and revert in V5.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: jhMikeS on February 14, 2015, 04:33:15 PM
Okiedokie: http://gerrit.rockbox.org/1145/

Whatever the case if it's hard to reproduce, the driver has a problem that this fixes.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 15, 2015, 03:33:43 AM
Yes, very strange. Can you try  0x80 | 47 + attached patch?
Thank you very much, it works.
Now I can test lower voltages.

EDIT:
no problems with 0x80 | 20
I can now confirm, that my fuzev2 variant0 works like a charm with
- Patch Set 7 471ced2d0f1df1f6e53824197c93e52563fdac3a
- rockbox-restore_irq.patch.txt
- the same changes in firmware/export/config/sansafuzev2.h as in the other config files

EDIT2:
for anyone else to test:
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z

My daughter just got an ' Undefined instruction set ...' crash with this build.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 15, 2015, 06:03:32 AM
My daughter just got an ' Undefined instruction set ...' crash with this build.
It was only once or regularly? In which conditions (step to reproduce)?

rbert:
Can you replace my "irq" patch with patch from jhMikeS and test it?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 15, 2015, 07:01:13 AM
My daughter just got an ' Undefined instruction set ...' crash with this build.
It was only once or regularly? In which conditions (step to reproduce)?


So far this was the only occasion (I run it in parallel on my fuze).
What she told me she was doing is: while listening to a song, she went into the file browser and selected a track -> then crashed
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 18, 2015, 06:11:10 PM
rbert:
Can you replace my "irq" patch with patch from jhMikeS and test it?

OK, I just compiled and tested
 - Enable frequency and voltage scaling on the AMSv2 devices. http://gerrit.rockbox.org/r/#/c/1062/ (http://gerrit.rockbox.org/r/#/c/1062/)  Patch Set 7
 - then I cherry-picked jhMikeS patch http://gerrit.rockbox.org/1145/ (http://gerrit.rockbox.org/1145/)
 - and made my changes to firmware/export/config/sansafuzev2.h

Once I got an "Undefined instruction at 300C7BD8",
but otherwise the fuzev2 hangs completely
or only the scroll wheel works, but skips menu items and doesn't react to button presses and usb
Title: Re: Sansа Clip Zip - Improve battery life
Post by: jhMikeS on February 18, 2015, 09:59:48 PM
Okay, it doesn't appear to be a race condition. There's should no race condition in the patched driver. I wonder if certain things happening, like interrupt processing, during a voltage change can cause glitches in operation. I really should patch my Fuze V2 with this scaling patch and dive deeper.

Who has which variant? Mine is variant 0.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 19, 2015, 02:00:07 AM
I have two of variant 0.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rbert on February 19, 2015, 03:59:13 AM
Mine is variant 0, too.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 19, 2015, 06:00:37 AM
Probably we should check ascodec_wait - we have one variant when irq enabled and other when irq disabled. Can we use semaphore_wait when irq disabled?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 21, 2015, 02:14:46 PM
Yes, very strange. Can you try  0x80 | 47 + attached patch?
Thank you very much, it works.
Now I can test lower voltages.

EDIT:
no problems with 0x80 | 20
I can now confirm, that my fuzev2 variant0 works like a charm with
- Patch Set 7 471ced2d0f1df1f6e53824197c93e52563fdac3a
- rockbox-restore_irq.patch.txt
- the same changes in firmware/export/config/sansafuzev2.h as in the other config files

EDIT2:
for anyone else to test:
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z

My daughter just got an ' Undefined instruction set ...' crash with this build.


I have NOT found any issue with this build on MY fuze (and have not heard any further report from my daughter). So I would say it's pretty good.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 21, 2015, 02:28:09 PM
I have NOT found any issue with this build on MY fuze (and have not heard any further report from my daughter). So I would say it's pretty good.

Could you charge the battery and then do a battery bench?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 21, 2015, 03:16:24 PM
I will.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 21, 2015, 03:59:40 PM
I will.

Maybe I misunderstood, but which build is this? 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 22, 2015, 05:35:42 AM
I am using the one posted by rbert in
http://forums.rockbox.org/index.php/topic,48549.msg233959.html#msg233959
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z

471ced2M-150209
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 22, 2015, 03:46:52 PM
I am using the one posted by rbert in
http://forums.rockbox.org/index.php/topic,48549.msg233959.html#msg233959
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z

471ced2M-150209

Sorry, I misunderstood and thought you meant that the newer patch was working. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 22, 2015, 03:50:32 PM
Okay, it doesn't appear to be a race condition. There's should no race condition in the patched driver. I wonder if certain things happening, like interrupt processing, during a voltage change can cause glitches in operation. I really should patch my Fuze V2 with this scaling patch and dive deeper.


Are you sure theres no possible race condition in there?  I don't see how interrupt processing would be more of a problem then audio decoding, and given that it seems to crash on probably the first or second voltage change, its apparently extremely likely to occur in an ISR but rarely or never happening otherwise. 

Plus the fact that it happens on the Fuze v2 but not Zip/Clip+ which have the same SOC makes me wonder if some other thread or peripheral specific to the fuze (scrollwheel, buttons, DBOP, etc) that causes this. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 23, 2015, 06:29:41 AM
Plus the fact that it happens on the Fuze v2 but not Zip/Clip+
As I mention before Zip also affected but in another case. If I remember right, it was when I try change voltage on pause/play.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on February 23, 2015, 01:08:45 PM
But since it depends on when you do it, that sounds like more of a conflict with the button driver I think?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 23, 2015, 02:10:52 PM
Not sure but possibly. What about clipv2 problem? Can you test it with my "irq" patch or you already have solution for it?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on February 23, 2015, 02:42:45 PM
I am using the one posted by rbert in
http://forums.rockbox.org/index.php/topic,48549.msg233959.html#msg233959
http://gregory.bplaced.net/rockbox/rockbox-fuzev2-1.7z

471ced2M-150209

Runtime: 26h 20min
without SD card.
Album with lame v2 (avg. 160 kbps).

Original ear buds.
Code: [Select]
# .cfg file created by rockbox 471ced2M-150209 - http://www.rockbox.org

volume: -30
repeat: all
backlight timeout: 7
volume display: numeric
battery display: numeric
show icons: off
replaygain noclip: on
crossfeed: meier
button light timeout: off

I bought the fuze ~5 years ago as a refurb, so the battery is somewhat aged, but I don't use it regularly. Working horse for commuting is a clip+.

If I remember correctly runtime with the 3.13 release (more than a year ago) was ~20h.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: 404_user_not_found on March 18, 2015, 09:27:17 AM
Tested with the new fresh sansa clip+. Unstable with current patch set. Solved problem by increasing CVDD2 to 114.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: grums on April 01, 2015, 04:22:50 PM
Which patch (link?) do I apply on a Clip+ daily build to see the effect of these developments?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on April 01, 2015, 07:24:01 PM
The latest in the gerrit task I believe, although you'll have to remove the changes to as3514.c as those are already committed. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on April 06, 2015, 01:46:55 PM
Updated builds:

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

Is this compile the most optimized for clip+ as of today?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on April 06, 2015, 03:30:52 PM
Updated builds:

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

Is this compile the most optimized for clip+ as of today?

No it doesn't have the DMA changes or the I2C fix.  I haven't had time to work on this lately though, so you'll have to grab the patches and build yourself. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: g.orlandini on June 01, 2015, 07:31:41 AM
Hi all,

I'm trying to patch last build e606ee4 for my clip+ with patch 7 (http://git.rockbox.org/?p=rockbox.git;a=patch;h=471ced2d0f1df1f6e53824197c93e52563fdac3a;hp=193c5df75d3b6d9e3442e42fa26fd8ccc4c5e3aa) to improve battery life, but I get the following:

patch --dry-run -p1 < "rockbox.git-471ced2d0f1df1f6e53824197c93e52563fdac3a.patch"
checking file firmware/drivers/audio/as3514.c
Reversed (or previously applied) patch detected!  Assume -R? [n]
Apply anyway? [n]
Skipping patch.
6 out of 6 hunks ignored
checking file firmware/export/config/sansaclipplus.h
Hunk #2 succeeded at 194 (offset -1 lines).
checking file firmware/export/config/sansaclipv2.h
checking file firmware/export/config/sansaclipzip.h
Hunk #2 succeeded at 193 (offset -1 lines).
checking file firmware/rolo.c
checking file firmware/target/arm/as3525/clock-target.h
checking file firmware/target/arm/as3525/system-as3525.c
checking file firmware/target/arm/as3525/usb-as3525.c
Hunk #1 FAILED at 33.
1 out of 1 hunk FAILED

Is the patch I'm applying not compatible with the last build e606ee4 or I'm doing something wrong? Where can I download a patched build for clip+ ?

Thanks a lot for your help
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 01, 2015, 12:17:15 PM
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
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 01, 2015, 12:33:41 PM
I also committed the DMA patch, so that should give everyone a very slightly lower CPU usage.  It works for me and in theory is correct, but I'll watch for any problems.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 01, 2015, 05:10:53 PM
I also committed the DMA patch, so that should give everyone a very slightly lower CPU usage.

Good! Can you also review/commit two bug fix:
http://gerrit.rockbox.org/r/#/c/1190/
http://gerrit.rockbox.org/r/#/c/1146/
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 01, 2015, 08:11:42 PM
I also committed the DMA patch, so that should give everyone a very slightly lower CPU usage.

Good! Can you also review/commit two bug fix:
http://gerrit.rockbox.org/r/#/c/1190/
http://gerrit.rockbox.org/r/#/c/1146/

Yes I'll commit those shortly.  I can't login into gerrit though, so I can't close the tasks.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: g.orlandini on June 02, 2015, 03:49:21 AM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 02, 2015, 06:37:56 AM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 03, 2015, 01:07:51 PM
Sorry I have never even looked at the USB stack, but a few people on IRC do know quite a bit about it.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on June 03, 2015, 04:28:37 PM
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 !)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 04, 2015, 07:17:26 AM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on June 04, 2015, 08:47:08 AM
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) ?

Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 04, 2015, 11:08:34 AM
(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.


Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 04, 2015, 02:19:48 PM
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). 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 04, 2015, 04:28:32 PM
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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 04, 2015, 05:20:24 PM
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. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 04, 2015, 06:33:06 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 04, 2015, 07:09:42 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: dreamlayers on June 04, 2015, 08:45:50 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 04, 2015, 09:03:29 PM
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. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 04, 2015, 09:07:12 PM
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? 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on June 04, 2015, 09:08:30 PM
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. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 05, 2015, 12:10:14 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 05, 2015, 12:14:40 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on June 05, 2015, 03:27:42 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on June 05, 2015, 04:51:01 PM
(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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on June 06, 2015, 10:32:35 AM
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).


Title: Re: Sansа Clip Zip - Improve battery life
Post by: g.orlandini on June 25, 2015, 07:39:15 AM
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
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on July 17, 2015, 02:58:58 AM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on July 27, 2015, 05:43:04 AM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on July 28, 2015, 04:38:01 AM
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?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on August 01, 2015, 06:34:18 AM
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).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: florin on August 01, 2015, 06:00:27 PM
Can you upload the build for Clip+ so that I can test too? Thanks.
Title: Sansа Clip Zip binary build including improved battery
Post by: Scalpos on August 05, 2015, 12:54:36 PM
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 ?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on August 08, 2015, 08:19:06 AM
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.)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Scalpos on August 08, 2015, 01:49:01 PM
Thank you very much ! I'll test them in suggested order and will report what I notice.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on August 08, 2015, 05:35:40 PM
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.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on August 09, 2015, 05:42:02 AM
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.)


I am trying these on two different clip+:
- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.
- for a newer one the first build seems stable so far, also with the SDcard inserted. Needs further testing.

Both are AMSv2 variant 1.

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on August 09, 2015, 12:50:23 PM
- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.

Can you test this build: http://knk.zz.mu/rb/clip+.zip ?

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).

All audio patches already commited to rockbox. We switch audio mode when traversing the -40 volume value, so small click unavoidable.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on August 09, 2015, 01:46:29 PM
- on an older refurb both builds crash very fast (browsing the file system, FF through an mp3). With an SDcard even worse.

Can you test this build: http://knk.zz.mu/rb/clip+.zip ?

BTW, it seems the patch that prevents the click when traversing the -40 volume value is not included (posted by Mihail in this thread).

All audio patches already commited to rockbox. We switch audio mode when traversing the -40 volume value, so small click unavoidable.

Hi Mihail,

your build works fine, I couldn't break it so far ;-)

As for the "audio patch" I know that Saratoga had commited it. I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on August 09, 2015, 04:39:52 PM
your build works fine, I couldn't break it so far ;-)

Can you also test next two builds?

http://knk.zz.mu/rb/clip+_20.zip
http://knk.zz.mu/rb/clip+_21.zip

I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.

Very strange. You should have small clicks/distortion on all builds. Better do cold restart (power off and than power on) after installing new build.
I hear more noise and have more power consumption when restarting without power off.
Title: Clip Zip tests
Post by: Scalpos on August 09, 2015, 10:48:13 PM
OK, did some tests with my 3 years old Clip Zip, AMSv2 variant 1; it is loaded with a 32GB Kingston µSDHC Class 10 / UHS-1 reported as SD32G Rev 3.0, Prod: 1/2014, Ser#: 0x00124ACE by Debug/View disk info. Database and dir cache are disabled.

- amsv2_scaling_v8 seems OK, but I experienced µSD card instability: songs played from the card were sometimes skipping to next one after 10-30 seconds, and after reboot Clip often displayed "nothing to resume", just as if the card was missing, and indeed it was not available in files browser. Playing from internal memory was fine. I live in France, and temperature has not exceeded 27 °C the last few days, so it's up to you to decide if this SD card instability might be related to the climate  ;)

- amsv2_scaling_v8+gui_boost+restore_irq has what looks like the same µSD card instability as previous build, plus when the clip was linked to the PC, drives show up, but Windows was not able to recognize them properly. I tried many times, rebooted both the Clip and the PC, with or without the card. Finally, as I had no access anymore to the Clip internal memory from PC in order to update it, I copied with the 3rd build's .rockbox directory onto the card and once loaded into the Clip, I copied it to internal memory. The copy partially failed, but it was enough to have access again to mounted drives with the Clip linked to the PC (full Rockbox reinstall avoided, fortunately).

- amsv2_scaling_v8+gui_boost+restore_irq+CVDD2_113 looks fine so far, no more SD instability for the moment. Had only one issue: at power on, load was stuck displaying Rockbox logo step; ejecting the card, power on + loading the card after the Clip had properly started was enough. I only played few hours with it and will use it as usual this week. I already noticed estimated autonomy looks funny, don't know if Rockbox is lost with the battery improvements. The remaining power percentage shown sometimes jitters: 75% is displayed, then 74%, 75% again and few seconds-minutes later it's back to 74%. Shall I reset anything in order to have it properly calculated, and have it taken into account by Rockbox Information panel ?

Let me know if providing any logs (and how) would help.

BTW, I did not notice any GUI lag using all three builds, Clip was of course restarted after every update.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on August 10, 2015, 02:48:24 PM
your build works fine, I couldn't break it so far ;-)

Can you also test next two builds?

http://knk.zz.mu/rb/clip+_20.zip
http://knk.zz.mu/rb/clip+_21.zip

I DON'T hear the click in the current dev builds nor yours, but in the one by LolaPalocz.

Very strange. You should have small clicks/distortion on all builds. Better do cold restart (power off and than power on) after installing new build.
I hear more noise and have more power consumption when restarting without power off.

I will test the new builds.
I have to take some of my statement back: If I pause playback and the change the volume, I do hear a click, but don't notice during playback.
In the one by LolaPalocz, it's very noticable also during playback.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on August 11, 2015, 02:51:51 PM
While testing I concentrate on the older refurb which seems to be more picky.

Using clip+_20, while listening to music and no particular activity, I suddenly face a crash with "data abort" like in this snapshot or the music stops playing and I have a black screen.
In either case pressing the power button for > 10sec is needed to be able to reboot.

This can happen after 5, 20 or 40min of playback, i.e. I have no indication what triggers it and I failed to reproduce it (e.g. playing the same playlist again).

clip+_21 is next.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: LolaPalocz on August 11, 2015, 03:07:45 PM
(you miss usb patch:  http://forums.rockbox.org/index.php/topic,48549.msg233822.html#msg233822).
Oups. I guess it wasn't essential for me, I'll include it next time I post a patch here or if people want it.

I have to take some of my statement back: If I pause playback and the change the volume, I do hear a click, but don't notice during playback.
In the one by LolaPalocz, it's very noticable also during playback.

I can't check this on a clip+. But I had this click at 40/41 since I started building with this patch (and i quite like it, as an audio feedback that I'm traversing this 40/41).
I checked on my clip zip that I also have it with the nightly dev build (unpatched). Dunno about the clip+.

- amsv2_scaling_v8+gui_boost+restore_irq+CVDD2_113 ...  I already noticed estimated autonomy looks funny, don't know if Rockbox is lost with the battery improvements. The remaining power percentage shown sometimes jitters: 75% is displayed, then 74%, 75% again and few seconds-minutes later it's back to 74%. Shall I reset anything in order to have it properly calculated, and have it taken into account by Rockbox Information panel ?

So, I guess clip zip need 113 to work with all sd cards. Dunno how much more power is used with 113 vs 111.
For the display of power %, I also notice it.
I dont think there's anything to reset, rockbox on the clips just follows a static table battery voltage => % left, so if it quickly goes up and down and up, it's because the battery voltage does this.
It's probably because of the gui_boost patch, which may suddenly draw more power, thus reducing the voltage (so the %). When boost mode is exited, less power is drawn, the battery is happy and shows more voltage (so the %). I wouldn't worry.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on August 11, 2015, 11:22:10 PM
In terms of getting something we could commit, I would really like to see fully stable frequency scaling (ideally on all AMSv2 players) at stock voltages first.  Then we could commit that and work on voltages.  Otherwise its very hard to know what is broken when someone reports a random crash. 
Title: Re: Clip Zip tests
Post by: Mihail Zenkov on August 12, 2015, 12:40:22 PM
Had only one issue: at power on, load was stuck displaying Rockbox logo step; ejecting the card, power on + loading the card after the Clip had properly started was enough.

It was only at once or you can reproduce this behavior?

Using clip+_20, while listening to music and no particular activity, I suddenly face a crash with "data abort" like in this snapshot or the music stops playing and I have a black screen.
In either case pressing the power button for > 10sec is needed to be able to reboot.

Good, I expect this result.

I guess it wasn't essential for me

Essential if you don't reboot player after usb disconnection.

Dunno how much more power is used with 113 vs 111.

Not much, in any case stability is more important.
For the display of power %, I also notice it.

I dont think there's anything to reset, rockbox on the clips just follows a static table battery voltage => % left, so if it quickly goes up and down and up, it's because the battery voltage does this.
It's probably because of the gui_boost patch, which may suddenly draw more power, thus reducing the voltage (so the %). When boost mode is exited, less power is drawn, the battery is happy and shows more voltage (so the %). I wouldn't worry.

Yes, you right.

In terms of getting something we could commit, I would really like to see fully stable frequency scaling (ideally on all AMSv2 players) at stock voltages first.

I think it stable but only with restore irq hack. I still don't have enough time to try fix this problem in more correct way.

Then we could commit that and work on voltages.  Otherwise its very hard to know what is broken when someone reports a random crash. 

You right, but all last crash report reproducible and we can fix it right now.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on August 12, 2015, 12:50:11 PM
I would be happy to do the systematic testing Saratoga suggests (if you can provide the compiles).
In our family we have 4 clip+ and 2 fuze v2.

But I will be on holiday for 4 weeks starting next Tuesday.
Title: Clip+, testbuild 21
Post by: johnb on August 13, 2015, 12:27:15 PM
Using clip+_21, everything seemed fine listening to mp3 and mpc.
Then on a flac album, I felt it was skipping to the next track while in the middle or close to the end of the song.
I couldn't reproduce it on this particular song, but then it happened again on a different song.
Then still in he same session, I got a similar "data abort" crash as with _20.

I will revisit http://knk.zz.mu/rb/clip+.zip with that flac album.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on August 14, 2015, 02:48:26 PM
I will revisit http://knk.zz.mu/rb/clip+.zip with that flac album.

clip+_20.zip have CVDD1=20 (like in  amsv2_scaling_v8)
clip+_21.zip have CVDD1=21
clip+.zip have CVDD1=22

So yes, please test clip+.zip more carefully.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: keyb_gr on August 27, 2015, 04:01:29 PM
^ I've slapped this one onto my bedside Clip+ now and will see how it behaves - fairly recent sample with a Sandisk 64 gig card. Feels just like the last standard build (c3c2c91-150421) so far, complete with the usual quibbles. (The database has been somewhat slugtastic ever since it's no longer being kept in RAM, and the scrobbler is the usual handbrake, with occasional crashes upon skipping back, even if the file played is on the µSD card. Power issue? Race condition during overlapped R/W?)

EDIT: Oops, it doesn't seem to like unplugging from the computer at all - dark screen and need for hard reset. (Safe removal, power not turned off.) Actually the unit is steadily refusing to come back up after attempt #2, even after holding the power button for what seems like an eternity. :o Looks like it has totally hung up. >:( Do I need to wait until the battery is depleted or what, like I once had to with my old Clip with OF? The headphone amp still seems to be running, so it should be a matter of about 2-3 days tops. Still annoying. There must be some quirks in USB disconnect handling still.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: keyb_gr on August 29, 2015, 05:33:48 AM
Phew,  it's alive again. Woke up to find no more activity from the player (a portable MW receiver is good for checking for DC/DC emissions, grabbed my trusty ICF-SW7600 from the drawer of shortwave receivers in this case), plugged it into the computer, booted up. Then it apparently crashed (no drives), so I just unplugged again and reconnected, worked this time. Replaced RB with previous build, pushed a button to turn on the display before unsafely removing it, confirmed "Reboot now?", and now it's charging.

I suppose what may be happening is that after "safe removal", the player returns to unboosted state while still connected when the display is off, and disconnecting external power somehow causes a major glitch. It's not like unplugging from the computer would have been totally trouble-free for me, the occasional crash with abort does occur even with a standard build. Is there anything one can do to track this kind of stuff? I usually can't even read these abort error screens since they're (a) in tiny font (and yours truly can easily compete with any proverbial bat) and (b) only visible for a second or two.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on October 31, 2015, 03:10:06 PM
Mihail:  Could you post the most up-to-date version of your patch?  I'd like to do a little testing but I'm not sure where you are at with the code right now.

Thanks.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on October 31, 2015, 06:24:54 PM
I don't work on this patch last few months.

I have same problem with usb like in keyb_gr last posts. But ...
1. it hard to reproduce - it crash one time for 10-30 connect/disconnect and probably only when we write something
2. not sure is it one problem or few - most time player just freeze with screen on, but one time I have hard lockup - in this state player have screen off and can't be reset by power button, but disconnecting battery (or drain battery like keyb_gr do) help.
3. probably it not related to this patch

In any case I want try debug it. Is rockbox have easy way to write/append in to file (log)? I want find in which function player freeze.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on November 01, 2015, 04:05:38 AM
I guess it is time for me to report back. I have been using Mihail's version: 983c808M-150809 on my clip+.

During regular usage I have not seen any quirks. I am not using any fancy EQs though, just replaygain, sometimes treble & bass, timestretch in podcasts. Formats: mpc, mp3, flac, opus

But I had three incidents in the context of USB:
2 times after safely removing the player (Win7 Pro) I still had the USB logo in the background and a rectangular box over it saying "loading " (I don't remember if it said firmware or file). I had to press power for several seconds for it to recover.

One time when connecting to USB there was a screen saying "prefetch abort ...".

As this happened over the past 2-3 months, I still consider it usable for me. I did have USB problems in-regularly with other builds before too.

P.S. I usually power the player on before connecting to USB.
Title: Patch disables hold-switch on Fuze v2-Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on December 04, 2015, 01:09:44 PM
* amsv2_scaling_v9.patch.txt

Your patch ('amsv2_scaling_v9.patch.txt') deactivates the functionality
of the "hold" button on Sansa Fuze v2: It is simply not functional
anymore, if I operate it it behaves just as if it has not been operated.

Without the patch, it works.

I am using rockbox version ad5e5c4M-151204 (according to the menu item
"System" -> "Rockbox Info" on the device itself),

it is compiled from the rockbox-source from
'git://git.rockbox.org/rockbox', git-checkout done at 2015-12-04 09:52
UTC, last commit was, according to 'git log', at 2015-11-17 21:30:31
UTC by Marcin Bukat:

  commit ad5e5c42fb00334ec0e9b0e9e8c69c4b7d05ac7a
  Author: Marcin Bukat <marcin.bukat@gmail.com>
  Date:   Tue Nov 17 22:40:31 2015 +0100

      hwstub: fix atj213x dsp lua code
   
      Change-Id: I5fbd1799b958bedbe74f91bdcdd8a544e15d2a78

Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 04, 2015, 01:56:32 PM
oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on December 07, 2015, 07:06:13 AM
oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.

Also with all those four patches ("amsv2_scaling_v9.patch.txt" + "rockbox-gui_boost.patch.txt" + "rockbox-usb.patch.txt" + "rockbox-restore_irq.patch.txt") the hold switch is without function.

This might practically decrease battery life, since every accidential turn of the wheel will activate the backlight.
Title: hold switch on fuze v2 -- Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on December 14, 2015, 06:15:36 AM
oid_maps
Can you check amsv2_scaling_v9.patch.txt  + rockbox-gui_boost.patch.txt?
http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910

P.S. I also recommend use rockbox-usb.patch and rockbox-restore_irq.patch if you use amsv2_scaling_v9.patch.txt.

Also with all those four patches ("amsv2_scaling_v9.patch.txt" + "rockbox-gui_boost.patch.txt" + "rockbox-usb.patch.txt" + "rockbox-restore_irq.patch.txt") the hold switch is without function.

This might practically decrease battery life, since every accidential turn of the wheel will activate the backlight.

No idea what could be changed in the patch to regain function of the hold switch?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 14, 2015, 07:52:18 AM
Probably we have problem with delay. Try attached patch.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on December 15, 2015, 05:18:46 AM
Probably we have problem with delay. Try attached patch.

Does not work, but there are some "symptoms" now:

If I switch to "hold", screen goes black very shortly (like a "black"-blinking), then is on again. Sometimes immediately, sometimes after ca. 2 seconds, or anything in between. If the switch stays in hold position, it infinitely continues to blink black, with varying pauses between the blink, anything in between ca. half a second and several seconds.

It seems that, if the device is doing less (no playiing, no scrolling text on the screen), the black-blinks are less often, even "never" (until the timeout for normal display-off occurs).

The device can be operated with the switch in "hold"-position.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 15, 2015, 06:19:22 AM
Another patch with bigger delay:
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on December 24, 2015, 11:55:36 AM
Another patch with bigger delay:

Yes, that does the job, thanks.

Why are the delays important? Race conditions?

Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on December 24, 2015, 02:23:12 PM
Yes, that does the job, thanks.
Thanks for report and testing :)

Why are the delays important? Race conditions?
Fuze v2 have hold and power button on same pin. We need some hack to detect hold state. This hack sensitive to delays.

Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?
Yes, it will be good. When we check buttons state we disable irq. So better have this delays low as possible.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 03, 2016, 05:39:47 PM
Does it make sense if I try to "tweak" the delays as low as possible, or is it negligible effect if the delay is a bit bigger than necessary?
Yes, it will be good. When we check buttons state we disable irq. So better have this delays low as possible.
There are two delays; the second one in your patches is half the time of the first one. How do the delays interact? Should I try arbitrary combinations of both (so it is a two-dimensional problem), should I keep the factor 2 (which makes it an one-dimensional problem), or should the second one be in some, but not strict, relationship to the first one?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 04, 2016, 04:50:31 AM
First, try find lower value for first delay. Then try same for second delay.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 13, 2016, 09:53:11 AM
When just changing the patch and compiling with changed values, everything "up to date" -- which binary to upgrade to the device? fuzpa.bin, or the .rockbox/-tree? (Currently, I copy both over to the device.)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 13, 2016, 11:24:35 AM
fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 13, 2016, 11:44:44 AM
fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa

Ah OK, thanks. But why then is the bootloader 15 MB big? So it's much more than just a loader. Or does it still have the original firmware for some reason -- which just doesn't get executed?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 13, 2016, 12:05:38 PM
The bootloader is a few kilobytes, the rest is the OF.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 14, 2016, 01:38:56 PM
So if the Fuze v2 is fixed by delay changes (???) the only device that absolutely does not work is the Clipv2. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 14, 2016, 03:17:59 PM
Probably we have similar problem with hold/power buttons in clipv2. Can you test attached patch? If it work - try remove second delay.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 14, 2016, 06:10:57 PM
Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch
Title: fuzev2 optimised button delay values - Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 15, 2016, 07:52:00 AM
First, try find lower value for first delay. Then try same for second delay.

So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

Here are the results:


+-------------+--------------+--------+
| First delay | Second delay | works? |
+-------------+--------------+--------+
|          20 |           10 |  yes   |
+-------------+--------------+--------+
|          18 |           09 |   no   |
+-------------+--------------+--------+
|          19 |           10 |  yes   |
+-------------+--------------+--------+
|          18 |           40 |   no   |
+-------------+--------------+--------+
|          20 |           05 |  yes   |
+-------------+--------------+--------+
|          19 |           05 |  yes   |
+-------------+--------------+--------+
|          19 |           01 |   no   |
+-------------+--------------+--------+
|          19 |           03 |   no   | (first, seemed to work, but every few seconds flickers very short)
+-------------+--------------+--------+
|          19 |           02 |   no   |
+-------------+--------------+--------+
|          19 |           04 |  yes   |
+-------------+--------------+--------+


So, shortest possible delays which still work for my device:
1. udelay(): 19, 2. udelay(): 4.

Corresponding patch attached.

@ Mihail Zenkov: Can you include that one in your patchset?

And: Is there a way to make this patches upstream? If not, it would be nice to host it somewhere (that people do not have to dig through all the forum posts to find the correct versions), if hosting is not possible and we have to resort to the forum, then putting everything into one file (.tar-archive, or a single patch file) makes things still more easy.


EDIT 2016-01-15, modified on 2016-01-17: First I thought, first delay 19, second delay 03 are good. But then I noticed very short flickering-on of the screen every few seconds, so I abandoned it.

EDIT 2016-01-17: How I tested: Just switching on the device and see if in "hold"-position screen stays dark.
Are there more/ special conditions I should test?

Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 15, 2016, 07:54:31 AM
fuzpa.bin - bootloader + original firmware, you should update it only if you need changes in bootloader or need new original firmware. Don't update it without good reasons - you can brick player if something going wrong.
For regular update to new rockbox revision - just replace .rockbox/* .
For small internal changes (like you doing with this patch) just replace one file - .rockbox/rockbox.sansa

Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:

Code: [Select]
$ ./configure --no-ccache --target=63 --type=b
  [...]
$ make
  [...]
  CC firmware/target/arm/as3525/sansa-fuzev2/button-fuzev2.c
  [...]

So, what's the reason that the bootloader takes into account that file?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 15, 2016, 07:56:56 AM
The bootloader is a few kilobytes, the rest is the OF.

.. and we still need to append the original firmware when we want to change the bootloader, right? (That's what is documented -- to use "mkamsboot" to patch the original firmware with the rockbox bootloader) Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?

Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?
Title: Re: fuzev2 optimised button delay values - Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 15, 2016, 07:59:53 AM
First, try find lower value for first delay. Then try same for second delay.

So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

[...]

So, shortest possible delays which still work for my device:
1. udelay(): 19, 2. udelay(): 5. (19, 4 still needs to be tested!)

Corresponding patch attached.

A user asked me if I can provide a working build. The forum does not allow to upload archive files. Is there a way I can upload it somewhere to a subpage of rockbox.org? I feel uncomfortable with hosting it by myself ... I did not dig into the legal issues yet (impressum of the website would be needed, warranty-disclaimer maybe, maybe some attribition to property rights I need to make).

Otherwise, I would email the .tar.xz-archive if people ask me directly (private message, and include your email address).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 15, 2016, 09:03:36 AM
I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

For fuse v2 we disable irq when check hold/power buttons, probably we should do same for clip v2.
Title: Re: fuzev2 optimised button delay values - Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 15, 2016, 09:12:22 AM
So, I narrowed the things down to get to know the shortest possible delays where the hold-switch still works on my Sansa fuzev2.

Here are the results:

Ok, thanks!

@ Mihail Zenkov: Can you include that one in your patchset?

Yes, it should by included in next update.

And: Is there a way to make this patches upstream?

We should fix all know issues before.

If not, it would be nice to host it somewhere (that people do not have to dig through all the forum posts to find the correct versions), if hosting is not possible and we have to resort to the forum, then putting everything into one file (.tar-archive, or a single patch file) makes things still more easy.

Probably you right and we should provide single patch for user.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 15, 2016, 09:15:39 AM
Edit:  Both delays set to 10 works pretty well, will try other values:

OK, for me first delay set to 18 and second to 09, but also second to 40, didn't even work (as well as 10, 05 did not work, neither did 12, 06; 14, 07; 16, 08). So maybe either the individual devices differ, or 10, 10 is a combination which would work again? Strange.

Cannot test right now.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 15, 2016, 09:21:32 AM
Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:

So, what's the reason that the bootloader takes into account that file?

We check button state in bootloader - to boot in original firmware or boot recovery mode.

Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?

We can't do separate update for bootloader and original firmware.

Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?

No, it fallback to recovery mode (usb flash drive).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: [Saint] on January 15, 2016, 01:06:42 PM
A user asked me if I can provide a working build. The forum does not allow to upload archive files. Is there a way I can upload it somewhere to a subpage of rockbox.org? I feel uncomfortable with hosting it by myself ... I did not dig into the legal issues yet (impressum of the website would be needed, warranty-disclaimer maybe, maybe some attribition to property rights I need to make).

Otherwise, I would email the .tar.xz-archive if people ask me directly (private message, and include your email address).


Why would you not simply host it on one of the many sites like Data File Host (http://www.datafilehost.com/) or so?

The only real requirement you _must_ undertake is that you need to be able to supply the full source code that generated that binary when asked to do so, as a requirement of the GPL license (note: technically speaking just supplying a patch file and pointing to the Rockbox sources and a given commit that the binary was built from is not actually good enough to satisfy this requirement).


[Saint]
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 15, 2016, 01:44:30 PM
Well, but I observe that also when compiling the bootloader, the file 'button-fuzev2.c' get's compiled:

The bootloader includes button drivers (and most other drivers).

Why is it not sufficient to just have a small bootloader ("fuzpa.bin") without the original firmware?

You could try and implement this, but without the original firmware as a backup you would brick your player if the main rockbox build or bootloader USB became inoperable. 

Does it fallback to the original firmware automagically if we don't have the .rockbox-tree on the device?

No I think it is too late to boot the OF by then since the bootloader will already have run.  Instead it tries to use the bootloader USB mode.  To boot into the OF you must start the process before the bootloader itself runs (since it will overwrite part of the OF in memory).  That is why you must hit a button as soon as you hit power to boot into the OF, any later and its already overwritten.  Possibly this could be changed but there is no reason to.



Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 15, 2016, 01:47:56 PM
I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

For fuse v2 we disable irq when check hold/power buttons, probably we should do same for clip v2.

I will do more testing, I want to make sure that the button problem does not occur in the stock builds before we disable IRQs for 20 microseconds at a time.  It could just be the CPU being overloaded by APE files.  I did test overnight playing APE files, player is still running fine now, so boosting appears quite stable.

I think we should think about committing this in parts. 

First part:  the frequency/voltage scaling code.
Second part:  config file changes to enable frequency scaling
Third part: wait a little while and make sure no one finds a device that breaks when frequency scaling.
Fourth part:  enable voltage scaling.

This way if there is some subset of devices that needs different voltages or delays we will be able to identify and correct them more easily.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 16, 2016, 05:25:28 AM
I will do more testing, I want to make sure that the button problem does not occur in the stock builds before we disable IRQs for 20 microseconds at a time.

Probably we can enable irq before second delay.


I think we should think about committing this in parts. 

Good. At first step I suggest test and commit frequency changes and related fix for buttons .
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 16, 2016, 06:27:55 PM
Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work
(I did apply the following patches, in that order:
amsv2_scaling_v9.patch
fix_button_clipv2_irq.patch
fix_hold_fuzev2.patch (with adjusted delay values)
rockbox-gui_boost.patch
rockbox-restore_irq.patch
rockbox-usb.patch

and an own patch which enables maximum hardware supported frequency range (76 .. 108 MHz) and finest granularity (0.05 MHz) of the radio tuner)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 16, 2016, 07:13:26 PM
Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work

If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze. 
Title: Re: fuzev2 optimised button delay values - Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 17, 2016, 04:36:59 AM
OK, first delay 19, second delay 4 works for me (fuze v2).

How I tested: Just switching on the device and see if in "hold"-position screen stays dark.

Are there more/ special conditions I should test?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 17, 2016, 04:42:21 AM
Adding the delay fixes boosting (well played for a few minutes at least).

Removing the second delay causes immediate reboot. 

I did notice that during frequent boosting some button inputs are skipped, although maybe that is unrelated.

Edit:  Both delays set to 10 works pretty well, will try other values:

http://mit.edu/mgg6/www/rockbox-clip_10_10delay.7z

Edit2:  diff:  http://mit.edu/mgg6/www/amsv2_scaling_v10.patch

Confirmed: For my fuzev2, both delays to 10 does _not_ work

If you're referring to the 10 delay above, thats for the ClipV2, it won't do anything on the Fuze.

Ah, OK. That wasn't clear from your writings, and since we were discussing fuzev2 and you didn't state otherwise I assumed you meant fuze v2.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 18, 2016, 04:41:39 PM
I pushed the updated delays for the clipv2.  If 19,4 are the lowest values that work on the Fuzev2, should I commit 20,5 to be safe?  Or maybe even 22,6 just in case since we only tested on a single device?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 18, 2016, 04:57:41 PM
I think 20,5 should be good for start. If we start with 22,6, we do not dare to reduce it in the future and do not know optimal value.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 18, 2016, 05:12:06 PM
One question, any idea why such a long udelay is needed with frequency scaling? I'm surprised that button read out should be so dependant on CPU frequency.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 18, 2016, 05:59:14 PM
Committed fuze delays and usb boost. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 18, 2016, 06:04:50 PM
One question, any idea why such a long udelay is needed with frequency scaling? I'm surprised that button read out should be so dependant on CPU frequency.

Not sure. Probably delay by udelay depends not only from CPU freq but also from PCLK. Or we need much more delay when GPIO work on boosted clock.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 18, 2016, 06:26:26 PM
Test builds with frequency scaling enabled but not voltage scaling:

http://mit.edu/mgg6/www/rockbox-clipv2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-fuzev2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clip+_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clipzip_frequency_test.7z

Source for just this change:

http://gerrit.rockbox.org/r/#/c/1242/

Edit:  Updated builds.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 18, 2016, 06:51:26 PM
Source for just this change:

http://gerrit.rockbox.org/r/#/c/1242/

It not critical, but I think we should change CPU_FREQ to 192000000. Also we should add changes for config/sansafuzev2.h.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 18, 2016, 07:01:16 PM
Thanks, overlooked both of those.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: oid_maps on January 19, 2016, 05:36:46 AM
I want to re-ask: Which "stress-tests" should I do to test if the delay values for fuzev2 work reliably? Or is it enough if without playing anything I see no flickering when switching to "hold"-position? (Anyway, flickerings could be that short that they wouldn't be visible with the human eye -- should there be some log data written out one could analyse afterwards?)
Title: Re: Sansа Clip Zip - Improve battery life
Post by: cereal_killer on January 19, 2016, 10:30:39 AM
Test builds with frequency scaling enabled but not voltage scaling:

http://mit.edu/mgg6/www/rockbox-clipv2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-fuzev2_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clip+_frequency_test.7z
http://mit.edu/mgg6/www/rockbox-clipzip_frequency_test.7z

Source for just this change:

http://gerrit.rockbox.org/r/#/c/1242/

Edit:  Updated builds.

I am not sure if this is something relevant, but I tested the clipv2 build and experienced a short delay when navigating from WPS to file browser and then to the parent directory with a button press to the left. Music is playing and not paused. This doesn't happen with the current dev build.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 19, 2016, 11:08:10 AM
I am not sure if this is something relevant, but I tested the clipv2 build and experienced a short delay when navigating from WPS to file browser and then to the parent directory with a button press to the left. Music is playing and not paused. This doesn't happen with the current dev build.

We know about this issue (http://forums.rockbox.org/index.php/topic,48549.msg233424.html#msg233424) and have temporary solution (http://forums.rockbox.org/index.php/topic,48549.msg234910.html#msg234910).
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 19, 2016, 11:12:37 AM
The CPU speed is definitely much lower during normal use, on the other hand we used to run on even slower devices so I'm surprised a simple GUI like on the clip lags.
Title: Re: Sansа Clip Zip - Improve battery life -> Fuze v2 udelay
Post by: johnb on January 19, 2016, 02:31:23 PM
I tested three fuze v2 builds that Oid Maps had provided me (will all saving patches active I believe and varying delays).
I have two devices, these are the results:

19_5: works with both
19_4: works with both
19_3: works fine with one. With the second the display shines through for a short time (flickers) when keys are pressed and a few secs afterwards.


I will now move on and test the builds that saratoga provided both on my fuzes and clip+es.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 20, 2016, 06:49:36 AM
The CPU speed is definitely much lower during normal use, on the other hand we used to run on even slower devices so I'm surprised a simple GUI like on the clip lags.

What should we change in gui boost patch to see  it in mainstream?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 20, 2016, 12:01:49 PM
The CPU speed is definitely much lower during normal use, on the other hand we used to run on even slower devices so I'm surprised a simple GUI like on the clip lags.

What should we change in gui boost patch to see  it in mainstream?

If I understand correctly, that patches changes the current boost on scrollwheel behavior to boost on any button press and then enables it for AMSv2 targets? 

I think enabling boost on scrollwheel for the fuzev2 should happen regardless, all other scroll wheel targets do it, and its probably necessary.  I'm not sure about the other change to make boost happen on more types of button press, we should probably talk to other people about it.  Testing on my Clip Zip playing MP3 (fast enough that there is no boosting at all) I notice that menu transitions involving album art are noticeably slower when unboosted, but otherwise everything seems comparable.  I don't think boost is really necessary, but I am ok with enabling it as the cost is very low. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 20, 2016, 01:02:11 PM
If I understand correctly, that patches changes the current boost on scrollwheel behavior to boost on any button press and then enables it for AMSv2 targets? 

Yes.

I think enabling boost on scrollwheel for the fuzev2 should happen regardless, all other scroll wheel targets do it, and its probably necessary.  I'm not sure about the other change to make boost happen on more types of button press, we should probably talk to other people about it.

Many people note low response rate with frequency scaling patch. We can boost not at all buttons, but is it have sense?

Testing on my Clip Zip playing MP3 (fast enough that there is no boosting at all) I notice that menu transitions involving album art are noticeably slower when unboosted, but otherwise everything seems comparable.  I don't think boost is really necessary,

I feeling mostly same, but I don't use EQ or DB.

but I am ok with enabling it as the cost is very low.

Yes, few minutes at boost - mostly nothing for whole playing time.
Title: Re: Sansа Clip Zip - Improve battery life -> Fuze v2 udelay
Post by: oid_maps on January 22, 2016, 05:55:21 AM
I tested three fuze v2 builds that Oid Maps had provided me (will all saving patches active I believe and varying delays).
I have two devices, these are the results:

19_5: works with both
19_4: works with both
19_3: works fine with one. With the second the display shines through for a short time (flickers) when keys are pressed and a few secs afterwards.

To complete the information, those builds are based on the following git sources:
* delays of 19, 05 and 19, 04: Rockbox source from 2016-01-16,
* delays 19, 03: Rockbox source from 2015-12-26,

and then patched with the following patches, applied in that order:

* amsv2_scaling_v9.patch
* fix_button_clipv2_irq.patch
* fix_hold_fuzev2-2.patch
(with varying delays, see above),
* rockbox-gui_boost.patch
* rockbox-restore_irq.patch
* rockbox-usb.patch

as posted in this forum,
as well as the patch

rockbox_firmware_tuner.c.diff

which is by myself and enables the maximum available frequency range
(76..108 MHz) and minimum available frequenc granularity (0.05 MHz) of
the device when the tuner setting REGION_OTHER is selected.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on January 23, 2016, 05:51:27 PM
Committed frequency scaling.  Do we want to do boost next?  Its probably annoying to use the Fuze V2 without it. 

Edit:  Just realized its already enabled, but only for the scroll wheel. 
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on January 23, 2016, 06:17:40 PM
Committed frequency scaling.

Great! We do that ;)

Do we want to do boost next?

Yes, as it fix regression in responsiveness. Also it can help with quick identification of problems in boost.

Its probably annoying to use the Fuze V2 without it. 
Edit:  Just realized its already enabled, but only for the scroll wheel. 

It also read scroll wheel each 5ms. All other AMSv2 targets read buttons each 10ms.
Title: Fuze v2: frequency scaling
Post by: johnb on January 30, 2016, 11:15:04 AM
On the fuze v2 the USB connection seems more unstable (Win10):
Plugging in the device (which was completely off), it boots, shows my recent bookmark list, then displays the USB logo. It does not mount properly on the PC.
Unpluggin it, the logo stays, but it's not completely stuck: the clock display updates, remaing battery life is displays 222h 0m, screen timeout is active, I can even use the Hold key, but the USB logo stays.

I have not seen this, when booting the device before plugging into USB.

My first tests involved a USB hub, then I also tried directly with the USB socket on the PC. There a first try worked fine, on the second same behaviour as above.

Using the "long power off", I shows a "undefined instruction at 000003c" until if finally turns off.

Other than that, I had no problems so far.
-------------------------------
Doing the same thing with the clip+ it goes into bootloader usb mode, which I suppose is the expected behaviour. Is it normal that only the internal memory is mounted, but not the sdcard?
Title: Fuze v2: frequency scaling --> version string
Post by: johnb on January 30, 2016, 11:34:56 AM
While the rockbox-info.txt from Sartoga's 7z file states
Version: ad18fa3-160119
the System->Rockbox Info on the player shows
Version: ad18fa3-160118

Should I care?
Title: Re: Fuze v2: frequency scaling
Post by: saratoga on January 30, 2016, 01:45:19 PM
On the fuze v2 the USB connection seems more unstable (Win10):

Could you clarify what you are testing and what you are comparing to?
Title: Re: Sansа Clip Zip - Improve battery life
Post by: johnb on January 31, 2016, 03:34:02 AM
Hi saratoga,

I apologize for the wording, I actually have no proof that it's "MORE unstable".
I am using your "frequency scaling" build from this thread (ad18fa3-160119).

Before that I have been using various other "battery optimized" versions from this thread. Maybe 2 months ago I upgraded from Win7 to Win10. I just don't recall seeing this behavior over the last year or so, but maybe it is just that the fuze was usually turned on before I connected it, which is anyway not as regular as with my clip+ which I use for podcasts whereas the fuze has a rather stable collection on the sdcard.


Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on February 20, 2016, 12:22:18 PM
Fixes for USB freezes (especial on USB extraction):
http://gerrit.rockbox.org/r/1269
http://gerrit.rockbox.org/r/1270
http://gerrit.rockbox.org/r/1271 (was posted in this tread before as rockbox-usb.patch)
http://gerrit.rockbox.org/r/1272

Affected AMSv2 and AMSv1.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: raige on May 15, 2016, 03:54:36 PM
Sorry to bump.
Please could someone post a simple firmware for Clip ZIp with better battery life and mods?

I've tried to read this entire thread, but it seems to have diverted to clip fuze and scaling.

I wanted simple clip zip better firmware with cpu scalling & better battery life and any other cool clip zip mods.

hopefully on a prebuilt fw?

thanks guys!
Title: Re: Sansа Clip Zip - Improve battery life
Post by: Mihail Zenkov on May 15, 2016, 04:03:13 PM
You should use latest "dev builds" as all patches from this topic already committed.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rrrrrrrrrrrr on May 30, 2016, 11:10:19 PM
What's the most recent dev build? The one I have is version d0d66f3-16032, which was linked from another thread on this site.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: saratoga on May 31, 2016, 08:38:52 AM
Check the "dev builds" link on the left side of the screen.
Title: Re: Sansа Clip Zip - Improve battery life
Post by: rrrrrrrrrrrr on June 01, 2016, 10:49:38 PM
Thank you.