Re: Sound

[Pierre Phaneuf <pp@ludusdesign.com>]

Ian Crawford wrote:

> > p.s.  How are you playing the sounds in the game?  I've looked at gsi
> > (wouters.www.cistron.nl/gsi/gsi.html) and it looks pretty good, but I
> > would also like details on low level access to the sound device.
> 
> I'm looking into using esd, the Enlightened Sound Daemon.  I've played
> with it a little, but not enough to be able to report on its
> strengths/weaknesses yet.

Both of these uses out of process sound servers, just like Doom did. I
remember a problem with this approach, it induced lag between the screen
and the sound.

Now, I don't know whether this is a failing of the implementation and
that GSI and esd are okay, or if they both suffer from the same problem,
but out of spite, here, we wrote our own sound routines that are
in-process, no thread or anything.

What we do is that we have a Sound::process() subroutine that is called
as often as possible (we put a call in our Video::flip() method!).

We have two "fragments" (as per the OSS documentation), during
initialization, we get the block size and allocate a buffer of that
size.

We call the SNDCTL_DSP_GETOSPACE ioctl() to check if we can write any
fragments without blocking (if audio_buf_info.fragments != 0). If we
can, we fill the buffer with mixed audio data and we write it to the
device. If we can't, we simply return.

I read in Zoid's .plan update once that the sound in Quake 1/2 is done
that way. Sounds fine here.

The problem is that we have to mix ourself, since we use the device on
the bare metal.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi
.