Selon Tom Grandgent <tgrand@canvaslink.com>:> I don't think any reasonable person is expecting your code to solve
> everything. But when people are running up against very difficult
> problems like these, those kinds of comments are really hurtful. I know
> I've spent *many* hours trying to make echo cancellation and
suppression
> work in my own application, and I've tested various hardware devices
that
> claimed they could do it, all with very little to show for it. (I still
> haven't had a chance to try the latest Speex echo canceller yet. I
> expect some major reworking of my audio system will be needed before I
> can even think about achieving the necessary synchronization.)
Well, the thing with echo cancellation is that it's inhearently easier to
break
than a codec (that will pretty much always work). There's a certain number
of
things that need to be done right and can't easily be worked around. For
example, it's much easier to use a decent recording volume than attempt to
work
around clipping problems (same applies to sync). Other things aren't as easy
to
solve, but it's still easier to solve the problem than attempt to work
around
it.
> Maybe better documentation of the issues surrounding echo cancellation
> and the exact requirements of your code could go a long way towards
> answering these questions in a productive way. Some sort of FAQ or wiki
> page specific to the Speex echo canceller, perhaps. Then, when these
> things come up, you can point people there and say "this has all
> information known to date". Or maybe the manual is the right place.
Actually, the manual points to "Echo Cancellation Demystified" (
http://www.embeddedstar.com/articles/2003/7/article20030720-1.html ), which
does a very good job at describing the echo cancellation problem and why you
can run into problems.
> Anyway, out of all the challenges in constructing a VoIP system, it seems
> echo cancellation is easily the most difficult. But it's also
extremely
> valuable functionality. So these issues will just keep coming up.
Yes it's sometimes a bit difficult, but it's definitely not impossible.
Just
look at the speexclient code in svn. It's only a few lines (most of which is
very verbose ALSA code) and the echo cancellation usually works fairly well.
Jean-Marc
> Tom
>
> "Coffey, Michael" <mcoffey@avistar.com> wrote:
> >
> > Millions of ordinary people have systems that do not meet your
stringent
> specifications.
> >
> > It does not matter what OS you or I use. It's the customers for
whom this
> work is done.
> >
> > -----Original Message-----
> > From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca]
> > Sent: Monday, July 02, 2007 6:35 PM
> > To: Coffey, Michael
> > Cc: speex-dev@xiph.org
> > Subject: RE: [Speex-dev] Backup Echo Suppression
> >
> > Selon "Coffey, Michael" <mcoffey@avistar.com>:
> > > Believe me; I've "played with" priorities and
buffering.
> >
> > Then either you haven't played well enough or you're using a
braindead OS.
> >
> > > Did you just say you have no idea how the Speex residual echo
suppressor
> > > works? If that is the case, can you tell me where I could get
some
> > > information about it?
> >
> > What I'm saying is that I've no idea how the residual echo
suppressor
> reacts
> > when it's used in a way it wasn't designed for (i.e. working
around broken
> > audio capture/playback).
> >
> > Jean-Marc
> >
> > > -----Original Message-----
> > > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]
> > > Sent: Friday, June 29, 2007 7:38 PM
> > > To: Coffey, Michael
> > > Cc: speex-dev@xiph.org
> > > Subject: Re: [Speex-dev] Backup Echo Suppression
> > >
> > > Coffey, Michael a ?crit :
> > > > I realize that the preprocessor echo suppression is not
designed
> > > > specifically to counter the effects of data loss. On the
other hand, as
> > > > much as I might like to, I do not have the option to
"fix that problem
> > > > for real." The sad truth is that some end users have
systems that may
> > > > drop samples, or do other unfathomable things, no matter
what I do. I
> > > > can not rewrite their drivers, firmware, or operating
system. My job is
> > > > to do the best I can in a difficult situation.
> > >
> > > Actually, there's still a lot you can do. You can reduce the
amount of
> > > sample drops by playing with the priority and the amount of
buffering
> > > you do. Also, there are sometimes ways to make sure that the
drops don't
> > > change rec/play synchronisation (the key is the sync, not the
lost
> > > samples). As for how the residual echo suppression works,
I've no idea,
> > > you need to try.
> > >
> > > > I initially assumed that the echo suppressor is similar to
other echo
> > > > suppressors (also called "nonlinear processors" or
"loss controls").
> > > > Those suppressors use cruder algorithms that exhibit
artifacts but that
> > > > may not depend on the fine time structure of the audio
signals. Is this
> > > > not true of the preprocessor echo suppressor?
> > >
> > > Not sure what other echo suppressors do. Some are actually
designed to
> > > act alone while others (like the Speex one) are designed only to
> > > suppress the echo that was left by a first echo canceller.
> > >
> > > Jean-Marc
> > >
> > > > -mjc
> > > >
> > > > -----Original Message-----
> > > > From: Jean-Marc Valin
[mailto:jean-marc.valin@usherbrooke.ca]
> > > > Sent: Tuesday, June 26, 2007 8:49 PM
> > > > To: Coffey, Michael
> > > > Cc: speex-dev@xiph.org
> > > > Subject: Re: [Speex-dev] Residual Echo Suppression by the
Preprocessor
> > > >
> > > > The residual echo suppression is supposed to be working
decently well
> > > > now. However, it's not designed to counter the effects
of samples being
> > > > dropped off the soundcard. You'll just need to fix that
problem for
> > > > real.
> > > >
> > > > Jean-Marc
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Speex-dev mailing list
> > Speex-dev@xiph.org
> > http://lists.xiph.org/mailman/listinfo/speex-dev
>
>
>