Re: [LAU] What exactly is JACK DSP % usage ?

From: Chris Caudle <chris@email-addr-hidden>
Date: Tue Feb 23 2016 - 17:10:43 EET

On Tue, February 23, 2016 8:32 am, Jonathan Brickman wrote:
> So, if one has a lot of things happening, multiple JACK
> instances could make more use of available resources?

I don't think that follows. That seems to me that you are asking if since
you have a lot of processing going on, would adding additional overhead
help.

If you have multiple processing chains that do not depend on one another,
then using jack2 may help, it can take advantage of multiple processor
cores.
I don't know if that would help with the two yoshimi instances or not, but
since you do not appear to be CPU limited, then probably not.

Real time operation is often more about overhead, the minimum amount of
time it takes for the OS to switch between user mode and kernel mode, the
time it takes the scheduler to determine the next process to run, the
amount of time it takes the kernel to read the current state of the
interrupt controller and call interrupt handlers, things like that. A
lot of those things take fixed amounts of time, so the best thing you can
do for a given system is to try to do them less often, i.e. larger
buffers. For given hardware you may be able to change the system behavior
by modifying firmware settings, like turning off hyperthreading/SMT, or
changing power saving features. Probably those are documented in some
wiki somewhere, but I can't find it on the jackaudio.org wiki at the
moment.

Of course you have to start by making sure that the OS runs the real-time
tasks first, and does not perform general OS housekeeping tasks when there
is real-time work to be done. That is the point of the -RT kernel patches
and to a lesser extent the low-latency config option in the unpatched
kernel tree.

-- 
Chris Caudle
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Tue Feb 23 20:15:01 2016

This archive was generated by hypermail 2.1.8 : Tue Feb 23 2016 - 20:15:01 EET