Christopher Oliver writes:
 > > With polling, you can still get practically optimal behavior, *if* you
 > > choose the polling interval well--it's one more knob to tune.
 > 
 > This is directly determinable from sample rate and buffer size.  Even in
 > the threaded code, you must have this information or an assurance of a
 > non-blocking write to /dev/audio short of KERNEL threads.  My feeling is
 > short of a truly uniform thread model across all architectures, you're
 > tying this very strongly to a single OS and architecture.  (Does your
 > model work with SunOS?)  I've had more than a couple of comments that
 > portability is a key issue here.


You can determine a good polling interval, if you know the buffer
size, sampling rate, and sample format.  To do really well, you could
also take into account things like memory speed and system-call
latency.

With the threads approach, you don't have to build such a timing model
a priori.  You just tell the operating system what you want done when
the data has finished being read/written.  This is conceptually a tiny
bit simpler IMHO.

The threads approach does require that threads are preemptive, so that
the background thread will get to complete its read() when it can.  (I
think that POSIX threads are required to be preemptive, but I'm not
sure).  The only other requirements on the thread libraries are that
mutexes and condition variables actually work.

These seem like pretty modest restrictions to me.  The strongest
restriction seems to be that a pthreads implementation exists at all.
If there isn't one, there are probably no preemptive threads packages
at all, and another approach is needed....

By the way, SunOS doesn't support OSS anyway.  It does have
kernel-supported async IO, which it would be a shame not to use if you
are rewriting code anyway.  (At least, this is what I glean from the
man page)

Lex