http://bugs.winehq.org/show_bug.cgi?id=28723
--- Comment #127 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-01 03:00:57 CST --- The new render.c:test_worst_case is very useful for early disagnosis:
http://test.winehq.org/data/f0cfa7cf46d7c832fb84555529d1a1b7c49c46c0/linux_m... render.c:1587: Should play 1000ms continuous tone with fragment size 480. render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1196ms render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1201ms render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1197ms
All such machines with period sizes near 12ms will stutter in Rage if my implementation of XAudio2 behaviour as described by Alexey in comment #19 is correct.
I've now augmented my tests to produce audible output. My Ubuntu Intrepid machine too has a 12ms CreateTimerQueue period and presents hiccups.
http://test.winehq.org/data/f0cfa7cf46d7c832fb84555529d1a1b7c49c46c0/linux_f... render.c:1587: Should play 1000ms continuous tone with fragment size 480. render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 2035ms render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1648ms render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1997ms 2 seconds is completely broken.
Some machines match 10ms: render.c:1587: Should play 1000ms continuous tone with fragment size 480. render.c:1631: Released 48000=100x480 -480 frames at 48000 worth 990ms in 1009ms They will stutter much less often, as 10ms events are not synchronized to wall time (or the DAC clock). Yet they will eventually stutter because of this slew. Unlike timeSetEvent, CreateTimerQueue does not take elapsed time into account when computing the next wake-up time.