Re: [LAD] [LAU] Update of jconv

Le 2 déc. 2009 à 11:09, fons@email-addr-hidden 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Dec 2 16:15:01 2009