15 Dec
2007
15 Dec
'07
8:12 a.m.
Lee Revell wrote:
On Dec 15, 2007 12:42 AM, Robert Persson
<ireneshusband(a)gmail.com> wrote:
afaict, if Robert is using jack svn, most probably jackd is hanging and
gets killed by its own jack_watchdog. having a core dump might not help
much in that situation i'm afraid.
the problem still resides in jackd (bad) behavior to get stuck when it
tries to kick-out some client due to a probable timeout or even non-zero
process callback return value. haven't i told you before that it
suffices for a client process() callback to return a non-zero value to
let jackd crash itself? and there's a lot of jacks apps out there which
are still returning non-zero as a legal value, for self-shutdown for
instance. just let one of those get in or out from the jack graph and
kiss goodbye to your rock solid and stable jackd, bwaahahah :o)
this is happenning on jack svn for quite some time now (>= 0.105.x),
almost since early Spring'07 :)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
On my system, as well as the problem of clients
being disconnected, jack
itself crashes a lot. I did not notice this problem until I started
using the SVN version. Jackd definitely gets realtime priority, albeit
using realtime-lsm (I didn't get very far with PAM). From what you have
said, this means that I must have a problem with configuration for the
hardware. I have an Audigy 2. Are there any weird settings I need to use
for this card to get jack running smoothly?
That's exactly what I would expect from an arbitrary SVN checkout. Of
course, it would be a great help to the developers if you could get
core dumps from these crashes (do "ulimit -c unlimited" then launch
JACK from a terminal).