[Bug 30071] New: Need a CreateTimerQueueTimer that is stable over time

http://bugs.winehq.org/show_bug.cgi?id=30071

Bug #: 30071
           Summary: Need a CreateTimerQueueTimer that is stable over time
           Product: Wine
           Version: 1.3.25
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: ntdll
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Andrew Eikum's quick test in
http://www.winehq.org/pipermail/wine-devel/2012-February/094457.html
suggests that CreateTimerQueueTimer stabilizes itself over time on *average*. 
For instance, when asked for a 12ms period, it will trigger 5 times within 60ms
even though it is unable to trigger every 12ms. The deltas are:
20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ...

This is an essential property that it would share with winmm timers.

Both winealsa and wineoss today crucially depend on this property.  The XAudio2
algorithm described in bug #28723 either writes one or zero period worth of
data per callback.  Hence it requires callbacks to agree with frame consumption
by the audio device.  If too late, XAudio2 will not catch up by writing 2
periods.

What currently happens is irregular crackling due to occasional underruns
because callbacks are further and further delayed and the audio buffers slowly
empties.  Compare timestamps from apps using winmm with mmdevapi:
winmm mmdevapi
x.304 x.304
x.315 x.315
x.324 x.326
x.334 x.336
x.346 x.348
x.354 x.359
winmm corrects itself and manages to trigger all 10ms events on the same
millisecond as the initial one: x.xx4.

CTQT accumulates delays because as its core, queue_timer_expire uses:
 [t->expire =] queue_current_time() + t->period;

I've separated this issue from bug #28723 because the root cause is not an
audio component and because several other bugs mention CreateTimerQueue, e.g.
bug #29585.