Speex dev - Nov 2006 - Stream Synchronization for Echo Cancellation

Isn't this the same problem described starting at the bottom of 
this page?
http://www.embeddedstar.com/articles/2003/7/article20030720-11.html

Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
wrote:
> 
> > As it says in 5.4.1 of the good book "Using a different soundcard
to do
> > the capture and playback will *not* work, regardless of what you may
> > think. The only exception to that is if the two cards can be made to
> > have their sampling clock 'locked' on the same clock
source."
> > 
> > It seems to me that it should be possible to achieve synchronization
> > using some combination of cross-correlation, clock skew estimation,
and
> > sample interpolation. But there are so many details to consider, I bet
> > it would take a long time to get right.
> 
> When you get that to work, please let me know and we'll publish some
> papers about it. Until then, your best hope is in echo *suppression*
> (i.e. frequency-dependent gain), although even that could be a bit tricky.
> 	
> 	Jean-Marc
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev

This paper is very interesting. Just to add my own opinion on this:

My main problem concerning those elements is to synchronize 
different soundcard on different PC!

The aec is working on both outgoing (mic) and incomnig (RTP) stream.
The problem most show up with USB wich appear to have very different
clock than "classic" soundcard hardware.

In those cases, when you get let's say 1000 packets of 20ms from the mic
you may have only 990 packets of 20ms from RTP incoming stream.

Thus, before sending outgoing mic/RTP stream, you would wait for 1000 
incoming packets: where last packet in fact arrive 10*20ms = 200ms
after it was supposed to. I have from my experience already seen 4s
of clock deviation each minutes between one USB headset and other
sound card....

In this case, synchronisation is a nightmare. It seems to be similar
issue than the one described in your link, but the difference is really
unpredictable and the resolution does not seems as simple...

Anybody that wish to share experience on this?

Tks,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/


On Wed, 1 Nov 2006, Tom Grandgent wrote:
> Isn't this the same problem described starting at the bottom of
> this page?
> http://www.embeddedstar.com/articles/2003/7/article20030720-11.html
>
> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:
>>
>>> As it says in 5.4.1 of the good book "Using a different
soundcard to do
>>> the capture and playback will *not* work, regardless of what you
may
>>> think. The only exception to that is if the two cards can be made
to
>>> have their sampling clock 'locked' on the same clock
source."
>>>
>>> It seems to me that it should be possible to achieve
synchronization
>>> using some combination of cross-correlation, clock skew estimation,
and
>>> sample interpolation. But there are so many details to consider, I
bet
>>> it would take a long time to get right.
>>
>> When you get that to work, please let me know and we'll publish
some
>> papers about it. Until then, your best hope is in echo *suppression*
>> (i.e. frequency-dependent gain), although even that could be a bit
tricky.
>>
>> 	Jean-Marc
>> _______________________________________________
>> Speex-dev mailing list
>> Speex-dev@xiph.org
>> http://lists.xiph.org/mailman/listinfo/speex-dev
>
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>
>

> In those cases, when you get let's say 1000 packets of 20ms from the
mic
> you may have only 990 packets of 20ms from RTP incoming stream.
> 
> Thus, before sending outgoing mic/RTP stream, you would wait for 1000
> incoming packets: where last packet in fact arrive 10*20ms = 200ms
> after it was supposed to. I have from my experience already seen 4s
> of clock deviation each minutes between one USB headset and other
> sound card....
> 
> In this case, synchronisation is a nightmare. It seems to be similar
> issue than the one described in your link, but the difference is really
> unpredictable and the resolution does not seems as simple...
> 
> Anybody that wish to share experience on this?
Actually, the jitter buffer in Speex tends to cope relatively well with
non-synchronised clocks. The only that that really doesn't like it is
the echo canceller. Even a drift by one sample means that the echo
canceller needs to re-adapt. So as soon as the (local) clocks aren't
*perfectly* synchronised, the echo cancellation performance goes down to
a point where it's mainly unusable.

	Jean-Marc

> Tks,
> Aymeric MOIZARD / ANTISIP
> amsip - http://www.antisip.com
> osip2 - http://www.osip.org
> eXosip2 - http://savannah.nongnu.org/projects/exosip/
> 
> 
> On Wed, 1 Nov 2006, Tom Grandgent wrote:
> 
>> Isn't this the same problem described starting at the bottom of
>> this page?
>> http://www.embeddedstar.com/articles/2003/7/article20030720-11.html
>>
>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote:
>>>
>>>> As it says in 5.4.1 of the good book "Using a different
soundcard to do
>>>> the capture and playback will *not* work, regardless of what
you may
>>>> think. The only exception to that is if the two cards can be
made to
>>>> have their sampling clock 'locked' on the same clock
source."
>>>>
>>>> It seems to me that it should be possible to achieve
synchronization
>>>> using some combination of cross-correlation, clock skew
estimation, and
>>>> sample interpolation. But there are so many details to
consider, I bet
>>>> it would take a long time to get right.
>>>
>>> When you get that to work, please let me know and we'll publish
some
>>> papers about it. Until then, your best hope is in echo
*suppression*
>>> (i.e. frequency-dependent gain), although even that could be a bit
>>> tricky.
>>>
>>>     Jean-Marc
>>> _______________________________________________
>>> Speex-dev mailing list
>>> Speex-dev@xiph.org
>>> http://lists.xiph.org/mailman/listinfo/speex-dev
>>
>> _______________________________________________
>> Speex-dev mailing list
>> Speex-dev@xiph.org
>> http://lists.xiph.org/mailman/listinfo/speex-dev
>>
>>
> 
> 
>