[LAU] bad jack behavior (was: A year of Linux Audio revisited - would like to know your oppinion)
pieterp at joow.be
Sat Dec 15 11:00:25 EST 2007
Rui Nuno Capela wrote:
> Lee Revell wrote:
>> On Dec 15, 2007 12:42 AM, Robert Persson <ireneshusband at gmail.com> wrote:
>>> 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).
> 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 :)
As per Dave's advice I've changed the topic.
I posted a fix for this issue to the jack devel mailing list, and I'm
waiting for feedback. It solves these issues for me, so I guess you
could say that it's going to be fixed RSN. After positive feedback it
will be committed.
PS: apparently persistent subtle complaining on high-exposure lists does
pay of on the long run :). Thx to Rui for constantly raising the
priority of this issue. ;)
More information about the Linux-audio-user