• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: FIR convolution & delayline buffer question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FIR convolution & delayline buffer question


  • Subject: Re: FIR convolution & delayline buffer question
  • From: Brian Willoughby <email@hidden>
  • Date: Tue, 23 Jun 2009 14:09:27 -0700

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>)

  • Prev by Date: Re: CoreMIDI Objective C framework ?
  • Next by Date: Re: Reduce Audio Time Latency
  • Previous by thread: FIR convolution & delayline buffer question
  • Next by thread: iphone Audio Unit mixer balance
  • Index(es):
    • Date
    • Thread