[PlanetCCRMA] The JACK Story

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Sat Nov 21 21:37:49 PST 2009


On Sat, 2009-11-21 at 23:20 -0500, Orcan Ogetbil wrote:
> On Sat, Nov 21, 2009 at 10:55 PM, Fernando Lopez-Lezcano wrote:
> > On Sat, 2009-11-21 at 22:02 -0500, Orcan Ogetbil wrote:
> >>
> >> Do you alternate for specific tasks?
> >
> > I have never had to "downgrade" to jack1.
> >
> > (I seem to recall somebody having a problem with jack2 and that's why I
> > have been keeping a jack1 package available as well - hopefully that
> > person will add to the thread)
> >
> 
> Hmm. Then we might as well update Fedora's jack to 2. You are the boss
> here, you know better. But yes, let's first wait for some response. Do
> you know why they keep developing jack1?

They are two completely separate efforts, jack1 was/is developed by Paul
Davis and I would say is the "reference implementation" of the Jack API,
jack2 is a completely different code base for exactly the same api, by
Stéphane Letz. Jack2 will eventually be the "next" version of Jack1
(AFAIK). It has a different internal architecture, Stephane gave a paper
on that in one of the LAC's. 

> >> Would you like to have them parallelly installable? We can achieve
> >> parallel installation via "alternatives".
> >
> > I'm not completely sure if that is possible. Keep in mind that all jack
> > server and client _libraries_ need to be switched in and out (ie: it is
> > not just a matter of switching the jackd binaries.
> >
> I am confident that we can handle it. Java, as a much bigger suite
> with many libraries, does it. We will have to reside the actual
> binaries+libraries in certain directories and alternatives will do its
> magic with the symlinks.

Ok, it would be worth trying. Having them both would be good. And the
user can choose the default. 

What is the default default? :-), the last one installed? Sorry, I'm not
familiar with the alternatives system. 

> > The jack2 (and jack1) package in Planet CCRMA also has a different
> > default priority that matches the best choice for the rt kernel (plus
> > optimized irqs using rtirq). That is not really compatible with the
> > current Fedora kernels (default priority is 60, below the irqs for the
> > soundcards but above all others). It won't hurt, but I presume it will
> > not fly either...
> >
> I understand. But in case we update Fedora's jack to 2, you can add a
> priorities file to kernel-rt's RPM that will go into
> /etc/security/limits.d/

The priority I'm talking about is the one jackd runs at so it is
internal to jack. I change the default in the source code to match
rtirq's tweaked priorities. Jackd does not look for it anywhere, you can
change it from the command line or qjackctl but it would be best to have
the best choice be automatic for the rt kernel, of course :-)

> (By the way, the current convention is to use that folder rather than
> editing limits.conf.)

Ah, I did not know that. I should change my current package to do that
instead of adding to limits.conf (when did this start? fc11?)

Thanks for bringing this up! I'm all for jack2 moving to Fedora proper,
the trick would be to figure out the jackd rt priority stuff so that it
can run under both kernels with no tweaking on the part of the user. No
answer to that yet.... :-(

-- Fernando




More information about the PlanetCCRMA mailing list