29 Jun
2019
29 Jun
'19
7:53 a.m.
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?
* Is it possible/good to use multiple rtprio threads controlled by jack?
(multiple clients, or multiple threads in one client)
* Should we keep using our non-rt helper threads?
* Should we be single-threaded, to have a (probably) longer average
time, but a better worst-case time?
* 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)?
Many thanks on advance!
Johannes
29 Jun
29 Jun
9:42 a.m.
On Sat, Jun 29, 2019 at 2:54 PM Johannes Lorenz <j.spam(a)lorenz-ho.me> 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?
* Is it possible/good to use multiple rtprio threads controlled by jack?
(multiple clients, or multiple threads in one client)
I'm not sure what the problem is...
Are you asking if all your threads can call jack_ functions? There are
some jack functions (jack_get_time I think) that can be called from a
different thread, but this is explicitly documented for each function.
If not, it's probably safe to assume that you can't call a jack_
function from a non-jack thread.
* Should we keep using our non-rt helper threads?
Probably...
* Should we be single-threaded, to have a (probably)
longer average
time, but a better worst-case time?
Probably not...
* 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)?
In this scenario, is the realtime thread waiting for a non-realtime
thread? Then the answer is no. ;-)
9:44 a.m.
On Sat, Jun 29, 2019 at 4:42 PM Kjetil Matheussen
<k.s.matheussen(a)gmail.com> wrote:
On Sat, Jun 29, 2019 at 2:54 PM Johannes Lorenz <j.spam(a)lorenz-ho.me> wrote:
I meant "probably" if you can make these threads run safely in realtime .
* Should we keep using our non-rt helper threads?
Probably... 
11:10 a.m.
Am 29.06.19 um 14:53 schrieb Johannes Lorenz:
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?
* Is it possible/good to use multiple rtprio threads controlled by
jack? (multiple clients, or multiple threads in one client)
* Should we keep using our non-rt helper threads?
* Should we be single-threaded, to have a (probably) longer average
time, but a better worst-case time?
* 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)?
Many thanks on advance!
Johannes
We use mutli threads a lot, some helper threads with not so relevant
(mostly GUI) stuff running without rt-priority, but as well some helper
threads running with rt-priority. Therefore we check the priority jack
is running with, and set the priority of our helper threads below that
mark. So, they wouldn't interference with jack ( and didn't be
controlled by jack), but, properly been ready fast enough. Think of
tuners, for example. It didn't needs to be just in time, but, it should
be fast enough that we've a result before the buffer is refiled from
jack. when we lost a buffer, it isn't critical at all.
That may be true for a lot of other stuff as well.
regards
hermann
11:13 a.m.
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
1:32 p.m.
Thanks!
Yes, see
http://jackaudio.org/api/group__ClientThreads.html
libjack offers jack_client_create_thread(), which is useful for helper
threads.
Where should our DAW call this function? From inside the jack callback,
or from outside (e.g. by the `main()` thread)?
Also, what should we pass for the "priority" argument? Probably the
result of `jack_client_real_time_priority` for the already running
realtime thread?
1:49 p.m.
On 6/29/19 8:32 PM, Johannes Lorenz wrote:
Thanks!
Creating threads is not realtime safe, so it must not be called from the
jack callback.
You usually create the threads at the same time when you connect to jack
and register the process callback, which is your main application/engine
thread, likely even main().
Yes, see
http://jackaudio.org/api/group__ClientThreads.html
libjack offers jack_client_create_thread(), which is useful for helper
threads.
Where should our DAW call this function? From inside the jack callback,
or from outside (e.g. by the `main()` thread)? Also, what should we pass for the "priority"
argument? Probably the
result of `jack_client_real_time_priority` for the already running
realtime thread?
Yes. Something like:
jack_client_t* jc;
jack_native_thread_t tid;
if (jack_client_create_thread (
jc, &tid,
jack_client_real_time_priority (jc),
jack_is_realtime (jc),
start_worker_method, NULL)
) { /* failed to create realtime thread */ }
Cheers!
robin
4:42 p.m.
Cool, that worked!
I just added those lines to the simple_client.c, and now I get
$ ps -o cmd,pid,pri,ni,rtprio -T $(pidof simple_client)
CMD PID PRI NI RTPRIO
./simple_client 9667 19 0 -
./simple_client 9667 19 0 -
./simple_client 9667 45 - 5
./simple_client 9667 45 - 5
Before adding the lines, there was only one "RTPRIO" thread. This proves
it worked :)
Am 2019-06-29 20:49, schrieb Robin Gareus:
On 6/29/19 8:32 PM, Johannes Lorenz wrote:
Thanks!
Creating threads is not realtime safe, so it must not be called from
the
jack callback.
You usually create the threads at the same time when you connect to
jack
and register the process callback, which is your main
application/engine
thread, likely even main().
Yes, see
http://jackaudio.org/api/group__ClientThreads.html
libjack offers jack_client_create_thread(), which is useful for
helper
threads.
Where should our DAW call this function? From inside the jack
callback,
or from outside (e.g. by the `main()` thread)? Also, what should we pass for the
"priority" argument? Probably the
result of `jack_client_real_time_priority` for the already running
realtime thread?
Yes. Something like:
jack_client_t* jc;
jack_native_thread_t tid;
if (jack_client_create_thread (
jc, &tid,
jack_client_real_time_priority (jc),
jack_is_realtime (jc),
start_worker_method, NULL)
) { /* failed to create realtime thread */ }
Cheers!
robin
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1994
days inactive
1994
days old
jackaudio@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Hermann Meyer -
Johannes Lorenz -
Kjetil Matheussen -
Robin Gareus