audio.c converted from WaitForSingleObject to poll
ughbash at yahoo.com
Thu Nov 1 02:57:43 CST 2001
--- eric pouech <eric.pouech at wanadoo.fr> wrote:
> well, from a pure semantic point of view, I think we
> have to wait.
I've shown (to myself) experimentally that just
removing the waits breaks.
What I've done instead is reversed my poll patch and
added a patch to mmsystem.c which causes application
(and possibly some non-application) callbacks to be
called from a different thread so that
wodPlayer_Notify doesn't ever halt waiting for the
application to return (which may in turn be waiting on
wodReset,wodRestart, wodClose, wodPause etc). I'll
post this to wine-patches in just a moment.
> for wodGetPosition, it currently returns the
> position of
> data which have been notified to the app (and which
> has been actually played).
> What's the exact issue on HL ?
With the audio.c poll patch I posted, wodPlayer_Notify
doesn't update the total bytes played until after
sufficient time has elapsed for the dsp to have
finished playing it. The absence of more data to send
to the dsp may stop the polling loop before all sounds
have been played, meaning that the total bytes for a
the last sample written may not be updated until the
next wave is queued to be written to the dsp.
It appears that HL loops checking wodGetPosition until
the last sound has been played before writing the next
sound. This never happens with my poll patch because
of the issue in the previous para. Hence: no sound.
I verified this by doing another evil hack which just
notified and updated total bytes as soon as they were
written. The sound returned.
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
More information about the wine-devel