[PlanetCCRMA] Problem with qjackctl in Fedora 14

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Wed Dec 29 12:11:03 PST 2010

On 12/29/2010 12:03 PM, David Cornette wrote:
> On Wed, Dec 29, 2010 at 11:48:36AM -0800, Fernando Lopez-Lezcano wrote:
>> You can add this file (name it "90-jack.conf") to the
>> /etc/security/limits.d/:
>> ---- CUT HERE
>> # Planet CCRMA, jack-audio-connection-kit
>> #
>> # Allow processes access to rt priority and memory locking
>> # without limits, needed by the rt kernel and jackd
>> *	-	rtprio	99
>> *	-	memlock	4194304
>> -- CUT HERE
>> This will allow all users to use the full range of priorities for
>> realtime scheduling. This is (as has been pointed out before) the most
>> secure option.
> How is this the most secure option?

Sorry, typo, it should have read "NOT the most secure option".

You are correct, the most secure option is to limit that option to be 
active for just one group and then add users that are trusted to that 

>> I have to see what is the best solution for this long term (probably an
>> additional package in the Planet CCRMA repository)...
> Why not put the limits.conf stuff in the rtirq package?  Isn't it the one that really needs to be able to set the priorities to the high values?

Well, that is not a bad idea. Although it does not technically belong to 
the rtirq source.

On the other hand I was thinking it was probably time to change the way 
rtirq works, or replace it with something else. It does currently have a 
problem in that it does not deal with dynamically added soundcards.

It can be configured to change the priorities of, say, usb hub irq 
requests but that is regardless of whether there is a soundcard plugged 
in there or not. Or, for example, I can plug in my RME PCI express mini 
card with a Multiface in my laptop and its IRQ does not get reassigned 
to a higher priority.

All of this should probably be moved to a set of udev rules... (and that 
would/should take care of only changing priorities of irqs that are 
actually assigned to soundcards at any time).

-- Fernando

More information about the PlanetCCRMA mailing list