[PlanetCCRMA] The JACK Story

[Jonathan Ryshpan]

Thanks for your very long reply to my very long message.  Usually I cut
back the message I'm replying to, but I don't see how to do this here.
Comments follow:

On Mon, 2009-11-23 at 23:26 -0800, Fernando Lopez-Lezcano wrote: 
> 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 to agree with you.  See below.

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

I'm using the standard Fedora-11 kernel as released.  CONFIG_PREEMPT=y.
I use the standard kernel because it's kept up to date by a fairly large
team of maintainers, which means more reliability and better security,
since you may not be able to keep up with all the kernel releases.  The
system is used mainly for non-audio work.  

See my last comment.

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

I'm using the jack from the CCRMA repo, namely:
        jack-audio-connection-kit-1.9.2-2.fc11.ccrma.x86_64

> 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'm confused.  If I follow your recent message, jackd will be started at
rtprio=20, which is the largest allowed by limits.conf.  Or does jackd
requesting rtprio=60 while limits.conf limits rtprio<=20 cause the
request to fail?  (A little experimentation shows that it seems to.)

In fact, starting jackd from qjackctl with Priority (default) starts
jackd with rtprio=10.  Would it be better to start it with Priority 20?

$ ps -LO rtprio 2639
  PID RTPRIO S TTY          TIME COMMAND
 2639      - S ?        00:00:00 /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p4096 -n4 -m
 2639      - S ?        00:00:00 /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p4096 -n4 -m
 2639      - S ?        00:00:00 /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p4096 -n4 -m
 2639     10 S ?        00:00:00 /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p4096 -n4 -m

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

Well then, go for it!

Good Luck - jon