[CLAM] Re: AudioPorts Usage

[xavier at create.ucsb.edu]

On Thu, 15 Sep 2005, Stéphane Letz wrote:

Hi again Stéphane,

> 
> But then you have the following issue : imagine a network which is  
> driven ( in a thread+blocking i/o  or callback based model) by a  
> buffer size of N, but where some internal nodes in the network use 2N  
> buffers. Then the 2N nodes get called every 2 callbacks but are  
> supposed to handle 2N "token" (frames) in the duration of N to meet  
> real-time deadline. Thus an algorithm that would use more 50% of CPU  
> time would not run in this configuration if everything is computed in  
> the same RT thread.
> 
> This is a typical "problem" Jamin software (doing FFT based  
> processing) has also and the way they solve it is to use another  
> lower-priority thread that will run along the RT thread, with ring- 
> buffer based data exchanges between the 2 threads.

I don't quite get the problem (nor the solution). Let's see, if you have 
nodes in the network that need 2N buffers, the total "process latency" in 
the network will be at least 2N, no matter what you do and how many 
threads you have. Whether that is RT or not does obviously depend on N 
(and on what you consider real-time;).

You can think about feeding the N tokens faster-than-real-time into the 
network but that is obviously not possible under streaming conditions. You 
can also think about having the 2N produce before it has finished 
processing the 2N tokens. But you still have the 2N latency limitation.

That said, I do understand the 50% CPU algorithm limitation you mention 
but I can't think that is a "typical" problem in spectral processing. I 
have done quite some profiling on spectral networks and never found that 
limitation. You might get that with very large window sizes but then the 
overall latency is so bad that you shouldn't care about RT anymore.