mmtimer resolution question

[Robert Reif]

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.