[PlanetCCRMA] The JACK Story

Jonathan Ryshpan jonrysh at pacbell.net
Mon Nov 23 18:33:04 PST 2009

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

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

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.

Thanks for CCRMA - jon

More information about the PlanetCCRMA mailing list