2 Dec
2009
2 Dec
'09
6:22 a.m.
Le 2 déc. 2009 à 11:09, fons(a)kokkinizita.net a écrit :
On Tue, Dec 01, 2009 at 10:57:58PM -0800, Ken Restivo
wrote:
So does this mean than going into freewheeling should be handled in a special way: like
dropping RT mode for additional worker threads and so on (then when freewheeling stops,
you would have to setup RT mode again...)
An quite interesting use case. I also always wondering how Ardour (using an additional
thread for disk access) handles freewheeling on/off, regarding thread management.
We could even imagine that JACK could provide some support for this kind of requirement :
allowing to define additional worker threads, automatically handling priority change when
freewheeling on/off....
Really? A huge number of tracks I've
published, were
mixed in Ardour freewheeling mode, using jconv for
reverb. Worked fine for me, at least with the older versions.
You've been lucky :-) This will probably still work with
the new version (maybe even 'better' as the result of a
bug fix), but it's not by design.
In theory zita-convolver could be modified quite easily
to work correclty in freewheeling even on MP systems.
The complicated part is switching between normal mode
and freewheeling 'on the fly' - I've not worked out
how to do that correctly.
But as said, on a single processor system it will work.
What is happening is this: zita convolver uses some
processing threads that effectively run with a period
that is a power-of-2 multiple of Jack's basic period.
They run on RT priorities just below the one of Jack's
process thread (-1 for for each doubling of the period).
The output of these threads must be ready when their
next period starts.
Zita-convolver checks this condition and will report
errors if these threads are too slow, but it will not
wait for them - you're not supposed to wait in Jack's
callback, and if your system does support the CPU load
for the given configuration they will be ready, even
with some safety margin.
When freewheeling, Jack's main process thread will be
non-RT, while these extra threads remain at RT. So
they will pre-empts Jack's thread and will appear to
be always ready on time. Except when you have 2 CPUs:
then Jack's thread will be allowed to continue even
if some of the others have not yet completed their
work.
The issue is complicated a bit more by the way these
threads are scheduled, it is *not*
(viem with monospaced font)
1 1 1 1 1 1 1 1 1 1
2 2 2 2 2
4 4 4
8 8
but
1 1 1 1 1 1 1 1 1 1
2 2 2 2 2
4 4 4
8
i.e. in each period at most one one them
is at its longer period boundary.
Ciao,
Stéphane