<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 14, 2013 at 3:33 AM, Jeremy Jongepier <span dir="ltr"><<a href="mailto:jeremy@autostatic.com" target="_blank">jeremy@autostatic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div>
> I think there must be some automated way for the system to recognize<br>
> that jack is out of control and kill it. [1] notes:<br>
><br>
>       -t, --timeout int<br>
>              Set client timeout limit in milliseconds.  The  default<br>
> is  500<br>
>              msec.   In realtime mode the client timeout must be smaller<br>
> than<br>
>              the watchdog timeout (5000 msec).<br>
><br>
> Interesting... "watchdog timeout"... but I have never seen any effect<br>
> from the watchdog mentioned here. Jack just keeps locking up the system<br>
> for way longer than 5 seconds. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
<br>
</div>Afaik Jack2 doesn't have a watchdog thread.<br></blockquote><div><br></div><div>Neither will the next release of Jack1.<br><br></div><div>I believe that the lockups here are actually caused by interactions with the kernel.<br>
<br></div><div>I also wasn't aware that anyone had added robustness-against-device-disappearance to any version of JACK. It was on my list of things to do while I'm on a JACK-hacking excursion.<br></div><div> </div>
</div><br></div></div>