On Tue, 22 Jan 2013, Joerg-Cyril.Hoehle@t-systems.com wrote: [...]
I believe you forgot to test your patch in Wine(!). The test
- ok(400 <= p2 && p2 <= 600, "%ums is not in the expected 400-600ms range\n", p2);
should fail in every version of Wine.
[...]
IIRC, the first non-null position reported by Wine is 667ms, because it successfully queues two 333ms buffers to waveOut.
Ouch. Right. I forgot to retest when I changed the upper limit. Actually I'm getting 1000ms here, which based on your comment below is probably because 667ms get buffered initially and then the first block get replaced by another 333ms block by the time the 500ms sleep completes so we end up with 1000ms.
I suggest adding a todo_wine plus an additional ok(0<p2 && strcmp(buf,"2000")) that Wine won't fail.
Ok. I think this can still be narrower, 400-1000ms for instance (that should work as long as Wine does not get ahead by more than 166ms).
And I'd decrease the sleep to e.g. 200 and 100 <= p2 && p2 <= 300 All those times sum up, the winmm test run long enough already.
The problem with decreasing the length of the sleep is that you increase the allowed speed variance, here from +/-20% to +/-50%. But if you tighten the range then you run into timing granularity and delay issues again.
MCIWave should use winmm:waveOutGetPosition while playing, however the MCI devices hardly have any decent thread-safety and the construct if(status == MODE_PLAYING) waveOutGetPosition(hWave, &pos) else pos = stopped_pos; is unsafe, as the player may have exited meanwhile and closed hWave.
I'm lost here.