Re: Linux sound (and threads)

[Jeff Read <bitwize@geocities.com>]

Pierre Phaneuf wrote:

> This is very curious, because I also thought of that approach. That's
> exactly the one used in Doom, and it does lag, but the reason it lags
> might be as simple as not flushing the pipe after a write (easily
> fixable) to the hard ones like the context switching required.

I have not noticed any lag while playing Gnudius. Playing Quake 2 under
Windows lags a lot more sound-wise; I think this has to do with thunking
DirectSound routines down to the standard Windows multimedia layer, so
that I can just *get* sound on my ancient sound card :)

> What I actually find curious is that when I considered this approach, it
> turned out that the trouble of crossing the process boundary (this
> involves managing resources in both processes, pipes, assigning IDs to
> the sound effects and keeping track of them) was *more* trouble than
> what was saved by having the sound server "work by itself". Calling the

You make it sound like a lot more trouble than it really ended up being
(at least for me). I coded xhsound in the space of a week or so and it
worked reasonably. A few tweaks made the lag go away for good :)

> process_sound() method is *really* easy to do, considering that games
> normally have a few hot spots where they go really often, like frame
> buffer page flipping or input polling.

I would have to agree with you that this is probably the better method.
But, I'm lazy, xhsound works fine and I haven't Gotten Around To Fixing
It. :)

> Also, count in additionnal time used to manage locks and mutexes for
> concurrent access, this just goes thru the roof for close-to-the-metal
> game programming.

Back when I was hacking Win32 the number of threads I had maxed out at
2, one that repeatedly positioned the objects and redrew the screen; and
another which handled input events. This was *relatively* easy to manage
and allowed me to take a programmer's shortcut by putting the
move/render thread in an infinite loop and the event thread in a
busy-wait. These days I just use the single thread and put everything in
the same big loop.

> In Quadra, we use matrix-based explicit dispatching between small units
> of execution, a kind of dynamic state machine, which is deadly
> efficient, switching "threads" at moments we precisely defined. Nothing
> is concurrent, so no locks/mutexes are needed.

I dunno what that means but it sounds a lot like what Sprite32 does
which is to call a user-defined method for each sprite before doing a
screen refresh. Using C++ inheritance you can make each game object into
an independent finite-state automaton which reacts to certain events
such as collision with another sprite or passing by a certain X
coordinate on the screen. This method is amenable to both single- and
multi-threaded execution and frees me from having to think about the
main game loop :)

(See? C++ object orientation is good for something.... :))

> The problem is, this is a pain to program to. We found that cool library
> that could do non-preemtive threads in Unix at
> http://www.engelschall.com/sw/nps/, but it doesn't work in Windows (uses
> a wizard-level hack involving signals and manipulating stack frames). A
> similar library that would work on both Unix (at least Linux) and
> Windows would be extremely cool. With a XFree86-style license or the
> MozPL (not the GPL, as we are into *commercial* games, and even the LGPL
> is a pain in the ass, it prevents statically linked binaries, for
> "dubious" systems (but is mostly fine otherwise)).

Guile (a GNU embedded interpreter) comes with a non-preemptive thread
library called QuickThreads (or QT, not to be confused with the Qt
widget set of KDE fame). I dunno how well it works for your purposes, or
how it works in Windows.
-- 
----------------------------------------------------------------------
Jeff Read <bitwize@geocities.com>
Unix Code Artist, Anime Fan, Really Cool Guy