Hi,
poking around in dsound the other day has raised a couple of questions
which I was too lazy to fully investigate. I thought I'd poll here to find
those pseudo experts.
1) There's a race condition between DSOUND_WriteAudio, DSOUND_CloseAudio and
DSOUND_OpenAudio. Calls to these methods have the pseudo guard of
if ( audioOK == 1) {...} which isn't strictly required (at least to a
cursory glance). What is required is a consistent critical section locking
scheme. Presently either the primarybuf->lock or the dsound->lock are used,
but not consistently. As a result we have thread clash that usually wacks
sound out badly.
I would suggest that the code should be the primarybuf->lock, but would
like confirmation.
Also, what order should the dsound and primarybuf locks be acquired in the
case where both are needed (to avoid deadlocking)? dsound then primarybuf?
2) What is the intention of the global dsound and primarybuf pointers? I'm
thinking that when multiple interfaces from multiple processes/programs are
using these things we'll end up with problems. Or, is it possible to have
per instance dll data (call me ignorant)? Would it not be better to just
pass something from the interface around - perhaps a little more clumsy
but more correct?
At present they at least partially confuse the code and make reference
counting a complete annoyance (and broken).
Ciao,
Peter Hunnisett
[EMAIL PROTECTED]
