> I've just kicked off project "Sphinx". Which is supposed to > sound like "Speex" merged with "INT". ;) Meaning I am working > on an integer encoder and decoder.Good news! Although you might want to choose another name since "Sphinx" is already used by CMU's open-source speech recognition engine (http://fife.speech.cs.cmu.edu/sphinx/).> It looks like I will be pulling in a new "integer plumbing" > into the foundation of the codec, comparing the results with > the old "floating point plumbing" along the way. Once the > integer code works, I can tear down the old floating point > code. Pray this works ;)Not sure what you mean here...> Another option I've been thinking about is replacing > all arithmetic operations (additions, multiplications, etc) > with #define macros. So you would get an integer or floating > point version depending on whether you use the int or the float > macros. Even though this would be "cool", it is more difficult > and error prone. I guess I'll use the previous option.I think it's probably possible to do something like that. Although it would likely be more complicated than just making macros for add/multiply (there are various precision issues), the result would be easier to maintain as the same change would affect both the float and int version. 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/03181858/signature-0001.pgp
> > <with Prof. Farnsworth voice> "Good News, everyone". > > I've just kicked off project "Sphinx". Which is supposed to > sound like "Speex" merged with "INT". ;) Meaning I am working > on an integer encoder and decoder. >Great. I looked into converting speex to fixed point a while ago, but my job has gotten much busier lately. Here's a short brain dump of what I've thought about so far. I hope it helps. 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. To do this, I needed a fixed point fft, preferrably that didn't use assembly. I tried to find an ANSI C fft routine that would do fixed point. I couldn't, so I wrote KISS FFT: a simple, portable radix2 FFT library that can be compiled to use either fixed or floating point math. See http://sourceforge.net/projects/kissfft 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. 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. IOTW, use matlab or octave to get the high precision impulse reponse of the IIR, scale it according to fixed point reqs., then round it. Assuming that the original IIR filter is stable, the impulse response will eventually subside so that the coefficients round to less than the fixed point precision, i.e. they become all zeros. At that point, you've reached the end of the new FIR, aka impulse response, that has almost exactly the same frequency response as the IIR version and is much closer than that of a fixed point IIR. <p><p><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.
> 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
<with Prof. Farnsworth voice> "Good News, everyone". I've just kicked off project "Sphinx". Which is supposed to sound like "Speex" merged with "INT". ;) Meaning I am working on an integer encoder and decoder. It looks like I will be pulling in a new "integer plumbing" into the foundation of the codec, comparing the results with the old "floating point plumbing" along the way. Once the integer code works, I can tear down the old floating point code. Pray this works ;) Another option I've been thinking about is replacing all arithmetic operations (additions, multiplications, etc) with #define macros. So you would get an integer or floating point version depending on whether you use the int or the float macros. Even though this would be "cool", it is more difficult and error prone. I guess I'll use the previous option. Christian <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.
On Thu, 2003-06-19 at 00:32, Christian Buchner wrote:> I've just kicked off project "Sphinx". Which is supposed to > sound like "Speex" merged with "INT". ;) Meaning I am working > on an integer encoder and decoder.Will you be making the development source tree available so others can contribute? -- --Jeff Sr. Unix Systems Administrator & Engineer SAIR Linux and GNU Certified Professional This email may contain privileged and confidential information. It is intended only for the use of the adressee(s). I'll further add that if this message is not digitally signed or encrypted using one of my keys, than I can deny composing it in the first place. --- >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.
Good news! Although you might want to choose another name since "Sphinx" is already used by CMU's open-source speech recognition engine (http://fife.speech.cs.cmu.edu/sphinx/). It's a working title, not necessarily a release name ;)> Not sure what you mean here...Every maths operation gets an integer duplicate. At certain points in the code I will compare the results of integer versus FP for accuracy. A deviation greater than a threshold will generate a warning message. That should allow me to pinpoint computational problems (rounding, filter stability etc). Once the whole code works on int, I can remove the FP code. Maybe the plumbing metaphor was a bit too colorful ;) --- >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.