Andrew Eikum wrote:
And, not too surprisingly, TimerQueue isn't sufficient. I've attached my tests here. The tests ask to execute the callback every 12 ms. On my Windows 7 VM, I found that it executed with intervals like: 20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... With an 11 occasionally interspersed. So, forget that.
No. Did you notice that on *average*, a callback occurs every 12ms (5 within 60ms)? This is the same essential property that winmm:setTimer exhibits too. Wine's CreateTimerQueue is buggy, because it doesn't do that. Wine's winmm:timer does. A patch is needed for CTQ.
Now if Wine's CTQ would be fixed, Wine's audio would have fewer underruns.
The periodicity is another topic.
my Windows 7 VM
I don't trust timings from a VM. 10/20ms may be an artefact. OTOH it may be a design decision from MS related to scheduler quantums or whatever.
Since we're already using poll() in winmm and it seems to work well, that would be my suggestion.
Sure, but then you need an own thread in mmdevapi, don't you? So we're back at the point where I said earlier that I can well imagine a fix to CTQ for wine-1.4.0, but less so a move to an own thread + poll.
Regards, Jörg Höhle