[Jack-Devel] Helper threads with lower priority?

[Robin Gareus]

On 6/29/19 2:53 PM, Johannes Lorenz wrote:
> Hello,
> 
> 
> we run a DAW (LMMS) with jack and would like to exploit multiple cores.
> Currently, we have one jack process (using `jack_set_process_callback`)
> and multiple other processes that share all the work. The problem is
> that only the jack process has RT prio. Imagine the following example:
> 
> * 4 threads, of which one is the jack thread, 3 have lower priority
> * 4 tasks (e.g. 4 instruments play one note each)
> * the realtime process is finished quickly, the other threads get
> preempted by the kernel
>
> These are situations where using such non-realtime helper threads can
> threaten realtime behaviour. What is the best practice?

Ideally you would use semaphores and 	worker threads.

In the jack process callback, unlock as many background threads as there
are CPU cores available, but at most as many as there are process-nodes.
The process callback waits on the semaphore for all background worker
threads to complete processing.

> * Is it possible/good to use multiple rtprio threads controlled by jack?
> (multiple clients, or multiple threads in one client)

Yes, see http://jackaudio.org/api/group__ClientThreads.html

libjack offers jack_client_create_thread(), which is useful for helper
threads.

> * Should we keep using our non-rt helper threads?

No, the worker-threads should use the same scheduler policy as the main
process callback/thread.

> * Should we be single-threaded, to have a (probably) longer average
> time, but a better worst-case time?

Maybe. Keep in mind that jack2 itself does parallel processing of its
graph (jack1 doesn't).

It should probably be a preference left to the user. It highly depends
on the CPU, hardware and and operating system.

A good default would be to use "all but one core". So on single and
dual-core machines there'll be no background processing by default.

> * Should we start with helper threads and only the last few jobs will
> only be run by the realtime thread (to avoid problems like in the example)?

Depends on your implementation. The main thread can also be a worker
thread, or it may only arbitrate realtime workers.

hope that helps,
robin