Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!bennett.berkeley.edu!parks
From: parks@bennett.berkeley.edu (Tom Parks)
Newsgroups: comp.dsp
Subject: Re: 48k to 44.1k sample rate conversion
Message-ID: <42250@ucbvax.BERKELEY.EDU>
Date: 26 May 91 22:15:01 GMT
References: <5826@media-lab.media.mit.edu.MEDIA.MIT.EDU> <457@valid.valid.com> <42200@ucbvax.BERKELEY.EDU> <498@valid.valid.com>
Sender: nobody@ucbvax.BERKELEY.EDU
Reply-To: parks@bennett.berkeley.edu (Tom Parks)
Organization: University of California, Berkeley
Lines: 49


In article <498@valid.valid.com>, lou@caber.valid.com (Louis K. Scheffer) writes:
|> True, but you only design it once (and it's done already, I've got the
|> coefficients for those who want them).  It takes about 10 CPU hours on a fast
|> machine to design the filter (using Remez exchange, anyway).  It takes 14000
|> coefficients to get +- 0.05 db passband, 104 db rejection stopband.

Ok, I went ahead and did a design for converting from 48 kHz to 44.1 kHz.
I cascaded 3 FIR filters to do this.  Their sample rate conversion ratios were 3:2, 7:5, and 7:16 and they required 147, 75, and 53 taps respectively.  Each filter had a pass band ripple of less than 0.05 dB and stop band rejection of over 100 dB.  It took me less than an hour of my time to design these filters, and it took less than 1 minute of CPU time on a SPARCstation.

|> Agreed, but you only design it once, and the program source is published in
|> "Theory and Application of Digital Signal Processing" by Rabiner and Gold.
|> (Actually, you need to tune it up a little for such large filters, but that's
|> only a few days work.)

You only have to design this set of filters once, too, and I didn't have to spend any time tuning up any software.

|> This appraoch will work, but it's not clear the computational requirement is
|> any less.  Direct convolution by the 14000 tap filter takes about 95 multiply
|> adds per output point (since 146/147 of the input samples are 0).  In your
|> example, the very first filter does:
|> 
|> 	increase by 3
|> 	decrease by 2 at 144 KHz  (but 2/3 inputs are 0)
|> 	throw away 1 of 2, rate now 72 KHz.
|> 
|> This filter looks like a 3x oversampling filter, and will require
|> about 130 coefficients, for a 130/3 = 43 multiplies per output sample (and
|> output is at a 72 KHz rate, so this implies 43 * 72/44.1  = 70 multiplies per
|> (44.1 KHz) output sample.

The first filter requires 49 macs per 72 kHz sample, or 3528000 macs/second.
The second filter requires 10.7 macs per 100.8 kHz sample, or 1080000 macs/sec.
The third filter requires 7.6 macs per 44.1 kHz sample, or 333900 macs/second.
The total is 4941900 macs to produce 44100 samples, or 112 macs/sample.
So this is comparable to the 14000 tap filter implementation as far as macs/second are concerned.

|> Thus if you implement the filters by multiply/adds, this takes more operations,
|> plus the book-keeping is *much* more complex.  The direct approach is a one
|> or two instruction loop on most DSP chips, for 100 or 200 cycles per output
|> point.  I doubt you can do the bookkeeping alone in less than 100 cycles
|> per output point for the method above.
|>

Since the three filters are cascaded, there isn't really any addtional overhead.  Each filter is a one or two instruction loop, and there's one of these loops for each filter.

So my implementation requires 112 multiply-accumulates per output sample (compared to 95), storage for 275 filter taps (compared to 14000), and takes less than a minute of CPU time to design (compared to 10 hours).

Tom Parks