Sansа Clip Zip - Improve battery life

[[Saint]]

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]

[saratoga]

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 . . .

[Mihail Zenkov]

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.

[Mihail Zenkov]

saratoga:

oid_maps can help with testing fuze v2. Can you create new build for fuze v2?

[saratoga]

What do you think should be tested?  Maybe 96MHz PCLK with no other changes? 

[Mihail Zenkov]

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.

[oid_maps]

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.)

[saratoga]

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

[keyb_gr]

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.

[saratoga]

Yes, that is committed. 

[Mihail Zenkov]

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

[Mihail Zenkov]

I think I found why we have problem with unboost after usb disconnected.

[Mihail Zenkov]

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

[music_lover001]

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.

[Mihail Zenkov]

It is very possible that I am unusually dense, but what what committed?

http://git.rockbox.org/?p=rockbox.git;a=commit;h=02414bf286e4ff6a08d19e951bff1e0905d330b4