Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Tested: codecs vs battery life on Android telephones (Read 6750 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Tested: codecs vs battery life on Android telephones

Over this year, I have let a couple of retired telephones run for 24 hrs only playing music (in flight mode), and tested the battery consumption. 

TL;DR:  If you want to maximize battery life, then choose a lightweight player - and that means you have to stick to the Android-supported codecs. 
For lossless that means FLAC, as Android natively supports no other lossless compressed codec.  The impact of player might be bigger than the impact of codec.   Your phone's native app may be the most frugal one.  VLC is not likely to be.

Phones and player apps:
Blackberry Priv and Samsung S3 9300 (ten years old). Both were tested with
Foobar2000 mobile
Foldplay (a lightweight app that plays a folder, recommended by someone on HA) - this one restricted to Android-supported codecs
The Samsung was also tested with its native player app.

Method: The Blackberry had room for a full 24 hours (no external memory card used!), so I did the following:
Took 23 albums from my signature, selected to be pretty spot-on 24 hours.  One untagged file per album. 
Encoded. Transferred them to telephone's (internal!) storage.
Charged telephone to 100 percent. 
Played the 24 hours - in flight mode, no SIM card no nothing else.  Zero volume. 
Noted the remaining battery percentage.
For the Samsung, I took fewer and put on repeat. Ran for ... well, around 24 hours, put duration and remaining battery percentage into a spreadsheet.
Everything was repeated a few times.

Numbers reported (milliamperes, lower is better), and results
First, to get you an idea of the impact, 24 hours would drain the about half the battery of the BlackBerry. Two thirds if you did Monkey's Extra High.
Numbers are milliamperes calculated the following crude way: Percentage of battery used was multiplied by nominal capacity in mAh ("as if they were new"), then divided by playing time (say 24 hrs on BB). That gives a mAh/h = mA number (which, with fixed battery voltage, translates to a wattage too). Nice surprise: approach made the phones agree fairly well on numbers.
Each number reported below is a median of a varying number of runs.  Caveats:
* No rigorous protocol.  Potential bias: a "WTF, this cannot be right?!" often accompanied by a couple more runs.  Also, a few settings had only a couple of runs - like WavPack -fx6: by 7+7 runs with -hx and -hh and then by 2+2 -fx6'es, it looks pretty much like not depending much on setting.
* No attempt at correcting for idle battery consumption.
* I don't want to pretend these manually recorded numbers to be more accurate than they are, so I rounded off to integers.

Lossy:
BlackBerrySamsungcodec & player
n/a59 mp3, Samsung default player.
7577   aac, Foldplay (fb2k not tried)
8081  mp3, Foldplay
8181  Opus, fb2k
8487  mp3, fb2k
n/a>100 mp3, VLC on the Samsung, median of two - not tried on the BlackBerry.
Lesson:
Prepare for surprises? Results may vary more between players than between codecs.  VLC is a resource hog - I did that test and a half more that run out of battery before I knew, leading to "high but not recorded" result.

8-bit uncompressed PCM, 44.1 kHz.  Why 8-bit?  To get it to the internal storage - and also, it turned out, fb2k decodes FLAC lighter than 8-bit WAVE: Since I decimated to 8 bits, the explanation isn't that uncompressed files are bigger and take more effort to read.
BlackberrySamsung
6970  WAVE, Foldplay
7885  AIFF, fb2k
8087  WAVE, fb2k
Lesson:
Looks like this shows you the penalty for stepping up from a lightweight player?

16-bit (CDDA) lossless. Foldplay and the Samsung native player don't support any other lossless compressor than Android does, namely FLAC: all lines that don't say player, are (necessarily) fb2k.
BlackberrySamsung
70-ish60-ishFLAC with Foldplay.  Numbers largely independent of FLAC -0 vs -7 - vs what I tested afterwards: --lax -l32 -q15 -r12,12
n/a66   FLAC -7 with Samsung default player.  Now hungrier than Foldplay, mildly surprising.
77-ish75     FLAC with fb2k.  Maybe fb2k did FLAC -0 faster than -7.  I did not test -l32 etc.  Note, it is lighter than uncompressed PCM 8-bit
8074      ALAC compressed with CUETools at level 10.  This was a surprise (see below) so I ran ALAC a couple of times extra.
7979      TAK -p4m.  Ran 5 resp 4 times due to the following mild surprise:
7783      TAK -p0m.  Mildly surprising compared to -p4m. Somewhat varying results though (ran this 6 resp 4 times).
78n/a  Monkey's Fast.  Not tried on the Samsung (you don't choose Monkey's to use "Fast" eh?!) Monkey's Normal between here and High.
..       Note, 8-bit uncompressed PCM would show up around here in the table.
8285      Monkey's High
8486      WavPack -fx6 and -hx and -hh - numbers largely independent of mode/setting.
8985       ALAC (default), prompting a few more ALAC runs.
9997      Monkey's Extra High
132140    Monkey's Insane
162n/a     DSD in WavPack. DSD is even more nonsense on mobile, but I was curious enough to test it once - draining battery to near-zero in 17 hrs.
Lessons?
Apart from "use a lightweight player and that means FLAC", I don't know exactly what to take home from this.  I presume that fb2k uses ffmpeg playback.  For TAK and WavPack, settings matter very little.  For ALAC, setting matters - but the opposite of what I would expect, since the high CUETools setting (I think?) uses higher prediction order.
For Monkey's, the numbers do follow complexity, and that can indicate that the Monkey's implementation is reasonably well optimized - more so than TAK/WavPack/ALAC, maybe?

Re: Tested: codecs vs battery life on Android telephones

Reply #1
Foldplay (a lightweight app that plays a folder, recommended by someone on HA) - this one restricted to Android-supported codecs

Me  8)

Interesting results, thanks. I thought playing AAC would be more power efficient than playing FLAC (but only because the latter means at least 3-5 times bigger audio files if we're talking about 256kbps AAC), turns out it's not the case.

Re: Tested: codecs vs battery life on Android telephones

Reply #2
I forgot:
The lossies were all created by ffmpeg using ffmpeg's default compression. Like, FOR looping ffmpeg -i filename.flac filename.mp3 (and then, realizing that ffmpeg writes a tag by default, deleting it by Mp3tag afterwards).


I thought playing AAC would be more power efficient than playing FLAC (but only because the latter means at least 3-5 times bigger audio files if we're talking about 256kbps AAC), turns out it's not the case.
Of course it might have been - or rather, I cannot rule out - that those are two effects, both significant - but with decoding complexity winning overall. Look here, Rockbox results: https://hydrogenaud.io/index.php/topic,82125.0.html . Quoting @saratoga , "FLAC is amazingly efficient.  Its probably the fastest compressed format in remotely widespread use". It is not an overwhelming task to decode a few samples by pen and paper - and in https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/ they have done precisely that.

I do not know if the following actually happens, but I cannot rule out, for example, that
* FLAC's larger files do slow down - significantly - compared to AAC, but FLAC's lower decoding complexity overtakes it.
* Differences in FLAC setting (decoding complexity) do matter, but the differences in file sizes counteract it, magnitudes depend on both FLAC implementation and hardware and material, and in the Foldplay table row, those effects will as good as zero out when added up. 
* The lighter decoding of WavPack -fx6 files is pretty much matched by the smaller -hx sizes
* TAK likewise: heavier complexity with -p4m sure, but smaller files.
* ALAC vs ALAC likewise
- this cannot explain CUETools.ALAC at level 10 vs other codecs. But when you test enough odds and ends there will "always" be one of them that is weirder than the rest.

The observation that Monkey's is more hungry at heavier settings would then be explained so much increased complexity that it overtakes it any file size differences - IIRC, Monkey's Insane could have block sizes > 20 seconds.
(DSD is subject to a lot of unknowns ... let's say, "any high number" would fall in the "not surprising" to me.)


Foldplay, BTW: That app has a good name, to someone who usually listens to albums rather than single tracks, and keeps the collection in one album per folder (concatenating them for testing only). A "good name" meaning, when I needed such a player, that was easy to remember and find back.

Re: Tested: codecs vs battery life on Android telephones

Reply #3
Interesting results!

Charged telephone to 100 percent. 
Played the 24 hours - in flight mode, no SIM card no nothing else.  Zero volume. 
Noted the remaining battery percentage.

Is there a chance that Apps deduce that, from zero volume, decoded PCMs will never be played and stop decoding?
If the mp3, Samsung default player, or FLAC with Foldplay was played with more volume, will the number change?

Re: Tested: codecs vs battery life on Android telephones

Reply #4
FWIW, I ran foobar2000's 'Decoding speed test' on a couple of different phones. Settings: Preload file to memory, 1 thread.
The audio file is ~30min electronic music, 48k stereo. FLAC at -8 and lossy codecs at ~190kbps VBR.
The results were the same on both phones, fastest to slowest: FLAC > AAC > MP3 > OGG Vorbis > Opus.
Same test with foobar2000 on the PC: AAC > FLAC > OGG Vorbis > MP3 > Opus.

Re: Tested: codecs vs battery life on Android telephones

Reply #5
Impressive. Must have taken quite a while to do these tests, it is not something you can do unattended.

I'm surprised the results are as they are. Then again, that Android phone is 10 years old already. One would assume CPUs are so fast (and efficient) these days that decoding CPU usage would not be measurable among other uses of the CPU. Especially seeing that simpler CPUs from old portable audio players were able to playback these codecs.

These results suggest that even on recent smartphone CPUs one could see differences. Those got better, but I don't think they got so much better that these results are no longer applicable. But then again, when airplane mode is off, the screen is turned on every now and then and the CPU is doing background tasks too, perhaps decoding lossless audio does become insignificant.

I wonder whether the difference between native FLAC and ffmpeg FLAC is down to the specific implementation, or whether it has something to do with ffmpeg running in the Android runtime environment and the native decoder not having to run in that.
Music: sounds arranged such that they construct feelings.

Re: Tested: codecs vs battery life on Android telephones

Reply #6
My experience is also that it depends on the firmware used (I know that it doesn't make all that much sense, but it did) and also there's a significant difference between ARMv7 and ARMv8A devices while running on their respective native architectures. Google's implementation of FLAC native decoder has been on a constant adventure of bad or mediocre patches with every iteration of Android version since it's introduction to the family. Unlike 32bit Windows version history, no ARMv7 device is also considered worth as a reference device to benchmark anything modern since most of the (post armv7-era) apps that include armv7 support are completely unoptimized and all of these devices unless they are flashed with any modern custom ROM, they are running on decoder implementations that do not represent the performance or the stability of today's standars. The most notorious example is FLAC. There are so many scenarios you can trip Android's native FLAC decoder on a i9300 stock Jellybean ROM it's rather embarassing. Alot of those still plague modern versions of Android though, which is even more embarassing considering that FLAC is being done right by so many apps for over a decade now but Google can't do anything above average even in 2023.
That being said, I'm so glad somebody is willing to do the job and benchmark on mobile devices.

Re: Tested: codecs vs battery life on Android telephones

Reply #7
* FLAC's larger files do slow down - significantly - compared to AAC, but FLAC's lower decoding complexity overtakes it.
There are results on the Rockbox codec performance test page from a while ago and lossyFLAC required the lowest CPU effort (even compared to lossless FLAC) on a Sansa Clip and a Sansa Fuze+ in 2015 and 2018 respectively.

https://www.rockbox.org/wiki/CodecPerformanceComparison

Re: Tested: codecs vs battery life on Android telephones

Reply #8
I should add to the "flight mode" that I also put on battery save. The rationale behind that was to keep the phone from fiddling around with other stuff that I hadn't "outright asked it to do".

Charged telephone to 100 percent. 
Played the 24 hours - in flight mode, no SIM card no nothing else.  Zero volume. 
Noted the remaining battery percentage.

Is there a chance that Apps deduce that, from zero volume, decoded PCMs will never be played and stop decoding?
Absolutely a question worth asking, and that would be a smart feature - when muted, don't decode, just count the seconds and then search in file when it resumes.

But nah, it does not look like they do that. First, with foobar2000 the difference between Monkey's Fast and Monkey's Insane is quite telling: it must do something heavier to the Insane file, and that would be the decoding.
So I tested with those lightweight app, and in particular: the native app that might communicate with the device - I put on a file and hit pause for a night and day on the Samsung. It spent like 3 percentage points. Repeated that with Foldplay. Still like 3 percentage points.  Not half the battery, as it does when playing.
The Blackberry test used more battery because I forgot to set it in flight mode ... and then I charged it and forgot to unplug the charger. Not a test for when you are in a hurry for results :-)

Re: Tested: codecs vs battery life on Android telephones

Reply #9
FWIW, I ran foobar2000's 'Decoding speed test' on a couple of different phones. Settings: Preload file to memory, 1 thread.
The audio file is ~30min electronic music, 48k stereo. FLAC at -8 and lossy codecs at ~190kbps VBR.
The results were the same on both phones, fastest to slowest: FLAC > AAC > MP3 > OGG Vorbis > Opus.
Same test with foobar2000 on the PC: AAC > FLAC > OGG Vorbis > MP3 > Opus.
I got similar results. Would like to see some explanations about why Opus is so slow. Opus is inherently more complex or the decoders are unoptimized?

Re: Tested: codecs vs battery life on Android telephones

Reply #10
FWIW, I ran foobar2000's 'Decoding speed test' on a couple of different phones. Settings: Preload file to memory, 1 thread.
The audio file is ~30min electronic music, 48k stereo. FLAC at -8 and lossy codecs at ~190kbps VBR.
The results were the same on both phones, fastest to slowest: FLAC > AAC > MP3 > OGG Vorbis > Opus.
Same test with foobar2000 on the PC: AAC > FLAC > OGG Vorbis > MP3 > Opus.
I got similar results. Would like to see some explanations about why Opus is so slow. Opus is inherently more complex or the decoders are unoptimized?

When I started looking into optimizing the rockbox opus decoder 10 years back, they were pretty unoptimized.  It is also slightly more work than usual since Opus uses uncommon transform lengths, so you can't just borrow already optimized code from Vorbis or AAC like you can for other transform codecs. 

Re: Tested: codecs vs battery life on Android telephones

Reply #11
Thank you for this research, comrade @Porcus. Do you have any small smartphone in mind that you could recommend as MP3-Vorbis-FLAC-WavPack player? You know, minimal configuration, no Google account, charging once a week.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Tested: codecs vs battery life on Android telephones

Reply #12
https://www.rockbox.org/wiki/CodecPerformanceComparison

The rockbox comparison reminds of that Opus isn't one codec, but two - SILK and CELT, supporting three modes - which probably shouldn't randomly tested together. https://wiki.xiph.org/OpusFAQ#Why_not_keep_the_SILK_and_CELT_codecs_separate?

Low bitrate Opus decoding seems to be significantly faster (i.e. should use less power for the same job), probably due to SILK or hybrid mode being used?

On the other hand, modern Opus with LACE/noLACE post-processing on high decoding complexity settting is probably a lot worse performance-wise - but makes up for that by significant enhancement in <16kbps quality.