Hi Sean,
Hi all, just grabbed the mad libs today. So far, the sound is as good as mpg123 (at least as far as my ears and speakers are concerned). The CPU usage is about 2 - 3 times that of mpg123 on the same mp3 files. However, mad seems to use a wee less memory.
The Layer III decoding should get a bit faster once the IMDCT is rewritten, and the memory footprint may even get smaller. :-)
I have doubts that the speed will eventually reach that of the floating-point decoders, but I'd love to be proven wrong. My primary goal was to have it run well on machines without an FPU, and so far so good.
All told, seems like a nice little lib, hope to dig into it more as time goes on. The web page mentions possible API changes, any idea of how soon? How far different?
Version 0.10.0b has a prototype API in place that I think is close to what I want. I'd very much like feedback from anyone who has looked at it. The API has two layers: a low-level interface in which each decoding step is carried out explicitly frame-by-frame, and a high-level interface which can be called either synchronously or asynchronously to decode and play an entire stream at once. The high-level interface merely makes calls to the low-level interface and uses callbacks to the application when it needs more input and to play the output.
The current madplay.c uses the high-level sync interface; the versions previous to 0.10.0b used the low-level interface. I am in the process of writing a small utility to calculate the exact playing time of an MPEG stream (even VBR streams) that will use the low-level API.
The part that's most incomplete right now is the async API. It will currently decode a stream in the background, but there's no way to send it control messages. (Well, you can send it messages, but they'll be ignored.) I'm not certain yet what these messages should look like.
Once I get some feedback and become fairly confident in the API, I plan to write up some documentation. Until then, feel free to ask if anything is unclear.
MAD's API is a little different from others I've seen in that the synthesis step is decoupled from the decoding step. This means there is an opportunity to write some interesting filters on the decoded subband samples before they are synthesized into PCM samples. For example, this is how madplay implements stereo->mono conversion given the -m switch, although for Layer III there is also a more efficient way to do this.
This is also where an equalizer filter could be added. Yet another possibility would be to mix two MPEG streams by decoding separately and joining in the filter, performing synthesis only once. This could be used for cross-fades or to overlay speech over music, etc. with minimal overhead.
Apart from the async API, the biggest change I can see coming would be for MPEG 2 multichannel support. I haven't looked into this very much yet but my copy of the ISO/IEC 13818-3 standard arrived recently so I can work on it.
-rob