6 Dec
2016
6 Dec
'16
1:37 p.m.
You could run "perf record" during the time jack consumes a lot of
resources. That way we may get samples of where it spends the most time.
You may need to rebuild jack to include debug symbols so function names
can be seen.
This may at least give a hint on where things are going wrong.
On 12/06/2016 08:03 PM, Thomas Howe wrote:
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(a)grame.fr> wrote:
> You should try to find out which thread eats the CPU.
>
> Stéphane