[LAD] [LAU] Update of jconv

[Stéphane Letz]

Le 2 déc. 2009 à 11:09, fons at kokkinizita.net a écrit :

> On Tue, Dec 01, 2009 at 10:57:58PM -0800, Ken Restivo wrote:
> 
>> 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.

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.... 


> 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