[LAD] [LAU] Update of jconv

Arnold Krille arnold at arnoldarts.de
Wed Dec 2 11:32:12 UTC 2009


On Wednesday 02 December 2009 11:09:18 fons at kokkinizita.net wrote:
> 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.

Wouldn't the easiest solution be to wait for the worker-threads when in 
freewheeling mode?

If I understand it correctly, it isn't "no waiting in jack-callback" but "no 
waiting in realtime threads". Afaik freewheeling means to run as fast as 
possible but let all clients do their work. So waiting for slave threads 
should be okay then.

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091202/7010299a/attachment.pgp>


More information about the Linux-audio-dev mailing list