14 Jan
2011
14 Jan
'11
3:35 p.m.
On 01/14/2011 03:47 AM, Leigh Dyer wrote:
On 14/01/11 13:15, Jörn Nettingsmeier wrote:
cheers leigh. here's the relevant section of fons' explanation:
On 01/14/2011 12:59 AM, Leigh Dyer wrote:
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… 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... 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