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: >http://www.steamballoon.com/wiki/Rlimits > >If this works for you, I am collecting success reports. Please email >rlimits-success@xxxxxxxxxxxxxxxx . > >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. shayne
