Jody McIntyre wrote:
The RT rlimits patch (nice-and-rt-prio-rlimits.patch)
has been proposed
as a solution to allow audio users to run their applications with
realtime priorities. While more complicated to configure, it's a much
cleaner patch than realtime-lsm and it's likely to get merged soon _if_
enough audio users test it and confirm that it works.
To encourage this, I have created a wiki page containing installation
instructions, links to prebuilt PAM packages, etc:
If this works for you, I am collecting success reports. Please email
If you have any problems with it, LAU is probably the best place to ask
for help. Unfortunately I don't have large amounts of time to spend
helping people with this, so any help requests emailed to me directly
may be deleted without a reply. Sorry.
i'd only compiled my first kernel the day before the post to LAU asking
people to test rlimits ... i had put realtime-lsm on top of that one ...
anyway, i got the 2.6.12RC2 kernel and patched that with the
nice/rlimits patch, then installed the patched PAM, edited limits.conf
with the settings suggested on the wiki, rebooted .... no realtime
access with jack :(
but then i changed the values in the limits.conf file to allow users of
"audio" group a rt_priority of 80, rather than the suggested 50 ...
logout/login - success!!!! (i think this could be because jack recently
changed its default RT priority to something like 63 ... i put 80 in
there just to be safe).
it seems to be pretty good, too - with my SB Live i can use a 256 period
setting with *no* troubles at all, running ardour/hydrogen/mixxx all at
the same time and fully loaded ... 128 works pretty well, too, with only
a few xruns (and no xruns if used in playback only mode).
i was using it all day yesterday at band practice, and it performed
admirably the whole way - not a single xrun, or performance issue :)
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?!
anyway, all good it seems ... i'll update the wiki to mention about
trying a different value in the limits.conf file if things don't work.