Something MikMod this way comes...

Ryan C. Gordon icculus at
Sat Jan 19 16:36:04 EST 2002

> Ryan, you've been mentioning problems with the MikMod decoder handling
> more than one module at a time. Is this related to the "ability to have
> several modules in memory (it doesn't work in all cases in the current
> version)" entry in the MikMod TODO, or are there other problems as well?
> This could be a good time to alert them to any problems we may find...

My concern is the global variables that control MikMod's behaviour.

For example, md_mixfreq. If I've got two MODs playing at once that want
different sample rates, I've got to convert at least one of them, which is
a needless expense, since that variable could have just as easily been a
part of the MODULE structure. There are other variables that are more
problematic than this one, if I recall correctly.

I haven't looked closely at it recently, but I was under the impression
that this is a problem that will require API breakage in MikMod to
correct. I'd just as soon make ModPlug the default (or at least, list it
before MikMod so it picks up most of the MODs) and not worry about it.

Other stuff:
 - shn.c has a (very hacky) rewind method, which is good enough for now.
 - The need to call SDL_OpenAudio before using SMPEG to decode can't be
   avoided, since SMPEG relies on SDL_MixAudio(), and that function needs
   an audio device spec to mix to. The most ideal solutions are to either
   add a function to SMPEG to decode without mixing (since we're just
   "mixing" with a buffer of silence everytime, this would fix the
   problem AND cut down some overhead, too), or add an mpglib decoder to
   SDL_sound (which I'd like to do eventually, but I'm not tackling it
   right now). Realistically, it's not a problem, since I presume anyone
   using SDL_sound will be using SDL for audio output, too, but it bothers
   me anyhow.  :)


More information about the sdlsound mailing list