Marius Sundbakken wrote:
I did wrap the minimad example easily into a class, but I then got stuck. Firstly, it outputs to stdio. Can MAD actually output to the audio device or is that beyond the scope of the library (i.e. it's only a decoder). I figured I could replace stdio with /dev/pcm (or audio?), but this, I'm afraid, is not very portable, is it?
MAD itself is just a decoder. What you do with the decoded PCM is up to you.
If you want to play the PCM on an audio device, you'll need to use the audio API for your particular system. Some systems use OSS (Open Sound System) which is accessed via /dev/dsp or /dev/audio, with a set of ioctl()s to select the output format and sampling frequency. Other systems use the Sun audio interface which is similar but different. On Windows boxes, there is the waveOut API. Other systems now support ALSA, the Advanced Linux Sound Architecture. And so on. So no, sound output methods are not very portable.
`madplay' supports multiple audio APIs as well as a number of audio file formats through an audio output abstraction, implemented by the audio_*.c files.
Writing these questions down, I realize how "trivial" they are. I think it shows clearly that documentation is needed, though I understand MAD still has some way left to go for a 1.0 release (true?) and things will change. Have you considered to use a documentation tool (e.g. Doxygen) for the code?
I'm not a fan of automatic documentation systems, but yes, documentation is definitely something on the list to do.
MP3File m("my_song.mp3"); m.play();
I don't think I've seen anything like this yet, but it sounds like it might be useful.
Absolutely. It's great that MAD provides a fine level of control, but a class like the above, with additional stop(), pause(), jump(int) functions is probably enough for many.
While I think this might be useful, let me clarify by saying I probably won't be the one to write such a thing. Perhaps, however, you will. :-)
Cheers, -rob