[Freeswitch-users] Hardware echo cancellation.

[David Knell]

On Fri, 2009-11-20 at 09:57 +0800, Steve Underwood wrote:
> On 11/20/2009 05:15 AM, David Knell wrote:
> > On Fri, 2009-11-20 at 00:15 +0800, Steve Underwood wrote:
> >
> >    
> >> The audio path between kernel and user space is not stable with any
> >> current PC based telephony system. At some point in the day the odd
> >> chunk of data is lost here and there, whether you use asterisk,
> >> callweaver, yate or FS, with dahdi or sangoma. This is the key problem
> >> for user space echo cancellation. When the path hiccups, the EC goes
> >> crazy, and howls. So far kernel space EC has been the only way to keep
> >> the path length rock solid.
> >>      
> > Why do you think this is?  Getting data from kernel space to user space
> > isn't something which it's difficult to do reliably: the disk system
> > manages it.  Even if data is being lost, buffer overruns can be dealt
> > with by using bigger buffers, or timestamping blocks of data on their
> > way in so that missing blocks can be detected.
> >    
> Disk isn't audio. Audio is real time, and real time constraints are a 
> harsh mistress. Big buffers are out of the question, due to latency. 

Not necessarily.  A decent-sized FIFO, mostly run empty, but there to
buffer data in the case of the user-side not being able to accept it for
a short period wouldn't necessarily add to latency unless it were
needed.  The user side could then make a decision as to how to deal with
the queued data - dump it or handle it - according to its requirements.

> Some mitigation could be provided if you can detect where missing chunks 
> occur and their exact size. Right now, the I/O schemes do not provide 
> for that, and incorporating support would be tough. You'd need some out 
> of band indication, like an ioctl or something, which would lead to more 
> user space/kernel space exchanges, further increasing the problem.

I don't think it'd be all that hard.  Were I to do this, I'd probably:
- define an error return (ESLIP, EDATALOST, something like that) which
might be returned by read/write
- add an ioctl to enable and disable it
- maybe add an ioctl to indicate how much data's been lost

Doesn't break existing stuff, doesn't add any overhead under normal
conditions, would be handy for better reliability with EC, DTMF, fax,
etc.

--Dave