On Fri, Feb 26, 2010 at 06:07:53PM -0500, Michael Gogins wrote: > It may be quite feasible to use thread locks without any intermediate > buffering. I did this in an earlier version of CsoundVST and it worked > fine. Basically, the CsoundVST process callback simply copied data out > of Csound into the host buffer, then released a lock to permit another > thread to use Csound to compute the next buffer. After computing that > one buffer, the Csound thread just waited to be unlocked by the > callback again. The locking was so efficient that the overhead was not > perceptible, and the thread switching did not seem to cause any more > dropouts than running Csound inside the callback. I changed the code > just because it was simpler to call performKsmps as required to refill > the buffer in the callback. Now that I think about it, the thread > switching version might be better because it would be more flexible > with respect to buffer sizes, balancing the load on the CPU or CPUs, > and so on. > > It also should be possible to modify Csound to run in a callback mode > if necessary. To work in freewheeling mode you need these locks *in both directions*. The Csound thread must wait for Jack, and Jack's callback must wait for Csound to be ready. The result, as far as timing is concerned, is of course equivalent to just calling the DSP code directly from the callback. If Jack's period is not a integer times ksmps you still need some buffering, but assuming ksamps < period the maximum amount needed is ksmps - gcd (ksamps, period). The situation ksmps > period must be avoided. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte ! ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net