Comment 25 for bug 990992

On Thu, 24 May 2012 16:43:07 -0000
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.

Assuming the handler thread is sleeping, waiting for some event or
sleeping, it still need to be rescheduled by the kernel, and there it
will most likely have to wait for the next jiffy.

> 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.

High *resolution* doesn't imply that you can use high *frequency*. You
can schedule with better accuracy, but it doesn't change much on how
often you can schedule a given action. The CPU just can run that much
code in a given time, at some point too much task switching is just
wasting time.

> 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.

This only allow fine tuning the priority between the threads, a good
negative nice get one a bit further to avoiding being unscheduled, but
it will still have to happen sometimes.

> 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. :)

Sure high *resolution* help a lot, but we are talking about wasting
time checking for events that the kernel probably knew weren't there in
the first place.

Alban