Re: Introduction

[Steve Baker <sjbaker1@airmail.net>]

Pierre Phaneuf wrote:
> 
> Keith Lucas wrote:
> 
> > Sound is a bit hairier: it's decoupled from Mesa, so anything goes,
> > but I've not found a ton of stuff about it. My systems minion
> > is playing with sound code ATM, but he's doing it at the fopen("/dev/dsp")
> > level. There are a few APIs about. I bet PLIB's got support in it.
> 
> There are *many* sound libraries (or code part of something else) that
> use a separate sound server process (like esd, koules, doom, xshipwars,
> etc...), a few that use a separate thread (SDL I think, maybe others)
> and even fewer that play sound synchronously (without any threading or
> forking).
> 
> I would think, with approbation of ddt and probably Steve Baker, that
> this is the best way to do it (synchronously, look at the quake
> sources). ddt made both doom and quake, and he always was sorry that he
> made the sound that way in doom, as a *lot* of people copied this, and
> it is crappy (fire off a few rockets and listen to the LAG!)...

Yep - PLIB's SL library does indeed run 'synchronously' - it
doesn't fork another process or thread, instead you promise to
call an 'update' function at a rate that equals or exceeds some
duration that you specify to the library in advance.

Hence, if your game typically runs at 60Hz, and assuming that
you call the sound update once per frame, you could set the
'safetymargin' to perhaps 33msec and each call to the 'update'
function would generate enough audio data to ensure that the
card won't run out of data before another 33ms has elapsed.
That way, even if you occasionally drop a frame due to heavy
load, there won't be a glitch in the audio.

That would also guarantee that there would never be more than
a 33ms delay between a sound being started in the game,
and the audio appearing at your sound card's output.

If your game can't keep a steady frame rate - then you
need to set a longer safety margin and ultimately, there
will be a delay between starting the sound and hearing
it.  How much that matters depends a lot on the nature
of the game.

(Notice that sound travels about a foot in a millisecond...
so unless your game is starting sounds at different times
depending on where they come from, 33ms == 33 feet - so
the delay in the sound system is probably comparable to
the error in when the sound starts due to your program!)

I believe that MikMod also works like this - but according
to the manual, there doesn't seem to be a way to set the
safety margin.

--
Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1