Joerg-Cyril.Hoehle@t-systems.com a écrit :
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.
I'm lagging answering my email yes, actually, only one thread should be running in background, so what you suggest sounds fine A+