Le 2 déc. 2009 à 11:09, fons@xxxxxxxxxxxxxxx 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-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
