[LAU] jconvolver / zita-convolver and freewheeling...

[Jörn Nettingsmeier]

On 01/14/2011 03:47 AM, Leigh Dyer wrote:
> On 14/01/11 13:15, Jörn Nettingsmeier wrote:
>> On 01/14/2011 12:59 AM, Leigh Dyer wrote:
>>
>>> Perhaps this is a question for Fons, but do you know if this plugin has
>>> the same issue that stand-alone jconvolver has with JACK's freewheeling
>>> mode? It'd be great to have Ardour exports continue to work as expected
>>> while using this plugin.
>>
>> what is this issue, btw? i've seen the warning message countless times,
>> but never found a problem with the audio after exporting from ardour in
>> freewheeling mode...
> 
> Fons has discussed it in the past on the list -- here's a link:
> 
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-December/065259.html

cheers leigh. here's the relevant section of fons' explanation:

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

and that explains why it seems to work for me, even though i have moved
to a quadcore system a while ago: my sessions tend to be biggish, and i
usually bounce to the same partition that ardour reads the tracks from.
hence, my export is i/o bound (not because of the raw bandwith i use,
but because of excessive disk head movements). so it seems i've been
lucky: since there is plenty of cpu left even when freewheeling "as fast
as possible", zita's helper threads always finish on time.


best,


jörn