[Speex-dev] AEC on a TI C6x - has no effect

[Itay Chamiel]

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 at usherbrooke.ca] 
Sent: Wednesday, August 16, 2006 3:56 PM
To: Itay Chamiel
Cc: Jim Crichton; speex-dev at 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