Rockbox EQ and battery

[lorriman]

It seems that I get barely more than 3 hours on my (nearly new) clip+ if I have EQ on, or Bass. My brother's clip+ also experiences this. Is there much potential for the EQ being optimised more?

[CrowdAds]

[saratoga]

How much do you get without EQ? It should use negligible power.

[lorriman]

Really? I had totally assumed the EQ was doing sophisticated and cpu intensive stuff. My mistake. Is there anything that does very intensive power-draining operations? I have a vague recollection that dithering does, though I don't use that.

As it happens I haven't tried without EQ: I just assumed that it must be that since it's the only extra setting I was using (apart from very occasional crossfeed).

In that case presumably it's higher bitrate files. I play ogg at 320. I've had a look for a cpu % to attempt to gauge matters but couldn't find one. Might that be because it's irrelevant in the context of off-cpu dsp stuff?

I've never had good playback times out of my clip+. I have a theory that perhaps it was stored too long with a higher li-ion charge and so lost capacity. Seems unlikely. But when I received my fuze v2 (not fuze+) the other day it had a reported 65% charge out of the box which supposedly loses 25% capacity per year. However I've read since that it's reported battery levels can't be relied on. Anyway, I'm slightly waffling at this point.

Anyway, thanks for the help: it certainly feels better to know the EQ is having no effect even if it doesn't solve my problem.

[saratoga]

Originally Posted by lorriman

In that case presumably it's higher bitrate files. I play ogg at 320. I've had a look for a cpu % to attempt to gauge matters but couldn't find one. Might that be because it's irrelevant in the context of off-cpu dsp stuff?

I doubt its due to that, Vorbis is extremely power efficient. I don't think theres anyway to monitor CPU usage on the Clip+. Usually we just use the test_codec plugin to measure how fast individual codecs and DSP effects run rather then monitor the player directly.

Originally Posted by lorriman

I've never had good playback times out of my clip+. I have a theory that perhaps it was stored too long with a higher li-ion charge and so lost capacity.

If its really only 3 hours, its probably just a bad battery.

Originally Posted by lorriman

Seems unlikely. But when I received my fuze v2 (not fuze+) the other day it had a reported 65% charge out of the box which supposedly loses 25% capacity per year. However I've read since that it's reported battery levels can't be relied on. Anyway, I'm slightly waffling at this point.

lithium batteries usually come out of the factory about 60-70% charged.

Originally Posted by lorriman

Anyway, thanks for the help: it certainly feels better to know the EQ is having no effect even if it doesn't solve my problem.

Well it has a small effect. But at maybe 2MHz per EQ band if you're only using 1 band you're using less then 1% of a 250MHz processor. Compare that to vorbis which is probably using 25 or 30 MHz to decode the file.

[lorriman]

Thanks for all that info. In the end I did a battery_bench with a prepared mp3 file (cbr 128 JS) and got 15 hours and 12 minutes, much of which I could account for myself as I was awake and could hear it. That seems to be a pretty good result.

So there you go. Perhaps it's not just amps with which we have serious subjectivist issues. Assuming I *did* experience much shorter play times I reckon this must therefore be due to my file size. Most of them are 320kbps ogg and so perhaps the 3x size factor also causes my perceived playtime which is perhaps closer to 5 than 3 hours. Obviously I'll have to test that out some time or else be wandering around in a daze thinking I'm going mad.

In the meantime, are there any settings that do cause a major drain? For example I've just discovered Stereo width which makes magic of many of my albums that need the opposite of crossfeed of which only a few albums have need. I also use dithering which I probably shouldn't because the effect is likely too subtle, but I've been bitten by the uber-quality bug (I use etymotic headphones, for example). I also use 'compressor' a lot especially when travelling, but also to get the volume up on my 32ohm headphones.

Is it true that the encoder can make a difference. A poor mp3 encoder will produce higher drainage files, for example. Or is it really just file size? Sorry for all the questions. These have been gnawing at me for a while.

[saratoga]

http://www.rockbox.org/wiki/CodecPer...RM926EJ_45S_41

You'd have to test the individual effects with test_codec to see how much they use, but I know channel width is very fast. Not sure about dither but its not useful anyway so don't use it. Compressor probably is probably pretty slow but I've never tested it.

[lorriman]

I've now tested ogg 320kbps. Here's a graph of the two battery benches :



link obligation (ignore)

They are on top of each other and practically identical. Ogg 320kbps was only about 10 minutes less run time than mp3 128kbps.

So it definitely was all in my mind. I am either quite, quite mad or subjectivism is the rule. Anyway at least that gives you some useful info when other people come here claiming short battery lives.

[lorriman]

What's particularly interesting to me is the test_codec results don't correspond at all to this.

Lame_128.mp3, 741.82% realtime, Decode time - 23.72s, 32.35MHz
vorbis_350.ogg, 403.81% realtime, Decode time - 43.56s, 59.43MHz

In theory we should be seeing battery times halved for ogg 320kbps, if cpu has anything to do with it.


I should add a few details. I've had my clip+ for a few months but I've carefully looked after the battery (few discharges below 10%, no charging beyond 50% except for long journeys). For the benchmark I fully discharged twice to reset li-ion discharge-protection drift. (which you are supposed to do every 30 charges anyway, but otherwise contribute to battery life exhaustion).

I ran with no settings, no EQ, no compression, nothing. volume at -20 with headphones plugged in.

[skip252]

Thanks for posting that. Now that you know what's really happening you can focus your attention on other things to help optimize your setup. There's a Sansa Runtime page on the Wiki. You may want to add your results there.

The response to questions like yours is pretty much what what you got. If you believe there's a difference run the appropriate standardized test and report the results. I've done the same with a number of items I thought I'd observed and found sometimes I was right and others I was wrong. The important part for me was that I knew for sure what happening rather than guessing.