Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!mit-eddie!uw-beaver!milton!ogicse!qiclab!onion!jomega!jomega.rain.com!mhorne From: mhorne@jomega.rain.com (Michael T. Horne) Newsgroups: comp.dsp Subject: Re: 48k to 44.1k sample rate conversion Message-ID: <1991May29.181125.7975@jomega.rain.com> Date: 29 May 91 18:11:25 GMT References: <502@valid.valid.com> <5826@media-lab.media.mit.edu.MEDIA.MIT.EDU> <457@valid.valid.com> <42200@ucbvax.BERKELEY.EDU> <498@valid.valid.com> <42250@ucbvax.BERKELEY.EDU> Sender: news@jomega.rain.com (Mr. News) Reply-To: mhorne@jomega.rain.com Organization: jOmega Systems, Beaverton, OR Lines: 34 In a recent article by lou@caber.valid.com (Louis K. Scheffer): > > This is not quite as good a filter, since at some point all the ripples will > add up to .15 db of ripple... > > ...However, the cascaded method will require considerably more code.... > > ...However, the direct method has the advantage of taking a uniform time per > output point.... > > Thus the direct approach has the advantages: > Fewer multiply accumulates for equivalent specs, 95 vs 112 > Simpler code (10 instructions vs 60? ) > Lower peak compute requirement per point. > > The cascaded approach offers: > Fewer coefficients to store. 275 (550 for both ways) vs 14000 > Some intermediate rates available for free > Easier to design (1 min cpu vs 10 hours) > I trust that everyone is aware that any design should be done within the context of an actual problem. One can hardly claim implementation advantages or disadvantages without context. Both methods are superior in a given implementation with specific constraints (e.g. computation time, passband quality, available code space, etc.). Mike -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Michael T. Horne DSP Hardware and Software Consulting Services jOmega Systems E-mail: mhorne@jomega.rain.com Beaverton, OR Phone: (503) 649-8957