Mixxx

Bug #990992
Comment #21

Comment 21 for bug 990992

Revision history for this message

RJ Skerry-Ryan (rryan) wrote on 2012-05-24: Re: [Bug 990992] Re: The new controller polling frequency is too high for desktop systems

#21

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
>

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 <990992@bugs.launchpad.net> wrote:

> On Thu, 24 May 2012 15:11:44 -0000
> RJ Ryan <990992@bugs.launchpad.net> 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
>