Re: The Artists thing

[Pierre Phaneuf <pp@ludusdesign.com>]

Pedro Medeiros wrote:

> > If you don't might to have the sound play next week. Esound has SO MUCH
> > latency, I can hardly believe it. I'm pushing for non-threaded sound
> > engines, so you can imagine what my opinion of sound engines in separate
> > threads is? ;-)
> 
>  I've completely forgot about that. :)

Actually, I meant "sound engines in separate processes", which is even
worse. :-)

> > Two processes for something as time-sensitive as sound is crazy. On my
> > girlfriend's K6-2/350, when playing a MP3 with XMMS through Esound, very
> > simple stuff like starting a xterm or moving a Netscape window (with
> > Window Maker) makes the audio skip. This doesn't look too good for
> > games. And I only have a Pentium MMX 225! ;-)
> 
>  Well... This thread thing must be the main reason why there is a
> project like Realtime Linux (is it the real name?). I know it's
> mostly used for scientific purposes, but I've seen some messages
> about game development with that. Or you could just use a sound mixer
> that doesn't use threads. What about fork()? Does fork() has much
> latency?

I use a sound mixer that doesn't use threads (non threaded).

fork() spawns a process, which is just like a thread, except that memory
and file handles are not shared between the two execution contexts
(which means that you either have to use inter-process communication,
like explicitly shared memory or pipes to communicate between the two).
I prefer fork() to threads when I just *absolutely* need a separate
execution context, but my primary choice is to avoid separate contexts
as much as possible.

Esound is an example of a fork()ed sound process that communicates with
pipes. Shared memory gives a performance closer to what happens with
threads (pipes are awful for large amount of communication, like sound
sample data).

-- 
"Unix gives you just enough rope to hang yourself -- and then a couple
of more feet, just to be sure." -- Eric Allman

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk