similar to: speex initialization @ TI C55 DSP

The builds that I referred to in my last mail should be 11398 and 11387, not 11387 and 11343. Sorry for any confusion. - Jim ----- Original Message ----- From: "Jim Crichton" <jim.crichton@comcast.net> To: "Jean-Marc Valin" <Jean-Marc.Valin@USherbrooke.ca> Cc: <speex-dev@xiph.org> Sent: Wednesday, May 10, 2006 11:47 AM Subject: Re: [Speex-dev] Speex echo

> The C55 and C64 builds diverge in exactly the same place as before (byte > 0x1000). The output from C55 build 11387 (svn head) diverges from C55 build > 11343 slightly later (byte 0x1116). Similarly, the output from C64 build > 11387 (svn head) diverges from C64 build 11343 slightly later (byte 0x1126). > So, your change clearly had an effect, not just on the 16-bit machine,

>> My builds for the two platforms used exactly the same source files, >> though >> there were a few ifdefs in the test_echo routine to deal with file I/O >> for >> the C55 with its 16-bit char size. When I get a chance, I will add some >> instrumentation and see if I can find where things diverge. Just looking >> at >> the canceled audio files

>> When the dust >> settles, I will send a patch with additions to the TI directory for the >> echo >> canceler example, including instructions on these last changes. Also, I >> would like to modify the memory allocation to follow the same structure >> as >> the encoder/decoder, including the ability to override the malloc >> function. >

Jean-Marc, I recently started looking at running the echo canceller on a TI C55 DSP along with the 8kbps narrowband Speex encoder/decoder. This is one of those "braindead compilers" that you refer to from time to time, and cannot handle the float struct assignments in the return statements in pseudofloat.h. Most of these were eliminated in build 11311 (patch by Brian Retford), but

> misc.c provides the ability to override some functions, including the > allocation and printing. fftwrap.c uses speex_alloc, then calls > kiss_fftr_alloc, which calls kiss_fft_alloc, which calls KISS_FFT_MALLOC, > which is defined as malloc in kiss_fft.h. It would make it more consistent > to define KISS_FFT_MALLOC as speex_alloc. That is the only change that I > would

Jean-Marc, Well I finally tracked down the problem. Then I checked my mail and found that you had fixed it several hours earlier. :( Build 11387 produces the same result as my modified build 11343. Because of compiler limitations in the TI tools, I did have to make modifications to pseudofloat.h (separating return of float values) and nb_celp.c (adding braces around a variable declaration

> I've just been made aware of these problems (look for the thread "speex > echo cancellation limitations"). It's on my short-term TODO list. I saw the other thread, my problems happened in different (but similar) routines. >> If fftwrap.c, I ifdefed out the spx_fft_float and spx_ifft_float >> routines, >> because there were not used and required

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not

>Just tried your files and I'm not running into any infinite loops and >the cancellation works fine. Unless the C6x has the same problem, I >suspect a 16-bit problem. I'll check and see if I find something. About >the r=0 problem, I can't find where it ends up in a denominator, so I >suspect is not (directly) the problem. I built and ran the same test on the TI C64

> Build 11387 produces the same result as my modified build 11343. Because of > compiler limitations in the TI tools, I did have to make modifications to > pseudofloat.h (separating return of float values) and nb_celp.c (adding > braces around a variable declaration in the middle of code). I have > attached a patch. You might prefer to do the nb_celp.c change in a >

Just tried your files and I'm not running into any infinite loops and the cancellation works fine. Unless the C6x has the same problem, I suspect a 16-bit problem. I'll check and see if I find something. About the r=0 problem, I can't find where it ends up in a denominator, so I suspect is not (directly) the problem. Jean-Marc Le lundi 08 mai 2006 ? 20:05 -0400, Jim Crichton a ?crit

> I built and ran the same test on the TI C64 simulator, and the echo was > canceled nicely (about 10:1 reduction in the peak amplitude during the > second of two brief speech bursts). So, my problem must again be related to > the 16-bit processing on the C5X DSPs. Good. At least we've narrowed it down a bit. > Also, the line where it is hanging is: >

Hi Jim, I've just been made aware of these problems (look for the thread "speex echo cancellation limitations"). It's on my short-term TODO list. > If fftwrap.c, I ifdefed out the spx_fft_float and spx_ifft_float routines, > because there were not used and required smallft.c (which is not so small at > all) to be added to the build. Right, need to cleanup that

Jean Marc, >> The C5x and C6x output diverges in build 10143, which has log message >> "lpc >> floor converted to fixed-point." Also, the measured SNR changed from >> 11.05 >> in builds 9854-10141 to 9.22 and 9.24 in 10143. > >Actually, build 10143 introduced another bug, that was the reason for >the 1.1.11.1 release. > >> There is just

The patch is still valid, though it may require minor adjustments. Although support could be improved (optimizations, codebook packing), the patch should at least allow Speex to run on a C55. Jean-Marc Le mercredi 02 mars 2005 ? 15:00 -0600, Paul Gryting a ?crit : > I saw a thread in the list archives about a speex port to TI 55x DSP. > Wondering how that worked out (is working out)?

> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one

Jean-Marc, >> Build 11169 in SVN works correctly. > > Good. I'll try not to forget the EXTEND32 from now on. > >> I have attached a zip file (renamed >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs >> consistent. > > Seems like unzip can't read it. Either it's in an unknown format or the > file got corrupted. Could simply

Jim Crichton, I'm trying to run speex on omap 1610 platform and i saw that you have a patch for c55. When i saw your mail about this, i decided to ask you for send me those files above: include\config.h (not automatically generated, sets memory sizes, enables manual alloc) include\speex\speex_config_types.h (match Speex types to compiler types, not generated from types.in

>> I was wrong, it is the encoder that is not working, and it stopped >> working >> in build 11103. The log message for this build is "another 640 bytes >> removed from the encoder state (using the input data instead of copying >> it >> to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build. >> What >> I am seeing