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
