On Sat, 10 Dec 2005 08:53:20 -0800 reuben <reubenf@xxxxxxxxx> 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
