Major mmdevapi and winmm audio bugs

[Andrew Eikum]

On Mon, Feb 27, 2012 at 11:41:56PM +0100, Maarten Lankhorst wrote:
> > W.r.t. to 1.4.0, I believe the following path should be taken:
> > - Write CreateTimerQueue tests to verify whether native behaves like:
> >   a) sleep(Xms)           /* what Wine does now */ or
> >   b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */
> > - If b), fix CreateTimerQueue.
> > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi
> >   and something else must be sought...
> Even if so, it is unneeded for the pulse driver, I'm using the auto timing
> update feature and the callback for when rendering is not running.
> When the buffer is not underflowed, I'm using the write callback to
> signal more data is available.
> 
> Timerqueue would be a lie, the driver should schedule when data can
> actually be written and not based purely on ticks. Pulseaudio allows
> this and I'm using this feature in my driver. It passes all the render
> tests now except the volume related ones (they're a reminder,
> and a nop on other drivers anyhow), and I'm working to complete
> capture in a similar fashion as well.
> 
> I believe the event should be triggered when there is actual data
> available, at least that's how I understood the event is supposed
> to work. Doing it based on a timer that isn't tied to the state in
> any way feels wrong. Having 2 threads for pulse feels wrong too,
> especially since it can be done with just using the one pulse
> provides, because you can set callbacks for when more data
> can be read or written.
> 

Unfortunately, the only backend that actually produces that kind of
information is Pulse. So we need a solution for the other drivers
anyway. At that point, we'll have to decide whether we want to use the
same mechanism for Pulse, or rely on the callbacks. There's an
argument for having each driver behave as similar as possible, even if
it's arguably less "correct."

I've also been burned enough times by relying on the audio backend to
work correctly that I hesitate to give the backends more
responsibility than absolutely necessary.

I'm investigating native TimerQueue's operation now. If it turns out
that TimerQueue isn't sufficient, we'll probably just switch over to
using poll() like winmm's timer stuff does.

Andrew