Bug#376202: breaks if EchoCancelation=true

[George Danchev]

On Thursday 13 July 2006 21:12, Santiago Garcia Mantinan wrote:
> Sorry for not replying before, I wanted to do some tests and I couldn't
> find the time to do them till today.
>
> > Do you find it acceptable to enable Echo Cancellation againt, without
> > kiax/iLBC and kiax/aec_nlms code which are the only non-DFSG-compliant
> > parts in kiax upstream ? This way we gain EC again and avoid segfault,
> > but the drawback is that our external libs will not be utilized.
>
> I've been testing this proposal (I've built after applying the
> ec-enable.patch and downloading new sources) and I don't see this clear at
> all.
>
> I mean... I tested echo cancellation and it doesn't seem to work at all, I
> mean, when we talked with upstream about echo cancellation [1] he always
> refered to the tipic patch and to NLMS. It looks to me like if we remove
> that, we are loosing the echo cancellation, at least the good one and the
> one that remains in the program is a bad one (IE: not working at all here).

Well, yes, but the files in aec_nlms/ directory are not free, so we have these 
ways to go:

a) have poor quality EC without aec_nlms bits
b) disable EC completely (as it is in 0.8.51.dfsg-2-1 package)
c) remove kiax from the archive

I'm not sure which way is the best compromise though.

> So... I'd say... either we try to find out if the license for all the tipic
> stuff is really LGPL and if so we package with tipic and EC and all the
> stuff, or we leave it like it is and we try to fix this bug in our sources.

We should reimplement aec_nlms/ bits then, which is not so trivial. I asked 
Emil Stoyanov to clarify some things for me (i.e. how that horror interact 
with portaudio lib), but he said that this has been implemented by his 
friend, so he shold ask him for details. There is not reply ever since.

> For me it was an error to let this -2 package get to testing, we should
> have left the RC bug till we had solved all this. That way the original
> dfsg package wouldn't have been overritten by this one which is mostly the
> same, but that is old stuff anyway.
>
> That's how I see it, but I'd like to hear other opinions, tests, ...

I have been waiting to hear other opinions too.

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB