wineoss message queue patch

[Robert Reif]

There are two queues in an audio process, a queue between the
application and the audio thread which contains both commands
and headers and a header queue internal to the audio thread.

The current implementation places commands before headers in
the between thread queue.  This is wrong.  For example, if you
submit 10s worth of headers to the between thread queue and
immediately send a reset command, the reset command is
placed at the head of the queue and will be the first thing read
by the audio thread from the queue.  The reset command has to
return the headers to the application with the done bit set.  The
audio thread looks at its internal header queue and sees that it
is empty and does nothing.  In reality depending on timing, there
may be none, some or all of the headers in the thread internal
header queue so you will get an indeterminate number of the
headers marked as done.  Windows expects all of the submitted
headers to be returned.  Wine currently dose not guarantee that.

Now suppose you submit another 10s worth of headers and
send a start command.  There may be up to 10s worth of headers
from the previous scenario so you end up playing up to 20s of
sound.  This is not expected Windows behavior.

When you submit headers, they will be queued up in the internal
thread queue.  You do not have to wait for them to be processed
before the state machine will process more commands.

The only way to guarantee the temporal relationship between
headers and commands is to preserve their ordering within the
between thread queue.  That way commands are guaranteed to
work on all previous headers and only those.  This is what my
patch does.  I should probably generate a test which tests for
this error and add it to the regression tests.

Eric Pouech wrote:

> Robert Reif wrote:
> > Changes message queue from priority queue to standard queue.
> this is wrong. If you've queued 10s worth of header, your reset request
> will have to wait 10s before being processed, which is not windows behavior.
> I'm also surprised if the headers (in case of a reset) are not send back
> to the app (this is what I see written in the code anyuway
> >
> > It is not necessary and actually causes problems to put non header
> > messages before header messages.  Headers are queued within each
> > thread.  Sending some headers and then a reset will not work properly
> > because the reset command will be placed at the head of the queue
> > before the headers.  It will then try to mark all headers done but there
> >
> > won't be any because they are still in the queue.
> I still don't get this... first the resetting message is gotten out of
> the queue in ProceedMessages, so I can't see how it can interfere (you
> said it's still in the queue) with the remaining headers
>
> A+
>
> --
> Eric Pouech