Re: [Iaxclient-devel] speex echo cancellation tested?

[Peter G. <jpg...@gm...>]

On Mon, Apr 28, 2008 at 4:22 PM, Matthew Crane <mc...@no...> wrote:
> On Fri, 2008-04-25 at 15:16 -0600, Matthew Crane wrote:
>  > On Fri, 2008-04-25 at 14:24 -0600, Matthew Crane wrote:
>  >
>  > > Unfortunately, it looks like some sort of audio problem has crept in
>  > > between 2.1beta3 and now (at least on SLED 10).  Incoming audio sounds
>  > > very choppy.  I turned echo cancellation off -- problem still there.  I
>  > > compiled using --without-echo-can -- problem still there.
>  > >
>  > > I'm going to checkout a version of the trunk from a few days ago to see
>  > > if the echo-cancellation merge introduced these problems or if it was
>  > > something earlier.
>  > >
>  > > -Matt
>  > >
>  >
>  > More info:
>  >
>  > A build of the trunk checked out with "-r {2008-04-20}" has got audio
>  > working correctly.  The current trunk as well as Mihai's echocan branch
>  > have both got audio problems (lots of dropouts -- like several per
>  > second) on SLED 10.
>
>  Okay, I've found the source of the problem.  In audio_portaudio.c, the
>  framesPerBuffer parameter in calls to Pa_OpenStream() was changed from
>  paFramesPerBufferUnspecified to SAMPLES_PER_FRAME.  When I changed it
>  back to the old value, audio sounds okay.  For whatever reason, the new
>  value causes very choppy audio playback in SuSE Linux.

Ah ha. I believe it.

>  I suspect that we will need the fixed value of SAMPLES_PER_FRAME in
>  order for echo cancellation to work, though, huh?  :-)

I think given the way the echo cancellation is currently implemented
that yes, this is true. However, I think a different echo cancellation
implementation that avoids doing sketchy things like fixing the
samples (frames) per buffer to inappropriate values is certainly
possible. I wish I had the bandwidth to address this right now, but I
do not. Maybe someone else out there would like to take a cut at this
one?

Pete