26 Apr
2005
26 Apr
'05
6:33 p.m.
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(a)steamballoon.com .
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.
Thanks for testing!
Jody
11:34 p.m.
On Wed, Apr 27, 2005 at 09:38:01AM +1000, Norval Watson wrote:
Would the patch and PAM pkgs work on amd64 (debian)?
If you're running official Debian for amd64, yes. If you're running the
more experimental pure64 stuff, no, but you should be able to get the
source and rebuild it trivially. This goes for anyone on other Debian
architectures too BTW.
- apt-get build-dep pam
- grab my sources, unpack
- dpkg-buildpackage
- install, test
- contribute your binary debs by linking from the wiki :)
Jody
Norv
--
11:54 p.m.
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(a)steamballoon.com .
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.
just wondering if i'm downloading the right kernel package to test this
patch against ... i'm getting this package:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.12-rc2.tar.bz2
shayne
29 Apr
29 Apr
8:21 p.m.
On Wed, Apr 27, 2005 at 12:01:39PM +1000, Shayne O'Connor wrote:
just wondering if i'm downloading the right kernel
package to test this
patch against ... i'm getting this package:
http://www.kernel.org/pub/linux/kernel/v2.6/testing/linux-2.6.12-rc2.tar.bz2
That will work. Older kernels should work as well since the rlimits
code hasn't changed much, but I haven't tested that.
Jody
shayne
--
27 Apr
27 Apr
1:01 p.m.
New subject: [linux-audio-user] Re: Please test the RT rlimits patch for audio
|--==> Jody McIntyre writes:
JM> The RT rlimits patch (nice-and-rt-prio-rlimits.patch) has been proposed
JM> as a solution to allow audio users to run their applications with
JM> realtime priorities. While more complicated to configure, it's a much
JM> cleaner patch than realtime-lsm and it's likely to get merged soon _if_
JM> enough audio users test it and confirm that it works.
JM> To encourage this, I have created a wiki page containing installation
JM> instructions, links to prebuilt PAM packages, etc:
JM> http://www.steamballoon.com/wiki/Rlimits
JM> If this works for you, I am collecting success reports. Please email
JM> rlimits-success(a)steamballoon.com .
JM> If you have any problems with it, LAU is probably the best place to ask
JM> for help. Unfortunately I don't have large amounts of time to spend
JM> helping people with this, so any help requests emailed to me directly
JM> may be deleted without a reply. Sorry.
JM> Thanks for testing!
I'll provide a test debian package for the A/DeMuDi distribution. I'm
a bit busy ATM hope this will happen next week.
Cheers,
Free
28 Apr
28 Apr
1:16 p.m.
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(a)steamballoon.com .
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
1:53 p.m.
"Shayne O'Connor" <forums(a)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.
--
joq
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.
4:07 p.m.
New subject: [linux-audio-dev] Re: [linux-audio-user] Please test the RT rlimits patch for audio
Jack O'Quin wrote:
>Perhaps someone can explain how to do this using PAM. I believe you
>set the `memlock' option in `/etc/security/limits.conf', somehow.
"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?
Maybe. Depends on what JACK clients you run (they all get mlocked).
Ardour takes up quite a lot of space. If you're willing to grant the
max priority (100), your system is probably a dedicated audio
workstation, so you might just as well make memlock "unlimited".
There is also the -m (--no-mlock) JACK option that disables memory
locking even with the -R (--realtime) option.
--
joq
22 May
22 May
3:27 a.m.
On Tue, 2005-04-26 at 16:32 -0400, Jody McIntyre wrote:
It appears that Linux has merged the RT rlimit patch, as of 2.6.12-rc3
or -rc4. I updated the wiki to remove the extra step of patching the
kernel.
Lee
4:11 a.m.
On Tue, 2005-04-26 at 16:32 -0400, 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.
For any Ubuntu users that are interested, I made a feature request here:
https://bugzilla.ubuntu.com/show_bug.cgi?id=11059
Lee
6913
days inactive
6939
days old
linux-audio-user@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
Free Ekanayaka -
Jack O'Quin -
Jody McIntyre -
Lee Revell -
Norval Watson -
Shayne O'Connor