Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: FIR convolution & delayline buffer question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FIR convolution & delayline buffer question



convolution necessarily involves latency, so you cannot directly process incoming buffers of arbitrary sizes and expect to produce outgoing buffers of the required size.

What you should do is pick a fixed buffer size which works well with your number of taps+coefficients and the resulting tail. Then feed your buffer from the incoming frames, run your convolution, and use the results to fill the output frames. It seems like you could have a very small latency with only 10 coefficients and taps, even though the Process function will be dealing with larger buffers. However, you cannot directly process things without an indirect step involving latency.

By the way, your simple code shows a 'delay' buffer on the stack which would be allocated and deallocated on every Process call. You cannot expect this to work well. You should allocate such buffers in your initialize method and make them part of the AU object. latency basically means that the output samples are delayed in time compared to the input samples. You must have storage which is not deallocated between Process() calls in order for this to work.

Brian Willoughby
Sound Consulting


On Jun 23, 2009, at 06:13, Salvator|TriTone Digital wrote:
I'm writing a simple convolution plugin, and face a problem with the convolution 'tail' beyond buffer size.
Actually the convolution take place fine within the buffer size boundaries, but at each end of buffer, the tail of convolution is either truncated, or feedingback.


Here's the simple code :

void MultitapAU::MultitapKernel::Process(const Float32 * inSourceP,
Float32 *inDestP,
UInt32 inFramesToProcess,
UInt32 inNumChannels,
bool &ioSilence )
{
float coefficients [10] = {1.,0.9,0.8,0.7,0.6,0.5,0.4,0.3,0.2,0.1} ;
int numTaps = 10;
float delay[inFramesToProcess+numTaps]; // my coefficients

memcpy(delay, delay+inFramesToProcess, sizeof(float) * numTaps-1); // i.e. save content by moving samples at beginning
memcpy(delay+numTaps-1, inSourceP, sizeof(float) * inFramesToProcess); // i.e. fill the last samples with input signal

vDSP_conv(delay,1,coefficients+numTaps-1,-1,inDestP, 1,inFramesToProcess,numTaps);// convolve "delay" with "coefficient" & output into inDestP


}


Any hints on how making the convolution preserving the samples that would be beyond "inFramesToProcess" ?
I also tried a circular buffer implementation, but face the exact same problem so I posted this one as it's simpler to read.


Thanks !

Salvator

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >FIR convolution & delayline buffer question (From: Salvator|TriTone Digital <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.