<div dir="ltr"><div><div>I tried running in non-realtime, and it still happens. I'll try to get the debug symbols and run "perf record" in a few days.<br><br></div>At 192kHz that makes sense, but it happens for the same amount of time at 96kHz which is confusing, but I reckon it's safe to say this is a frame counter-related bug :)<br><br>Is there a way to reduce the size of the frame counter from 32 bits to something like 20, so I wouldn't have to leave the process running over 6 hours each time I do a test?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 7 December 2016 at 10:50, John Rigg <span dir="ltr"><<a href="mailto:j@jrigg.co.uk" target="_blank">j@jrigg.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Dec 06, 2016 at 07:03:04PM +0000, Thomas Howe wrote:<br>
> It does seem to be consistently 6 hours and 13 minutes before the process<br>
> spike, even when the sample rate is changed from 96 kHz to 192 kHz.<br>
<br>
</span>At 192kHz the JACK frame counter (32 bit uint) overflows and rolls over<br>
to zero after approximately 6hr 12min 49.6s. Coincidence?<br>
<span class="m_8913729341904083213HOEnZb"><font color="#888888"><br>
John<br>
</font></span><div class="m_8913729341904083213HOEnZb"><div class="m_8913729341904083213h5">______________________________<wbr>_________________<br>
Jack-Devel mailing list<br>
<a href="mailto:Jack-Devel@lists.jackaudio.org" target="_blank">Jack-Devel@lists.jackaudio.org</a><br>
<a href="http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org" rel="noreferrer" target="_blank">http://lists.jackaudio.org/lis<wbr>tinfo.cgi/jack-devel-jackaudio<wbr>.org</a><br>
</div></div></blockquote></div><br></div></div>