Comment 22 for bug 990992

In general it doesn't make sense that scheduling a timer for 1ms when the
system tick is 250Hz would inherently cause any additional CPU burden than
if the system tick were 1000Hz. The only thing that should happen in that
case is that the timer will be triggered later than 1ms -- potentially 4ms
later.

Since we're asking for a 1ms repeated timer from QTimer, is it possible
that when the system tick expires, QTimer realizes that 4 timer events
should have happened and calls them all at once? This would cause us to
issue 4 polls every 4ms instead of 1 poll every 1ms.

On Thu, May 24, 2012 at 12:43 PM, RJ Ryan <email address hidden> wrote:

> Hi Alban -- while it's true that without a realtime kernel you lose out on
> a lot of guarantees about scheduling, scheduling is /unrelated/ to timing
> accuracy in this case. Scheduling describes when your handler for a timer
> is scheduled, not when the timer itself is triggered as complete by the OS.
>
> Using basic timing primitives like select() is bad because you tie
> yourself to the system timer and your timer can't complete between jiffies.
> It's not true that those are the only option. Linux has a high-resolution
> timer framework that doesn't require having a realtime kernel. In fact,
> Ubuntu comes with the HRT system enabled by default. This high-res timer
> framework allows your timer to trigger between jiffies. I think we should
> use this instead of QTimer simply because it's more accurate.
>
> To address your point about scheduling.. we strongly suggest people enable
> realtime scheduling by tweaking their /etc/security/limits.conf file on
> Linux (note we don't suggest people use a realtime kernel since there are
> many stability issues with realtime kernels). This allows Mixxx to set its
> mixing thread to have higher priorities over its other threads. It's not
> true realtime but it's much better than the default.
>
> High-resolution, accurate timing is a requirement of any DSP-heavy or
> latency-sensitive application. Even just processing jog-wheels accurately
> and with no drift requires accurate timing. There's no way around this. :)
>
>
> On Thu, May 24, 2012 at 12:22 PM, Alban <email address hidden> wrote:
>
>> On Thu, 24 May 2012 15:11:44 -0000
>> RJ Ryan <email address hidden> wrote:
>>
>> > @juliusvonkohout we are searching for the right fix. "just reverting it"
>> > doesn't give us any useful information about how to avoid issues like
>> > this in the future. High-frequency timers are a very necessary part of
>> > getting rid of latency in Mixxx and making it more responsive.
>>
>> Reliable timer with 1ms accuracy are just not possible without a
>> realtime OS. In my experience anything under 10ms is not reliable
>> enough to be really useful on a desktop OS.
>>
>> If the design really require such high frequency timer it is a big flaw
>> IMHO. One *must* use OS events (select() and the like) to efficiently
>> implement anything that would otherwise need polling with more than
>> 100Hz. Desktop OS are just no realtime OS with guaranteed timing
>> constraints!
>>
>> Alban
>>
>> --
>> 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
>>
>
>