Jack O'Quin wrote:
>"Shayne O'Connor" <forums@email-addr-hidden> writes:
>
>
>
>>one thing i noticed is that whenever an audio app is started from the
>>terminal, it prints this out:
>>
>>cannot lock down memory for RT thread (Cannot allocate memory)
>>
>>though, in regards to what i mention above, this message doesn't seem to
>>have had an effect on performance ... what does it mean? surely jack at
>>least has RT access?!
>>
>>
>
>The realtime-lsm grants memory locking privileges as well as
>scheduling privileges. This is not essential, may systems will work
>fine without it. But, if you are tight on memory, you may see rather
>drastic xruns due to something getting paged out. Normally, the
>realtime pages are "hot" enough to stay resident, anyway. That is why
>JACK does not consider this a fatal error, even when running with -R.
>
>If you are doing something critical (like recording a band), you
>should probably also grant mlock() privileges. This is already
>supported via rlimits in 2.6 kernels. Check it using the `ulimit -l'
>command. The default limit is probably rather small.
>
>Perhaps someone can explain how to do this using PAM. I believe you
>set the `memlock' option in `/etc/security/limits.conf', somehow.
>
>
yep, this works for me ... here are my PAM settings in limits.conf:
<domain> <type> <item> <value>
@audio - rt_priority 100
@audio - nice 10
@audio - memlock 250000
i've got a total of 512mb RAM, so i thought half of that would be
appropriate ... is this setting ok/too high/too low?
shayne
Received on Thu Apr 28 20:15:19 2005
This archive was generated by hypermail 2.1.8 : Thu Apr 28 2005 - 20:15:19 EEST