Re: [tuxracer-devel] Greetings, and a question.

[Steve B. <sjb...@ai...>]

Joseph Toscano wrote:

> Yeah, the MikMod_Update() routine takes for *ever* sometimes. I could
> never understand that.

Having written the sound module for PLIB, I can explain this easily.

When the sound 'update' routine is called (presumably every frame),
it has to generate enough sound into the sound board to last until
the application program gets around to calling it again.

You *could* generate 'enough' to last a couple of seconds - but if
you did that, you'd run into trouble if the player pushes the 'fire'
button 10 milliseconds later and needs a "BANG!!!" sound effect within
a tenth of a second or so.  You've already buffered up a couple of
seconds of audio - so it would be two whole boring seconds between
pushing the button and hearing the sound.

So, you really have to generate a SMALL amount of audio data - but
not so small that you'll have gaps in the sound when the graphics
and game-play code takes a little longer than you expected.

My PLIB library lets you set how much data to compute in each
iteration.  MikMod appears not to - which means (I think) that
it has to set the time to some large number to allow for the
worst case application.  Hence MikMod isn't great for sound
effects (IMHO).

Another problem (which seems to afflict glTron sometimes) is
that if every call to the audio 'update' function generates
(say) 1/10th second of audio - but the application calls
update (say) 20 times per second - then each frame the
amount of queued up data going into the sound card will
exceed the amount coming back out again and eventually,
the buffer will fill up - causing the audio software to
lock up until it empties.

MikMod seems to do that a lot - which explains the
occasional pregnant pause.

What PLIB does in each 'update' call is to ask the
OS how much data is queued up in the sound card - and
only to generate just enough to 'top it up' to the
required margin.

I suspect that either MikMod doesn't do that - or
perhaps that it uses some kind of dead-reckoning
mecthod to guess how much to send.  A small error
in that estimate could build up over several seconds
and cause the problem I saw with glTron.

Dunno exactly though.


 Question, though: The Adonthell team is writing
> Adonthell using SDL. The people who wrote SDL integrated MikMod into a
> seperate add-on lib, SDL_Mixer. It works fine. Not sure what lib you're
> using for Tux Racer, of course. I wonder if MikMod can be rolled into
> that library somehow.

Perhaps.  I'm not sure it would help with MikMod's lockup problem
though.
 
> I. . . *suppose* I could write music in MOD format, but. . . if the
> music ends up in MOD format, it's better to have no music at all. It's
> depressingly unimpressive. <g> It'd detract from the game if anything.

Well, I do plan to add more music formats to PLIB *sometime* - but
I only have so many hours in the day.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)