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