mciwave: need to serialize record and play

Eric,

I've not yet tested your patches but I thought to additionaly use STATUS_NOT_READY
as an intermittent marker for work in progress, so other threads know something
is going on and don't pull the carpet under the feet. What do you think?
E.g. play; play from 0; play from 1000; play from 0; seek to 0; should be handled correctly
(including NOTIFY ABORTED with play notify; play from 0 notify; play ... notify; seek notify).

This may or may not eventually be completed by a critical section in record+play. I don't know yet.

Eric, I can stop working on mciwave for the moment to avoid git conflicts
and go check another D3D issue. Do you plan to work on
- the record+play as well as
- the 333ms issues?

After the new notification system gets in play, I'll change mcimidi and mcicda.
Because these are the interesting drivers, mciwave has just the advantage that
it does not depend on other broken code (Timidity).

BTW, I found the ADPCM and µ-law samples I use on http://en.wikipedia.org/wiki/Dct_(File_Format)

Regards,
 Jörg Höhle.

Eric,

I now tested you 2 "async split" patches on a pristine 1.1.31, i.e. without
any of my patches.  It is a good idea and astep in the right direction.  The
next step would be to move all possible tests before the split point,
e.g. return OUTOFRANGE for bad positions.

However, it 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.

E.g., I added calls to mciStop at the top of Play and Resume. It still hangs,
proving that the problem is not at start, but within playing/recording.

Regards,
 Jörg Höhle.

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.

[Eric Pouech]

[e-mail] 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+