parallel decimation?

Hello all,
I'm writing an application in which I need to decimate the input (44100
samples per second) signal by a factor of 4 and 16.

I'd like to do this as efficiently as possible, but I'd also like to keep
the delay as low as possible - particularly for the divide by 16 branch.

If I didn't care about the delay I'd obviously cascade two divide by four
decimators to give my two output rates, but this does give rather a large
delay on the divide by 16 branch.

So I was wondering if anyone knows of a neat algorithm that will enable me
to compute the divide by 4 and divide by 16 branches in parallel (as opposed
to in cascade) as efficiently as possible?

MTIA

Fraser

FA wrote:

> Hello all,
> I'm writing an application in which I need to decimate the input (44100
> samples per second) signal by a factor of 4 and 16.
> 
> I'd like to do this as efficiently as possible, but I'd also like to keep
> the delay as low as possible - particularly for the divide by 16 branch.
> 
> If I didn't care about the delay I'd obviously cascade two divide by four
> decimators to give my two output rates, but this does give rather a large
> delay on the divide by 16 branch.
> 
> So I was wondering if anyone knows of a neat algorithm that will enable me
> to compute the divide by 4 and divide by 16 branches in parallel (as opposed
> to in cascade) as efficiently as possible?
> 
> MTIA
> 
> Fraser
> 
> 
I would expect that the delay of any suitable decimation algorithm would 
be dominated by the wait for the relevant sample to come in; any 
computation should be trivial compared to that.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

FA schrieb:

> Hello all,
> I'm writing an application in which I need to decimate the input (44100
> samples per second) signal by a factor of 4 and 16.
>
> I'd like to do this as efficiently as possible, but I'd also like to keep
> the delay as low as possible - particularly for the divide by 16 branch.
>
> If I didn't care about the delay I'd obviously cascade two divide by four
> decimators to give my two output rates, but this does give rather a large
> delay on the divide by 16 branch.

You can use minimum phase decimation filters instead of linear phase.
The main chunk of the signal will come out earlier that way (can't
really speak of delay anymore, because the delay of minimum phase
filters is frequency dependent).

FA wrote:

> Hello all,
> I'm writing an application in which I need to decimate the input (44100
> samples per second) signal by a factor of 4 and 16.
> 
> I'd like to do this as efficiently as possible, but I'd also like to keep
> the delay as low as possible - particularly for the divide by 16 branch.


If you have to lowpass the signal to the frequency F, then the 
processing delay is going to be no smaller then 1/F. The way to 
accomplish the minimum delay is to use the minimum phase lowpass filters.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Hi all,
Thanks for the responses so far - I should have also added that I actually
need linear phase response too - just to make it more complex :-(

To clarify a little bit, my application is actually a multiresolution
modelling application and I eventually resynthesise (at the 44100 rate)
after processing each decimated step, I then subtract the resynthesised
output from the (delayed) input to obtain a residual. Obviously in order to
do this effectively I need my resynthesised signal phase locked with the
original (hence I'm using FIR filters).

In order to get good antialiasing I obviously need a fair number of
coefficients and my decimators give a delay (at the decimated rate) of

(((N - 1)/2) - (D -1))/D

Where N is the number of FIR filter coefficients and D is the decimation
factor (4 and 16 in my case)

So for my divide by 16 decimator I have N = 223 and D = 16 giving a delay
of:

6 at the decimated rate or 96 at the original sample rate.


And fo my divide by 4 decimator I have N = 63 and D = 4 giving a delay of:

7 at the decimated rate or 28 at the original sample rate


however if I cascade my two divide by four decimators I get a delay of:

(7 + 7/4) * 16 = 140 at the original sample rate

The reality is actually much worse because to get the same antialiasing as
my original divide by 16 decimator I really need more than 63 coefficients
in ny second divide by 4 decimator.


As I said in my original post I was really looking to see if there was any
neat way of combining a divide by 16 and divide by 4 decimator such that
they may be applied in parallel to the original input - that is to say so
that for example one only has to do say a convolution iteration once and any
symmetry may be exploited - I've a hunch that this may be plausible, however
I'm sorry to say that my maths is rather rusty and I was hoping somebody may
have already tried this to save me a whole load of algebra....

Best regards and Merry Christmas

Fraser.


Vladimir Vassilevsky wrote in message
>
>
>FA wrote:
>
>> Hello all,
>> I'm writing an application in which I need to decimate the input (44100
>> samples per second) signal by a factor of 4 and 16.
>>
>> I'd like to do this as efficiently as possible, but I'd also like to keep
>> the delay as low as possible - particularly for the divide by 16 branch.
>
>
>If you have to lowpass the signal to the frequency F, then the
>processing delay is going to be no smaller then 1/F. The way to
>accomplish the minimum delay is to use the minimum phase lowpass filters.
>
>Vladimir Vassilevsky
>
>DSP and Mixed Signal Design Consultant
>
>http://www.abvolt.com