IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Audio Codecs And CPU Usage, On A Phone, Nokia Symbian (N79)
Brand
post Dec 8 2011, 21:30
Post #1





Group: Members
Posts: 317
Joined: 27-November 09
Member No.: 75355



I did a test comparing the CPU usage while playing back a test track converted into different formats.

I used a Nokia N79 with FolderPlay for playback and also with the default audio player (where indicated). The phone was in offline mode with the fewest possible programs open.

The test track has three 30 second clips with some silence in between. It's uploaded and described here.

The same test track was played twice in sequence (with a different name, not on repeat).
Looking at the graphs, you should ignore the high CPU usage on the left and right edges, that's because of switching between programs etc. The bare audio-playback-related usage should be seen in the central part.

WAV vs FLAC (compression level 8) vs MP3 V3 vs OGG Vorbis q5.4:


WAV clearly has the lowest CPU usage, FLAC varies according to content or bitrate (very low on silence and quiet passages, higher on loud/high bitrate passages like at the start of the 3rd sample), MP3 reasonably low all-around, OGG Vorbis very high.


MP3 V3 vs MP3 V0 vs MP3 320:


No noticeable difference between these. BTW, they were encoded with LAME 3.99.3.


AAC Q0.50 vs MP3 V3 (using the default player here, since FolderPlay doesn't support AAC in MP4 container):


Very close, almost identical CPU usage. For AAC encoding I used Nero AAC 1.5.4 in Foobar.


MP3 V3 with the default player vs MP3 V3 with FolderPlay:


FolderPlay seems to have a more consistent CPU usage with fewer spikes and it has gapless playback. The default player produces a noticeable spike when transitioning from one track to the next.

This post has been edited by Brand: Dec 8 2011, 21:37
Go to the top of the page
+Quote Post
saratoga
post Dec 8 2011, 21:44
Post #2





Group: Members
Posts: 4897
Joined: 2-September 02
Member No.: 3264



You might be interested in my tests in this thread:

http://www.hydrogenaudio.org/forums/index....showtopic=82125

I tested many of the same decoders, but used much more optimized versions of them then are included in FolderPlay. In particular using a modern Vorbis decoder resulted in Vorbis being much faster then MP3.
Go to the top of the page
+Quote Post
Brand
post Dec 10 2011, 13:48
Post #3





Group: Members
Posts: 317
Joined: 27-November 09
Member No.: 75355



Yeah, interesting that Vorbis would be faster than MP3. I always thought (I'm not a programmer) that Vorbis is just complex/slow by design and you can't help it. So it's all open to optimization or are there any well-known limits regarding CPU efficiency? Could the MP3 decoder you tested also be optimized to beat Vorbis?

I also noticed Vorbis is significantly slower when encoding (with Foobar). With MP3 and AAC it varies, but MP3 is mostly faster.



EDIT: Also something else I later saw on my graphs is that with Vorbis the CPU usage drops on the silent parts of the track (like with FLAC). Whereas this doesn't seem to (noticeably) happen with AAC and MP3.

This post has been edited by Brand: Dec 10 2011, 13:55
Go to the top of the page
+Quote Post
saratoga
post Dec 10 2011, 21:27
Post #4





Group: Members
Posts: 4897
Joined: 2-September 02
Member No.: 3264



QUOTE (Brand @ Dec 10 2011, 07:48) *
Yeah, interesting that Vorbis would be faster than MP3. I always thought (I'm not a programmer) that Vorbis is just complex/slow by design and you can't help it.


No its a bit less complex then mp3. By design Mp3 is quite complex, it was designed by a committee of people who each had their own patents/ideas they wanted to shove into it.

QUOTE (Brand @ Dec 10 2011, 07:48) *
Could the MP3 decoder you tested also be optimized to beat Vorbis?


Since then I've improved mp3 somewhat, and other people have worked on vorbis. I have some bigger mp3 optimization in the works since last year, which will hopefully shave a couple more MHz off of mp3. But I think beating Vorbis would be very hard on a typical embedded ARM processor. MP3 has to do a lot more work.

QUOTE (Brand @ Dec 10 2011, 07:48) *
I also noticed Vorbis is significantly slower when encoding (with Foobar). With MP3 and AAC it varies, but MP3 is mostly faster.


I think differences in encoding speed have little to do with the format, and are mostly about how hard the encoder is trying to maximize compression/quality. Thats why different mp3 encoders vary by orders of magnitude in encoding speed.

QUOTE (Brand @ Dec 10 2011, 07:48) *
EDIT: Also something else I later saw on my graphs is that with Vorbis the CPU usage drops on the silent parts of the track (like with FLAC). Whereas this doesn't seem to (noticeably) happen with AAC and MP3.


On a lot of phones, particularly older ones, the main CPU doesn't decode built in audio formats like MP3 and AAC, but rather its done by a slower but more energy efficient coprocessor or DSP core. Are you sure those tests are even measuring the performance of the Mp3 decoder and not just how much busy-waiting the CPU is doing while the music player app waits for the DSP to finish its part?

This post has been edited by saratoga: Dec 10 2011, 21:28
Go to the top of the page
+Quote Post
dutch109
post Dec 11 2011, 17:30
Post #5





Group: Members
Posts: 123
Joined: 20-June 06
Member No.: 32044



Very interesting measurements, thanks for taking the time to make them.

Does anyone know how these results could be transposed to Android?

I have noticed on my Nexus S that playing Vorbis music encoded at -q 2 consumes as much battery as watching a H264 baseline video with AAC audio (using the stock Android player for both). I have not done any rigorous measurements, but I suspect H264 and AAC decoding are optimized and use Neon instructions when available unlike Vorbis decoding.

This post has been edited by dutch109: Dec 11 2011, 17:30


--------------------
Vorbis -q2/5 (Android/PC) & WavPack -hhx6
http://playnoise.com/
Go to the top of the page
+Quote Post
saratoga
post Dec 11 2011, 21:59
Post #6





Group: Members
Posts: 4897
Joined: 2-September 02
Member No.: 3264



H264 decoding on android does not use the CPU. You should observed ogg and aac using similar amounts of CPU time since they are very similar formats.
Go to the top of the page
+Quote Post
Brand
post Dec 17 2011, 15:55
Post #7





Group: Members
Posts: 317
Joined: 27-November 09
Member No.: 75355



I did another test, but this time with a different player: OggPlay. I used the older stable version (1.72), because the new one (currently in the alpha stage) wouldn't work on my phone.

As the name suggests, it could be a player that's optimized for OGG Vorbis playback, and indeed, there's a noticeable improvement over FolderPlay in this regard:


FLAC is a bit better optimized here compared to FolderPlay and is clearly the most efficient. OGG Vorbis performs significantly better than in FolderPlay, although it still has a slightly higher CPU usage compared to MP3 and AAC.

The 1.72 version of OggPlay doesn't yet support gapless playback and there are some CPU spikes when going from one track to the next.


OggPlay also allows switching between using the Nokia's built in codec for MP3 (default setting) and using the OggPlay's own MP3 codec. I put them side to side, along with FolderPlay (which also uses the Nokia's MP3 codec) and OggPlay's Vorbis codec:


As expected, the Nokia MP3 codec performs about the same in both players, while OggPlay's own codec has a slightly higher CPU usage with MP3 playback and it's very similar to OGG Vorbis playback in this regard.



QUOTE (saratoga @ Dec 10 2011, 21:27) *
On a lot of phones, particularly older ones, the main CPU doesn't decode built in audio formats like MP3 and AAC, but rather its done by a slower but more energy efficient coprocessor or DSP core. Are you sure those tests are even measuring the performance of the Mp3 decoder and not just how much busy-waiting the CPU is doing while the music player app waits for the DSP to finish its part?

I honestly don't know. BTW, I used CpuMonitor for the graphs.
I thought about doing a test comparing the battery life (which codec drains the battery faster), but it's a bit less practical to do it properly and more time consuming, so I went with these graphs. I still might do it eventually..
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 20th August 2014 - 20:17