Decoding performance on iPOD

[Buschel]

Hello everybody,

after using and playing around with rockbox I am now quite interested in the decoder performance of especially musepack on the PP-processor (iPOD). Did anyone made
measurements or profilings? Are there measurements which can be compared to e.g.
.mp2 or .mp3?
I just downloaded the source code and plan to get it compiled over the next weekend.
Of special interest is the synthesis filterbank which was quite well optimized for PCs
(586). I wonder if there is still some performance left to sqeeze out of the decoder on
the iPOD...

Anyone can give me some hints about current measurements (.mp2/.mp3/.mpc)?
Or any history on the optimizations made within the .mpc-decoder (I know there were lots of optimizations in 2005)?

thanks,
Buschel

[stripwax]

Hi Buschel
Optimising decoder performance is definitely a hot topic, good to see you are interested in this!  Two good metrics for measuing "performance" are boost ratio, and battery life between charges (search the wiki for a good methodology for measuring battery life).  Boost ratio refers to the percentage of time that the CPU is running at a higher clock speed (as pp cpus have a variable frequency) - this is viewable in the rockbox debug menu.  Lowering the boost ratio should have the side effect of increasing the battery life between charges, of course.

Almost certainly ipod codecs can be optimised further - in fact rockbox devs will not formally 'release' the ipod rockbox port until battery life has improved considerably.  

You can also find some patches on the tracker relating to code optimisations for audio decoders, there may be some detailed profilings there too.

For example, here's some possibly relevant patches along this theme
http://www.rockbox.org/tracker/task/5226
http://www.rockbox.org/tracker/task/6705
http://www.rockbox.org/tracker/task/6848
http://www.rockbox.org/tracker/task/6734

Not sure anyone has conducted a thorough investigation of musepack performance compared to (say) tremor or mp3, would be interested in the results.

[saratoga]

This week a plugin was added for benchmarking codecs that can give you the exact runtime, so no more need to use boost ratio.

Actually, if anyone is interested, it might be neat to make a wiki page like for the battery runtime ones, except for how fast each codec is on a given player with a given SVN revision.  

[Llorean]

There would need to be a definition for proper testing: For example, always using the maximum bitrate the decoder allows, or do you use equal bitrates (128 for all lossy codecs, for example), or some standard bitrated decided in advance for each?

As well, at those bitrates, you should probably encode from the same .wav file just for consistency's sake.

[saratoga]

Depending on the bandwidth to burn, maybe reference tracks in each format could be provided, that way the test is exactly the same for each person.  

[Buschel]

Hello,

thanks for the answers. I will have a look at the codec benchmark -- I guess it is activated via compile switch.
Two ideas:
1. Why not create / use reference files for each codec. For decoding performance we could simply use white noise encoded at e.g. 192kbps target bitrate -- most codecs should support this bitrate or can be tweaked via commandline to use up to this rate. No rights issues with white noise )
2. Do we have a possiblity to decode files to disc/flash? This would a good point to check whether the performance optimization lead to same or comparable results. Especially when tweaking the synthesis filters one could get hints about possible failures and the bug-location.

[Lear]

You can certainly hack the codec, or write a test plugin (that uses the decode library) to write to a file. And you can run this in the simulator, which is convenient for verification purposes.

There's also a profiler in Rockbox, enabled by selecting (A)dvanced, (P)rofiling during configuration. (It's not used that much, so you might need to do some hacking to get it to build.) See the Wiki page SourceProfiling for some more information about this, including on how to get useful information from it.

[Buschel]

Ok, so the PC-simulator will do real decoding? I thought it would just simluate the HMI-behaviour. Nevertheless I cannot test for performance only for for validation of decoding results. But that's better than nothing

[linuxstb]

Hello,

thanks for the answers. I will have a look at the codec benchmark -- I guess it is activated via compile switch.

To enable the "test_codec" plugin, add the line "test_codec.c" to apps/plugins/SOURCES and also add the line "wav,viewers/test_codec,-" to apps/plugins/viewers.config and recompile Rockbox.

You can then test decoding any audio file by choosing test_codec from the "Open With..." context menu option.

Two ideas:
1. Why not create / use reference files for each codec. For decoding performance we could simply use white noise encoded at e.g. 192kbps target bitrate -- most codecs should support this bitrate or can be tweaked via commandline to use up to this rate. No rights issues with white noise )

This has been discussed for years, but no-one has got round to creating such a set of test files.  The closest is rasher's collection here:

http://www.rasher.dk/rockbox/soundfiles/

But that's out of date as far as file formats supported by Rockbox.

No need to go for white noise - there are many freely distributable audio files available, for example those at www.archive.org.

Bagder has offered to host such a set of files at http://download.rockbox.org

2. Do we have a possiblity to decode files to disc/flash? This would a good point to check whether the performance optimization lead to same or comparable results. Especially when tweaking the synthesis filters one could get hints about possible failures and the bug-location.

I'm working on adding a wav-writing option to test_codec, but it's not done yet.

[Buschel]

Hi all,

first the good news:
Installing cygwin and everything around worked fine. I am able build the software for iPOD-Video and get it running on my hardware! Thanks to your good how-to's )
Also the test-codec feature works fine.

the bad news:
From what I saw in the source I was sure there were several double-calculations within the synthesis filterbank. I removed these calculations with direct int32 / int64-multiplications. Decoder now becoms (slight) slower?
In general the signal workflow in fixed point is hard to follow compared to the float-signals I am coped to...

[safetydan]

What codec are you seeing that uses double? For MP3 decoding, libmad is already fixed point and shouldn't need any changes in that respect.

[Buschel]

I am working on musepack. Just tested some thoughts about reducing 64bit-multiplies -- seems to work, the speed-up is few though (+5%). For this I needed to reduced the quality of the synthesis filter, I do not have any overview about the differences in the overall-output yet.

[linuxstb]

I've just (a few minutes ago) committed wav-writing capabilities to test_codec.  Hope it helps.

[preglow]

From what I saw in the source I was sure there were several double-calculations within the synthesis filterbank. I removed these calculations with direct int32 / int64-multiplications. Decoder now becoms (slight) slower?
In general the signal workflow in fixed point is hard to follow compared to the float-signals I am coped to...

Where did you see this? The only use of doubles I can see in synth_filter.c is in the _() macro that is used for stuff that is resolved at compile-time. There shouldn't be any floating point calculations done runtime.
Which 64 bit multiplies are you removing? In general, one should try optimising all other areas of the code before starting to compromise accuracy.
Also, why optimise musepack? This codec is already one of the fastest ones we have, why not try to optimise libmad, for example? :)

[Buschel]

I am working on musepack because I only have .mpc-files. Also I am quite into this codec...

Regarding the use of doubles/float in the synthesis-filter: As far as I can see there are several scaling operations in calc_new_V() which use the macros MPC_SCALE_CONST, MPC_MULTIPLY_FRACT_CONST_FIX and similar ones. These macros are expanded with usage of the MAKE_MPC_SAMPLE_EX macro. This one will use double-conversion and -multiplication.

I removed these conversions via defining additional constants and a new macro. Now either 64bit- or 32bit-multiplies are possible.

Current I am measuring different combinations of the optimization -- including using -O1 instead of -O2. Including all optimizations (also accuracy reduction) the performance went up by up to 18%.