[PlanetCCRMA] Problem with qjackctl in Fedora 14

[Fernando Lopez-Lezcano]

On 12/30/2010 10:47 AM, Orcan Ogetbil wrote:
> On Thu, Dec 30, 2010 at 1:17 PM, Fernando Lopez-Lezcano wrote:
>> On 12/30/2010 09:59 AM, Orcan Ogetbil wrote:
>>>
>>> Hello all,
>>>
>>> Sorry I have been busy lately with real life and my upstream projects,
>>> and I didn't spend much time on packaging lately (except I built the
>>> new qjackctl-0.3.7 recently). I hope you figured things out by now.
>>>
>>> On Thu, Dec 30, 2010 at 7:15 AM, Oded Ben-Tal 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
>>>>
>>>> Possibly silly questions. Perhaps because I upgraded from an earlier
>>>> version I have two files in /etc/security/limits.d/
>>>> 90-nproc.conf  99-jack.con
>>>>
>>>
>>> Typo? It should be 99-jack.conf. Otherwise pam won't read it.
>>>
>>>> questions:
>>>> 1) do the number matter (i.e. is it important that the jack one is 90)?
>>>>
>>>
>>> The documentation says: "The files are parsed one after another in the
>>> order of "C" locale."
>>>
>>> That means 99 beats 90. Unfortunately, I did set the conf file that
>>> comes with jack to 99. I was probably assuming the other way around.
>>> Should I pull that number down in the jack package so the
>>> corresponding PlanetCCRMA package can override?
>>
>> It would be nice to have that option, 99 precludes anyone else from changing
>> the priority (I had not noticed that).
>>
>>> Of course, you can
>>> give RT priorities to all users, then 99-jack.conf file won't do
>>> anything. But this would be insecure, right?
>>
>> Yes, it would open the door to denial of service attacks, for example. But
>> for a "normal" audio workstation with trusted users that would be of little
>> consequence (others surely will disagree).
>>
>> I have to see what I can do to change things in the rt patched kernel and
>> rtirq so that it is possible to use it with the reduced (arbitrary) priority
>> of 20.
>>
>
> Let me know what comes out. I might get yelled at if I update the F-14
> jack package just with this change, because of these new updates
> policies.

It is a pain, right? I find this all a bit ironic as Fedora has never 
been too concerned about stability or major changes that break things.

> Is there any other fixes, patches that I can throw in and
> that would be nice to have?

Let me think a bit about this. We will eventually need something that 
allows us to change the directory where jack stores the fifos and 
sockets but that is probably in the fc15 time frame (and it may be 
included in newer versions of jack).

I'm trying to see how to do the rt priorities through udev, does not 
seem too easy (I have to somehow link the sound device to the irq pid so 
that I can use chrt to reorder priorities...)

> By the way I am glad that our utsname.version "PREEMPT RT" hack works
> for everyone.

Yes, that seems to be working fine.

-- Fernando