Eric,
I wrote:
However, it[Wine's MCI] still hangs in the full tests. I believe the last bug in mciwave will only be nailed down once the play and record loops manage to talk robustly with other commands such as pause and close.
A recent idea of mine is to build upon your thread split work and - ensure at most one player thread is running at any time; - by adding a wmw->thread slot; - and stopping a playing thread before the next play or record starts a new one.
This might cause a larger delay when issuing play mysound; play mysound from 0; play mysound from 500 which would require thread destruction and creation, which is much more expensive than just bumping wmw->dwPosition (mor or less safely) while another thread is playing, or starting a new one while the old one is not finished yet (as is currently done, causing subtle bugs).
What do you think?
BTW, please don't change mciwave now as I still have many patches in the queue.
Regards, Jörg Höhle.