https://www.youtube.com/watch?v=Aypje2qZPxs - here's a YouTube version of the original video, maybe that will work better.

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.

I think the spike is happening in the realtime threads (see https://drive.google.com/open?id=0B2eROo5JatB4am00R2NsS3R6bVk for a low-contrast screenshot of top), so I'm going to try running Jack with realtime disabled this time.

On 5 December 2016 at 09:25, Stéphane Letz <letz@grame.fr> wrote:
You should try to find out which thread eats the CPU.

Stéphane

> Le 5 déc. 2016 à 01:34, Thomas Howe <tho7maspenguin@gmail.com> a écrit :
>
> It happens without dbus support (although it is still jackdbus installed).
>
> This time it lasted between 6 hours and 6 hours 30 minutes, and the video shows between 6 hours 12 minutes and 6 hours 13 minutes, so I'm guessing it's about the same duration each time before it spikes, but I'd need to verify this to be sure.
>
> I guess I'll try the jack2 package instead. Any ideas on where I should report this bug?
>
> On 4 December 2016 at 20:43, Thomas Howe <tho7maspenguin@gmail.com> wrote:
> I haven't measure how long it takes to happen, but it tends to be 'after a while'. This is the first time I've realised it stops after several more hours, which was a surprise. I'm trying to measure how long it takes now.
>
> Is there a way to figure out what's getting processed when this happens?
>
> I'm currently running the process with both of QJackCtl's d-bus boxes unticked to see if (and when) it happens again. PulseAudio isn't installed and I didn't have my ALSA bridge running when recording the video, but I won't start it today anyway just in case it would make a difference. No process spike yet...
>
>
> On 4 December 2016 at 11:01, Harry van Haaren <harryhaaren@gmail.com> wrote:
> On Sun, Dec 4, 2016 at 4:26 AM, Thomas Howe <tho7maspenguin@gmail.com> wrote:
> I'm having a problem with the jackdbus process; after some hours it starts maxing out two of my four CPU cores, which in turn causes xruns when running apps. It looks like other people have found the same problem, but no solutions.
>
>
> I could well be wrong; but my suspicion is not on audio threads - but rather management threads for things like DBus integration, or other "non realtime" operations. If it was the audio thread that was causing the deadlock and spinning, you would hear *no* audio at all.
>
> So next steps I'd suggest running without any extra features (disable Dbus support, or Pulseaudio integration, or ALSA loopback devices, or anything else that's not "core" JACK). See if it still happens..
>
> Good luck! -Harry
>
> --
>
> http://www.openavproductions.com
>
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org