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.

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 :)

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?

On 7 December 2016 at 10:50, John Rigg <j@jrigg.co.uk> wrote:

On Tue, Dec 06, 2016 at 07:03:04PM +0000, Thomas Howe wrote:
> It does seem to be consistently 6 hours and 13 minutes before the process
> spike, even when the sample rate is changed from 96 kHz to 192 kHz.

At 192kHz the JACK frame counter (32 bit uint) overflows and rolls over
to zero after approximately 6hr 12min 49.6s. Coincidence?

John

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