[Gta04-owner] Speex echo cancelation now working?

NeilBrown neilb at suse.de
Sun Apr 29 01:07:28 CEST 2012


On Mon, 23 Apr 2012 23:13:06 +0000 Radek Polak <psonek2 at seznam.cz> wrote:

> On Saturday 21 April 2012 21:45:17 NeilBrown wrote:
> 
> > It looks correct if both sound devices are ready to start producing
> > samples.
> > 
> > However if you start the program before the Option module is producing
> > sound samples, then the internal sound card will still be ahead of the
> > Option source.
> > 
> > So it looks correct iff the call is already connected.
> > I haven't performed any experiments to see when Option actually starts
> > generating samples.  If it is predictable (immediately after "ATA" or
> > "ATDnnnn;") then this would be fine.  If, when dialling, you don't get
> > samples until the call connects - then I don't think the patch is correct.
> 
> Hi,
> I am attaching patch (it assumes my previous patch applied) and two output 
> logs. One of them is captured when routing was started right after the number 
> was dialed, the second one is from routing started during call.
> 
> In both situations the stream look synced (the difference between r0 and r1 
> delay is very small).
> 
> The log routing-started-during-call.txt is not interesting. We agree that 
> routing works ok here.
> 
> Interesting is the second one (routing-started-before-call.txt) - mainly the 
> beginning:
> 
> 2865566ms: route_stream_read(&r0)
> 32ms:     OK
> ^^^ r0 read was 32 ms, this is normal
> 
> 0ms: route_stream_read(&r1)
> 3121ms:     OK
> ^^^ r1 read is 3s long because call was not estabilished yet
> 
> voice routing started
> delay r0=0 r1=0
> 
> 2ms: route_stream_read(&r0)
> 
> r0 (default): overrun occured: Broken pipe
> ^^^ since we waited 3s on r1 it caused overrun on r0. In this case we call 
> snd_pcm_prepare(s->handle); and start again reading r0 and r1. This gets the 
> streams in sync
> 
> 0ms:     ERR
> 0ms: route_stream_read(&r0)
> 32ms:     OK
> 0ms: route_stream_read(&r1)
> 0ms:     OK
> ^^^ here it starts working the normal way
> 
> delay r0=0 r1=4
> 
> So if i understand it right, the streams got synced with long r1 read and 
> overrun on r0. Does it sound logical?

Yes.... but not perfectly in-sync, and I don't think there is anything here
that encourages the streams to be in-sync.
I suspect that different delays in reading from r1 will result in different
time differences between the streams.  You were lucky to get only a few ms
difference.  When I experimented I was unlucky and got a much larger
difference.

I think there needs to be some mechanism to force them both to by in-sync.
Maybe call snd_pcm_prepare on both if you call it on either?  Probably with
a snd_pcm_drop as well??

NeilBrown
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20120429/c060e457/attachment.bin>


More information about the Gta04-owner mailing list