Re: [linux-audio-user] qjackctl & set_rtlimits

From: Florian Schmidt <mista.tapas@email-addr-hidden>
Date: Sat Dec 10 2005 - 19:21:05 EET

On Sat, 10 Dec 2005 08:53:20 -0800
reuben <reubenf@email-addr-hidden> wrote:

> (Not terribly surprisingly) I can't get the Agnula low latency kernel
> working on my Ubuntu box (the nvidia drivers are not happy!)
>
> So, I figured I'd attempt the set_rtlimits approach.
>
> Starting jackd with:
> set_rtlimits -d -r=10 /usr/bin/jackd -dalsa -dhw:1 -r44100 -p1024 -n2
>
> *almost* gets rid of xruns. What are more appropriate settings? I've
> tried everything from -r=1 to -r=100. Nothing completely eliminated xruns.
>
> Second, how do I configure qjackctl to use set_rtlimits, if this is
> indeed the best approach? I see hooks for start & stop scripts, but
> nothing to modify the command.

Hi,

i sense some confusion on your part. Let's first clarify what steps are
necessary to get good low latency on a linux system:

1) get jack to run with SCHED_FIFO scheduling. This scheduling class is
often also called "realtime scheduling" (there's more realtime
scheduling classes besides SCHED_FIFO, but these don't concern us at the
moment).

run jackd with the -R option to achieve this goal (see man jackd).

Normally only root is allowed to run processes with realtime scheduling,
so we need a way to make ordinary users able to do this, too. There's
two common ways on 2.6.x systems:

- realtime lsm

this is a kernel module which is easy to setup. ubuntu should have it,
too. If not, file a featuer request.

- rt_limits

this is a more general approach which fits better into the linux
security architecture than the realtime lsm. Or at least some argue so
:)

For the time being realtime lsm support is much better in many distros
than rt_limits, so i'd recommend going that route.

Ok, now we have jackd running with the -R option. This should lead to
quite good results even on vanilla 2.6.x kernels. So go ahead and get
this to work first. I suppose running with 2*256 frames should be
possible pretty much xrun free, given that you don't put too much other
load on the system.

2) If you want rock solid jack performance, undisturbed by heavy
disk/network/video/whatever-load you should get a realtime preemption
kernel. Besides reducing the worst case code path latencies through the
kernel, it offers a way to effectively prioritize IRQs. I won't go into
the details here (search the archives of this ML and lkml or browse my
little page (see signature)), but basically it goes like this:

- make soundcard irq highest prio in the system (i.e. 98).

- run jackd with prio higher than all irqs other than your soundcard's
(use -R -P 70 for example)

With such a system it is i.e. possible to compile a kernel, watch some
videos, d/l stuff via the network, do a find / or two and at the same
time run jackd and some clients completely xrun free (given that the
clients are well coded and don't produce any by themself) even at
periodsizes of 32 or even 16 frames.

So, how you continue further depends on your needs..

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org
Received on Sat Dec 10 20:15:06 2005

This archive was generated by hypermail 2.1.8 : Sat Dec 10 2005 - 20:15:06 EET