On Fri, Feb 26, 2010 at 10:14:58PM +0000, Victor Lazzarini wrote:

> Because as it is it cannot be guaranteed to run in sync with the Jack  
> callback. This is my impression when looking at the code, but I may be  
> wrong. I think a freewheel-capable client should not have the kind of  
> intermediary buffering with thread locks we have in Csound. The way to  
> do this would be to have a client that calls PerformKsmps() or  
> PerformBuffer() from inside the jack callback. Again, this is my  
> impression, I might be wrong; Fons can correct me if I am.

Almost correct :-). A freewheeling client *can* have 
buffering, but this must be 'rigid' - no escape routes
when data is not ready or when there is not enough space
to write it - just wait instead. But in the end that means
that things could work as well without buffering (or with
just the amount to cover for unfortunate ksmps / period
combinations).

How RT-safe is Csound's DSP code in fact ?

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