Re: [LAU] Update of jconv

On Tue, Dec 01, 2009 at 10:57:58PM -0800, Ken Restivo wrote: 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. 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, -- FA Wie der Mond heute Nacht aussieht ! Ist es nicht ein seltsames Bild ?