[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