> I had the idea of implementing a lot of the operations in FFTs. ( for > example, it is possible to do auto-correlation and FIR filtering using > FFTs.) There are two advantages to this. > 1. It's almost always faster > 2. By swapping fft implementations, it could be easy to recompile for > fixed or floating point versions.No. FFT's require higher precision than filters. Also the filters are only applied in 40-sample chunks so the cost of the FFT would be much higher. Last thing: I don't think you can handle the current (direct form II) memories with an FFT.> Now the problem of IIR filters: IIR filters and fixed point math do not > mix well. Truncation errors and limited dynamic range problems are > amplified by the feedback nature of the IIR.Speex makes sure the filters are never too close to being unstable, so I'm confident there will be no problem with the IIR.> There are a bunch of IIR filters used in speex. It seems to me that using > the rounded impulse responses of those filters (up to limit of precision) > would be a good approach, as opposed to redesigning all the filters. I've > done a few tests, and it looks promising.There's a chicken-and-egg problem here. How do you compute the impulse response without using an IIR filter in the first place? The IIR filters are different for each 40-sample sub-frame BTW (i.e. you can't cache them). Jean-Marc -- Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Ceci est une partie de message numériquement signée Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20030619/5fec0e57/signature-0001.pgp
>> I had the idea of implementing a lot of the operations in FFTs. ( for >> example, it is possible to do auto-correlation and FIR filtering using >> FFTs.) There are two advantages to this. >> 1. It's almost always faster >> 2. By swapping fft implementations, it could be easy to recompile for >> fixed or floating point versions. > > No. FFT's require higher precision than filters. Also the filters are > only applied in 40-sample chunks so the cost of the FFT would be much > higher. Last thing: I don't think you can handle the current (direct > form II) memories with an FFT.Each math operation introduces some error. So the fewer operations required, the fewer roundoff errors occur. This leads to a happy correlation between efficiency and accuracy. For fewer than ~64 taps, the O(nh) complexity of a directly calculated FIR is better than the O( log(nh) ) complexity that comes from using FFTs. So for FIR filters with length of 40, direct calculation probably would be a better choice. <p>>> Now the problem of IIR filters: IIR filters and fixed point math do>> not mix well. Truncation errors and limited dynamic range problems are >> amplified by the feedback nature of the IIR. > > Speex makes sure the filters are never too close to being unstable, so > I'm confident there will be no problem with the IIR.Have you tried working with fixed point IIR filters? Stable or not, the frequency response suffers. Maybe it will still be good enough. <p>>> There are a bunch of IIR filters used in speex. It seems to me that>> using the rounded impulse responses of those filters (up to limit of >> precision) would be a good approach, as opposed to redesigning all the >> filters. I've done a few tests, and it looks promising. > > There's a chicken-and-egg problem here. How do you compute the impulse > response without using an IIR filter in the first place? The IIR filters > are different for each 40-sample sub-frame BTW (i.e. you can't cache > them).Are the coefficients for the LPC or other IIR filters dependent on the data? I thought that they were derived from the modes and submodes defined in the various flavors. If the coefficients are data-dependent, that makes things considerably more difficult. <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Mark Borgerding wrote:> Each math operation introduces some error. So the fewer operations > required, the fewer roundoff errors occur. This leads to a happy > correlation between efficiency and accuracy.The more important problem is addition of numbers that differ in magnitude. Roundoff error is soooo small compared to that ;) <p>Segher --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> Have you tried working with fixed point IIR filters? Stable or not, the > frequency response suffers. Maybe it will still be good enough.I think it'll be good enough. Keep in mind that speech codecs have musch looser quality requirements for these things than, say, Vorbis.> Are the coefficients for the LPC or other IIR filters dependent on the data? > I thought that they were derived from the modes and submodes defined in > the various flavors. > > If the coefficients are data-dependent, that makes things considerably > more difficult.Of course it's dependent on the data. For every frame, the encoder estimates LPC coefficients and transmit them (as LSP's) to the decoder. The decoder uses these coefficients (that change for each sub-frame because of filter interpolation) to reconstruct the signal. Regardless, it's really no big deal. Jean-Marc -- Jean-Marc Valin, M.Sc.A. LABORIUS (http://www.gel.usherb.ca/laborius) Université de Sherbrooke, Québec, Canada <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Ceci est une partie de message numériquement signée Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20030619/415d50ac/signature-0001.pgp