Re: Optimizing a tapped delay (FIR) filter implementation
- From: Jani Huhtanen <jani.huhtanen@xxxxxxxxxxx>
- Date: Thu, 29 Jun 2006 15:27:42 +0300
Kumar Appaiah wrote:
It looks like there is some jinx! Moments after I post a query on
comp.dsp, I get the answer:
http://www.dspguru.com/info/faqs/fir/implemnt.htm
However, in the document, the idea proposed is doubling the length of
one of the FIR data lines, and duplicating the buffer contents, so that
the overflow is taken care of. Though this is very efficient when it
comes to cycles, it eats huge memory. I was wondering whether there was
a way to have the cake and eat it too, by striking a balance somewhere
in between.
Or, if you feel about 20 kilo bytes of memory duplicated is all right
(this is for a PC, not a DSP), please tell me.
Thanks.
Kumar
Same effect can be achieved by taking advantage of the mmu. Many OSs allow
you to map two pages to same physical address. In the sense of used
physical memory, this is free.
--
Jani Huhtanen
Tampere University of Technology, Pori
.
- Follow-Ups:
- Re: Optimizing a tapped delay (FIR) filter implementation
- From: Kumar Appaiah
- Re: Optimizing a tapped delay (FIR) filter implementation
- References:
- Optimizing a tapped delay (FIR) filter implementation
- From: Kumar Appaiah
- Re: Optimizing a tapped delay (FIR) filter implementation
- From: Kumar Appaiah
- Optimizing a tapped delay (FIR) filter implementation
- Prev by Date: Re: Dynamic Filter for Audio Applications
- Next by Date: Re: Independent vs uncorrelated
- Previous by thread: Re: Optimizing a tapped delay (FIR) filter implementation
- Next by thread: Re: Optimizing a tapped delay (FIR) filter implementation
- Index(es):
Relevant Pages
|
|