[linux-audio-user] Please test the RT rlimits patch for audio

[Shayne O'Connor]

Jack O'Quin wrote:

>"Shayne O'Connor" <forums at machinehasnoagenda.com> 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