Small memory-leak in MOD decoder

[Ryan C. Gordon]

> It looks like I've put a small memory-leak in the MOD decoder. In
> MOD_close() I only call Player_Free(m->module), I never call free(m).

It's fixed in CVS now.

> Ryan, I assume you've been busy elsewhere lately (working for money
> again, eh? ;-), but could you please make that change when you get the time?

Working for free at this moment.  :)  I just made the change.

> (Ideally I'd also like to see the libtool and "test for MP3-ness"
> patches discussed in the past few days applied. I can't even build
> SDL_sound unless I use rev 1.1 of acinclude.m4 instead of 1.2, which
> makes it look as if we're in much worse shape than we really are.)

I'll look at the MP3 thing in the morning. I'm leaving the autoconf
details to Max, since (honestly) autoconf scares the hell out of me.  :)

Right now I'm trying to get a Shorten (.shn) decoder implemented for
SDL_sound. Sam is giving me write access to SDL_mixer in the near future,
which is darned good motivation to get SDL_sound prepared.

SDL_sound is actually in good shape, feature-wise. The things that are
lacking are on the near horizon (such as MIDI support, etc). What should
really become a priority for us is making sure the library is portable to
various platforms. Max's work on the build system is going to be 9/10ths
of that battle (and I can't thank him enough for doing such a thankless
job!)...the other sliver of work will be cleaning out portability
assumptions, and, harder, finding a means to try this. I don't have a
Windows or BeOS or Solaris box handy, and I don't have a recent compiler
for MacOS classic...however, I have built SDL_sound on PowerPC Linux, and
it DOES seem to be byte-order clean, which is good news.

In short, Max will handle the initial ugliness, and then we need to find
systems (or volunteers with systems) to get SDL_sound working on their
exotic platforms. After those minor patches are in place, whoever is brave
can help me tackle the SDL_mixer work.

There are other things that can be done with SDL_sound, too. Besides the
fact that there are other decoders to be written, no API is worth jack
without applications using it. I'd like to see a XMMS input plugin as a
proof of concept for this (and I see an API extension needed there...the
ability to seek in a sound file if possible). XMMS certainly has input
plugins for everything that SDL_sound currently does, but like I said,
proof of concept. Another thing that might be interesting would be a sound
converter; you decode something through SDL_sound, and then this program
can spit the sound out in another format...hmm...sounds like sox. At any
rate, there's other applications for SDL_sound, although SDL_mixer is the
real beneficiary here.

We have tons to do still, but I think we're doing well, and (by my
calculation) we're actually a little ahead of schedule at the moment.  :)

--ryan.