Small memory-leak in MOD decoder

[Max Horn]

At 5:20 Uhr -0400 01.10.2001, Ryan C. Gordon wrote:
>  > 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.  :)

If somebody could tell me what we are talking about here, sure, I 
will look at it :) I read the mails about the MP3-ness chaeck, but 
how is this related to libtool ??!? what libtool patch?!?

You mean CVS rev 1.1 vs 1.2 of acinclude.m4, and 1.2 is not working - 
well, it contains libtool.m4. But one could argue whether that is a 
good idea, since we require libtool anyway... I think it is better to 
add a comment regarding this to the readme, and get rid of libtool.m4 
in acinclude - this way both users of 1.3.x and 1.4.x can be happy.


>
>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!)...

Thanks :)

>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.

I could test on classic MacOS eventually, but that will require a 
seperate build system anyway (no autotools etc.)

Anyway, so far I have troubles playing something. MP3's don't work at 
all. WAVE, you told me, has no compression support yet, which is a 
serious problem to me; but OK, I converte an MacOS AIFF (resource 
fork based) to WAVE uncompressed, 22,5 kHz, 16 bit stereo - it 
sounded as if it was played at doubele speed -> no good.

"playsound" (which can be built by issuing "make check", just for the 
records), crashes when pointed to an invallid file (e.g. an empty 
file, or the "bootstrap file from CVS).

MP3 ain't work for me, either, which I found somewhat suprising... hm.



>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.

Yeah.


>
>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.  :)



Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890