Re: Linux sound

[Mads Bondo Dydensborg <madsdyd@challenge.dk>]

On Mon, 14 Jun 1999, Pierre Phaneuf wrote:

> Jeff Read wrote:
> I see more and more of things like 'esd' and other sound daemons, and
> also many games uses a separate process or thread to manage the sound
> output to /dev/dsp.

This is what I do (seperate thread).
> 
> But we decided upon another path. We didn't want to use anything else
> than /dev/dsp directly, because the sound daemons aren't very standard
> right now. But the general way of doing it via a subprocess and a pipe
> (or shared memory) wasn't very appealing either. Most people took it
> from Doom I think, and even with Doom, there was problems with the sound
> lagging behind, as the pipe needed flushing and a context switch had to
> happen before the sound was actually sent to the sound card. I would
> assume that the sound daemon approach also has this problem.
> 
> After reading the .plan of zoid@idsoftware.com one time, we decided to
> do it like Quake2 does it, in a single process, with calls to a
> "process_sound" subroutine "sparkled" over the code (we didn't have to
> sparkle very much, we call it at every end of video frame and it seems
> to suffice). This process_sound subroutine uses an ioctl to check
> whether /dev/dsp can take another buffer of sound data, and if so, mixes
> and send the data. If it doesn't have any free buffer, process_sound
> returns without doing anything.

I actually considered this, -after- coding the thread, because I had
serious problems getting pthreads to work with svgalib. (It turned out,
that this problem disappeared in glibc 2.1).

However, I have ended up going for the thread, mostly because of two
things;
- avoiding to call "process_sound" - the sound is beeing processed in the
  background by the OS.
- I almost know exactly how long it takes to enqueue a new sound.
  (Meaning, a call to sound_play(sound) returns almost immidiatly.
  If I had to write to a buffer, it could take variable length. Not a big
  deal.)

> 
> So the sound in Quadra seems fine and in any case, it does work, but I
> was still wondering after hacking that thing if that was the best way to
> do this?

It is almost the same as mine. There are benefits to controlling the
scheduling yourself, and benefits to having the OS do it.

One thing that needs to be considered in both cases is the size of the
buffer, as this will influence lag etc much. I have choosen 3 buffers of
512 bytes at 11khz - this seems to work good. (not on sblive though).

The thread sleeps 12 ms between each write to the buffers. (And it kinda
sleeps in the write, I assume).

As you, I am also wondering.

Mads

-- 
Mads Bondo Dydensborg.                               madsdyd@challenge.dk
Free your mind and your desktop will follow....
                                     Linux - the choice of a GNU generation