Rockbox Technical Forums
Support and General Use => Hardware => Topic started 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
-
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.
-
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.
-
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.
-
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.
-
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.
-
I check PCLK - try 12MHz and 6Mhz - no significant difference.
-
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%.
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
Checked - no significant difference at pause, low volume (-35dB) and high (0dB).
-
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 :)
-
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.
-
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 :)
-
Freenode offers an IRC web-client, as linked on the left hand side of the page (https://webchat.freenode.net/?channels=rockbox).
[Saint]
-
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
-
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?
-
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.
-
Current git + 1.1v CPU (no change to other clocks): 15h 0min
Is 1.1V lower stable voltage on 240Mhz?
-
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.
-
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.
-
New version with frequency scaling based on as3525v2-cpufreq-v11.patch.
-
I'm curious how stable frequency scaling is for you?
-
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.
-
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.
-
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).
-
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.
-
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.
-
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?).
-
Can you try increase CVDD1?
-
I'm testing that right now, < 1.0 volts may not be safe. This is an older 130 nm chip.
-
I use for test two player, both manufactured 9 months ago.
-
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.
-
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.
-
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.
-
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?
-
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?
-
Sorry, I mean change PLLA and have FCLK 180 / PCLK 90.
-
Maybe just seeing if FLCK switching from 240 to 24 at constant PCLK works would be best?
-
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.
-
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.
-
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?
-
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.
-
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":
/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.
-
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.
-
Changes in V5:
- set PLLA=192mHz, disable PLLB
- set FCLK=192mHz and PCLK=96mHz at boost
- set FCLK=38.4mHz and PCLK=19.2mHz at normal
- minimize pop-click noise
- fix boot firmware though rolo
- disable mixer and connect DAC directly to output when volume -40dB or louder
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.1 | 93.6 |
THD, %: | 0.046 | 0.037 |
IMD, %: | 0.061 | 0.041 |
No load, 0dB.
| Without patch | With patch |
Dynamic range, dBA: | 93.3 | 95.0 |
THD, %: | 0.016 | 0.0037 |
IMD, %: | 0.019 | 0.0065 |
Original firmware show same result as rockbox without patch.
-
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.
-
Yes, for testing stability frequency scaling better use APE - in this case CPU switch to boost and back to normal each second.
-
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.
-
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.
-
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.
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.
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?
-
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.
-
21 hours 29 minutes.
Not bad.
-
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.
-
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.
-
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.
-
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.
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?
-
http://pastebin.com/tTXpLSsj
Patch with cleaned up USB.
You can also remove frequency_lock.
-
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/
-
Good.
-
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
-
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?)
-
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.
-
Would this patch also be effective on a Sansa e200v2?
-
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.
-
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.
-
You try old patch - look at date, try patch from this topic or gerrit: http://gerrit.rockbox.org/r/#/c/1062/
-
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.
-
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).
-
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.
-
We haven't updated the time remaining calculation show it won't change.
-
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"
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)
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
-
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.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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.
-
For rockbox stable just means that its an old build, not actually that its likely to work better or have less problems.
-
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.
-
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.
-
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).
-
Stable meaning unchanging not free of bugs. We fixed lots of stuff since 3.13 which is why its not useful to test it.
-
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.
-
404_user_not_found:
Can you try slightly rise CVDD2 (change 111 to 112 or 113) and test runtime again?
-
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.
-
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.
-
Fantastic result!
Can you try rise CVDD1 to 20 (in patch it 19), set CVDD2 to 112 and check battery runtime again?
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
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.
-
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.
-
404_user_not_found:
Ok. Thanks!
saratoga:
Can you provide new test build for clip+ users with CVDD1=20 and CVDD2=113 ?
-
Updated builds:
http://web.mit.edu/mgg6/www/rockbox-clipv2.7z
http://web.mit.edu/mgg6/www/rockbox-clipplus.7z
-
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.
-
saratoga:
Can you check clip v2 without CVDD1 and CVDD2 mod? And without sd card.
-
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!
-
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.
-
If you could provide a build for the fuze v2, I could do the testing.
Cheers
johnb
-
You could try this:
http://web.mit.edu/mgg6/www/rockbox-fuzev2.7z
Its untested though.
-
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:
- The UI freezes.
- I get an error like:
undefined instruction at 300C7BF8
pc: 300C7BF8 sp: 308049E0
bt end
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.
-
johnb:
Thanks for report!
saratoga:
I think we should try remove CVDD1 for normal mode in build for fuze v2.
-
Constant CVDD1:
http://web.mit.edu/mgg6/www/rockbox-fuzev2.7z
-
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
-
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
-
Setting PCLK to 64MHz fixes the problem on my Clipv2.
Good. Did you try set bigger divider for DBOP with PCLK=96MHz?
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.
-
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).
-
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
-
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.
-
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.
-
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 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 :-(
-
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.
-
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.
-
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?
-
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.
-
I look at dbop-as3525.c and see "magic" delay in line 47 and 108, maybe we should check it?
-
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]
-
I just want to pop in and thank you guys for doing this work/testing. Really exciting stuff!
-
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).
-
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.
-
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!
-
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.
-
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]
-
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?
-
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]
-
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?
-
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.
-
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]
-
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 . . .
-
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.
-
saratoga:
oid_maps can help with testing fuze v2. Can you create new build for fuze v2?
-
What do you think should be tested? Maybe 96MHz PCLK with no other changes?
-
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.
-
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.)
-
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
-
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.3 | 95.0 |
THD, %: | 0.016 | 0.0037 |
IMD, %: | 0.019 | 0.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.
-
Yes, that is committed.
-
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 ;)
-
I think I found why we have problem with unboost after usb disconnected.
-
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
-
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.
-
It is very possible that I am unusually dense, but what what committed?
http://git.rockbox.org/?p=rockbox.git;a=commit;h=02414bf286e4ff6a08d19e951bff1e0905d330b4
-
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?
-
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.
-
I'm a little confused about the new patches. Are they in the gerrit yet? Also can
Enable frequency and voltage scaling on the AMSv2 devices.
Change-Id: I41a15351a418677fabf1fd2578afc948b3837682
be rebased so I can cherry pick it easily? Something is conflicting.
-
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.
-
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.
-
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
-
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.
-
If you don't want to compile yourself you can use the download link I posted above.
-
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
-
Or that, although it has the unrelated backlight patch as well.
-
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.
-
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)
-
PagaN:
Latest build with all patches for clip zip: http://gdurl.com/c_OQ/download
-
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.
-
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?
-
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:
/* Set CVDD2 power supply for fuzev2 */
ascodec_write_pmu(0x17, 2, 0x80 | 116);
/* Set CVDD1 power supply for fuzev2 */
ascodec_write_pmu(0x17, 1, 0x80 | 47);
-
All I did was comment out the voltage reduction on unboost.
Edit CPU voltage, cvdd1.
-
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.
-
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
ascodec_write_pmu(0x17, 1, 0x80 | 20);
and
ascodec_write_pmu(0x17, 1, 0x80 | 47);
-
Very strange. What clock setting you have in "system > debug > view hw info" ?
-
Very strange. What clock setting you have in "system > debug > view hw info" ?
-
rbert:
Can you try force normal (unboost) mode - replace if(frequency == CPUFREQ_MAX) to if(0) and try find lower stable CVDD1?
-
still no luck, if I try to set CVDD1 during unboosted mode
-
Even if you set ascodec_write_pmu(0x17, 1, 0x80 | 47); ?
-
Even if you set ascodec_write_pmu(0x17, 1, 0x80 | 47); ?
yes, exactly
something's strange
-
Yes, very strange. Can you try 0x80 | 47 + attached patch?
EDIT: wrong patch, reattached.
-
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
-
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.
-
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.
-
Okiedokie: http://gerrit.rockbox.org/1145/
Whatever the case if it's hard to reproduce, the driver has a problem that this fixes.
-
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.
-
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?
-
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
-
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
-
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.
-
I have two of variant 0.
-
Mine is variant 0, too.
-
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?
-
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.
-
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?
-
I will.
-
I will.
Maybe I misunderstood, but which build is this?
-
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
-
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.
-
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.
-
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.
-
But since it depends on when you do it, that sounds like more of a conflict with the button driver I think?
-
Not sure but possibly. What about clipv2 problem? Can you test it with my "irq" patch or you already have solution for it?
-
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.
# .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.
-
Tested with the new fresh sansa clip+. Unstable with current patch set. Solved problem by increasing CVDD2 to 114.
-
Which patch (link?) do I apply on a Clip+ daily build to see the effect of these developments?
-
The latest in the gerrit task I believe, although you'll have to remove the changes to as3514.c as those are already committed.
-
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?
-
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.
-
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
-
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
-
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.
-
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/
-
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.
-
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.
-
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.
-
Sorry I have never even looked at the USB stack, but a few people on IRC do know quite a bit about it.
-
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 !)
-
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.
-
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) ?
-
(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.
-
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).
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
(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.
-
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).
-
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
-
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.
-
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.
-
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?
-
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).
-
Can you upload the build for Clip+ so that I can test too? Thanks.
-
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 ?
-
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.)
-
Thank you very much ! I'll test them in suggested order and will report what I notice.
-
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.
-
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).
-
- 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.
-
- 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.
-
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.
-
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.
-
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.
-
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.
-
(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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
^ 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.
-
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.
-
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.
-
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.
-
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.
-
* 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
-
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.
-
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.
-
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?
-
Probably we have problem with delay. Try attached patch.
-
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.
-
Another patch with bigger delay:
-
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?
-
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.
-
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?
-
First, try find lower value for first delay. Then try same for second delay.
-
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.)
-
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
-
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?
-
The bootloader is a few kilobytes, the rest is the OF.
-
So if the Fuze v2 is fixed by delay changes (???) the only device that absolutely does not work is the Clipv2.
-
Probably we have similar problem with hold/power buttons in clipv2. Can you test attached patch? If it work - try remove second delay.
-
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
-
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?
-
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:
$ ./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?
-
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?
-
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).
-
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.
-
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.
-
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.
-
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).
-
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]
-
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.
-
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.
-
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 .
-
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)
-
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.
-
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?
-
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.
-
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?
-
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.
-
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.
-
Committed fuze delays and usb boost.
-
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.
-
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.
-
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.
-
Thanks, overlooked both of those.
-
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?)
-
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.
-
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).
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
On the fuze v2 the USB connection seems more unstable (Win10):
Could you clarify what you are testing and what you are comparing to?
-
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.
-
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.
-
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!
-
You should use latest "dev builds" as all patches from this topic already committed.
-
What's the most recent dev build? The one I have is version d0d66f3-16032, which was linked from another thread on this site.
-
Check the "dev builds" link on the left side of the screen.
-
Thank you.