<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 22, 2014 at 5:38 PM, Fons Adriaensen <span dir="ltr"><<a href="mailto:fons@linuxaudio.org" target="_blank">fons@linuxaudio.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
So it seems that the frame time is not a reliable method to<br>
determine how many frames have been lost.<br></blockquote><div><br></div><div>I don't think that anything in the API documentation suggests that it is.<br><br></div><div>xruns, whether caused by clients or kernel scheduling, essentially reset the clock. nothing in jack1 (and i believe nothing in jack2) attempts to maintain clock consistency (monotonicity or linearity) across xruns.<br>
</div><div><br></div><div>of course, there is a legitimate argument that this would be useful, but it would require (as far as i can tell) a bunch of assumptions that while often correct, are not really solid. most of them relate to the ability to continue using a DLL that links a system clock and the audio clock across a restart of the audio clock (since the system clock is the only thing that could keep running as far as JACK is concerned). <br>
</div></div></div></div>