4 Dec
2016
4 Dec
'16
1:43 p.m.
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(a)gmail.com> wrote:
On Sun, Dec 4, 2016 at 4:26 AM, Thomas Howe
<tho7maspenguin(a)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