[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PFile problems
Peter Burns wrote:
> > Well, I guess the former includes the latter, but do you mean it is
> > possible to play sound synchronously (without a thread)?
> It is possible to play sound synchronously without a thread. Take a look
> in AudioToFile.cpp. This file is for the implementation of the
> AudioToFile class which is used for systems that I can treat as if the
> device was a file. This includes the open sound system (/dev/dsp), the
> enlightened sound daemon and simply writing the output to a file. If you
> define NO_MIXER_THREAD then instead of having a thread call
> AudioToFile::Mix() every now and again, it is assumed that the
> programmer is responsible enough to do it regularly enough to prevent
> gaps in the sound. I did this so that it would be easier to test since
> gdb isn't great with threads.
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
I think you can map this to some kind of "objects" on Win32, I do not
know for other OS. I was told that on most OS there was a select
equivalent *except* for BeOS, which assumed that you threaded heavily,
so simulating a select has to be done by spawning a thread for each file
handle, trying to read zero byte from it (this will block if nothing is
available) and killing all the threads when one of the thread is ready.
This is a naive implementation and could probably use something like a
poll of threads or whatever.
This was just FYI.
Ludus Design, http://ludusdesign.com/