[CLAM] Re: CLAM digest, Vol 1 #199 - 4 msgs

[Stéphane Letz]

>
> --__--__--
>
> Message: 4
> Date: Tue, 13 Sep 2005 11:00:57 -0700
> From: Xavier Amatriain <xavier at create.ucsb.edu>
> To: Thomas Andrea <thomas.an at hotmail.com>
> CC: clam at iua.upf.es
> Subject: Re: [CLAM] AudioPorts Usage
>
> I guess you are implementing a vst plugin or something similar, right?
> If so, you can either write the samples to a CLAM::Audio object on  
> each
> call to the Process function or (better) write them to an independent
> Outport that you can connect to the SpectralAnalysis Inport. I  
> recommend
> you read this other thread on the CLAM mailing list:
>
> http://iua-mail.upf.es/mailman/public-archives/clam/msg00435.html
>
> BTW, in any case if you are writing a vst plugin, the real problem is
> how to adapt the size of the incoming buffer to the one configured at
> the Spectral Analysis. We have a couple of working implementations but
> none of them are clean enough so as to be in the main distribution.  
> All
> of them are loosely based on Stephan Letz's very interesting article
> "Callback Adaptation Techniques" [1]
>
>
> [1]
> kmt.hku.nl/~pieter/SOFT/CMP/src/portaudio/pa_asio/ 
> Callback_adaptation_.pdf
>


I'm surprised to see this old technical report being of use for  
someone...

The main disadvantage of this "buffer size adaptation" technique is  
that it has bad consequences in the way CPU is used.

For example if a consumer using a bigger buffer size is feed by a  
producer using a smaller buffer size, then the consumer is called  
with a smaller rate but has to deal with the bigger buffer size each  
time its callback is called... but in the maximum duration of the  
smaller buffer size. Thus CPU use is not "homogeneously" distributed  
if all computations are done in the same thread. Ore more complex  
multi-threads techniques would have to be used.

I'm interested to see in what kind of use it is used in CLAM. You are  
speaking about spectral data. Could you explain more?

Thanks

Stephane Letz