Re: PFile problems

[Pierre Phaneuf <pp@ludusdesign.com>]

Peter Burns wrote:

> > Excellent! The best interface (on Linux) is that of being able to
> > select()/poll() on the file handle. This enables very easibly both ways
> > of playing sound (threaded or not), as the programmer can either
> > select() with a zero (or appropriate for his application) timeout to do
> > it synchronously only when needed, *or* he can spawn a thread that will
> > go in an endless loop of select() with a -1 timeout and calling the
> > mixer.
> 
> Would you like to modify AudioToFile::MixerThread(), to do this instead
> of what it currently does? At the moment it's simply a while loop.

I do not have much time, but I did gave a quick look. You have to know
that /dev/dsp doesn't block if there is enough free buffer, so you might
find yourself mixing too much in advance if there is a lot of free
buffers (I do not know what the defaults are and I think it could depend
on the sound card).

In Quadra, what I do is that I use the OSS ioctl()s to ask for two
buffers of 8196 bytes (I think, this is from memory. My mixing function
mixes for a buffer worth of samples at a time, but before doing so, it
uses an OSS ioctl() that asks if there is a free output buffer. If there
is no free buffer, it returns right away without doing anything (letting
the game add more stuff to play). The idea is to mix as little as
possible in advance, because this will cause lag in the output. I use
two buffers (I think this is the minimum) and they are of a size chosen
according to sample size and the timebase in the game (it runs on a 10
millisecond timebase and a buffer contains something like 30 millisecond
worth of sound, allowing for some lossage). If this is too small, you
will have skipping (you'll hear the same thing repeat repeat repeat like
this), and if this is too large, you'll have lag.

What I think is that your thread simply keeps those buffers as full as
they can be. How large are the buffers? I do not know. If they are large
enough and the sample size small enough, you could have as much as 1
second of lag between the moment the game asks for a sound and the user
starts hearing it!!!

> Win32 has "I/O completions" or something like that. They are basically
> an object that does something when a read or write has finished. I think
> you can set it up to either call a function or trigger an event.

I/O completion ports are only in Windows NT I think, not Win95/98, is
that possible?

I think the MsgWaitForMultipleObjects or something like that call is
more select()-like, it doesn't asynchrously call a function or event or
signal, nothing like that. It takes a number of "objects" (Win32
thingies) and waits until one (or more) of them is "ready" (for writing?
reading? both? selectable?) or a timer expires.

Take a look around line 270 of gmain.c in GLib (the library that used to
be in GTK+).

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/