12 Feb
2006
12 Feb
'06
6:45 p.m.
Frank Barknecht:
That is rediculous. Do you really have to start program that way
to get realtime priority? In case, I guess (and _really_ hope)
that realtime-lsm (or something similar) will continue to exist for a
long time still.
Is it true
that realtime-lsm is deprecated? How do I enable realtime
preemption on a 2.6.15?
It's true. The easiest alternative IMO is to use set_rtlimits. A quick
explanation is at http://tapas.affenbande.org/?page_id=22
Basically you download and install this:
http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz
then add something like this to /etc/set_rtlimits.conf:
@audio /usr/bin/jackd -1 90
assuming you have a user group "audio" and start jackd like:
$ set_rtlimits -r /usr/bin/jackd --realtime -d alsa -d hw:0
Alternatively you can use a patched PAM-module, but that is a bit more
work, if your distribution doesn't ship it. 
12 Feb
12 Feb
7:03 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Sun, 2006-02-12 at 14:45 -0800, Kjetil S. Matheussen wrote:
Frank Barknecht:
That is rediculous. Do you really have to start program that way
to get realtime priority? In case, I guess (and _really_ hope)
that realtime-lsm (or something similar) will continue to exist for a
long time still.
Yes, absolutely, it is ridiculous.
In the upcoming Ubuntu Dapper release this will Just Work. No patching
the kernel or PAM or cryptic CLI utilities.
In the meantime everyone should use the realtime LSM IMHO. And if you
don't use Ubuntu, contact your distro and urge them to solve this
problem in the next release.
Lee
Is it
true that realtime-lsm is deprecated? How do I enable realtime
preemption on a 2.6.15?
It's true. The easiest alternative IMO is to use set_rtlimits. A quick
explanation is at http://tapas.affenbande.org/?page_id=22
Basically you download and install this:
http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz
then add something like this to /etc/set_rtlimits.conf:
@audio /usr/bin/jackd -1 90
assuming you have a user group "audio" and start jackd like:
$ set_rtlimits -r /usr/bin/jackd --realtime -d alsa -d hw:0
Alternatively you can use a patched PAM-module, but that is a bit more
work, if your distribution doesn't ship it. 
9:37 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Sun, Feb 12, 2006 at 06:03:52PM -0500, Lee Revell wrote:
On Sun, 2006-02-12 at 14:45 -0800, Kjetil S.
Matheussen wrote:
Is it really ? If you start apps via an icon or menu, you
don't see any difference at all. If you use a terminal
to start them, just define an alias. Having a prefix such
as nice, sudo, or rt_limits -r is not really worse than
having options (IMHO).
--
FA
That is rediculous. Do you really have to start
program that way
to get realtime priority? In case, I guess (and _really_ hope)
that realtime-lsm (or something similar) will continue to exist for a
long time still.
Yes, absolutely, it is ridiculous.
9:52 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Mon, 2006-02-13 at 02:35 +0100, fons adriaensen wrote:
On Sun, Feb 12, 2006 at 06:03:52PM -0500, Lee Revell
wrote:
No, it's not that bad, but IMHO it's more of a pain than the realtime
LSM, or the PAM solution. It's just too confusing for users when there
are 3 different ways to do the same thing for no apparent reason. So
I'm recommending they stick with realtime LSM until the new rlimits are
fully supported by most distros.
Lee
On Sun, 2006-02-12 at 14:45 -0800, Kjetil S.
Matheussen wrote:
Is it really ? If you start apps via an icon or menu, you
don't see any difference at all. If you use a terminal
to start them, just define an alias. Having a prefix such
as nice, sudo, or rt_limits -r is not really worse than
having options (IMHO).
That is rediculous. Do you really have to start
program that way
to get realtime priority? In case, I guess (and _really_ hope)
that realtime-lsm (or something similar) will continue to exist for a
long time still.
Yes, absolutely, it is ridiculous. 
13 Feb
13 Feb
10:04 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Sun, Feb 12, 2006 at 08:52:30PM -0500, Lee Revell wrote:
No, it's not that bad, but IMHO it's more of a
pain than the realtime
LSM, or the PAM solution.
Does a process inherit its parent's RT rlimits? I would expect them
to work that way. If so, it should be enough to run your display or
window manager under set_rlimits. Then, any app you started in that X
session would automatically inherit the ability to request RT
scheduling and mlock pages.
Also removes the issue of overly fine-grained control. Anytime a user
with permission logged in, any app they ran will automatically work.
Of course, if rlimits are process specific and not inherited, then its
moot. I thought about testing this last night, but went to sleep instead,
heh.
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
14 Feb
14 Feb
6:15 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
Hallo,
Ross Vandegrift hat gesagt: // Ross Vandegrift wrote:
On Sun, Feb 12, 2006 at 08:52:30PM -0500, Lee Revell
wrote:
set_rtlimits unfortunatly doesn't inherit, at least not in the way,
you would prefer jackd to work. For example, to run jackd and ardour
with higher priority, you need to start both jackd and ardour with
"set_rtlimits -r" and the full path. I agree, that this is
inconvenient and that set_rtlimits is to be considered just a
temporary quickfix solution.
However for example I had problems with realtime-lsm when suspending
my laptop, so I had to configure unloading of the module and possibly
reloading again after waking up. This is not necessary with
set_rtlimits. When I find the time, I might play with PAM as well,
however the latest patch I found didn't work with the latest
libpammodules in Debian for me, and I was just too lazy to give it a
deeper look, when set_rtlimits worked out of the box. I normally only
run Pd anyways, and I only need Pd's realtime operation when
performing, so this issue doesn't have a high priority (sic!) for me
currently.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
No, it's not that bad, but IMHO it's more
of a pain than the realtime
LSM, or the PAM solution.
Does a process inherit its parent's RT rlimits? I would expect them
to work that way. If so, it should be enough to run your display or
window manager under set_rlimits. Then, any app you started in that X
session would automatically inherit the ability to request RT
scheduling and mlock pages.
Also removes the issue of overly fine-grained control. Anytime a user
with permission logged in, any app they ran will automatically work.
Of course, if rlimits are process specific and not inherited, then its
moot. I thought about testing this last night, but went to sleep instead,
heh. 
5:44 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Mon, 2006-02-13 at 21:04 -0500, Ross Vandegrift wrote:
On Sun, Feb 12, 2006 at 08:52:30PM -0500, Lee Revell
wrote:
I may be missing something here but, why would you run your window
manager as the same user that you use to run RT applications? I
normally log in as Joe_User and then start my applications as a
privileged user (in my case root because I'm lazy ;-) In most window
managers/desktops it is pretty easy to start an app as a different user
with a desktop icon. The only PITA is that you have to enter a password
to start the apps but you only do that once so it's not a big problem.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
No, it's not that bad, but IMHO it's more
of a pain than the realtime
LSM, or the PAM solution.
Does a process inherit its parent's RT rlimits? I would expect them
to work that way. If so, it should be enough to run your display or
window manager under set_rlimits. Then, any app you started in that X
session would automatically inherit the ability to request RT
scheduling and mlock pages. 
15 Feb
15 Feb
12:54 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On 2/14/06, Jan Depner <eviltwin69(a)cableone.net> wrote:
On Mon, 2006-02-13 at 21:04 -0500, Ross Vandegrift
wrote:
First of all, I'm sure you understand that running applications as
root is a security risk and not recommended...
Secondly, if you run as root, you don't need a patched PAM or set_rlimits..
Dana
On Sun, Feb 12, 2006 at 08:52:30PM -0500, Lee
Revell wrote:
I may be missing something here but, why would you run your window
manager as the same user that you use to run RT applications? I
normally log in as Joe_User and then start my applications as a
privileged user (in my case root because I'm lazy ;-) In most window
managers/desktops it is pretty easy to start an app as a different user
with a desktop icon. The only PITA is that you have to enter a password
to start the apps but you only do that once so it's not a big problem.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744 No, it's not that bad, but IMHO it's more
of a pain than the realtime
LSM, or the PAM solution.
Does a process inherit its parent's RT rlimits? I would expect them
to work that way. If so, it should be enough to run your display or
window manager under set_rlimits. Then, any app you started in that X
session would automatically inherit the ability to request RT
scheduling and mlock pages.
1:49 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Tue, Feb 14, 2006 at 03:42:00PM -0600, Jan Depner wrote:
Dana's security objection is one worth remembering, but I must say it
seems a moot point when the alternative is letting regular users run
things at realtime priorities... ::-)
I think Jan will agree that if the other user isn't root, then using
two users is pointless. After all, you just have to configure
everything discussed for some other user. root is free.
My reasons:
1) File ownerships. I do everything as "ross", "ross" owns
everything. I don't need to worry about how any files were created.
I own them all. Of course I could change them. This would annoy me.
2) Environment configuration. My user "ross" has years and years of
customized environment built up in ~. I don't want to have to either
replicate it to root, or remember what environment I have when,
depending on what apps I'm using when. This would also annoy me
greatly.
3) Stupidity protection. Ever "rm -r ." without checking pwd? Oh
yea, I have. I'm not saying I'd intentionally name an ardour session
something like "/lib/libc.so.6". But hey, I might! Better to protect
myself from doing horrible things like this.
If I were going to do audio as root, I'd just log my Xsession in as
root - cause I'd be even lazier than Jan ::-)
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
Does a process
inherit its parent's RT rlimits? I would expect them
to work that way. If so, it should be enough to run your display or
window manager under set_rlimits. Then, any app you started in that X
session would automatically inherit the ability to request RT
scheduling and mlock pages.
I may be missing something here but, why would you run your window
manager as the same user that you use to run RT applications? I
normally log in as Joe_User and then start my applications as a
privileged user (in my case root because I'm lazy ;-) In most window
managers/desktops it is pretty easy to start an app as a different user
with a desktop icon. The only PITA is that you have to enter a password
to start the apps but you only do that once so it's not a big problem. 
4:39 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, 15 Feb 2006, Ross Vandegrift wrote:
On Tue, Feb 14, 2006 at 03:42:00PM -0600, Jan Depner
wrote:
>> Does a process inherit its parent's RT rlimits? I would expect them
>> to work that way. If so, it should be enough to run your display or
>> window manager under set_rlimits. Then, any app you started in that X
>> session would automatically inherit the ability to request RT
>> scheduling and mlock pages.
I didn't want to say this earlier, because I realize most of the users
on this list are probably running single-user workstations, and are not
expecting their machines to perform as general purpose Unix sites on the
Internet, but...there are at least a few reasons why running an entire
desktop session from the window manager up at realtime priority would be
a really _bad_ idea. The kernel runs many of its internal processes at
specific priorities or niceness levels because they're considered
important enough that nothing below a certain level should be able to
preempt them, and there are often daemons in user space that are almost
as important. While it's nice to be able to assign that kind of
importance to some particular audio app (like Ardour), because its CPU
needs are so exotic (compared to other kinds of apps) and so demanding
that it's an exception, I still really don't think I'd like having every
process on my desktop all screaming at the kernel at the same time, "I'm
realtime! Realtime! No, ME! Listen to ME right NOW!"
Dana's security objection is one worth
remembering, but I must say it
seems a moot point when the alternative is letting regular users run
things at realtime priorities... ::-)
The best solution would be to have it controlled by some Posix group,
just like you have people who can access audio hardware, or video, or
burn CD's, or anything else like that in /etc/group. You could decide
who you trust to not abuse the realtime privilege.
2) Environment configuration. My user
"ross" has years and years of
customized environment built up in ~. I don't want to have to either
replicate it to root, or remember what environment I have when,
depending on what apps I'm using when. This would also annoy me
greatly.
Absolutely! In fact, the first thing I think when I see a system that
has lots of dot files in root's home directory is somebody's been using
the root account here _way_ too much. If anybody should have customized
settings, it should be the regular user accounts.
3) Stupidity protection. Ever "rm -r ."
without checking pwd? Oh
yea, I have. I'm not saying I'd intentionally name an ardour session
something like "/lib/libc.so.6". But hey, I might! Better to protect
myself from doing horrible things like this.
That actually brings to mind what is to me the main reason not to run
things as root (especially big complex audio apps): It's not so much
the security issue -- because frankly, while it's true your binaries
might be trojaned, let's face it, they probably aren't -- it's the
STABILITY issue. Problems in the code that might just result in a
segfault as a regular user can cause a system hang as root.
Filesystems can be corrupted. Uptime can be mysteriously shortened.
As a rule, the more big and exotic the application is, the more running
it as root scares me silly. I think that guideline would probably put
things like Ardour running as root in the Freddy Kreuger Nightmare on
Elm Street department, because applications on Linux don't get much more
big and exotic than Ardour. Heck, I don't even think people who run
Emacs as root are sane. Yes, it's a text editor...but...it's a text
editor the size of Ohio. Who _knows_ what's in that thing...
If I were going to do audio as root, I'd just log
my Xsession in as
root - cause I'd be even lazier than Jan ::-)
Aeeii! No!! Make it stop! :-)
--
+ Brent A. Busby, UNIX Systems Admin + "It's like being +
+ James Franck / Enrico Fermi Institute + blindsided by a +
+ The University of Chicago + flying dwarf..." +
4:52 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, 2006-02-15 at 14:39 -0600, Brent Busby wrote:
On Wed, 15 Feb 2006, Ross Vandegrift wrote:
set_rtlimits, as i understand it, doesn't run its child process with RT
scheduling, it makes it possible for its child (and grandchildren etc.)
to successfully ask for RT scheduling.
--p
On Tue, Feb 14, 2006 at 03:42:00PM -0600, Jan
Depner wrote:
>> Does a process inherit its parent's RT rlimits? I would expect them
>> to work that way. If so, it should be enough to run your display or
>> window manager under set_rlimits. Then, any app you started in that X
>> session would automatically inherit the ability to request RT
>> scheduling and mlock pages.
I didn't want to say this earlier, because I realize most of the users
on this list are probably running single-user workstations, and are not
expecting their machines to perform as general purpose Unix sites on the
Internet, but...there are at least a few reasons why running an entire
desktop session from the window manager up at realtime priority would be
a really _bad_ idea.
5:32 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
Hallo,
Paul Davis hat gesagt: // Paul Davis wrote:
set_rtlimits, as i understand it, doesn't run its
child process with RT
scheduling, it makes it possible for its child (and grandchildren etc.)
to successfully ask for RT scheduling.
Well, not it's grandchildren, at least not in my tests. If I put only
/usr/bin/jackd in /etc/set_rtlimits.conf, then start "set_rtlimits -r
/usr/bin/jackd -R -d alsa -d hw:0", jackd runs with higher priority.
However if I then start ardour, it complains about not being able to
gain RT scheduling.
The fix for me is, to also add /usr/bin/ardour to
/etc/set_rtlimits.conf, and then start ardour as: "set_rtlimits -r
/usr/bin/ardour" after jackd.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
5:51 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, 15 Feb 2006 22:32:16 +0100
Frank Barknecht <fbar(a)footils.org> wrote:
Hallo,
Paul Davis hat gesagt: // Paul Davis wrote:
Well, actually ardour is not a child process of jackd at all. It's a
seperate programm communicating through a library with jackd.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
set_rtlimits, as i understand it, doesn't run
its child process with RT
scheduling, it makes it possible for its child (and grandchildren etc.)
to successfully ask for RT scheduling.
Well, not it's grandchildren, at least not in my tests. If I put only
/usr/bin/jackd in /etc/set_rtlimits.conf, then start "set_rtlimits -r
/usr/bin/jackd -R -d alsa -d hw:0", jackd runs with higher priority.
However if I then start ardour, it complains about not being able to
gain RT scheduling.
16 Feb
16 Feb
12:14 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
Hallo,
Florian Schmidt hat gesagt: // Florian Schmidt wrote:
Well, actually ardour is not a child process of jackd
at all. It's a
seperate programm communicating through a library with jackd.
I stand corrected and hide under a rock...
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
15 Feb
15 Feb
6:23 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, 2006-02-15 at 22:32 +0100, Frank Barknecht wrote:
Hallo,
Paul Davis hat gesagt: // Paul Davis wrote:
a jack client and its libjack-created thread is in absolutely no way a
child of jackd.
--p
set_rtlimits, as i understand it, doesn't run
its child process with RT
scheduling, it makes it possible for its child (and grandchildren etc.)
to successfully ask for RT scheduling.
Well, not it's grandchildren, at least not in my tests. If I put only
/usr/bin/jackd in /etc/set_rtlimits.conf, then start "set_rtlimits -r
/usr/bin/jackd -R -d alsa -d hw:0", jackd runs with higher priority.
However if I then start ardour, it complains about not being able to
gain RT scheduling.
10:47 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, Feb 15, 2006 at 03:50:30PM -0500, Paul Davis wrote:
set_rtlimits, as i understand it, doesn't run its
child process with RT
scheduling, it makes it possible for its child (and grandchildren etc.)
to successfully ask for RT scheduling.
Ok, now I have to run an experiment. Someone posted earlier in the
thread that the set_rlimits properites do not inherit to child
processes of the set_rlimits'ed application.
I was very suprised to hear that was the case (very un-Unixy), and
will need to figure out. The best possible solution I can imagine is
easy as pie then - anyone in group "realtime" (or whatever) can run
their window manager with set_rlimits. Boom. Magically, everything
and anything run as an appropriate user gets RT scheduling if it
wants.
Even better - if set_rlimits will still run an app that doesn't have
RT permissions (but maybe throw a warning), you can just run X with
that ability and not have to worry about users having to modify their
X session.
See ssh-add for a real-world example of something like this (though it
uses environment variables, not limits of any kind).
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
16 Feb
16 Feb
4:07 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Wed, Feb 15, 2006 at 09:47:00PM -0500, Ross Vandegrift wrote:
Ok, now I have to run an experiment.
Experiment is done. rlimits properly inherit with set_rlimits.
Granting RT privileges to any program I run is easy and transparent:
1) I added a line to set_rlimits.conf allowing anyone in the group
audio to run my window manager with RT abilities:
@audio /usr/local/enlightenment/bin/enlightenment nice=-1 rtprio=80 memlock=67108864
2) I changed my .xsession to run the window manager with set_rlimits:
exec /usr/local/bin/set_rlimits -k /usr/local/enlightenment/bin/enlightenment
The -k to set_rlimits is an option I added to continue even if
realtime privileges cannot be setup. I did this so if I ever take
myself out of the audio group, I will still be able to login to my
Xsession. Patch is below.
It's now just a bit more work to take the patch set_rlimits and edit
the system-wide display manager to invoke any users session with
set_rlimits. Then, any user can take advantage of this without
modifying their config files.
diff -ur set_rlimits-1.2.0/set_rlimits.c set_rlimits/set_rlimits.c
--- set_rlimits-1.2.0/set_rlimits.c 2005-12-20 06:37:35.000000000 -0500
+++ set_rlimits/set_rlimits.c 2006-02-16 02:04:34.000000000 -0500
@@ -98,6 +98,7 @@
signed int debug = 0;
signed int verbose = 0;
+signed int cont = 0;
/* rlimits for process */
Rlimits rlimits = {
@@ -123,6 +124,7 @@
"Available options:\n"
" -d Turn on additional debugging output.\n"
" -h Display this help message.\n"
+ " -k Continue running program even if there's an
error.\n"
" -n[=<nlimit>] Set nice limit to <nlimit>. Values 0 to 39
equate to nice\n"
" levels 19 to -20 respectively.\n"
" -r[=<priority>] Set realtime priority limit to <priority>. Max
available is\n"
@@ -216,6 +218,9 @@
debug = 1;
break;
case 'h': err = -1; break;
+ case 'k':
+ cont = 1;
+ break;
case 'v':
if (argv[i][2]!=0)
err = -1;
@@ -632,10 +637,14 @@
return -1;
}
/* No matching entry - permission denied */
- if (!match) {
+ if (!match && !cont) {
fprintf(stderr,"set_rlimits: no permission to run %s with elevated resource
limits\n",
*exec_path);
return 0;
+ } else if (!match && cont) {
+ fprintf(stderr,"set_rlimits: no permission to run %s with elevated resource
limits\n",
+ *exec_path);
+ fprintf(stderr,"set_rlimits: continuing anyway, as requested...\n");
}
if (debug) {
--
Ross Vandegrift
ross(a)lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
12 Feb
12 Feb
11:41 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On 2/12/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
Yes, absolutely, it is ridiculous.
In the upcoming Ubuntu Dapper release this will Just Work. No patching
the kernel or PAM or cryptic CLI utilities.
Really? That is good news.
But as far as I can see, ubuntu bug 17348 has seen no action aside
from you, myself and Dana Olson each providing different versions of
the bleeding trivial patch to pam that would enable it.
https://launchpad.net/distros/ubuntu/+source/pam/+bug/17348
I realize there is still 2 months left before dapper releases, but the
feature freeze is right around the corner.
https://wiki.ubuntu.com/DapperReleaseSchedule
I honestly have no idea why all the distros are dragging their feet on this.
--
Will Dyson
11:48 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Sun, 2006-02-12 at 22:41 -0500, Will Dyson wrote:
On 2/12/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Although that bug report might not reflect it, the Ubuntu developers are
working on it and have told me that this will be fixed in Dapper. It
will be in the next glibc update, and PAM will probably be fixed soon
after (since the glibc patch makes the PAM patch smaller and less of a
hack).
Lee
Yes, absolutely, it is ridiculous.
In the upcoming Ubuntu Dapper release this will Just Work. No patching
the kernel or PAM or cryptic CLI utilities.
Really? That is good news.
But as far as I can see, ubuntu bug 17348 has seen no action aside
from you, myself and Dana Olson each providing different versions of
the bleeding trivial patch to pam that would enable it.
https://launchpad.net/distros/ubuntu/+source/pam/+bug/17348
I realize there is still 2 months left before dapper releases, but the
feature freeze is right around the corner.
https://wiki.ubuntu.com/DapperReleaseSchedule
I honestly have no idea why all the distros are dragging their feet on this.
11:52 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On Sun, 2006-02-12 at 22:41 -0500, Will Dyson wrote:
I honestly have no idea why all the distros are
dragging their feet on
this.
Probably because few users have bothered to ask them to fix it. The
Ubuntu developers were glad to support this, but other than that old
Debian bug report, no one else had asked them for this feature.
Does anyone know the status of this in FC5?
Lee
13 Feb
13 Feb
2:47 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On 2/12/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
On Sun, 2006-02-12 at 22:41 -0500, Will Dyson wrote:
Are you saying that the Ubuntu devs were aware of the Debian bug, but
not the one in Malone? Or just that they don't take bug reports in
their own system seriously?
Heh.
I honestly have no idea why all the distros are
dragging their feet on
this.
Probably because few users have bothered to ask them to fix it. The
Ubuntu developers were glad to support this, but other than that old
Debian bug report, no one else had asked them for this feature. Does anyone know the status of this in FC5?
Or Suse 10.1?
For what it's worth, I just filed a wishlist bug againt debian's
libc6-dev, asking for a backport of the patch that defines RLIMIT_NICE
and RLIMIT_RTPRIO in <bits/resource.h>. Perhaps if that happens, the
pam maintainers will feel less sketchy about backporting the pam
patch.
--
Will Dyson
12 Feb
12 Feb
11:58 p.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On 2/12/06, Will Dyson <will.dyson(a)gmail.com> wrote:
On 2/12/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Actually, I now see the note on the ubuntustudio wiki that you have
convinced an ubuntu developer to take action on this.
Thanks for your behind-the-scenes work!
--
Will Dyson
Yes, absolutely, it is ridiculous.
In the upcoming Ubuntu Dapper release this will Just Work. No patching
the kernel or PAM or cryptic CLI utilities.
Really? That is good news.
But as far as I can see, ubuntu bug 17348 has seen no action aside
from you, myself and Dana Olson each providing different versions of
the bleeding trivial patch to pam that would enable it.
13 Feb
13 Feb
12:35 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
On 2/12/06, Will Dyson <will.dyson(a)gmail.com> wrote:
On 2/12/06, Will Dyson <will.dyson(a)gmail.com>
wrote:
Indeed, thanks Lee! I have been keeping my eye out for it, but no sign
yet. Mark and his team are being very awesome about supporting
musicians.
Forest and I have been working on getting some more packages into
Dapper before it ships. He's working on DSSI and some plugins for it
like Hexter and FluidSynth, and I've had a fixed seq24 approved, as
well as mx44 (which was based on Willem's initial work). Now I am
packaging QMidiArp. I wanted to download LinuxSampler, but the
original tarballs are 404s.. Not sure what I will work on after
QMidiArp, possibly more of the missing apps from alsamodular.sf.net.
I also packaged a new version of my studio launcher. Not sure who
would find it useful, but I do, so I figured I may as well try and get
it into Dapper too, for convenience's sake. But now all the installed
apps that have .desktop files in the Audio category are listed, and it
has a user-configurable blacklist and such. I spent about an hour or
so improving it so it's almost not useless. :)
Dana
On 2/12/06, Lee Revell
<rlrevell(a)joe-job.com> wrote:
Actually, I now see the note on the ubuntustudio wiki that you have
convinced an ubuntu developer to take action on this.
Thanks for your behind-the-scenes work!
--
Will Dyson
Yes, absolutely, it is ridiculous.
In the upcoming Ubuntu Dapper release this will Just Work. No patching
the kernel or PAM or cryptic CLI utilities.
Really? That is good news.
But as far as I can see, ubuntu bug 17348 has seen no action aside
from you, myself and Dana Olson each providing different versions of
the bleeding trivial patch to pam that would enable it.
5:04 a.m.
New subject: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,
Hallo,
Lee Revell hat gesagt: // Lee Revell wrote:
On Sun, 2006-02-12 at 14:45 -0800, Kjetil S.
Matheussen wrote:
As ridiculous as having to start another program before being able to
get audio in and out of Ardour? ;)
That is rediculous. Do you really have to start
program that way
to get realtime priority? In case, I guess (and _really_ hope)
that realtime-lsm (or something similar) will continue to exist for a
long time still.
Yes, absolutely, it is ridiculous. In the upcoming Ubuntu Dapper release this will Just
Work. No patching
the kernel or PAM or cryptic CLI utilities.
As I wrote, PAM is another solution and it's the one to prefer in the
long run, but it's the harder one to get right now, *if* your
distribution doesn't have patched packages. (Does Slackware still ship
without PAM?) The set_rtlimits approach is dead simple compared to
that. It even is dead simple compared to realtime-LSM, if someone
doesn't want to mess with kernel-modules, because it is completely in
userspace.
But of course if someone already has the LSM set up and has
no problems with it, (s)he should continue to use it. Deprecated
doesn't mean disfunctional.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
11:30 a.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
I want to enable realtime privileges on my SUSE 9.3 2.6.11 kernel. I
have no idea how to do this, and numerous google searches have turned up
not many results. It would be nice if someone could tell me how to do
this, but even better if someone could either send me the resources
where I can find out all this stuff, and even better if someone could
send me both things. (Why? I want to be able to get realtime audio
privileges as user.)
Also, is it better for me to upgrade to a 2.6.15 kernel? All the info
I've read (and understood) seems to make me think yes.
Even a google link would be nice.
Bless you guys
Jonty
12:09 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Jonty Needham wrote:
I want to enable realtime privileges on my SUSE 9.3
2.6.11 kernel. I
have no idea how to do this, and numerous google searches have turned up
not many results. It would be nice if someone could tell me how to do
this, but even better if someone could either send me the resources
where I can find out all this stuff, and even better if someone could
send me both things. (Why? I want to be able to get realtime audio
privileges as user.)
Also, is it better for me to upgrade to a 2.6.15 kernel? All the info
I've read (and understood) seems to make me think yes.
Even a google link would be nice.
Bless you guys
Jonty
Download this patch:
http://sourceforge.net/project/showfiles.php?group_id=106645
and follow instructions inside the README. You may need to recompile the
kernel if you don't have this settings :
CONFIG_MODULES=y
CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=m
CONFIG_SECURITY_SELINUX=y
Otherwise, just do 'make && make install'.
Then add your own user to the 'audio' group in /etc/group.
Then make the REALTIME module loaded at startup with:
MODPROBE gid='the gid of the audio group in your distro'
c.
--
www.cesaremarilungo.com
12:47 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Jonty Needham wrote:
I want to enable realtime privileges on my SUSE 9.3
2.6.11 kernel. I
have no idea how to do this, and numerous google searches have turned up
not many results. It would be nice if someone could tell me how to do
this, but even better if someone could either send me the resources
where I can find out all this stuff, and even better if someone could
send me both things. (Why? I want to be able to get realtime audio
privileges as user.)
Also, is it better for me to upgrade to a 2.6.15 kernel? All the info
I've read (and understood) seems to make me think yes.
Even a google link would be nice.
Bless you guys
Jonty
Hi probably you want go here :
http://www.jacklab.net/
Saludos.
--Carlos.
5:39 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Jonty Needham escribe:
Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches.
Cordially, Ismael
--
Dropping science like when Galileo dropped his orange
http://lamediahostia.blogspot.com/
http://www.flickr.com/photos/ivalladt/
5:59 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Ismael Valladolid Torres wrote:
Jonty Needham escribe:
Where do most FC3 users obtain their kernels? Does anyone use pre-built
kernels? from where?
Or, does everyone here roll-their-own? (sheesss.. does that phrase show
my age?)
brad
Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches.
6:14 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
On Monday 13 February 2006 22:58, Brad Fuller wrote:
Ismael Valladolid Torres wrote:
Hi Brad. Having just rolled one, the tobacco version that is, I normally get
my kernels from planetccrma. I must admit that I'm not too up to date with
kernels, but is worth looking at what Fernando at planetccrma has available
for FC3. Nigel.
Jonty Needham escribe:
Where do most FC3 users obtain their kernels? Does anyone use pre-built
kernels? from where?
Or, does everyone here roll-their-own? (sheesss.. does that phrase show
my age?)
brad Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches. 
6:31 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
On 2/13/06, Brad Fuller <brad(a)sonaural.com> wrote:
Ismael Valladolid Torres wrote:
For Fedora, either PlanetCCRMA or I do my own.
Cheers,
Mark
Jonty Needham escribe:
Where do most FC3 users obtain their kernels? Does anyone use pre-built
kernels? from where?
Or, does everyone here roll-their-own? (sheesss.. does that phrase show
my age?)
brad Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches.
16 Feb
16 Feb
12:22 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Brad Fuller escribe:
Or, does everyone here roll-their-own? (sheesss.. does
that phrase show
my age?)
Roll-over-Beethoven would. ;)
Cordially, Ismael
--
Dropping science like when Galileo dropped his orange
http://lamediahostia.blogspot.com/
http://www.flickr.com/photos/ivalladt/
13 Feb
13 Feb
6:56 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
Hallo,
Ismael Valladolid Torres hat gesagt: // Ismael Valladolid Torres wrote:
Jonty Needham escribe:
Careful with 2.6.15, though: ALSA's USB-audio driver has a bug. It's
easy to fix with a little patch and doesn't affect USB-midi devices,
but still worth to note.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches.
7:40 p.m.
New subject: [linux-audio-user] Newbie alert. Realtime knowledge stuff
On Mon, 2006-02-13 at 23:57 +0100, Frank Barknecht wrote:
Hallo,
Ismael Valladolid Torres hat gesagt: // Ismael Valladolid Torres wrote:
Fixed in 2.6.15.x stable release
Jonty Needham escribe:
Careful with 2.6.15, though: ALSA's USB-audio driver has a bug. It's
easy to fix with a little patch and doesn't affect USB-midi devices,
but still worth to note. Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches. 
7:45 p.m.
New subject: [linux-audio-user] Re: Newbie alert. Realtime knowledge stuff
On 2/14/06, Frank Barknecht <fbar(a)footils.org> wrote:
Hallo,
Ismael Valladolid Torres hat gesagt: // Ismael Valladolid Torres wrote:
How does this bug manifest itself? I've tried running 2.6.15 with
ingo's patches and it run incredibly slowly, with the irq for my usb
card seeming to consume 100% cpu. This sounds like this issue?
Loki
Jonty Needham escribe:
Careful with 2.6.15, though: ALSA's USB-audio driver has a bug. It's
easy to fix with a little patch and doesn't affect USB-midi devices,
but still worth to note.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
Also, is it better for me to upgrade to a 2.6.15
kernel? All the info
I've read (and understood) seems to make me think yes.
Upgrading to a newer kernel usually solves problems. Running 2.6.15
would allow you trying Ingo Molnar's realtime patches.
14 Feb
14 Feb
6:03 a.m.
New subject: [linux-audio-user] Re: Newbie alert. Realtime knowledge stuff
Hallo,
Loki Davison hat gesagt: // Loki Davison wrote:
How does this bug manifest itself? I've tried
running 2.6.15 with
ingo's patches and it run incredibly slowly, with the irq for my usb
card seeming to consume 100% cpu. This sounds like this issue?
No, that must be something else. The bug in 2.6.15 was just producing
silence on (some?) USB cards after a while. Great to hear, that the
latest version has this fixed.
Ciao
--
Frank Barknecht _ ______footils.org_ __goto10.org__
6916
days inactive
6920
days old
linux-audio-user@lists.linuxaudio.org
35 comments
19 participants
participants (19)
-
Brad Fuller -
Brent Busby -
Carlos Pino -
Cesare Marilungo -
Dana Olson -
Florian Schmidt -
fons adriaensen -
Frank Barknecht -
Ismael Valladolid Torres -
Jan Depner -
Jonty Needham -
Kjetil S. Matheussen -
Lee Revell -
Loki Davison -
Mark Knecht -
Nigel Henry -
Paul Davis -
ross＠lug.udel.edu -
Will Dyson