[CLAM] Re: CLAM digest, Vol 1 #199 - 4 msgs
letz at grame.fr
Wed Sep 14 00:55:51 PDT 2005
> 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
> call to the Process function or (better) write them to an independent
> Outport that you can connect to the SpectralAnalysis Inport. I
> you read this other thread on the CLAM mailing list:
> 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.
> of them are loosely based on Stephan Letz's very interesting article
> "Callback Adaptation Techniques" 
I'm surprised to see this old technical report being of use for
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?
More information about the clam-users