14 Nov
2006
14 Nov
'06
2:07 p.m.
Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
If i start jack with 'jackd -R -d alsa' it says:
jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
As you see there no warning about missing realtime-cappabilities, anyhow realtime seems
not work, because i got a lot of xruns....
What i am missing?
Do i need other requirements to fullfill to get realtime to work, e.g. special
kernel-configuration?
Thank you,
Julian
2:33 p.m.
On Tue, 14 Nov 2006 13:22:27 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Tue, 2006-11-14 at 19:08 +0100, Julian Hagenauer
wrote:
Hi,
tank you... i though 0.79-4 would be enough :-)
Sincerely,
Julian
i am using Debian testing with libpam-modules
0.79-4.
Too old. You need at least PAM 0.80. Please ask the Debian maintainers
to ship a newer one.
Lee
2:38 p.m.
On 11/14/06, Julian Hagenauer <chaosbringer(a)gmx.de> wrote:
tank you... i though 0.79-4 would be enough :-)
That depends on the patches applied by the maintainer. Ubuntu has
a similar version, but with the realtime feature back-ported. Works fine.
libpam-modules/dapper uptodate 0.79-3ubuntu14
--
joq
3:32 p.m.
On Tue, 14 Nov 2006 13:22:27 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Tue, 2006-11-14 at 19:08 +0100, Julian Hagenauer
wrote:
I found the following additions in the Debian changelog for the
libpam-runtime package (0.79-4) :
[...]
- add support for (and document) new RLIMIT_NICE and RLIMIT_RTPRIO
settings in Linux 2.6.12 and above; closes: #313542, #313588.
[...]
Shouldn't that do it ?
Thanks.
--
David
i am using Debian testing with libpam-modules
0.79-4.
Too old. You need at least PAM 0.80. Please ask the Debian
maintainers to ship a newer one. 
3:41 p.m.
On Tue, 2006-11-14 at 20:31 +0100, David wrote:
On Tue, 14 Nov 2006 13:22:27 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
Yes, it should.
Lee
On Tue, 2006-11-14 at 19:08 +0100, Julian
Hagenauer wrote:
I found the following additions in the Debian changelog for the
libpam-runtime package (0.79-4) :
[...]
- add support for (and document) new RLIMIT_NICE and RLIMIT_RTPRIO
settings in Linux 2.6.12 and above; closes: #313542, #313588.
[...]
Shouldn't that do it ? i am using Debian testing with libpam-modules
0.79-4.
Too old. You need at least PAM 0.80. Please ask the Debian
maintainers to ship a newer one. 
2:27 p.m.
Julian Hagenauer wrote:
Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
If i start jack with 'jackd -R -d alsa' it says:
jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
As you see there no warning about missing realtime-cappabilities, anyhow realtime seems
not work, because i got a lot of xruns....
What i am missing?
Do i need other requirements to fullfill to get realtime to work, e.g. special
kernel-configuration?
Thank you,
Julian
i think that standard debian pam-modules are not rt cappable?
we had this thread here already:
Ismael Valladolid Torres wrote:
Right now libpam-modules version available for Debian
etch is
0.79-3.1. Does anybody know if this version is rlimits-aware or if it
needs to be patched?
libpam-modules_0.79-3.2_i386.deb is not rlimit aware
I found a debian package that is rlimit aware at :
http://seite9.de/~burkhard/pam_debian_rlimits/
David.
Cordially, Ismael
.................
me myself using some ubuntu pam-modules on debian testing too and it
worsk here.
cheers,
doc
2:37 p.m.
On 11/14/06, Dragan Noveski <perodog(a)gmx.net> wrote:
Julian Hagenauer wrote:
I very well could be wrong, but I'm not using libpam, i'm using
set_rlimits. Is one of these methods considered better/cleaner? I
tried to figure out for a while how to get pam set up for rlimits, but
in the end this seemed much simpler.
thanks,
spencer
Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
2:44 p.m.
On 11/14/06, Spencer Russell <slothlove(a)gmail.com> wrote:
On 11/14/06, Dragan Noveski <perodog(a)gmx.net>
wrote:
I think the PAM solution is better, once your distribution includes
the necessary update. Trying to patch PAM yourself is probably
more trouble than it's worth for most of us.
With limits.conf updated and your UID added to group "audio", just
log out. From then on, everything should "just work". You should
not have to think about this absurd problem ever again.
Sad that it has taken so many years to reach this point, and that
many distributions still do not contain that fix.
--
joq
Julian Hagenauer wrote:
I very well could be wrong, but I'm not using libpam, i'm using
set_rlimits. Is one of these methods considered better/cleaner? I
tried to figure out for a while how to get pam set up for rlimits, but
in the end this seemed much simpler. Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
3:39 p.m.
New subject: [linux-audio-user] Re: Realtime not working on Debian testing... why?
On Tue, Nov 14, 2006 at 07:08:11PM +0100, Julian Hagenauer wrote:
Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
If i start jack with 'jackd -R -d alsa' it says:
jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
As you see there no warning about missing realtime-cappabilities, anyhow realtime seems
not work, because i got a lot of xruns....
What i am missing?
Do i need other requirements to fullfill to get realtime to work, e.g. special
kernel-configuration?
Debian testing current libpam-modules 0.79-4 supports rtprio (I use it).
To be sure just run :
jackd -R -P 70 -d dummy
in another shell launch :
top -H -p `pidof jackd`
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26812 moino 18 0 21652 21m 3892 S 0 2.1 0:00.01 jackd
26813 moino 18 0 21652 21m 3892 S 0 2.1 0:00.00 jackd
26814 moino 19 0 21652 21m 3892 S 0 2.1 0:00.00 jackd
26815 moino -81 0 21652 21m 3892 S 0 2.1 0:00.00 jackd
26816 moino *-71* 0 21652 21m 3892 S 0 2.1 0:00.00 jackd
If rlimit is not working you won't see a thread at prio -71
Don't be afraid if you don't have the thread at -81 you must have an
old version of jackd.
If you can verify this you can be sure your problem does not come from
rlimit or realtime stuff.
You will have to investigate more.
Goood luck.
PS. If you have a dual core setup I'm not sure your jackd version is patched
against some hw clock drift problems. Do you have the --clocksource
option when you launch jackd -h ?
David.
6:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Julian Hagenauer wrote:
Hi,
i am using Debian testing with libpam-modules 0.79-4.
I added
@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000
to /etc/security/limits.conf and i am member of the audio-group.
If i start jack with 'jackd -R -d alsa' it says:
jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
As you see there no warning about missing realtime-cappabilities, anyhow realtime seems
not work, because i got a lot of xruns....
What i am missing?
I run Debian Sid and realtime works perfectly.
$ apt-cache policy libpam-modules
libpam-modules:
Installed: 0.79-4
Candidate: 0.79-4
Version table:
*** 0.79-4 0
500 http://ftp.us.debian.org testing/main Packages
500 http://ftp.us.debian.org unstable/main Packages
The /etc/security/limits.conf as shipped by Debian does still need to be
edited (as you have already done).
Do i need other requirements to fullfill to get
realtime to work, e.g. special kernel-configuration?
Yes - a kernel configured for realtime preemtion.
$ zcat /proc/config.gz |grep PREEMPT_RT
CONFIG_PREEMPT_RT=y
The realtime patcheset is slowly getting incorporated into the main
kernel tree. Not exactly sure what the status of that is at this time.
If you don't want to build your own rt kernel you can get one here:
http://mzilikazix.org
These are even configured for 1000 Hz kernel timer.
$ zcat /proc/config.gz |grep CONFIG_HZ_1000=y
CONFIG_HZ_1000=y
Several flavors to choose from with more on the way.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFWkmVS/p1trUxzngRAsimAJ0fGu+ViIZJs3UVjdsL2qjm6zAozwCfWaRX
NiP4NzkC6ih//PPZn0dfVrg=
=4zyd
-----END PGP SIGNATURE-----
7:11 p.m.
On Tue, 2006-11-14 at 15:56 -0700, Glenn Greenfield wrote:
Yes - a kernel configured for realtime preemtion.
$ zcat /proc/config.gz |grep PREEMPT_RT
CONFIG_PREEMPT_RT=y
Actually no. This is a common misconception.
The point of realtime preemption is to improve realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow non-root
users to run realtime applications.
The two have nothing to do with each other.
Lee
7:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lee Revell wrote:
On Tue, 2006-11-14 at 15:56 -0700, Glenn Greenfield
wrote:
Hmm interesting - thanks for the clarification.
- -glenn
Yes - a kernel configured for realtime
preemtion.
$ zcat /proc/config.gz |grep PREEMPT_RT
CONFIG_PREEMPT_RT=y
Actually no. This is a common misconception.
The point of realtime preemption is to improve realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow non-root
users to run realtime applications.
The two have nothing to do with each other.
Lee
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFWk9HS/p1trUxzngRAqZAAJ9jdKUU7ikRdKIdv+y9XbrGxFcRiACff2aB
bLPS9aLp3YRW5+/QN3tJ9Jo=
=xRwM
-----END PGP SIGNATURE-----
10:54 p.m.
On Tue, 14 Nov 2006 18:11:14 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
On Tue, 2006-11-14 at 15:56 -0700, Glenn Greenfield
wrote:
But there would be no point in using the realtime LSM or the RT rlimit
on a non RT kernel. True ?
Thanks.
--
David
Yes - a kernel configured for realtime
preemtion.
$ zcat /proc/config.gz |grep PREEMPT_RT
CONFIG_PREEMPT_RT=y
Actually no. This is a common misconception.
The point of realtime preemption is to improve realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow
non-root users to run realtime applications.
The two have nothing to do with each other.
15 Nov
15 Nov
12:13 a.m.
On Wed, 2006-11-15 at 03:54 +0100, David wrote:
On Tue, 14 Nov 2006 18:11:14 -0500
Lee Revell <rlrevell(a)joe-job.com> wrote:
No, not true. Normal kernels can run realtime applications too. They
just don't perform as well.
Lee
On Tue, 2006-11-14 at 15:56 -0700, Glenn
Greenfield wrote:
But there would be no point in using the realtime LSM or the RT rlimit
on a non RT kernel. True ? Yes - a kernel configured for realtime
preemtion.
$ zcat /proc/config.gz |grep PREEMPT_RT
CONFIG_PREEMPT_RT=y
Actually no. This is a common misconception.
The point of realtime preemption is to improve realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow
non-root users to run realtime applications.
The two have nothing to do with each other.
12:15 p.m.
On 11/14/06, Lee Revell <rlrevell(a)joe-job.com> wrote:
Right. And vanilla kernels perform well enough for most audio
applications to work just fine. At this point, the RT kernel patch
is really only necessary for squeezing out very low latency.
One could argue that RT kernels should provide more reliable
realtime operation (fewer glitches), but this must be balanced
against the extra risk of running a non-standard kernel. Which
is *actually* more reliable can best be determined by testing
your own applications on your own system.
--
joq
On Wed, 2006-11-15 at 03:54 +0100, David wrote:
But there
would be no point in using the realtime LSM or the RT rlimit
on a non RT kernel. True ?
No, not true. Normal kernels can run realtime applications too. They
just don't perform as well.
3:52 p.m.
On Wed, 15 Nov 2006 10:15:04 -0600
"Jack O'Quin" <jack.oquin(a)gmail.com> wrote:
On 11/14/06, Lee Revell <rlrevell(a)joe-job.com>
wrote:
Right. And vanilla kernels perform well enough for most audio
applications to work just fine. At this point, the RT kernel patch
is really only necessary for squeezing out very low latency.
One could argue that RT kernels should provide more reliable
realtime operation (fewer glitches), but this must be balanced
against the extra risk of running a non-standard kernel. Which
is *actually* more reliable can best be determined by testing
your own applications on your own system.
Thank you Lee and Jack.
--
David.
On Wed, 2006-11-15 at 03:54 +0100, David wrote:
But there
would be no point in using the realtime LSM or the RT
rlimit on a non RT kernel. True ?
No, not true. Normal kernels can run realtime applications too.
They just don't perform as well. 
12:15 p.m.
Lee Revell wrote:
The point of realtime preemption is to improve
realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow non-root
users to run realtime applications.
Where can I read about the two, and what steps should be taken in
setting them up on a debian system?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
1:15 p.m.
On Wed, 2006-11-15 at 17:15 +0100, Atte André Jensen wrote:
Lee Revell wrote:
LAU archives. This has been covered over and over and over and over.
Lee
The point of realtime preemption is to improve
realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow non-root
users to run realtime applications.
Where can I read about the two, and what steps should be taken in
setting them up on a debian system?
8:01 p.m.
On Wednesday 15 November 2006 16:15, Atte André Jensen was like:
Lee Revell wrote:
http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
We are the people We've been waiting for.
The point of realtime preemption is to improve
realtime performance.
The point of PAM and RT limits and the realtime LSM is to allow non-root
users to run realtime applications.
Where can I read about the two, and what steps should be taken in
setting them up on a debian system?
16 Nov
16 Nov
3:05 a.m.
tim hall wrote:
Thanks!
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
6584
days inactive
6586
days old
linux-audio-user@lists.linuxaudio.org
20 comments
10 participants
participants (10)
-
Atte André Jensen -
David -
David Causse -
Dragan Noveski -
Glenn Greenfield -
Jack O'Quin -
Julian Hagenauer -
Lee Revell -
Spencer Russell -
tim hall