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
