[PlanetCCRMA] The JACK Story
luisgarrido at users.sourceforge.net
Mon Nov 23 01:05:41 PST 2009
Nice breaking up of the problem, Nando, I am sure this will help the
layman to understand the problem.
The key number here is 50, which is the default priority of the kernel
threads. To further clarify it, AFAIK the absolute value is not
significant: threads with a priority of 50 won't run 5 times faster
than those with priority 10. As long as a thread has higher priority
it will receive the full attention of the kernel.
And herein lies the problem. You have to be very, very (very) careful
of what threads you are going to put above the kernel ones, since the
potential for misuse is great and the consequences ugly. Those threads
have to be extremely well behaved.
Letting an user up her max priority to 20 is a relatively safe
setting, appropriate for a general purpose distribution. It's only us
audio users who are willing to trust a bug in jackd not rendering our
As Nando pointed out, a possibility is modifying rtirq so it crams
non-audio kernel threads below 20. Since you still have 20 values I
see this as a very viable solution, and the easiest one, since I don't
think more than 5-6 levels are really necessary:
- sound driver
- external port driver (if needed, like usb or firewire).
- rest of the populace
In the case it would be deemed wise to have a bit more headroom it
would be probably easy to convince the mainstream maintainer to up his
limit to 40, which is still below the kernel default.
Another possibility is to push jackd limits to a file in the
/etc/security/limits.d hierarchy. Since it looks like you can order
the settings there by filename Nando could create a minipackage with a
settings file that would override the mainstream one, like:
More information about the PlanetCCRMA