« Return to Thread: new patch to help jackd along

Re: new patch to help jackd along

by Rui Nuno Capela :: Rate this Message:

Reply to Author | View in Thread


On Fri, May 9, 2008 15:39, Pieter Palmers wrote:

> Rui Nuno Capela wrote:
>
>> On Fri, May 9, 2008 03:24, Paul Davis wrote:
>>
>>> Changes:
>>>
>>>
>>> * use poll+read, not just read, when waiting for clients to finish up
>>>  non-process "event" handling * mark clients as Finished after their
>>> process callback has executed * remove clients that failed to respond
>>> to events * add new -r option to completely remove the JACK shm
>>> registry at startup (orthogonal to everything else, but in my codebase
>>> for months)
>>>
>>> I would commit this directly, but I'm trying to be cautious for once.
>>> It
>>> works much better for me now. Note that I believe there may be some
>>> locking issues still to address in the code (insufficient locking,
>>> that is, not deadlocks).
>>>
>>
>> sorry to tell, but it still fails on the jack_test2.c crash tester (the
>>  very same at stake on that last night in Cologne:)
>>
>> fyi, this is just one simple client that, after a while, enters into an
>>  endless loop and tests for jackd being able to detect and remove it
>> from the graph. what happens is that jackd gets severely stuck and
>> jack_watchdog kicks in and bang! everything is thrown to the floor
>>
>> funny thing, and it might just be relevant to the case, is that this
>> meltdown behavior seems to be most evident when, and only when, the bad
>>  client shares the graph with any other client. when left alone,
>> everything seems to work just fine. puzzled ;)
>
> For me it seems to be working fine. I'm on a dual core machine though so
> this might be the reason.
>
> I've attached a slightly modified version of your tester that also
> displays a loop counter for when the process callback enters the stuck
> loop. for me this gives the following:
>
> ppalmers@ox-D820:~/programming/jack/tests$ ./jack_test2 2> log
> seconds to run: 30 num.of ports: 2 client_name: jack_test2-32116
> jack_test2-32116: client_new
> jack_test2-32116: port_register
> jack_test2-32116: set_process_callback
> jack_test2-32116: on_shutdown
> jack_test2-32116: activate
> jack_test2-32116: connect: jack_test2-32116:out_0 -> system:playback_1
> jack_test2-32116: connect: jack_test2-32116:out_1 -> system:playback_2
> jack_test2-32116: running(0, 0)...  1
> jack_test2-32116: mark!
> jack_test2-32116: running(1, 2071971914)... 54
> *** shutdown ***
> jack_test2-32116: running(1, 2147483647)... 48
> ppalmers@ox-D820:~/programming/jack/tests$
>
>
> after the shutdown message, the counter stops increasing, so the process
> callback is dead. The client itself stays alive, as I would expect it to
> be. This is both with and without other clients in the graph.
>

did you test it also when some other (sane) client is in the graph? eg.
qjackctl active?

i do get a similar (good) behavior when jack_test2 is the *single* client
around, having either jackd patched or not. big problem seems to occur
when jack_test2 is *not* the first client in the graph

cyaa
--
rncbc aka Rui Nuno Capela
rncbc@...

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

 « Return to Thread: new patch to help jackd along