30 Dec
2005
30 Dec
'05
12:52 p.m.
On Fri, 2005-12-30 at 17:17 +0100, Florian Schmidt wrote:
good point.
On Fri, 30 Dec 2005 10:41:46 -0500
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
you don't know the correct priority to use. i imagine an api along the
lines of:
jack_create_thread (pthread_t*, void* (thread_function)(void*),
void* arg, int relative_to_jack);
the last argument would specify that the thread should run at, above or
below the jack RT thread(s) by a given amount. typical values would be
+1, 0, -1 etc.
several people have wanted JACK to export a
thread create call that
would take care of the RT-ness. that way, if you can run JACK with RT
scheduling, you can run a MIDI thread too, with no extra steps. it would
also be useful for people doing FFT in JACK clients using a separate
thread.
actually, with realtime-lsm, there's really no need for this, except for
some convenience. Every app can create its own RT threads these days.
The 2.4.x capabilities days are (thank gawd) over :) i don't
agree with florian that the MIDI thread should run with higher
priority than the JACK watchdog, btw. i think the watchdog should be
higher than anything else until such a time as the kernel guarantees
"watchdog" functionality itself.
Agreed. why not make it prio 98 by default then? (system timer should
still be higher i suppose). With a difference of only 10 between main
jack loop and the watchdog, it might get a little crowded :)