Rockbox Technical Forums
Support and General Use => Hardware => Topic started by: Mihail Zenkov on January 01, 2017, 03:15:13 AM
-
I have new idea how improve power consumption even more: add scaling for CVDD2 and PVDD1. We can set CVDD2 to low value when internal and external flash/SD at idle. Also we can set lower value for PVDD1 for lower volume.
So I have prepared new patch (hack ;)) and builds for tests.
So what expected?
1. Improved battery life - up to 30 hours playtime on mp3 on Clip Zip.
2. Minor improvements in audio quality at 0 dB, notable at <= -9 dB and major at > 0 dB (as with new settings clipping at high volume should be completely eliminated).
3. Freezes and bugs as always :)
Know problems:
1. Backlight of screen (on Clip Zip) changes brightness if flash/SD in usage and if you switch volume > 0 dB.
2. At this moment I test only DAC, so problems with ADC (recordings) or FM can be expected.
So what I want to know?
1. Is it works at all on others players? Write the name and variant (system > debug > view hw info) of your player and result.
2. If it works without big problems - try do battery runtime testing.
http://knk.square7.ch/cvdd2/rocobox-cvdd2_scaling-0.patch
Builds with this patch + i2sout_without_dma.patch (http://forums.rockbox.org/index.php/topic,51184.0.html):
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-12.zip
http://knk.square7.ch/cvdd2/rockbox-clipv2-cvdd2_scaling-12.zip
http://knk.square7.ch/cvdd2/rockbox-fuzev2-cvdd2_scaling-12.zip
http://knk.square7.ch/cvdd2/rockbox-zip-cvdd2_scaling-12.zip
P.S. Don't touch new settings in debug menu (*VDD*) if you not sure what you doing :)
Technical details:
PVDD1 derived from CVDD2.
PVDD1 used by digital part of DAC and ADC.
CVDD2 used by for flash, SD, RAM and probably OLED, some part of USB (and maybe something else). At now I can't set lower value for CVDD2 due internal flash instability. But I still hope to find solution and got 40 hours from Clip Zip at some day :)
Audio settings:
AVDD17 derived from AVDD27.
AVDD17 used by analog part of DAC and ADC. Also used by others analog parts. If we rise it we got bigger maximum output volume. But at some point we got clipping. So I tune CVDD2, PVDD1 and AVDD17 for get maximum possible volume without clipping. Lower value of PVDD1 consume less power and slightly improving THD/IMD but at very low value we got clipping - so best value depend from volume.
All measurements (more than 100 measurements) was done with RMAA and Emu0204 with load 32 om.
I also checked again AUDIOSET2_HPH_QUALITY_HIGH + AUDIOSET3_HP_BIAS_150. It consume only 0.2 mA. At high volume (>= 0 dB) mostly no difference in audio quality. But if volume <= -9 dB we have notable improvement (THD better for 35%).
-
Thanks for this, will test this ASAP!
Newb question - apart from replacing everything in .rockbox with this, are there any more steps necessary for successful boot?
-
No, just shut down once after copying over.
-
I'm experiencing freezing when trying to play any sort of file (all Opus in my case).
Edit: It took approx. 2 minutes to load single Opus file. No change even with FLAC.
Basically everything takes more time (even shutting down)
Running on Clip+
-
Which exactly variant of clip+ you have (system > debug > view hw info)?
-
[Submodel:]
AMSv2 variant 1
Edit: Output is notably increased with this mod. 1041mVrms with no distortion. Bravo!
Battery seems to be reporting about the same values as before, though no testing was done yet.
-
Try this: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-1.zip - less power saving but probably more stability.
Edit: Output is notably increased with this mod. 1041mVrms with no distortion. Bravo!
Good :) But be warned: at >0 dB it consume more power than current rockbox.
Battery seems to be reporting about the same values as before, though no testing was done yet.
We are can't directly measure battery consumption from firmware. We do battery runtime testing and than just set this value to firmware.
So only battery runtime testing can show right value.
-
My apologies, the previous build is working OK as long as the frequency is set to 48kHz while playing Opus.
I had it set to 44.1kHz to mitigate the pitch problem from another thread. I switched it back and it's much more responsive.
Nevertheless I'll try this updated version and report back.
-
scaling-1 now works fine even with extra resampling in the way (48k->44.1k)
-
clip+ variant1, still reporting on the first build: works ok when running mp3 from internal memory, but fails on sd access:
with dir cache on it takes a while but the shows the top level dirs, but trying to enter an album directory it shows (if at all) as empty.
This is with a Samsung EVO 64GB card.
-
asymsucon, johnb:
Did you see abnormally changes in screen brightness?
-
I just returned home and tried a different card: Sandisk 128 GB.
I AM able to browse directories and play songs! With dir cache off, there is a huge lag, e.g. WPS-> File browser to even appear. Responsiveness is horrible.
With dir cache on, it's much better, but I see a delay in start of playing a song after it has been selected in file browser.
-
Nothing so far, even with contrast set to 50 and stressing the CPU with some extra effects (scaling-0 tested)
Running 128GB microSDXC Sandisk Ultra
-
Rg. brightness: nothing special.
Should I continue testing more stuff with the first build or go on with your latest version?
I can also test with a variant 0, if you want me to?
-------------------
I just switched to a Kingston 8GB card: I see none of the delay and lacking responsiveness :-)
---------------------
When decreasing from +6dB (i.e. in the + range) I hear sometimes a click (similar to transitioning the -40dB threshold).
--------------------------
the variant 0 gets a little further on the Samsung card: I can browse through the dirs and even select a song. It displays the tags in WPS, but won't ever play.
-
Should I continue testing more stuff with the first build or go on with your latest version?
Can you test latest version with sd cards which have problems?
I can also test with a variant 0, if you want me to?
Yes, it can be useful.
When decreasing from +6dB (i.e. in the + range) I hear sometimes a click (similar to transitioning the -40dB threshold).
Ok, probably I know solution for this.
-
When decreasing from +6dB (i.e. in the + range) I hear sometimes a click (similar to transitioning the -40dB threshold).
I hear a pop too - sometimes on a +3dB mark going downwards, but it's very faint and almost unnoticeable.
-
the latest build does not improve the SDcard behaviour!
"
the variant 0 gets a little further on the Samsung card: I can browse through the dirs and even select a song. It displays the tags in WPS, but won't ever play.
"
I am now going to look at FuzeV2.
-
Fuze variant 0:
- Samsung card shows the same behaviour as with clip+ -> unusable
- Sandisk Ultra 128GB: worse than with clip+: trying to load a song sometimes seems completely unresponsive, but then recovers. Skipping to next song, it can take 10+ s for the playback to really start.
Volume: going from +3 to +4 playback pauses for a few milliseconds.
-
OK, my battery is now fully charged, so I'll test the variant 0.
Still, it seems that the best way to measure this consumption would be on a used opened unit with a PSU instead of 3.7V li-ion battery.
This battery benchmark will produce different results based on 'wear level' of each user's battery and is thus a poor indicator of how much energy was saved compared to dev build.
From your 30-hour figure, that'd be around 38mW during playback (3.7V@290mAh). That's insanely low!
Just for comparison, Fiio X5II consumes about 25 times more, Fiio X7 over 40 times more! :)
Good :) But be warned: at >0 dB it consume more power than current rockbox.
I'm curious. How much more approximately? Having an undistorted 1V RMS into 600Ohm load would be worth sacrificing a bit of battery runtime, but depends on how much.
-
The battery lasted 9 hours and 14 minutes. Not an improvement from regular version.
During the test the UI was somewhat unresponsive.
Playback through folders, -10dB volume, output loaded with 600Ohm headphones (AKG K240)
-
Still, it seems that the best way to measure this consumption would be on a used opened unit with a PSU instead of 3.7V li-ion battery.
This battery benchmark will produce different results based on 'wear level' of each user's battery and is thus a poor indicator of how much energy was saved compared to dev build.
I do that for myself tests and measuring current. But we have short spike of big power consumption when read from flash or sd so I cant measure it right.
From your 30-hour figure, that'd be around 38mW during playback (3.7V@290mAh). That's insanely low!
I have ~9.5 mA consumption on mp3 playing and in future we can get even less power consumption.
Just for comparison, Fiio X5II consumes about 25 times more, Fiio X7 over 40 times more! :)
:) But it have external DAC and AMP so it should consume more. Probably it also can be optimized.
For example - original sansa firmware have poorly optimized flac decoder and consume ~40 mA. At same conditions my latest build consume ~8 mA.
I'm curious. How much more approximately? Having an undistorted 1V RMS into 600Ohm load would be worth sacrificing a bit of battery runtime, but depends on how much.
I will try measure it later. In any case - better have high volume with higher power consumption than unusable high volume with clipping and lower consumption.
-
The battery lasted 9 hours and 14 minutes. Not an improvement from regular version.
During the test the UI was somewhat unresponsive.
If you have some big lag in UI - you have problems with reading/writing on sd card or internal flash: driver try reread again and again and drain battery too fast. So don't have sense do battery bench if you have this problem.
Probably I found solution to prevent instability - I update links in first my post.
At first better try test and do battery bench without sd card at all (eject it).
-
BTW, when I copied the build over to the Fuze, properly ejected in Win10 and the unplugged I got (with the first build and the latest) a white screen with
data abort
and I have do a longpress Power ...
instead of being asked if I want to reload firmware.
-
Now using the -2 version on clip+ var1:
* no issues with internal memory
* drop out on +3 -> +4dB remains
* still the same navigation issues with my Samsung EVO 64GB -> empty dirs
* different Samsung 64GB:
Startup and scanning disk takes long. I can play songs from SD. Resume playback after boot (on a flac file) -> starts to play, pauses, plays, pauses ...
The buffer runs empty (checked in debug). When skipping to the next song, this does no longer happen. Seeking in the song it happens again after playing has resumed.
-
On buffering from internal vs. external flash, I picked an extreme test case, i.e. a hires file from http://www.2l.no/hires/index.html :
http://www.lindberg.no/hires/test/2L-125_stereo-88k-24b_04.flac
File size : 26 MB (27 275 400 bytes)
Bitrate : 2177 kbps
It plays without stuttering from internal memory, but not from any of my Samsung SDs nor the 128GB Sandisk.
-
johnb,
Do you have any experience with Transcend microSDXC cards in Sansa players? I'm about to get a new card, possibly compatible with this low-power mod :)
-
The max size of Transcend I have is 32GB and atm I don't know in which device (camera, cell phone, dap) these are buried ...
I feel Sandisk is a good bet for larger cards. I will test a different Sandisk 128GB later ...
-
:) But it have external DAC and AMP so it should consume more. Probably it also can be optimized.
Of course, the power capabilities of X5II and X7 are nowhere near that of Clip+. X5II is rated 2.82Vrms and X7 4.12Vrms. However my point was that while this power is useful for indoor usage with full-sized circumaural headphones, on a portable player it's not as well utilized. Most people listen to IEMs or earbuds on the road, to which DAPs need to put just 1mW to reach dangerous listening levels. In that usecase, the overpowered X5II or X7 is nothing but a hand-warmer and powerhog, burning over 99.9% of consumed energy and only turn that measly 1mW into useable power that travels to the earbuds/IEMs.
Sansa players with their much lower quiescent consumption are thus more suitable for this application, as they can well deliver over 15mW into headphone sources and still consume only 50-60mW in total. :)
I will try measure it later. In any case - better have high volume with higher power consumption than unusable high volume with clipping and lower consumption.
Agree 100%.
-
The max size of Transcend I have is 32GB and atm I don't know in which device (camera, cell phone, dap) these are buried ...
I feel Sandisk is a good bet for larger cards. I will test a different Sandisk 128GB later ...
I have only good experience with Transcend cards, but the largest one I have is 8GB. But I'd assume they could work better than Samsung or Sandisk.
-
* still the same navigation issues with my Samsung EVO 64GB -> empty dirs
* different Samsung 64GB:
Startup and scanning disk takes long. I can play songs from SD. Resume playback after boot (on a flac file) -> starts to play, pauses, plays, pauses ...
Try new build with this cards: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-3.zip
-
I'll test with the following cards (only ones I have):
Samsung EVO 128GB
Sandisk Ultra 128GB
Sandisk Ultra 200GB
-
clip+: A night and day difference with the Samsung cards: all the lagging is gone, UI very responsive, no stuttering with real life files so far (some with other hires files which I don't regard as relevant).
Now it makes sense to do thorough testing.
-
johnb:
Good. But can you first test another build with samsung cards?
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-4.zip
It should be slightly more efficient fix.
-
sure
-
johnb:
Good. But can you first test another build with samsung cards?
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-4.zip
It should be slightly more efficient fix.
Variant4
No apparent problems on Samsung 128GB filled to 98%.
Gapless and FLAC HiRes (24/48, 24/192) works without issues, opus with extra resampling in the way too.
BTW, this card works very erratically and glitchy on Fiio players, so it's a great candidate for this test.
Manual track change is a bit slower, sometimes it takes up to 1 second, but overall non-issue.
No audible distortion on 1k sine into 2000Ohm at +6dB. 100ms square wave distortion when going downwards from +6dB to 0dB that happens on +3dB and 0dB step - Non-issue.
Audible pops when approaching +6dB from 0dB on sensitive earbuds with no music playing.
-
clip+ var1 with -4:
seems to work fine with regular files on both Samsung cards. I had one shrieking glitch (no stuttering) with one of the hires files.
FuzeV2 var0 with -2:
Similar to what I reported for the respective clip version: long startup, huge delay in starting songs on one of the 64G Samsungs, for the 64 EVO I cannot even browse the SD.
-
Variant4
No apparent problems on Samsung 128GB filled to 98%.
Good.
100ms square wave distortion when going downwards from +6dB to 0dB that happens on +3dB and 0dB step - Non-issue.
Audible pops when approaching +6dB from 0dB on sensitive earbuds with no music playing.
I will try eliminate it later.
-
clip+ var1 with -4:
seems to work fine with regular files on both Samsung cards. I had one shrieking glitch (no stuttering) with one of the hires files.
Good.
FuzeV2 var0 with -2:
Similar to what I reported for the respective clip version: long startup, huge delay in starting songs on one of the 64G Samsungs, for the 64 EVO I cannot even browse the SD.
I update links in my first post - so you can try new build for FuzeV2.
-
59% battery left after 10 hours!
I'll update this post once it reaches 0%.
BTW, I do have this little issue with charging. For me, charging stops at 80%, once I reboot it starts back again and then concludes at 100%.
Final update: OK, I got a little carried away, it wasn't 20 hours, but really close. 19 hours, 21 minutes.
55mW average consumption, 64Ohm headphones, level set to -25dB, playback through folders, Opus - 140kbit at 48kHz
Very impressive! I think M3 just got pwned. ;D
Further savings could be delivered from dimming the OLED a bit more - I have it on 0 and it's still unnecessarily bright. Though the PWM dimmer could have been a bit faster, say 500Hz instead of sub-200Hz.
-
FuzeV2 var0 with -4:
tested with various cards, looks good. Responsive UI, startup sometimes delayed depending on card. In one session with the 64GB EVO card I had the effect, that mpc, flac, mp3 files started immediately, but songs from an album with opus 140kbit files had a 5s delay in starting.
Swapping different cards in and out I cannot reproduce it anymore.
What are further things we should look out for, like stressing the device?: High file I/O and or CPU load?
-
FuzeV2 var0 with -4: with a different card: Lexar 64GB
Both for a flac and mpc album I see a delayed start of the track (3-5s). However, for opus files and even hires flac files in each in one folder it starts immediately. No idea what is different.
Then I cross-checked with clip+ var1 with -4 and this card, no issue.
My daughter has got a clip+ var0, I will check this card when she gets home.
-
IT, S3M, XM and MOD modules takes more time to load and the position counter is out of sync. All of them plays correctly though.
-
clip+ var0: no problems at all with the Lexar card!
I tested some more with FuzeV2 var0 with -4 & Lexar and it got even worse:
It takes a while to display album art (folder.jpg) as before, but then it stays at 0.00. Seeking in the file, it plays then immediately. Again this is with one FLAC and one MPC album.
-
When changing volume from +3dB to +6dB with music playing, playback stops for 1-2 seconds (var. 4).
Also battery drain on +6dB is tremendous! I've gone from 59% to 44% in just 1.5 hours of listening.
On +3dB it's comparable to regular rockbox.
+9dB would have been awesome, but that'd likely fry the amp stage. ;D
-
The FuzeV2 var0 with -4 seems to be especially picky: yesterday I had some hangs of the UI and playback with the Sandisk Ultra 128GB that seemed to work ok earlier.
On the Fuze I have the database and auto-update active since this is the DAP I use for listening at home. I am going to turn this on on the clip+ to see if it makes any difference.
-
Experienced 3 dropouts with Opus today, usually at the end of tracks.
-
johnb, asymsucon:
Thanks for reports!
I update links in first post.
News:
UI freezes and sound dropouts should be complete eliminated.
Slightly lower power consumption.
New debug feature: you can check system > debug > sd retry stats. It show numbers of retry on data (read and write) and on reinit for internal flash and sd card.
If all ok, you should see all zeros except "SD card reinit" - it will be 1.
-
Thanks Mihail.
Loading IT modules with var. 5 takes much longer compared to both var. 4 and regular rockbox.
2 seconds with regular version, 5 seconds with var. 4 and over 15 seconds with var. 5
Got "125" SD Card reinits, all other values are 0
-
My mistake - I build v5 with values strongly optimized for my player. Upload v6 with more general/safe values.
-
It's not a problem. I can always use 2nd Clip+ for modules. As long as the tradeoff is better battery life, it's perfectly manageable. 8)
Did you manage to test the consumption at +6dB?
Thanks
-
It's not a problem. I can always use 2nd Clip+ for modules. As long as the tradeoff is better battery life, it's perfectly manageable. 8)
We will try tune consumption on each model later - after whole stabilization.
Did you manage to test the consumption at +6dB?
No, but I'll do it later. I want add more steps for scaling on high volume - so I'll return to measurements.
-
:o
So values above +6dB are not entirely out of question? If so, I could just throw away my X3II ;D. As long as clip+ manages 1.5-1.6Vrms I don't need anything else for my high-impedance headphones.
I'll try var. 5 with other codecs once I return home
-
So values above +6dB are not entirely out of question?
No. It not possible without hardware modification.
Now in my patch I switch voltages once for each 3dB. But we can switch for each 1.5dB. So just more steps, better power saving, less delay on switching, but not more volume :)
I'll try var. 5 with other codecs once I return home
First try v6. Than we try tune it.
-
No change in loading IT modules, no other problems yet. Only I left it running inside my module folder and it drained the last 30% battery in very short time, but I guess that can be expected.
-
You still have many "SD Card reinits" ? Without sd card you have normal loading speed?
-
With SD card I still get 571 reinits on battery. On USB power none.
None also without SD card on battery.
-
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-7.zip
Probably we have some difference between clip+ and clip zip for PVDD2. I revert this changes, but we should check it later.
-
Still 514 SD reinits on battery when playing IT.
Should I send you some files to check on your Zip?
-
You should send this player with sd card :D
Can you check all others sd cards which you have?
-
OK, will do tomorrow.
-
Should I go for -6 of -7 on my clip+?
I did not have any re-read numbers with -6 so far ...
-
Try v8: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-8.zip
-
Hi Mihail,
slightly off-topic, but maybe this also provides additional information:
I have tried -6 and -8 on the clip+ with the potentially dying internal memory I described here:
http://forums.rockbox.org/index.php/topic,51304.msg237134.html
With the current dev builds the crash (see picture) happens maybe every 3 or 4 weeks with daily usage, I believe when RB tries to write the .playlist_control file. All my music is on the SD card.
With -6 I had one bookmark, which triggered this reproducible. Also happened during playback sometimes.
With -8 this happens within 5 - 20s when I start playback!
I tried to increase CVDD2 to 100 and 110 in the debug section, but it didn't help.
So it seems that my internal flash needs higher voltages to be able to write.
------------------------
I will try -8 with a different clip+.
-
Different setup:
clip+ variant 0 with build -6:
Kingston 6GB: 0,0,51,0 in debug menu, number keeps increasing, but no noticable impact on playback, UI or responsiveness -> usable
Samsung Evo 64GB:
1. start from recent bookmark, skip to beginning: WPS updates but stays at 0s, no playback, backlight shuts off
2. skipping has a lag of 10s sometimes
0,0,21,84
--> not usable
Lexar 64GB: seems to always stay at 0,0,1,0
Single occasion where after seek in a flac file, WPS updated but playback did not continue, the UI stayed responsive.
Numbers above did not change!
-> usable
I have NO clicks when changing volume above 0dB. Faintly noticeable delay, not annoying.
-
I have tried -6 and -8 on the clip+ with the potentially dying internal memory I described here:
http://forums.rockbox.org/index.php/topic,51304.msg237134.html
Special build for this player: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-8_sd_only.zip
You should install it on sd card. It should mount only sd card so all your setting will be saved on sd card.
-
Kingston 6GB: 0,0,51,0 in debug menu, number keeps increasing, but no noticable impact on playback, UI or responsiveness -> usable
Samsung Evo 64GB:
1. start from recent bookmark, skip to beginning: WPS updates but stays at 0s, no playback, backlight shuts off
2. skipping has a lag of 10s sometimes
0,0,21,84
--> not usable
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-9.zip
In this build I add delay again so it can be less responsive/slower. But I want to know what you have in debug menu for this cards.
-
Kingston 6GB: 0,0,51,0 in debug menu, number keeps increasing, but no noticable impact on playback, UI or responsiveness -> usable
Samsung Evo 64GB:
1. start from recent bookmark, skip to beginning: WPS updates but stays at 0s, no playback, backlight shuts off
2. skipping has a lag of 10s sometimes
0,0,21,84
--> not usable
http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-9.zip
In this build I add delay again so it can be less responsive/slower. But I want to know what you have in debug menu for this cards.
Kingston 8G:
playing songs from internal, went quickly up to 0,0,27,0 but then stayed there
running songs from SD going to 0,0,30,0 and stayed there within the same song. Selecting song n+2 it went up to 0,0,33,0
2 more skip songs: 0,0,38,0
and so on . Loading a song slightly delayed, but otherwise responsive.
-------------
Samsung Evo:
UI / WPS delayed, but playing from SD works
0,0,1,0
Skipping songs on SD stays at 0,0,1,0 !
Wow!
-
I have tried -6 and -8 on the clip+ with the potentially dying internal memory I described here:
http://forums.rockbox.org/index.php/topic,51304.msg237134.html
Special build for this player: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-8_sd_only.zip
You should install it on sd card. It should mount only sd card so all your setting will be saved on sd card.
True, the failure is gone!
This works with the Lexar but not the the Samsung EVO. Here I cannot even browse files.
I see just the status bar for maybe 40s, then ' Select Bookmark' but just a blue bar not BM listed. 'disk access' symbol is on all the time.
-
Kingston 8G:
playing songs from internal, went quickly up to 0,0,27,0 but then stayed there
running songs from SD going to 0,0,30,0 and stayed there within the same song. Selecting song n+2 it went up to 0,0,33,0
2 more skip songs: 0,0,38,0
Try increase CVDD2, check debug menu, select next track and check changes in debug menu. Don't change volume after setting CVDD2 - changing volume reset CVDD2.
-
95->100 no improvement
105 lower incr respectively no increment any more -> stays now at 0,0,15,0
Reported success to early> now at 0,0,20,0
107 seems to do the job.
-
Try new build with this card: http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-10.zip
It can be very slow, but I want know is it help.
-
NO! Very slow. Loading takes forever. UI lags.
Playing from internal it stays at 0,0,1,0 but from SD 0,0,x,0 with x increasing +2 per second (that is without modifying CVDD2).
With change to 107 it is ok again.
Now I even have drop outs (buffer running empty).
-
Hi Mikhail,
first of all thanks for all your excellent job in optimising clip+. In order to reduce power consumption maybe it would be interesting to extend your frequency scaling to more than 2 levels (38.4 MHz and 192 MHz), for example to 3 levels (32-96-256 MHz) or 4 (32-64-128-256 MHz). I'm no expert just an happy Rockbox user, I don't know if it's easy or not to implement it and if it useful in your power saving work. Sorry to be a bit OT about your discussion but I didn't want to open another thread.
-
In order to reduce power consumption maybe it would be interesting to extend your frequency scaling to more than 2 levels (38.4 MHz and 192 MHz), for example to 3 levels (32-96-256 MHz) or 4 (32-64-128-256 MHz).
It hard for implementation as rockbox player, codecs and plugins expect only two state: normal (38 MHz) and boost (192 MHz).
It harder for stabilization - as we should check each frequency (+voltage) step on many players. AFAIK current voltage scaling still can be case issue for someone. So I want add options in debug menu for tuning/disabling it.
It will be minor (5-10%) improvement in power consumption as at mostly case we still want lowest or max frequency. In linux (gnu or android) you can check "/sys/bus/cpu/devices/cpu0/cpufreq/stats/time_in_state".
-
Hi Mikhail,
as I said I'm no expert and I thank you for your answer. Maybe we could turn off USB and enable/disable it inside a menu.
-
We thought about 3 level power management for many years. There are ways it could be implemented, but it would be complex and the benefits may be small so I'm not sure how worthwhile it would be.
-
Maybe we could turn off USB and enable/disable it inside a menu.
We already shutdown USB when it not in use.
We thought about 3 level power management for many years. There are ways it could be implemented, but it would be complex and the benefits may be small so I'm not sure how worthwhile it would be.
You mean 'idle' state? AFAIK it rarely used and have little sense. Or I wrong?
-
One way to do it would be to have codecs inform the playback engine of their estimated complexity (or have playback measure it). Than the boost and/or unboosted frequency could be changed depending on the codec being decoded. So FLAC might set a very low unboosted frequency or ape a higher boosted frequency.
-
Hi Saratoga and Mikhail,
maybe we could have different frequency presets (normal and boost) that we can select from menu (after a rebooting if needed) so if we listen to files easy on CPU we can select from menu an appropriate set of normal and boost frequencies. For example preset could be 32-128, 38-192, 38-256 and so on...
-
Hey, sorry for the delay in my tests, had a bit of rough week.
Sandisk 128GB is still giving me 200+ reinits, even on basic playback and seeking with v.6
Sandisk 200GB - 1 reinit (tried IT, MOD and Opus)
Samsung 128GB - 1 reinit same tests
So it appears only the Sandisk 128GB is demanding.
-
asymsucon:
Try http://knk.square7.ch/cvdd2/rockbox-clip+-cvdd2_scaling-9.zip as it best what we have for today.
-
Had a kernel panic with v.9 yesterday:
(http://i.imgur.com/mhXa01X.jpg)
-
asymsucon:
Bit strange as no big changes between v6 and v9. You have it only once or can reproduce?
-
Yes, only once so far. It happened during fast forwarding an Opus file.
-
Mihail, should I coninue testing clip+-cvdd2_scaling-9 or do you plan for any other changes soon?
-
I update links to v11. v11 same as v9 but based on fresh git.
If it working without big problems - I want know which minimum CVDD2 we can set for each player. To check that you should extract sd card and play music from internal memory. Then step-by-step set lower CVDD2 in debug menu (don't change volume - it reset CVDD2). After each step switch to next track and check what you have in debug menu "SD retry stats". When you got "internal flash reinit" > 0 - check is internal memory freeze (you don't see files or can't paly it) or not (you can play next file but reinit rising as it was with sd cards).
I want know:
1. Name and variant of player.
2. On which value of CVDD2 you got reinit?
3. Is internal memory freeze on reinit or not?
4. With which value of CVDD2 you can play music for long time (> 1h) without reinit?
-
Just to confirm: the procedure/experiments you describe are WITHOUT SDcard, i.e. we are testing the standalone player?
-
Just to confirm: the procedure/experiments you describe are WITHOUT SDcard, i.e. we are testing the standalone player?
yes
-
On a clip+ variant 0:
Installing -11, shutdown, rebooting and then playing a song I got a panic (pic 1), but this happened only once.
N.B.: sometimes the value of CVDD2 resets to 88, even if I never used the volume keys. So I checked back on the debug setting regularly.
I manage to go (step by step) down to 76. Stats stayed at 0,0,0,0. Also bookmark creation during shutdown worked. I have a long playlist running right now.
However, getting safely down to 76 is the tricky part. For instance, after the successful shutdown I had a hard time getting safely back to 76.
If you try several increments at a time, it can get stuck. Anything can happen from
not responsive at all,
WPS updating when skipping, but no playback
to crash with dc_write_callback (pic 2).
Once the stats values start to increase it almost never recovers.
What seems to work is: play song (and pause), decrease CVDD2 1 per 2sec, go back to WPS, play, skip ...
So far 75 has not worked for me.
I will report back on the playlist.
-
johnb:
Great result! I got only 87 on first my clip zip (variant 1) and 88 for second (also variant 1) on long playing.
If you try several increments at a time, it can get stuck.
Should be fixed in v12. I update links.
-
Results (v12):
1st (var. 1) Clip+
XM playback - crashes at 85 during load into dc_write_callback
86 works OK
Other formats (512k Opus and FLAC) crash at 85, but later, at about 2 mins into track
No reinits so far (0,0,0,0) on 86
2nd (var. 1) Clip+
Plays XM at 84, Opus/FLAC fails up until 87 with either dc_write_callback or:
(http://i.imgur.com/lRGIAEf.jpg)
Upon restart (and reset to 90), internal flash reinit on 6. May need more than 90 for stable operation.
3rd (var. 1) Clip+
At 82 no panic, but couldn't load XM (returned to menu) and logged
42 internal flash reinits
3 retry data
Unstable until 88, but at that level no reinits.
Should I test more Clips?
-
Reporting back on the clip+ variant 0:
It has run now for more than 12h @ 76, stats still at 0,0,0,0!
I then switched to 75. The display starts to flicker slightly (too low refresh rate?), but it is running now for 80min stats still @ 0,0,0,0.
-
johnb
What's the format of your files?
-
My interactive tests: flac, mp3 320kbit, opus 128kbit, some aac 128kbit.
The long playlist is mp3.
-
Could you try these in spare time?
http://www26.zippyshare.com/v/9VqYDNSp/file.html
Both may take a while to load (30-90 seconds)
-
Upon restart (and reset to 90), internal flash reinit on 6. May need more than 90 for stable operation.
Can you check what we should set (91-95) for this player?
Should I test more Clips?
We should find worst case for each player (name+variant). So first check player that need more than 90 and than check others with this value.
If you have clip+ variant 0 - try 76.
-
Reporting back on the clip+ variant 0:
It has run now for more than 12h @ 76, stats still at 0,0,0,0!
Good!
I then switched to 75. The display starts to flicker slightly (too low refresh rate?), but it is running now for 80min stats still @ 0,0,0,0.
With very low voltages we can have problem not only with internal flash but also with RAM (panics, freezes, screen corruption time to time).
Can you check other your players?
-
Mihail, I will test others (started clip+ var1), but I am visiting relatives and only have a few with me ;-)
I will stop trying with the var0 for now.
asymsucon
the files play fine with clip+ var0 @ 76. Stats @ 0.
-
Can you check what we should set (91-95) for this player?
Unfortunately, it won't be that easy. Now I can't access its internal flash at all.
All attempts on connecting it to PC end with this:
(http://i.imgur.com/W0VNp5G.jpg)
regardless on CVDD2 setting (tried 100 and 105)
Any idea what to do?
-
asymsucon
Is usb from bootloader (when player off - try hold select (middle button) and connect it to usb) works?
-
asymsucon
Is usb from bootloader (when player off - try hold select (middle button) and connect it to usb) works?
Yes, that work. "USB Input device" connected, but I can't access its flash.
-
Are you on linux?
-
Nope, on Win7 32bit.
-
My son's clip+ var1:
Played for hours without re-inits @ 87.
With 86 played for a while, but then got stuck when I tried to load a different song in the file browser.
A single event @ 87: crash (see pic4)
-
Nope, on Win7 32bit.
Can you see usb disk size? Original firmware also don't work?
-
No, I can't access any of internal flash memory. It simply won't display under My Computer.
I have now tried with SD card inserted and SD is accessible, but not internal storage.
Is it possible to revert to original firmware directly from player?
-
No. You need usb drive for updating firmware.
You have old rockbox bootloader or new (from this topic http://forums.rockbox.org/index.php/topic,51304.0.html) which able boot from sd?
-
I suppose the old one, which was downloaded automatically through Rockbox Utility for Win.
-
asymsucon
What if you boot into the OF (LEFT + PowerON), set it to MSC mode and then copy .rockbox of current dev build over?
-
johnb
Good suggestion, but OF isn't loading as well:
(http://i.imgur.com/TQeIlDp.jpg)
It's stuck on this screen
After unplugging with SD card in it, it shows garbled text:
(http://i.imgur.com/MXyunn6.jpg)
It's still under warranty, so I can attempt return. Just need a confirmation that it failed not because of our experiments, but on its own.
-
My notorious clip+ variant 1 (the one you provided the SDonly for):
Played fine @ 85, I stopped after 8hs.
Tried 84, but got a dc_write_callback error after 2.5h.
This means we should at least run for 3h without problems before reporting success.
-
It's still under warranty, so I can attempt return.
In warranty can be denied since you have replaced original firmware to rockbox.
Just need a confirmation that it failed not because of our experiments, but on its own.
I do not think that these experimentation or rockbox can kill internal flash. We set lower voltages than in original - it can not burn anything.
We have many reports about porblems with internal flash memory with or without rockbox.
I have two clip zip (both 3 years old).
First used 3-6 hours everyday, internal flash often used. I do all test on it - few hundred experimental rockbox updates. It still alive without any problems.
Second player - used not so often - 1 hour per day, internal flash mostly not used at all. I rarely update rockbox on it - 10-15 times for all time. It also still work, but few month before it switch internal flash to read only mode. I just write latest rockbox on sd card and loading rockbox from sd card (as I have new bootloader on it).
-
This means we should at least run for 3h without problems before reporting success.
You right, but we can rise this value later if someone report about problem.
Can you check what you have on fuze v2?
-
Yes, I am at it for a while now:
my fuze variant 0 is not stable (stats increasing) at 95, so the current test uses 97.
fuze variant 1 is fine so far @ 90, but less than 2h atm.
Regarding the bootloader, do you have a version which always starts RB from the SDcard?
The mount_SDonly patch you gave me still loads the firmware from internal memory AFAIK.
-
If you have the normal bootloader installed I think bootloader USB mode should work. If you plug into USB while the player is off and the select button is held down, USB should work.
-
@Saratoga, were you replying to me? Then I don't get your point ???
I have installed the bootloader that you and Mihail provided a while ago: This only boots from SD, if the internal memory cannot be mounted. But what if - like Mihail described it- internal is not longer writable, i.e. you cannot update RB anymore?
The SDonly I was referring to above, loads RB from internal, but the leaves only SD mounted, but requires the .rockbox directory to be on SD. Later on, all settings will be written to the directory on SD.
-
Regarding the bootloader, do you have a version which always starts RB from the SDcard?
The mount_SDonly patch you gave me still loads the firmware from internal memory AFAIK.
You right, I add patches to bootloader topic.
-
If you have the normal bootloader installed I think bootloader USB mode should work. If you plug into USB while the player is off and the select button is held down, USB should work.
OK, this seem possible as USB Input device is recognized that way.
My question is though, how can I load in the bootloader from Win7 if the internal flash is no longer recognized?
-
In warranty can be denied since you have replaced original firmware to rockbox.
Sansa firmware is still present on the device. The vendor didn't specify warranty conditions, and in fact offered the player as "rockbox ready". I'd be surprised if he refused exchange.
The bootloader patch should be applied according to this guide? https://www.rockbox.org/wiki/WorkingWithPatches#Applying_A_Patch
As for performance, v12 takes at least 15 seconds to load Opus files of any bitrate.
-
v12 on a fuze var1:
No re-inits @ 83, but already @ 84 the shade of the color screen changes sometimes (no flickering) and sometimes loading a song can take several seconds.
-
The bootloader patch should be applied according to this guide? https://www.rockbox.org/wiki/WorkingWithPatches#Applying_A_Patch
Yes, but better wait until someone provide tested binary build.
sometimes loading a song can take several seconds.
My patch have delay (1 ms) before start each read. So if we read many small blocks we can have longer loading. I see this delay when have track with album art. I'll fix it later - when all other will be fixed - as it help a lot in debug.
As for performance, v12 takes at least 15 seconds to load Opus files of any bitrate.
Try this: http://download.rockbox.org/test_files/opus_192k.opus
-
V12, Fuze var0: has been running now for 6h @99 without any re-init, etc.
With 98 they still happened.
-
With 98 they still happened.
Is internal flash work after reinit (you can play next file)?
-
I am checking now again with 98, but after 4hs stats are still at 0,0,0,0 ...
-
johnb
Can you set 95-90 and check is it freeze on reinit or not? Also what you have on others players after reinit on internal flash? Is it freeze or not?
-
Try this: http://download.rockbox.org/test_files/opus_192k.opus
No change.
I take those 15 seconds back, I tested it on the faulty one. On all other ones, it's 3 seconds.
I did finish testing on all 5 Clip+ var. 1. 88-89 should be best compromise with extra room for error.
-
No change.
I take those 15 seconds back, I tested it on the faulty one. On all other ones, it's 3 seconds.
Without reinit in debug menu?
-
Exactly, no reinits (0,0,0,0).
Shutdown also takes a while longer.
-
asymsucon
It looks like opus codec specific problem: it read by small chunks or/and read big part of file before start. In any case it will be fixed later.
-
Tried Opus with different lengths (up to 60 mins) with no change in load time. (pending further confirmation on all units)
Perhaps they'll fix the FFT length requirements in libopus 1.2.x which would help its optimization.
-
johnb
Can you set 95-90 and check is it freeze on reinit or not? Also what you have on others players after reinit on internal flash? Is it freeze or not?
I had the fuze var0 running now @92 for 2h: 2,9,0,0 but still responsive, can use the file browser and launch other songs.
On my clip+ on reinits it was mostly stuck or incrementing the counters or it even crashed with dc_write_callback etc.
-
I had the fuze var0 running now @92 for 2h: 2,9,0,0 but still responsive, can use the file browser and launch other songs.
What about fuze var1?
On my clip+ on reinits it was mostly stuck or incrementing the counters or it even crashed with dc_write_callback etc.
You mean clip+ v1? On clip+ v0 it just crash/panic at low voltage?
-
Mihail, I am afraid I did not note that down properly and need to re-run ...
-
Fuze var1: crashed in less than 30min with "data abort" @81, prefetch data abort to be precise.
clip+ var0: I ran without any re-inits for more than 5hs at even 74, flickering got even worse. It got stuck when I navigated through the shortcuts, still playing the song. I could stop the song, but stayed in shortcuts and then idle powered off.
-
For internal flash 86-88 on CVDD2 seems to be the most stable overall. Unfortunately all my units are only var. 1.
Except for the Clip+ with faulty internal flash, all other 5 run very well on 88.
If we could move on to the SD card testing, I'm getting 2 extra 64GB microSD cards, Transcend and Samsung.
I'd imagine no issues on v12 for those, but this 128G Sandisk is still giving me tons of reinits and causes Clip+ to be very slow (even browsing through dir structure).
Loading and seeking through Opus takes anywhere from 3 to 15 seconds.
DOOM takes forever to load (after 10 mins I performed reset) :)
IT/XM modules vary between 1-3 minutes.
After 3 hours of continuous playing I was at 0,0,134,0
But despite this slowdown, I'm fairly certain we're close to 30 hrs target runtime. After those 3 hrs, the battery percentage dropped just by 8%.
-
Samsung 64GB works perfectly fine. After several hours just 0,0,1,0
Browsing through dir structure is now without delays, but Opus files still take awhile to load (2-8 seconds).
The rest stays the same
-
Hi, sorry to bump this again, just wanted to ask if there are any planned updates.
-
Yes, next update should have notable changes but now I don't have enough time to do all fix and testing.
-
Mihail, do you possibly have the earlier builds (6 and 9) for download somewhere? The last one is a bit slower to be a filler till a new version comes up. Thanks
Edit: Never mind, found it in your dir index ;D
BTW I found a cheapo Clip Zip, new in original box for $30, so from now on you can throw Zip builds at me too. ;)
-
Mihail, do you plan to keep CVDD2 adjustable also in the future to match the specific card being used or would you rather choose a globally safe default?
-
Mihail, do you plan to keep CVDD2 adjustable also in the future to match the specific card being used or would you rather choose a globally safe default?
Next patch should have "CVDD2 autotuner". Probably I should register it as trade mark and got patent :)
-
Mihail, as part of your mod, could you add wider brightness control range from Clip+? Even the lowest value "0" is unnecessarily bright - this could save the battery a bit more.
Thanks
-
Cool, another player bricked, this time in read-only :-\
No coincidence, this happened straight after loading the 12th version.
No changes are reflected in the internal flash. Even when trying to copy new rockbox inside Sansa firmware.
Even when booting with centre button pressed, the internal flash behaves the same.
The Zip is running the modified firmware that should allow booting from SD card should such malfunction happen, however it still boots from the internal flash only.
-
I believe the same happened to my son's player that I experimented with: read-only.
I put a RB version on the SD which only mounts the SD, so after loading it from SD with ROLO, at least the player is usable with the writable SD.
-
I believe the same happened to my son's player that I experimented with: read-only.
I put a RB version on the SD which only mounts the SD, so after loading it from SD with ROLO, at least the player is usable with the writable SD.
How to force the player to boot from SD with the modified firmware?
-
It does not boot from the SD, that would have required a different bootloader before it failed.
I applied Mihail's "SD only" patch/hack, copied the .rockbox folder to the SD, copied it's rockbox.sansa to the root of the SD.
So after booting I go to /<sdcard>/rockbox.sansa and select it. Rolo loads it and the internal drive is invisible, all data is read and written to the SD.
You can download this modified build from
https://www.mediafire.com/?227wiw8we1i6z4r
-
I applied the modded firmware before this failure from this thread: http://forums.rockbox.org/index.php/topic,51304.0.html
In case of issues with internal flash it should have booted straight to .rockbox located on SD card.
-
I believe you got this wrong. You said that your player is read-only. In this case the internal drive is still accessible, i.e. it won't boot from SD.
You will have to follow the instructions I gave in my previous post.
A bootloader that can directly boot from SD, if the SD card is prepared for this is here:
http://www.mediafire.com/file/c7loz2mi7f7goar/clppa_new.bin.zip by Bilgus.
For this to work you also need a modified RB version on the SD. But as said, once your internal flash is read-only, it's too late for that.
-
Is that firmware available for Zip as well?
I cannot find the original thread.
-
https://www.mediafire.com/?v3xu38yua39aoni
It contains the special build that Bilgus provided (in the forum or IRC), but I don't recall the original location, so I uploaded it. I have also included the file that triggers the bootloader to start from SD: rockbox_main.clip+
Just unpack into the root of the SD. (of course after having installed the above bootloader, otherwise it has no effect).
Please refer to Bilgus' work here:
http://gerrit.rockbox.org/r/#/c/1558/
All credits go to him.
-
Many thanks for the uploads, but the all the files seems to be intended for Clip+, not Clip Zip:
Currently only Sansa Fuze+ and Sansa Clip+ are implemented
-
Oooops, sorry I failed to notice that you are talking about a zip.
I don't have the zip versions ready.
-
Here is an updated post on how Clip+, Fuze+ and ClipZip users can install the bootloader and Multiboot Firmware
http://forums.rockbox.org/index.php/topic,51844.msg240021.html#msg240021
-
Anything new since last year?