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(a)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(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org