Tested: codecs vs battery life on Android telephones

Topic: Tested: codecs vs battery life on Android telephones (Read 3473 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Tested: codecs vs battery life on Android telephones

2023-10-07 12:11:49

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:

BlackBerry	Samsung	codec & player
n/a	59	mp3, Samsung default player.
75	77	aac, Foldplay (fb2k not tried)
80	81	mp3, Foldplay
81	81	Opus, fb2k
84	87	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.

Blackberry	Samsung
69	70	WAVE, Foldplay
78	85	AIFF, fb2k
80	87	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.

Blackberry	Samsung
70-ish	60-ish	FLAC with Foldplay. Numbers largely independent of FLAC -0 vs -7 - vs what I tested afterwards: --lax -l32 -q15 -r12,12
n/a	66	FLAC -7 with Samsung default player. Now hungrier than Foldplay, mildly surprising.
77-ish	75	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
80	74	ALAC compressed with CUETools at level 10. This was a surprise (see below) so I ran ALAC a couple of times extra.
79	79	TAK -p4m. Ran 5 resp 4 times due to the following mild surprise:
77	83	TAK -p0m. Mildly surprising compared to -p4m. Somewhat varying results though (ran this 6 resp 4 times).
78	n/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.
82	85	Monkey's High
84	86	WavPack -fx6 and -hx and -hh - numbers largely independent of mode/setting.
89	85	ALAC (default), prompting a few more ALAC runs.
99	97	Monkey's Extra High
132	140	Monkey's Insane
162	n/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 – 2023-10-07 13:48:38

Quote from: Porcus on 2023-10-07 12:11:49

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

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 – 2023-10-07 15:04:05

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

Quote from: birdie on 2023-10-07 13:48:38

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 – 2023-10-07 15:56:29

Interesting results!

Quote from: Porcus on 2023-10-07 12:11:49

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 – 2023-10-07 17:28:35

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 – 2023-10-08 12:31:05

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.

Re: Tested: codecs vs battery life on Android telephones

Reply #6 – 2023-10-08 22:52:58

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 – 2023-10-09 07:07:45

Quote from: Porcus on 2023-10-07 15:04:05

* 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 – 2023-10-09 23:26:44

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

Quote from: Kamedo2 on 2023-10-07 15:56:29

Quote from: Porcus on 2023-10-07 12:11:49
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 – 2023-10-10 10:54:22

Quote from: Brand on 2023-10-07 17:28:35

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 – 2023-10-10 18:23:37

Quote from: bennetng on 2023-10-10 10:54:22

Quote from: Brand on 2023-10-07 17:28:35
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 – 2024-03-15 14:51:09

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.

Notice