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