Speex dev - Oct 2006 - speex-1.2beta1 AEC garbles up audio unless compiled with --enable-fixed-point

Greetings everyone,

I was about to compare AEC performance between 1.1.12 and 1.2beta1 when 
I noticed something.

If I configure (and compile) speex-1.1.12 with

./configure --enable-shared=no --enable-static=yes

it compiles and works as expected: I can run a mic and speaker signal 
through testecho, it runs in a reasonable amount of time (about 23 secs 
for 3 minutes of audio) and I get back good audio.

If I configure (and compile) speex-1.2beta1 with

./configure --enable-shared=no --enable-static=yes

it compiles, but with the same input files testecho runs very long (say 
about 21-24 minutes, probably data-dependent), and the output audio is 
garbled up.

It does the same with --enable-sse.

But with --enable-fixed-point, AEC returns to normal.

This is happening on a Gentoo stable (1.12.4) system, gcc 4.1.1, glibc 
2.4, processor is "Intel(R) Pentium(R) 4 CPU 3.00GHz" (with 
HyperThreading disabled).

My data is real-world audio captured from a physical speaker and mic 
setup in a room, by the left and right channels of the same soundcard 
input, and is sampled at 32 kHz. 1.2beta1 AEC without 
--enable-fixed-point garbles the audio up whether I claim it is sampled 
at 8 kHz or 32 kHz in testecho.c, it just does so differently. I can't 
hear anything of my original audio, instead I hear a very loud 
(full-scale), regularly repeating noise. When I look at the waveform, it 
looks a bit like 1/x for x>0, where overflowed samples values are not 
clipped but wrapped back down; that is, the first few dozen samples are 
wildly swinging between -32768 and 32767, later slow down but still 
full-scale, even later the sample values asymptotically approach zero 
from above; then suddenly the cycle begins again. (I can provide samples 
of input and output on request.)

Is anyone else seeing anything like this?

Thanks in advance.

Best Regards,
Andras Kadinger

You may have triggered an instability problem. Can you upload your files
somewhere so I can have a look at them?

	Jean-Marc

Andras Kadinger a ?crit :
> Greetings everyone,
> 
> I was about to compare AEC performance between 1.1.12 and 1.2beta1 when
> I noticed something.
> 
> If I configure (and compile) speex-1.1.12 with
> 
> ./configure --enable-shared=no --enable-static=yes
> 
> it compiles and works as expected: I can run a mic and speaker signal
> through testecho, it runs in a reasonable amount of time (about 23 secs
> for 3 minutes of audio) and I get back good audio.
> 
> If I configure (and compile) speex-1.2beta1 with
> 
> ./configure --enable-shared=no --enable-static=yes
> 
> it compiles, but with the same input files testecho runs very long (say
> about 21-24 minutes, probably data-dependent), and the output audio is
> garbled up.
> 
> It does the same with --enable-sse.
> 
> But with --enable-fixed-point, AEC returns to normal.
> 
> This is happening on a Gentoo stable (1.12.4) system, gcc 4.1.1, glibc
> 2.4, processor is "Intel(R) Pentium(R) 4 CPU 3.00GHz" (with
> HyperThreading disabled).
> 
> My data is real-world audio captured from a physical speaker and mic
> setup in a room, by the left and right channels of the same soundcard
> input, and is sampled at 32 kHz. 1.2beta1 AEC without
> --enable-fixed-point garbles the audio up whether I claim it is sampled
> at 8 kHz or 32 kHz in testecho.c, it just does so differently. I can't
> hear anything of my original audio, instead I hear a very loud
> (full-scale), regularly repeating noise. When I look at the waveform, it
> looks a bit like 1/x for x>0, where overflowed samples values are not
> clipped but wrapped back down; that is, the first few dozen samples are
> wildly swinging between -32768 and 32767, later slow down but still
> full-scale, even later the sample values asymptotically approach zero
> from above; then suddenly the cycle begins again. (I can provide samples
> of input and output on request.)
> 
> Is anyone else seeing anything like this?
> 
> Thanks in advance.
> 
> Best Regards,
> Andras Kadinger
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
> 
>

I'll try to make some shorter samples later, but for now here are the 
ones I have tried with:

http://www.surfnonstop.com/~bandit/speex/1.2beta1_AEC_garble/

The original recordings are in mic.raw and spk.raw.

Jean-Marc Valin wrote:
> You may have triggered an instability problem. Can you upload your files
> somewhere so I can have a look at them?
>
> 	Jean-Marc
>
> Andras Kadinger a ?crit :
>   
>> Greetings everyone,
>>
>> I was about to compare AEC performance between 1.1.12 and 1.2beta1 when
>> I noticed something.
>>
>> If I configure (and compile) speex-1.1.12 with
>>
>> ./configure --enable-shared=no --enable-static=yes
>>
>> it compiles and works as expected: I can run a mic and speaker signal
>> through testecho, it runs in a reasonable amount of time (about 23 secs
>> for 3 minutes of audio) and I get back good audio.
>>
>> If I configure (and compile) speex-1.2beta1 with
>>
>> ./configure --enable-shared=no --enable-static=yes
>>
>> it compiles, but with the same input files testecho runs very long (say
>> about 21-24 minutes, probably data-dependent), and the output audio is
>> garbled up.
>>
>> It does the same with --enable-sse.
>>
>> But with --enable-fixed-point, AEC returns to normal.
>>
>> This is happening on a Gentoo stable (1.12.4) system, gcc 4.1.1, glibc
>> 2.4, processor is "Intel(R) Pentium(R) 4 CPU 3.00GHz" (with
>> HyperThreading disabled).
>>
>> My data is real-world audio captured from a physical speaker and mic
>> setup in a room, by the left and right channels of the same soundcard
>> input, and is sampled at 32 kHz. 1.2beta1 AEC without
>> --enable-fixed-point garbles the audio up whether I claim it is sampled
>> at 8 kHz or 32 kHz in testecho.c, it just does so differently. I
can't
>> hear anything of my original audio, instead I hear a very loud
>> (full-scale), regularly repeating noise. When I look at the waveform,
it
>> looks a bit like 1/x for x>0, where overflowed samples values are
not
>> clipped but wrapped back down; that is, the first few dozen samples are
>> wildly swinging between -32768 and 32767, later slow down but still
>> full-scale, even later the sample values asymptotically approach zero
>> from above; then suddenly the cycle begins again. (I can provide
samples
>> of input and output on request.)
>>
>> Is anyone else seeing anything like this?
>>
>> Thanks in advance.
>>
>> Best Regards,
>> Andras Kadinger
>> _______________________________________________
>> Speex-dev mailing list
>> Speex-dev@xiph.org
>> http://lists.xiph.org/mailman/listinfo/speex-dev
>>
>>
>>