28 Apr
2005
28 Apr
'05
2:36 p.m.
Jack O'Quin wrote:
"Shayne O'Connor"
<forums(a)machinehasnoagenda.com> writes:
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
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.