Comment 24 for bug 990992

I dug into the QEventDispatcher code a little bit and it looks like my
hypothesis that multiple timer invocations come after a tick is wrong. On
UNIX, Qt checks whether multiple timer periods have elapsed and only sends
one timer event. Timer waits are accomplished by setting the timeout of the
event loop select() to the time to the next timer event, so this is
inherently limited to boundaries of jiffies.

Other interesting tidbits from reading the Qt source is that for timers
below 20ms on Windows, Qt uses the WinMM timeSetEvent method which provides
millisecond accuracy but from various Googling appears to be able to
reliably deliver 1ms callbacks with low jitter. Good to know.

On Thu, May 24, 2012 at 1:34 PM, Sean M. Pappalardo <
<email address hidden>> wrote:

> In addition, see #8: someone with a 1000Hz kernel has the same problem.
> There's something else mysterious going on here. I just wish one of our
> devs had the problem. raskolnikov (or anyone affected by this): are you
> gather some profiling data for us? We would need you to build Mixxx from
> source with profiling=1, run it, try to use the MIDI controller for
> about a minute, then close Mixxx. Then run gprof ./mixxx and attach the
> output to this bug.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/990992
>
> Title:
> The new controller polling frequency is too high for desktop systems
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/990992/+subscriptions
>