[sdlsound] mpglib in SDL_sound

[Ryan C. Gordon]

> The files decode_i386.c and dct64_i386.c would seem to indicate that
> it's only tested on Intel-based platforms. Perhaps it's making
> assumptions about byte ordering and/or alignment? Can anyone here verify
> that? If so, that would seem like a good place (for someone else :-) to
> start tinkering.

My list of known bugs for mpglib is currently:
 1) Completely intolerant of corruption. I had an MP3 with two bad frames
    (according to mp3_check), and the decoder aborts with an error upon
    hitting it (and as such, the SDL_sound interface throws up
    SOUND_SAMPLEFLAG_ERROR). I've been playing this song through SMPEG for
    weeks, and never noticed. XMMS (which uses mpg123's more robust engine
    for MP3 decoding) doesn't puke, either.

 2) Lots of stderr chatter. Easy enough to fix.

 3) Doesn't seem to like looping very much. This one is probably my bug,
    though.

 4) Decoding uses a global variable (look for "gmp" in the mpglib
    sources), which needs to be removed to prevent race conditions.

 5) I have the sample properties hardcoded, but a lot of files seem to
    play as a single channel, or < 44100Hz or something, and sound awful.
    How to get this information from mpglib wasn't immediately obvious, or
    it is SUPPOSED to play at that format, but doesn't recognize those
    formats (or perhaps it chokes on variable bitrate files?

 6) Probably other things.

I can't check the byte ordering thing, since I don't have a decent setup
on the iMac at the moment. Max? Darrell? Want to see if this thing even
builds on MacOS?

--ryan.