audio.c converted from WaitForSingleObject to poll

[Simon Britnell]

Please forgive the length of this missive, I have not
the time to write a short one.

There are a couple of (serious) bugs in my patch to do
with notifications (more latere).  It has, however,
uncovered a couple of race conditions that
applications may trigger to hang the wodPlayer with or
without this patch.

-- BUSY LOOP --
There is no busy loop because:

retval=poll( pollfd.all,
             wwo->state==WINE_WS_PLAYING),
             -1 );

only polls the dsp when in the playing state and:

if( !wodPlayer_WriteFragments(wwo) ) {
    /* stop playing if there's nothing to play */
    wwo->state = WINE_WS_STOPPED;
}

Causes the state to become stopped if we run out of
things to write.

-- BUGS --

Some wave completions will not be notified until
something else is played (Doh!).  I'm still thinking
about this, but the (wrong) easy solution would be to
notify on completion of the write instead of
completion of the playback.

wodGetPosition doesn't keep pace with how much has
actually been played.  This causes sound to fail in
HalfLife.  I'd like to remedy this by keeping track of
the total written rather than the total played and to
return that value less the amount ioctl says is still
in the buffer to be played.

-- RACE CONDITION --

wodPlayer_Notify (which, as you may guess from the
bugs above, is my arch nemesis) triggers a callback
into the application.  If the application makes any
wod calls which wait on the wodPlayer thread to set an
event (wodReset,wodRestart or wodPause), the wodPlayer
thread hangs waiting for wodPlayer_Notify to return,
which is waiting for wodPlayer to
SetEvent(wwo->hEvent).  Any other threads attempting
to wodReset, wodRestart or wodPause will then pile up
behind the stalled wodPlayer, potentially hanging the
whole program.

Looking at the code, it appears at first blush that we
may simply remove the SetEvent() and the
WaitForSingleObject() calls to remove this race
condition.  It seems unlikely that this will cause any
problems.
-- WHERE TO FROM HERE --

I shall put my poll patch to one side and provide two
patches against the encumbent audio.c  The first patch
will remove the SetEvent -> WaitForSingleObject on
wodPause,wodReset and wodRestart.  The second patch
will update wodGetPosition per my above suggestion.  I
will then re-examine the poll patch/notification
timeliness issue to see if I can come up with
something reasonable.

Questions? Objections? Flames ? :)

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com