Re: [LAD] Kontakt Spikes

On 10/11/2011 01:52 AM, Clemens Ladisch wrote:
> I wrote:
>> What is the time quantum that sched_rr_get_interval() returns for these
>> threads?
>
> Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
> uses a fixed RR time quantum of 100 ms which cannot be changed (except
> by changing DEF_TIMESLICE in kernel/sched.c).
>
> This means that, when you have five RR/50 threads on one core, a thread
> will run for 100 ms and then be interrupted for 400 ms. The only way
> for the threads to user shorter intervals is for all of them to
> cooperate and to call sched_yield() after having completed such
> an interval.

In our case this won't be an issue. We are really only using multiple
threads so multiple cores can be used at the same time; not to divvy up
a lengthy task, which is the normal use for threading. The fact that
there are five realtime threads in our example is not a design decision,
but only an unfortunate and unavoidable side-effect of how Receptor's
and Kontakt's multi core modes work.

All the realtime threads need to complete their work within the audio
quantum (2.9 msecs in this case) or there will be drop outs. If any of
the threads actually needed 100ms, playback will be so messed up and the
cpu will be so overloaded they would probably have to hard-power off!

We have gotten some interesting results from cyclictest and the new
ftrace system. Hopefully that will point us to some kernel latency that
we can work around or fix.

Thanks... mo
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Oct 11 20:15:04 2011