[PlanetCCRMA] The JACK Story

[Fernando Lopez-Lezcano]

On Mon, 2009-11-23 at 18:33 -0800, Jonathan Ryshpan wrote:
> On Sun, 2009-11-22 at 16:37 -0800, Fernando Lopez-Lezcano wrote:
> > There are two options for integrating Jack into Fedora and _not_ losing
> > any performence:
> > 
> > 1) adapt to Fedora's default of max rt priority for users of 20. That
> > would involve changing rtirq and squeezing _all_ kernel and jack
> > priorities within the range of 20. No pretty but doable, I guess (I
> > don't see a reason of why 20 is a good choice). 
> > 
> > 2) convince the maintainer of jack in Fedora _and_ all other parties
> > involved in Fedora that 20 is a bit to low and perhaps 50 or 70 would be
> > better. I don't see much hope in that (or even 90, if you want to run an
> > overlord process that monitors all other rt processes like in the case
> > of rtkit then limiting users to _anything_ would be fine, it should not
> > matter whether it is 20 or 90).
> 
> I can't see any reason to integrate jack into Fedora, meaning the
> standard Fedora repos, as long as CCRMA maintains its own repo. 

A better jack in Fedora would make it more usable as an audio distro out
of the box. The more packages migrate to Fedora, the better (pros: less
packages for me to maintain, more eyes on Fedora packages mean better
quality packages, better integration, no need to use other repositories;
cons: probably longer response times to upgrades, etc, etc). 

> I have
> been using CCRMA's jack (in fact the complete CCRMA repo) successfully
> with the standard Fedora+Rpmfusion repos.  I've tested jack pretty
> thoroughly for xruns, and there aren't any.  Of course my computer is a
> 4-processor x86_64 machine, so it has a good deal of throughput, and I
> have rebuilt the kernel to be fully preemptable (or is it preemptible),
> though not realtime.  

So you are not using the Planet CCRMA kernel, right? Any particular
reason? (just curious). What PREEMPT_* option have you selected? Is this
a compiled from source kernel? Or a proper package?

> Now that I've read FL's latest posting it's clear that the priorities
> in /etc/security/limits.conf or /etc/security/limits.d/xxx ought to be
> changed; they read now:
>         $ cat /etc/security/limits.conf
>         ...
>         ## Automatically appended by the Planet CCRMA jack-audio-connection-kit
>         # * - rtprio 99
>         # * - memlock 4194304
>         # * - nice -10
>         
>         ## Appended by jonrysh according to advice in 
>         ## www.harald-hoyer.de/linux/pulseaudio-and-jackd
>         @jackuser - rtprio 20
>         @jackuser - memlock 4194304
>         @pulse-rt - rtprio 20
>         @pulse-rt - nice -20

Not necessarily. It depends on which Jack you are using and which kernel
you are using (both influence the decision). 

If your kernel does not have full RT_PREEMPT enabled then (as far as I
remember) you will not have individual rt threads for kernel stuff and
the priority of 20 will be good enough (and rtirq will be irrelevant).
In that case if you use the newest Planet CCRMA jack you will have to
override the default priority in qjackctl so that it is not 60 but 10 or
whatever you want below 20. 

> I'd advise not to try to get Fedora to change its policies, if you can
> avoid it.  Such coordination is always trouble for both parties.

Maybe so. If a better jack makes it into Fedora it would be best that it
could be made compatible with the rt kernel and rtirq. We'll see how it
goes. 

-- Fernando