22 Jan
2004
22 Jan
'04
4:45 a.m.
Since there has been a lot of post concerning jack usage and
optimisation recently it has remind me a problem I got that I never been
able to understand.
I have never been able to run jackstart with -R option when compiling
jack with Sys V shm support. jackd -R as root work with SysV shm but if
I want to use jackstart I have to use POSIX shm.
The error message I am getting with SysV shm is the classical "cannot
lock down memory for RT thread (Cannot allocate memory)".
I am running a Mandrake 9.2 multimedia kernel (2.4.22, low latency,
preemption and capability patches).
Since most of jack users seem to use SysV shm I don't understand why I
cannot (I am the only exception ....)
Christophe
22 Jan
22 Jan
5:53 a.m.
On Thursday 22 January 2004 09.45, Christophe Vescovi wrote:
Since there has been a lot of post concerning jack
usage and
optimisation recently it has remind me a problem I got that I never been
able to understand.
I have never been able to run jackstart with -R option when compiling
jack with Sys V shm support. jackd -R as root work with SysV shm but if
I want to use jackstart I have to use POSIX shm.
The error message I am getting with SysV shm is the classical "cannot
lock down memory for RT thread (Cannot allocate memory)".
I am running a Mandrake 9.2 multimedia kernel (2.4.22, low latency,
preemption and capability patches).
Since most of jack users seem to use SysV shm I don't understand why I
cannot (I am the only exception ....)
Christophe
Hi Christophe,
I'm glad you brought it up, I have this problem too (actually with an Mdk9.2
system but I don't think it's related) and have forgotten to report it back
here.
I've done a fair bit of investigation in this area. The problem seems to be
that when locking the program tries to lock _all_ memory that the program
touches.
If you have DRI running in your X configuration (as I do) and utilize a QT
based program (as I do) there is a major problem. (It probably is similar
with other toolkits.)
I'm not sure of this but evidence suggest that QT maps the graphic memory
(available through DRI) into it's memory space.
What this means in reality is that with my 128mb graphic card QT apps occupy
300mb of memory(!). With 512mb physical memory I sometimes manage to lock ONE
application, but never two.
My "solution" has been to limit the amount of graphic-memory the x-server is
allowed to use by adding this line to the XF86Config-4 in the Section
"Device":
VideoRam 32768
thus limiting it to 32mb memory, which is quite enough for me.
Another solution is to remove DRI, but I use it so it can't be removed.
---
That there is a difference if you build with POSIX shm vs SysV shm I didn't
know. I guess there are still other problems with POSIX shm that keep you
from using that ?
Regards,
Robert
6:11 a.m.
Robert Jonsson a écrit :
That there is a difference if you build with POSIX shm
vs SysV shm I didn't
know. I guess there are still other problems with POSIX shm that keep you
from using that ?
Hi Robert,
Well in fact I use jack with POSIX shm for a few month now and every
thing is fine. I can run all jack audio app I have without any problem
with my cheap SBLive. I have no xrun with -p1024 and a few when
switching desktop or starting apps with -p512 (which seems to be the
normal behaviour with a SBLive).
But it seems that there is a preference for SysV shm (this is the
default in configure !!) so I was wondering why.
Christophe
11 p.m.
Christophe Vescovi <vescovi(a)lpsc.in2p3.fr> writes:
Well in fact I use jack with POSIX shm for a few month
now and every
thing is fine. I can run all jack audio app I have without any
problem with my cheap SBLive. I have no xrun with -p1024 and a few
when switching desktop or starting apps with -p512 (which seems to
be the normal behaviour with a SBLive).
But it seems that there is a preference for SysV shm (this is the
default in configure !!) so I was wondering why.
I sometimes run POSIX shm on my Linux system for testing purposes to
make sure it continues working. As far as I can tell, it works fine.
The MacOSX port uses POSIX shm exclusively.
An earlier POSIX shm implementation worked, but not reliably. This
was blamed at the time on bugs in the Linux kernel. I have not
observed these problems on my system, but they were the reason why
Paul decided to make System V shm the default on Linux. There were
also install problems due to the requirement that users create an
/etc/fstab entry of type tmpfs for /dev/shm.
It may be that newer kernels have a more robust POSIX shm support.
Or, perhaps the present JACK shm implementation not longer stresses
whatever component was failing before. Or, maybe I just haven't run
it enough to notice, yet. :-)
The problems that you mention are serious and should be reported in
the JACK bug database, <http://jackit.sourceforge.net/mantis>.
--
joq
23 Jan
23 Jan
4:33 a.m.
Jack O'Quin a écrit :
I sometimes run POSIX shm on my Linux system for
testing purposes to
make sure it continues working. As far as I can tell, it works fine.
The MacOSX port uses POSIX shm exclusively.
An earlier POSIX shm implementation worked, but not reliably. This
was blamed at the time on bugs in the Linux kernel. I have not
observed these problems on my system, but they were the reason why
Paul decided to make System V shm the default on Linux. There were
also install problems due to the requirement that users create an
/etc/fstab entry of type tmpfs for /dev/shm.
It may be that newer kernels have a more robust POSIX shm support.
Or, perhaps the present JACK shm implementation not longer stresses
whatever component was failing before. Or, maybe I just haven't run
it enough to notice, yet. :-)
The problems that you mention are serious and should be reported in
the JACK bug database, <http://jackit.sourceforge.net/mantis>.
Well, as suggested by Steve, I tried to traced the problem yesterday.
Since I need to re-compile jack I have update my CVS tree, compile why
SysV shm and it works !!!!
First time I had this problem was in September with jack 0.80.0, before
I was not using the -R option, after I was using POSIX shm. The error
message was issued only when a client want to connect to jack.
Anyway, the problem seems to be fixed, and for me JACK shm
implementation seems to be stable both with POSIX and SysV shm.
Regards,
Christophe
9:16 a.m.
Christophe Vescovi <vescovi(a)lpsc.in2p3.fr> writes:
Well, as suggested by Steve, I tried to traced the
problem
yesterday. Since I need to re-compile jack I have update my CVS tree,
compile why SysV shm and it works !!!!
First time I had this problem was in September with jack 0.80.0,
before I was not using the -R option, after I was using POSIX shm. The
error message was issued only when a client want to connect to jack.
JACK 0.80.0 predates the current shm implementation. That version had
problems with leaving old shm segments lying around after jackd
terminated. Maybe they caused the problem you saw.
Anyway, the problem seems to be fixed, and for me JACK
shm
implementation seems to be stable both with POSIX and SysV shm.
Glad to hear it. Thanks for the report.
--
joq
22 Jan
22 Jan
6:17 a.m.
cc'd to jackit-devel list.
This is a tricky problem. There was some concern about this previosuly.
I wonder if its possbile to inspect the library map locations (ala
"cat /proc/$$/maps", libelf maybe?) and selectivly munlock the ones that
are known to be realtime unsafe (toolkits basicly).
Its a bit of a gruesome hack, but it may help.
- Steve
On Thu, Jan 22, 2004 at 10:48:36 +0100, Robert Jonsson wrote:
On Thursday 22 January 2004 09.45, Christophe Vescovi
wrote:
Since there has been a lot of post concerning
jack usage and
optimisation recently it has remind me a problem I got that I never been
able to understand.
I have never been able to run jackstart with -R option when compiling
jack with Sys V shm support. jackd -R as root work with SysV shm but if
I want to use jackstart I have to use POSIX shm.
The error message I am getting with SysV shm is the classical "cannot
lock down memory for RT thread (Cannot allocate memory)".
I am running a Mandrake 9.2 multimedia kernel (2.4.22, low latency,
preemption and capability patches).
Since most of jack users seem to use SysV shm I don't understand why I
cannot (I am the only exception ....)
Christophe
Hi Christophe,
I'm glad you brought it up, I have this problem too (actually with an Mdk9.2
system but I don't think it's related) and have forgotten to report it back
here.
I've done a fair bit of investigation in this area. The problem seems to be
that when locking the program tries to lock _all_ memory that the program
touches.
If you have DRI running in your X configuration (as I do) and utilize a QT
based program (as I do) there is a major problem. (It probably is similar
with other toolkits.)
I'm not sure of this but evidence suggest that QT maps the graphic memory
(available through DRI) into it's memory space.
What this means in reality is that with my 128mb graphic card QT apps occupy
300mb of memory(!). With 512mb physical memory I sometimes manage to lock ONE
application, but never two.
My "solution" has been to limit the amount of graphic-memory the x-server is
allowed to use by adding this line to the XF86Config-4 in the Section
"Device":
VideoRam 32768
thus limiting it to 32mb memory, which is quite enough for me.
Another solution is to remove DRI, but I use it so it can't be removed.
---
That there is a difference if you build with POSIX shm vs SysV shm I didn't
know. I guess there are still other problems with POSIX shm that keep you
from using that ?
Regards,
Robert
5:54 a.m.
On Thu, Jan 22, 2004 at 09:45:29 +0100, Christophe Vescovi wrote:
Since there has been a lot of post concerning jack
usage and
optimisation recently it has remind me a problem I got that I never been
able to understand.
I have never been able to run jackstart with -R option when compiling
jack with Sys V shm support. jackd -R as root work with SysV shm but if
I want to use jackstart I have to use POSIX shm.
The error message I am getting with SysV shm is the classical "cannot
lock down memory for RT thread (Cannot allocate memory)".
I am running a Mandrake 9.2 multimedia kernel (2.4.22, low latency,
preemption and capability patches).
Since most of jack users seem to use SysV shm I don't understand why I
cannot (I am the only exception ....)
Have you strace'd it to find out what its trying to do? might give some
clues.
- Steve
7638
days inactive
7639
days old
linux-audio-user@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Christophe Vescovi -
Jack O'Quin -
Robert Jonsson -
Steve Harris