mmtimer resolution question

[Jeremy White]

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