--- eric pouech eric.pouech@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. http://personals.yahoo.com