mmtimer resolution question
reif at earthlink.net
Fri Feb 11 10:25:08 CST 2005
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
> 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.
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.
More information about the wine-devel