PF>I allocated enough buffers (min 2) to hold as many seconds of audio data as
PF>required.  Each buffer also gets its own event sem.  As
PF>each buffer is played,  and i get the MMOS2 notification,
PF>I post the event sem for that buffer -- at which time
PF>another thread, blocked on that sem (the sems are always
PF>cleared in the same round robin order) wakes up and fills
PF>the buffer with new data.

Yes, except I need the latency from the time I choose to start playing a
sound, to the time it actually comes out the speakers to be as short as
possible, which means I need the buffers between the application, and
the sound card to be as small as possible.  With my original playlist
implementation, like the one you are using below, I needed at a minimum
3 64K buffers, at 44K/sec, that's 1-1/3 seconds of buffered data.  I
don't think people would like pulling the trigger, then waiting over a
second for it to go "bang!"  I AM running the playlist continuously, so
its not the startup delay that's the problem, its the time it takes to
get through all the layers and out the speakers.

Having talked to several people on the original MMPM design team (love
that internet) I've come to the conclusion that 2.1 folks, and those
without DART capable sound drivers, are going to get music and
voice only, no sound effects.  Which is too bad, with the Dolby Pro
Logic code I have added, those sfx sound pretty spectacular.

PF>ps: why still support OS/2 2.1?  This only makes sense if
PF>you are writing a business application,  as they are still
PF>a few businesses that have not switched over.

There are around 10M OS/2 users according to IBM.  There are some 6M
warp users.  I don't like to exclude FOUR MILLION PEOPLE if I can
avoid it, since the rest of the program is perfectly 2.1 compatible. I
am going to need all the customers I can find when this thing finally
hits the market.

Rob.
___
 X SLMR 2.1a X It isn't pretty being easy.

--- Maximus/2 3.01