Jack O'Quin wrote: >"Shayne O'Connor" <forums@xxxxxxxxxxxxxxxxxxxxxx> 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
