Something MikMod this way comes...
Ryan C. Gordon
icculus at clutteredmind.org
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.
- 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