There have always been complaints about Ogg being more of a battery hog on the Nokia tablets compared to Nokia optimized MP3. I decided to measure the difference.
All tests were run on a preproduction n900 device that Nokia distributed at the Maemo Summit. The software is the Maemo5 41-10 release which was already installed in the device. I installed Ogg Support, gst-av, ffmpeg and OpenSSH. Otherwise the device is the default 41-10 release. WLAN connection was configured but not activated during the tests. A SIM card was in place only in the SIM idle test.
Before every test I charged the device, disconnected the charger once I noticed the green led, and rebooted the device. After the boot I started a simple script in the xterm. The script logged current time to a file, run “sync” command and slept 60 seconds after which it started the loop again.
Idle tests
I run two idle tests between the libvorbis and ffvorbis tests but I’ll introduce the idle results first.
First idle test was a generally idle device. I.e. it did have the default processes running but I didn’t start anything, except my logging script. During the test I did check a couple of times if the device was still on. The battery lasted for 93.8 hours.
According to Igor Stoppa, there’s a cellmo sw bug that makes current higher without a SIM card. Therefore I rerun the idle test with a SIM card inserted. During the test I received two phone calls which I hung up, I received two SMS messages and wrote one. At one point the notification led was blinking for 45 mins. The battery laster for 93.6 hours.
There’s probably a few hour error margin on those tests, so basically the battery lasted roughly a bit over 90 hours in both tests.
Powertop shows that after 60 seconds of showing the xterm with display blanked, the CPU is mostly in the highest C4 sleep state:
| C# | Ratio | Avg/dura | Frequency | Ratio |
|---|---|---|---|---|
| C0 | 0.3% | 600 MHz | 0.0% | |
| C1 | 0.0% | 550 MHz | 0.0% | |
| C2 | 0.1% | 1.1ms | 500 MHz | 0.0% |
| C3 | 0.2% | 15.2ms | 250 MHz | 100.0% |
| C4 | 99.5% | 2297.0ms |
Ogg vs. MP3
Now that we know how long the device will last when idle we can move to the actual results.
I run two sets of tests. First one was with the Ogg Support 1.0.5 from Extras and the second one with Felipe’s gst-av (2009-09-25) which is using vorbis decoder from FFmpeg (2009-09-07). I repeated both tests three times, running every other test with MP3 and every other with Ogg.
After restarting the device with a fully charged battery I started the logging script in the xterm, started the File Manager and clicked on the MP3 or Ogg file which then started playing that single file in a loop in the Media Player. Both files were encoded with variable bitrate 192kbps settings. Volume of the device was set to minimum and no headphones were connected.
This is what powertop shows while playing MP3 in Media Player compared to libvorbis:
| MP3 | libvorbis | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Clearly while using libvorbis the CPU spents more time in lower sleep state and running with higher frequency. The following graph shows how this affects the battery. The battery lasts around 18 hours while playing MP3 but only around 11 hours while playing Ogg.
Next numbers are with ffvorbis instead of libvorbis. Powertop shows that while using ffvorbis the time spent in different sleep states matches quite closely to the ones of MP3 usage:
| MP3 | ffvorbis | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
The similarity of the powertop numbers can be seen in the battery duration as well:
The average battery duration while using ffvorbis was slightly better than while using MP3 but probably well within the error margins. So basically they are equal when battery duration is concerned.
It’s interesting to see how the situation changes in a year, will Nokia make better optimizations to their MP3 decoder than the community to the FFmpeg. These tests were run in a preproduction device with a pre-sales software. I’m sure the overall power management of the device will get (even?) better in the future software releases.
Addition (2009-11-17):
When using the speakers the n900 runs some “speaker protection algorithms” that take extra power. I repeated the ffvorbis test case with Nokia’s headset and here are the results:
On the average the battery duration improved a bit over three hours.
Addition (2009-11-25):
I run the same tests (Ogg Support 1.0.5, no headset) for Flac:
n900 with a pre-sales w41-10 software can run Flac roughly 1.5 hours longer than MP3.
so next version of ogg support will use ffvorbis instead of libvorbis?
so next version of ogg support will use ffvorbis?
Probably not in the next version. But once the missing features have been implemented to gst-av, it will replace the current implementation.
Very interesting, thanks for doing these tests. I hope you can do them again in the future and see what has changed!
Pingback: uberVU - social comments
Can you possible do a FLAC playback test too seeing as that is part of the ogg support?
Personally I use AAC for lossy (iTunes downloads) and FLAC for lossless so the current test is meaningless for me.
Maybe a bit later. I’m currently running tests with headphones.
Looking at some of my older FLAC powertop results, the FLAC spents more time in the deeper sleep states than ffvorbis, so I guess it draws less battery as well. It do run at a slightly faster frequency but I think the sleep state is more important when the battery is concerned. But those were quick tests so there can be errors.
It would also be interesting to test AAC files as I would expect those to also be DSP assisted.
I would love to do it myself but even if my N900 shows up next week I will be far too busy using it normally. Would not be able to spare it to deliberately drain the battery running tests. ;-) I will be testing how it copes logged into AIM, Yahoo and MSN all day over WiFi though as that is hopefully a usage pattern it will handle with ease.
Looks like there’s no audio DSP decoders at all, so all are decoded in the ARM side.
@Alex: AAC improved massively in recent ffmpeg trunk… The FFT gets an unbelievable 12x faster thanks to going from C to hand-optimized NEON. It means less cycles => more battery life.
@Ian is that relevant to the N900 specifically? AAC is supported out of the box is it not, so does it use ffmpeg or something else?
Like I said, most of my music will be FLAC as I tend to only carry a relatively small selection of tracks around with me rather than a lot of people who like their whole collection at all times. The only AAC will be the tracks I get off iTunes that I was unable to get hold of in FLAC, but I am still interesting out of curiosity as much as anything, how they compare.
Nokia is using a proprietary AAC decoder called “Nokia AAC decoder” on n900 with a primary (256) rank.
Is it possible to change the buffering? As vorbis doesn’t need much actual CPU time for the whole song the problem seems to mostly be that it is constantly doing work instead of in bursts. If there was a bigger buffer to put the decoded result in (waiting for it to be played) then the CPU could be in C0 for a short while and then the rest in C3.
@IanR: ffvorbis and a lot of other audio decoders are also using FFT, so it is already contributing. And regarding the huge speedup, one way of making NEON look very fast is to put an extremely slow VFP unit into ARM Cortex-A8 core ;-)
What does this mean to devs who have apps that depend on vorbis? Is it as simple as changing to ffvorbis? Is there a compatible library to link to?
The NEON FFT was added on 2009-09-10 with SVN rev 19806, and further improved over the following days. This optimised FFT made Vorbis decoding 3x faster, so it would be interesting to see if that further improved the battery life.
@Flandry: I think I need to keep the libvorbis there as well as many games etc. use that. One choice would be to include the current libvorbis and its gst-plugin in the future as well but with a lower rank so that ffvorbis/gst-av would be used automatically instead of the libvorbis. I guess the ffvorbis has an API of its own.
@Mans: Hmm.. I need to verify the exact SVN version I used somehow. I remember FelipeC saying that the FFmpeg got some NEON improvements back then and I think I took a version after that.
@Mans: I compiled version 745e506 and got roughly one hour longer battery duration with the new ffvorbis compared to the one I used in my original tests.
Pulseaudio looks to be chewing up 15-25 (peak) percent CPU. Some ideas to help this.
0) Take a hard look at pulseaudio and see what functionality can be disabled/optimized.
1) Allow apps to disable xprot and eq if they limit speaker volume to 70%?
2) Allow apps to tell pulseaudio “I have pre-eq’d audio”. This means ogg or mp3 playback can be equalized at almost no cpu cost, before transforming the frequency-domain data into time-domain.
Ah i had another thought but it fled…. it fled into the void.
What the pulseaudio is actually doing? It takes less cpu with headset connected but still quite a lot.
Is it worth mentioning that Vorbis is a more efficient encoder than MP3? I’ve seen listening tests that claim 80kps vorbis is equal to 128kbps lame (both VBR) and that 96kps is better than 128kbps lame. That’s a 25-40% difference in filesize at those (lower) rates, which I’d imagine translates into power saving. I know these things are difficult to objectively control but I’d suggest it’s worth mentioning at least.
AAC is held to be equal to Vorbis, but it is more complex than MP3 and so should eat more power (unless they’ve done fancy DSP things to compensate).
@Dave: Yeah, I didn’t mention the Ogg being much better than mp3 because it’s hard to measure :)
Based on the DSP binaries in /lib/dsp/ I would guess that all audio decoding is done on software only.
Thanks for interesting experiments. In headset mode I think sample rate conversion from 44.1 kHz to 48 kHz causes still some PA load. Using HW native 48 kHz results to slightly lower load.
Sample rate conversion in music encoding phase could also increase a bit the quality if the converter is of good quality.
Hi Tuomas
Will ffvorbis be showing up in ogg support package any time soon?
Probably not in any time soon. I don’t want to include it, if it doesn’t support everything in the current (1.0.5/6) version.
I could try to find the files (ffmpeg and gstav) I used for the ffvorbis tests and put those somewhere available, if people want to try them out without proper packaging.