Hi,

- PlaySound_Alloc does not call _Free anymore, so it does not use WINMM_cs
���anymore, which makes it easier to reason about use of critical sections.
- psStopEvent was never used like an event rather than a boolean.
- No need to muck with WHDR_DONE.
- No need to keep the unused thread handle object around.
- Abort the playloop in case of error, like I did for mciwave. ���The error
���may not be transient.

- Free waveHdr and hEvent after closing hWave. ���Either you believe that
���WAVERR_STILLPLAYING can happen, then obviously waveHdr is in use and must
���not yet be freed, or you believe checking for STILLPLAYING is a waste of
���code because waveOutReset must have done its job.

���I should have added an ERR() message.

���One should think again about what to do in such a case. ���Why/when would
���sleep help? ���User-friendlier might be not to wait, not to free WaveHdr
���and accept to leak resources in such a case.

���Actually, waveOutClose can fail with STILLPLAYING because waveOutReset
���can fail. ���If you look at winealsa, you'll see it uses CreateEvent to
���synchronously wait for acknowledge of the message. ���Now guess what
���happens if CreateEvent fails because memory is tight?
���What happens in the app when waveOutClose's CreateEvent fails?
���It's always tough to reason about the many error paths.

Regards,
��� ��� ��� ���J���rg H���hle