similar to: Speex echo canceller on TI C55 DSP

>> 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

> 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,

> 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

> 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 >

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

>> 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. >

>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

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

> 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: >

For me, this was a memory allocation problem. I am using a private heap, and somewhere between build 11522 and 11700, the allocation for two large buffers was changed from calloc to speex_alloc (I am sure that this was a cleanup change, and I have not had a chance to locate it yet). This was overrunning my heap, and enlarging the heap solved the problem. I suspect that Itay is having a

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

Jim Crichton a ?crit : > Itay, > > I tested on C6x in May with build 11343 and 11398, and it worked > fine. I just ran the same test with build 11768, and there was no > cancellation, just as you saw. I will try to track this down in the > next day or two. In the meantime, I suggest that you try testing > with 11398. Hmm, that's odd because the fixed-point seems to

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'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

Dear All, When I used speex on C55, the program always printed out something like "Persist Allocated..." and couldnot run into the core program. What's wrong ? Thanks. Hua -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/speex-dev/attachments/20170122/b2acac5a/attachment.html>

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 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

Itay, I tested on C6x in May with build 11343 and 11398, and it worked fine. I just ran the same test with build 11768, and there was no cancellation, just as you saw. I will try to track this down in the next day or two. In the meantime, I suggest that you try testing with 11398. - Jim ----- Original Message ----- From: Itay Chamiel To: speex-dev@xiph.org Sent: Monday, August 14,