Flac vs Ogg vs MP3 - CPU utilization on slower devices

[trueg]

Have there been any definitive tests done on which compression type has the highest and lowest CPU utilization?

I'm in the process of compressing the audio for Broken Sword 2. Using 'compress-sword2.exe', I have the options of Flac, Ogg and MP3. Using music1.clu as an example I get the following file sizes.

music1.clu - 144 MB (original)
music1.clf - 170 MB (--flac --best -b 1152)
music1.clg - 76 MB (--vorbis -q 10)
music1.cl3 - 55 MB (--mp3 -B 160 -V0 -q0)

I used the options for highest quality, so there should be no discernible difference from the original.

Normally, I compress as flac so that I know I am not loosing any quality, but in this case it creates a larger file (I'm assuming the original has some type of rudimentary compression). So flac is out.

That leaves OGG & MP3. On my 201 MHz HTC Touch (Elfin), I run batterystatus to scale the CPU speed based on CPU load. 100 MHz for little to no load and 234 MHz at the top end. This allows me to maximize battery life.

To test CPU load, I encoded a music file in Flac, Ogg and Mp3 and played it in CorePlayer. With CorePlayer minimized I was able to observe the CPU scaling behavior. With Flac and Mp3, CPU speed dropped to 100 MHz and stayed there. With Ogg, the CPU speed wouldn't go below 156 MHz and stayed mostly at 182 MHz. It was so demanding in fact that when I went to open CorePlayer again the audio cut out a few times.

Based on this, for slower PPCs, I would use the following guidelines.

Flac - space is not a concern, you want low CPU utilization and maximum quality.

MP3 - space if of moderate concern, you want low CPU utilization and near original quality (using best quality settings)

MP3 low quality - space is of high concern, you want low CPU utilization and are willing to sacrifice quality (default MP3 settings).

OGG - space is of high concern, you want the best quality vs. size and don't care about CPU load.


One variable I cannot account for is CorePlayer. It is possible that the CPU load using CorePlayer to decode the various formats is not the same as what ScummVM would have. If this is the case, I don't know how we could test this.

[robinwatts]

In general, in my experience on ARM devices, an optimised Ogg decoder will be about 50-100% slower than an optimised MP3 decoder. Very rough figures.

No idea about flac.

HTH,

Robin

[saratoga]

In general, in my experience on ARM devices, an optimised Ogg decoder will be about 50-100% slower than an optimised MP3 decoder. Very rough figures.

My experience with ARM is that when well optimized (IMDCT, synthesis filters, windowing in ASM) Tremor is a little faster then MAD when both are set to > 16 bit precision.

That leaves OGG & MP3. On my 201 MHz HTC Touch (Elfin), I run batterystatus to scale the CPU speed based on CPU load. 100 MHz for little to no load and 234 MHz at the top end. This allows me to maximize battery life.

To test CPU load, I encoded a music file in Flac, Ogg and Mp3 and played it in CorePlayer. With CorePlayer minimized I was able to observe the CPU scaling behavior. With Flac and Mp3, CPU speed dropped to 100 MHz and stayed there. With Ogg, the CPU speed wouldn't go below 156 MHz and stayed mostly at 182 MHz. It was so demanding in fact that when I went to open CorePlayer again the audio cut out a few times.

I'm not sure how efficient your software is, but I was able to get real time decoding of both formats at about 35 MHz on ARM9. Not sure why your CPU usage was so high, but it sounds like something was quite wrong.

[robinwatts]

My experience with ARM is that when well optimized (IMDCT, synthesis filters, windowing in ASM) Tremor is a little faster then MAD when both are set to > 16 bit precision.

Odd. Tremolo is faster than Tremor, and is slower than AMPlayer (on the RISC PC that I tested it on years ago).

I'm not sure how efficient your software is, but I was able to get real time decoding of both formats at about 35 MHz on ARM9. Not sure why your CPU usage was so high, but it sounds like something was quite wrong.

I was using a 200MHz StrongARM on a slow memory bus; AMPlayer manages to work in about 10-15% of the CPU (if memory serves), so that's 30MHz ish. Tremolo was taking more.

AMPlayer isn't bit correct though, and that test was done with a version of Tremolo based on Tremor before the LOW_ACCURACY stuff was introduced.

Robin

[saratoga]

My experience with ARM is that when well optimized (IMDCT, synthesis filters, windowing in ASM) Tremor is a little faster then MAD when both are set to > 16 bit precision.

Odd. Tremolo is faster than Tremor, and is slower than AMPlayer (on the RISC PC that I tested it on years ago).

Well, we're talking ARM here, which is quite a bit different then a typical RISC PC due to the odd multiplier performance.

Anyway, I don't have numbers for ARM9 handy, but I have numbers for ARM7 (Sandisk Sansa) at 192k:

Tremor: 33MHz
MAD: 40MHz

Both are mostly ASM for the core components, but theres no ARM7 specific optimization, just generic ARM. Using short circuiting multiplies in MAD for the synthesis filter, I figured I could save another 2MHz or so, but haven't gotten around to it. If you've had any luck optimizing MP3, I'd love to hear about it.

I was using a 200MHz StrongARM on a slow memory bus; AMPlayer manages to work in about 10-15% of the CPU (if memory serves), so that's 30MHz ish. Tremolo was taking more.

Sorry, I meant the 156MHz numbers in the first post.

Anyway, it sounds like Tremorlo is a bit slower if StrongARM core isn't beating the pants off of ARM7, though I'll have to take a look at their source and see if theres anything I can use.

AMPlayer isn't bit correct though, and that test was done with a version of Tremolo based on Tremor before the LOW_ACCURACY stuff was introduced.

Do you know what codec they use? I couldn't find anything when I googled it.

[robinwatts]

Well, we're talking ARM here, which is quite a bit different then a typical RISC PC due to the odd multiplier performance.

Yes, the RISC PC is an odditity due to the slow bus it has (the StrongARM card for the RISC PC is a plug in replacement for the ARM6 which it was originally designed with).

Anyway, I don't have numbers for ARM9 handy, but I have numbers for ARM7 (Sandisk Sansa) at 192k:

Tremor: 33MHz
MAD: 40MHz

Both are mostly ASM for the core components, but theres no ARM7 specific optimization, just generic ARM. Using short circuiting multiplies in MAD for the synthesis filter, I figured I could save another 2MHz or so, but haven't gotten around to it. If you've had any luck optimizing MP3, I'd love to hear about it.

Both AMPlayer and Tremolo use generic ARM code too (well, they assume the existence of the long multiplier instructions, no funkier ARM v5 stuff).

Things like MAD and Tremor seem to rely on using inline ARM code fragments to accelerate performance. With AMPlayer and Tremolo I take this further by coding entire routines as assembly, thus ensuring that scheduling and register juggling is optimal too.

Anyway, it sounds like Tremolo is a bit slower if StrongARM core isn't beating the pants off of ARM7, though I'll have to take a look at their source and see if theres anything I can use.

Tremolo is faster than Tremor - it's basically Tremor with additional sections hand coded in ARM.

Do you know what codec they use? I couldn't find anything when I googled it.

AMPlayer was based on MPG123, but integerised by Thomas Olsson. Further optimisation was done by Justin Fletcher, and I ARM coded all the speed critical parts.

Robin

[saratoga]

Robin, I sent you an email to the Tremolo account mentioned in your source code a few days ago. Did you get a chance to look at it?