So, I see comments to the effect of "need some n-bit type here", "depend on <type> being n-bits", etc. Is there a reason you did not use the int32_t and what not types? They are part of the new C standard, so will be portable.
There are only a very few places where I make assumptions about type length, and this is largely due to haste more than anything. These places are marked so I (or you :-) can fix them.
A bigger problem in my view with respect to portability are the places where I rely on sign-extending right-shifts, and the GCC extension I used to initialize members of the Huffman table unions. In time I'll fix these too.
The inline assembly naturally is also non-portable, but this is conveniently isolated and there are a few C substitutes at hand.
As part of the library API change, it would be nice if library calls were prefixed by some library name, i.e. mad_audio_output(). This way calls for library routines are easily separated from other code. mapplay.c has a function called audio_init(), yet audio_output() is from libmad. This is down right confusing. Seems some functions are defined with the mad_ prefix and others are not.
Be careful not to confuse libmad with madplay; all (well, most) exported libmad symbols are indeed prefixed with mad_. The only exception I think is the fixed-point abstraction which uses f_ and the fixed_t type. (Perhaps these should also be prefixed with mad_?)
The other audio_* calls you see in madplay are not part of libmad; they're part of madplay's audio abstraction to support multiple output modules. A look through audio.h, audio.c, and audio_*.c should be instructive. Admittedly, madplay probably should not have defined its own audio_init() and audio_finish(). Sorry about that. :-)
It might also have helped if I had put the libmad source strictly into a separate subdirectory, and I may eventually do this. For now, only what you see in libmad.h should be considered part of libmad.
Trying to use 64bit fpm on my pII box causes the CPU load to go up from the average 10% that top shows to around 15%, no noticable sound change. How difficult would it be to add support for external dsp's, like on the sound blaster mp3 cards?
I don't have very much experience programming DSPs so I don't know. Anyone?
I used to own a netwinder, how is the performance on the arm chips?
Funny you should ask. :-)
I was recently doing some performance tests to compare MAD against other fixed-point decoders I'm aware that also run under ARM. Here's what I found; this is the amount of CPU time required to decode a stereo MPEG stream in each of the audio layers as a percentage of audio real-time:
CPU: StrongARM 1100 220MHz OS: Linux 2.2.14-rmk5-np17-empeg22 Layer Layer Layer decoder version I II III ------------------------------------------------------------- [1] MAD 0.10.0b 23% 22% 37% [2] Xaudio 1.3.1 21% 25% 24% [3] splay-fixpoint 0.81 41% 36% 43% [4] mpg123-arm32 0.59r [5] 27%[6] 32%
[1] http://www.mars.org/home/rob/proj/mpeg/ (GPL) [2] http://www.xaudio.com/ (commercial) [3] ftp://ftp.netwinder.org/users/n/nico/ (GPL/LGPL) [4] http://melanoma.cs.rmit.edu.au/werj/simonb/ (restricted)
[5] failed to decode bitstream [6] outputs silence
This doesn't tell the full story, though, as there are reports of splay decoding Layer III using as little as 4% of the CPU under a 280MHz SA-110 Netwinder while Xaudio and MAD still require 15-23%. This is quite a dramatic improvement for splay, and I'd love to see if MAD could likewise be optimized. (Hi Nicolas!)
I think there is potential for MAD to reach at least Xaudio's level of performance on the ARM. MAD's Layer II decoding is already faster than it is with Xaudio, and all layers share the same CPU-intensive subband synthesis... The current challenge will be in writing a fast Layer III IMDCT, of which several examples exist.
-rob