> I followed your advice on running the trivial case. The float version > started cancelling sounds out within a second. The fixed point > version also worked, but took a little longer before the effect was > noticeable. Since I now realized the fixed point version might need a > little more tweaking than the float version, I started modifying some > things and ended up with the following changes:Can you check if you see the same difference between fixed-point and floating-point in 1.1.12?> 1. Buffered up the "play" buffer by one frame (192 samples on our > system), such that the delay between the play and rec is reduced from > about 350 samples (43 msec) to a little under 200 samples. (yes I > realize 350-192 != 200, there are slight variations between runs.) I > didn't buffer by 2 frames because this would run the risk of a > negative delay value. 2. Reduced the filter size from 800 or 400 > (which I was using before) to 200.Try using smaller frames. If your system uses frames of 196, try splitting that in two and using a frame size of 96 for the AEC. This should improve things. Also, a tail length of 200 might be a bit short.> With these changes the fixed point version is working well. I guess > the conclusion we can reach here is not that the fixed point version > doesn't work, but that it is not *equivalent* to the floating point > version. The floating point version is better at adapting in somewhat > harder conditions (larger delay), and can adapt in conditions where > the fixed point version won't adapt at all.Care to send me (small) files where there's a big difference. In the samples I have, the fixed-point is actually pretty close to the float version. Maybe it's only because of the larger frame size (FFT quantization noise increases with frame size). Jean-Marc
Jean-Marc, I am trying these things, but the main problem that has been bothering me recently is that the fixed-point algorithm works "sometimes". Meaning that sometimes it will work well, and other times it will not work at all. I think I've found the source of the problem. The speex_alloc() function, called by speex_echo_state_init(), calls calloc() and returns a zeroed array. On the other hand, the TI implementation (as it is if you don't change the MANUAL_ALLOC define) replaces speex_alloc() with a different version that doesn't use the heap but only allocates memory from a large application-supplied memory block. Nothing zeroes this memory, and there is no hint in the comments (ti\user_misc.h, lines 36-46) to let me know that the block must be zeroed externally. I believe this should be clarified in these comments, or perhaps instead add a memset in speex_alloc() in ti\user_misc.h to zero the memory. Now that I'm zeroing this block in my initialization, everything seems to be working much more consistently. Thanks, -Itay
Jean-Marc, Your advice to use smaller frames turned out to have a major effect, it really does work much better when I divide the operation into two calls of 96 samples each. This really ought to be added to the documentation, as many codecs use frame sizes as large as 1152 samples and I was initially working with that (before switching to 192). I would never have thought to divide the calls into smaller ones on my own. It would be hard for me to supply you with sample files, because I don't work with files. I have a realtime system with mics and speakers and I'm doing my testing by talking into a microphone (admittedly not the perfect method of comparing scenarios, because I can't emit the exact sound twice). By the way, encoding 192 samples takes just 1.2 msec after the optimizing compiler. This is under 5% CPU! Thanks, -itay -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Wednesday, August 16, 2006 3:56 PM To: Itay Chamiel Cc: Jim Crichton; speex-dev@xiph.org Subject: Re: [Speex-dev] AEC on a TI C6x - has no effect> I followed your advice on running the trivial case. The float version > started cancelling sounds out within a second. The fixed point version> also worked, but took a little longer before the effect was > noticeable. Since I now realized the fixed point version might need a > little more tweaking than the float version, I started modifying some > things and ended up with the following changes:Can you check if you see the same difference between fixed-point and floating-point in 1.1.12?> 1. Buffered up the "play" buffer by one frame (192 samples on our > system), such that the delay between the play and rec is reduced from > about 350 samples (43 msec) to a little under 200 samples. (yes I > realize 350-192 != 200, there are slight variations between runs.) I > didn't buffer by 2 frames because this would run the risk of a > negative delay value. 2. Reduced the filter size from 800 or 400 > (which I was using before) to 200.Try using smaller frames. If your system uses frames of 196, try splitting that in two and using a frame size of 96 for the AEC. This should improve things. Also, a tail length of 200 might be a bit short.> With these changes the fixed point version is working well. I guess > the conclusion we can reach here is not that the fixed point version > doesn't work, but that it is not *equivalent* to the floating point > version. The floating point version is better at adapting in somewhat > harder conditions (larger delay), and can adapt in conditions where > the fixed point version won't adapt at all.Care to send me (small) files where there's a big difference. In the samples I have, the fixed-point is actually pretty close to the float version. Maybe it's only because of the larger frame size (FFT quantization noise increases with frame size). Jean-Marc
Itay,>I am trying these things, but the main problem that has been bothering >me recently is that the fixed-point algorithm works "sometimes". Meaning >that sometimes it will work well, and other times it will not work at >all. > >I think I've found the source of the problem. The speex_alloc() >function, called by speex_echo_state_init(), calls calloc() and returns >a zeroed array. On the other hand, the TI implementation (as it is if >you don't change the MANUAL_ALLOC define) replaces speex_alloc() with a >different version that doesn't use the heap but only allocates memory >from a large application-supplied memory block. Nothing zeroes this >memory, and there is no hint in the comments (ti\user_misc.h, lines >36-46) to let me know that the block must be zeroed externally. I >believe this should be clarified in these comments, or perhaps instead >add a memset in speex_alloc() in ti\user_misc.h to zero the memory.>Now that I'm zeroing this block in my initialization, everything seems >to be working much more consistently.There IS a memset at the bottom of speex_alloc in ti\user_misc.h, so I do not understand why your zeroing of this block makes any difference. There may be some more subtle problem. - Jim