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.