Jeremy White wrote:
I'm taking a public thread that I responded to privately back to public view:
Robert Reif wrote:
Jeremy White wrote:
Putting traces into the mmtimer thread loop shows WaitForSingleObject is sleeping for about 20 ms and then calling the callback twice to catch up.
Well, that means mmtimer is right.
You might try putting traces around the conditional YieldExecution on line 730 of ntdll/sync.c and see if that chews up time; if it does, removing the Yield might help.
Interesting results. It fixes the sound quality and FIXME problem but it is still going about 20 ms between callback pairs.
Could the yield just be aggravating the timer resolution problem?
I think this is the thread priority problem I mentioned earlier.
The behavior of winmm is correct; it is supposed to deliver every single timer request, even if it has to double or triple (or more!) up to do it. I verified that very carefully on Windows.
The reason you see pretty steady 10 ms resolution on Windows is that the winmm thread on Windows is flagged as a priority 15 thread, so it does not get interrupted or time sliced away; it fires precisely when it wants to. It's much harder to achieve the same thing on Linux, sadly.
Hmm. As I sit here and think about this, though, I do find myself a little bit puzzled. I would have expected that, if my understanding is right, you would have seen much more dramatic time gaps. On a 2.6 kernel, for example, I would expect you to see jumps on the order of 100 ms (hence ten winmm requests fired). And exactly 20 ms spacing is a little too consistent and interesting a number; it suggests that there is a more precise understanding that should be available.
That may be a function of the test program, though. I suspect in a 'real' program, where other active threads are demanding more cpu that you might get more sporadic results. It might be interesting to add a spin looping thread to the test case and see if you suddenly get larger gaps.
Cheers,
Jeremy
I just posted a simple mmtimer test for the regression tests.
Running it like this
WINETEST_DEBUG=2 wine winmm_test.exe.so timer
will print out the actual raw data.
The tests with a period of 1 or 20 ms gives good results (much better than on xp). The 10 ms tests give the 19 and 1 ms steps like I'm seeing in direct sound.