Hardware echo cancellation.
I am about to build a new machine as a VOIP server. I am going to get either a quad core intel or a six core AMD processor with at least eight gigabytes of RAM in it. Given that much horsepower I am wondering if there is any need to purchase hardware with echo cancellation (I am thinking about redfone devices).. I can save some money by not getting the echo cancellation. So is it worth saving that money? Is it always better to have hardware echo cancellation? Is a quad core capable of dealing with echo cancellation needs of an IVR which is going to take lots of simultaneous calls? Thanks.
If you have TDM hardware, Buy the echo canceller. It's worth it. It's not required for standard SIP calls though, only when dealing with analog or TDM circuits. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 18-Nov-09, at 12:39 PM, Tim Uckun wrote:
I am about to build a new machine as a VOIP server. I am going to get either a quad core intel or a six core AMD processor with at least eight gigabytes of RAM in it. Given that much horsepower I am wondering if there is any need to purchase hardware with echo cancellation (I am thinking about redfone devices).. I can save some money by not getting the echo cancellation.
So is it worth saving that money? Is it always better to have hardware echo cancellation? Is a quad core capable of dealing with echo cancellation needs of an IVR which is going to take lots of simultaneous calls?
Thanks.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Given that it's an IVR system I think you'll find the DTMF results better with hardware based echo cans ... and to be frank the hardware based echo cancellations are really not that much more expensive on cards from folks like Sangoma. SDR Tim Uckun wrote:
I am about to build a new machine as a VOIP server. I am going to get either a quad core intel or a six core AMD processor with at least eight gigabytes of RAM in it. Given that much horsepower I am wondering if there is any need to purchase hardware with echo cancellation (I am thinking about redfone devices).. I can save some money by not getting the echo cancellation.
So is it worth saving that money? Is it always better to have hardware echo cancellation? Is a quad core capable of dealing with echo cancellation needs of an IVR which is going to take lots of simultaneous calls?
Thanks.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Tim, Here you go: http://old.nabble.com/echo-cancellation-on-PRI-cards-td22552605.html
I am about to build a new machine as a VOIP server. I am going to get either a quad core intel or a six core AMD processor with at least eight gigabytes of RAM in it. Given that much horsepower I am wondering if there is any need to purchase hardware with echo cancellation (I am thinking about redfone devices).. I can save some money by not getting the echo cancellation.
So is it worth saving that money? Is it always better to have hardware echo cancellation? Is a quad core capable of dealing with echo cancellation needs of an IVR which is going to take lots of simultaneous calls?
In (very) brief: maybe, no, and depends on the definition of 'lots'. --Dave
On Thu, Nov 19, 2009 at 10:04 AM, David Knell <dave@3c.co.uk> wrote:
Hi Tim,
Here you go: http://old.nabble.com/echo-cancellation-on-PRI-cards-td22552605.html
Thanks. That's almost exactly the same situation as the one I am going to find myself in.
In (very) brief: maybe, no, and depends on the definition of 'lots'.
By lots I mean somewhere between 50 to a 100 but it's mostly an IVR application so all it will be doing is either playing prompts or recording messages. Almost no live conversations.
On Wed, Nov 18, 2009 at 1:36 PM, Tim Uckun <timuckun@gmail.com> wrote:
On Thu, Nov 19, 2009 at 10:04 AM, David Knell <dave@3c.co.uk> wrote:
Hi Tim,
Here you go: http://old.nabble.com/echo-cancellation-on-PRI-cards-td22552605.html
Thanks. That's almost exactly the same situation as the one I am going to find myself in.
In (very) brief: maybe, no, and depends on the definition of 'lots'.
By lots I mean somewhere between 50 to a 100 but it's mostly an IVR application so all it will be doing is either playing prompts or recording messages. Almost no live conversations.
Just get the HW echo can - all the COOL kids are doing it! :P
-MC
Hi Tim,
In (very) brief: maybe, no, and depends on the definition of 'lots'.
By lots I mean somewhere between 50 to a 100 but it's mostly an IVR application so all it will be doing is either playing prompts or recording messages. Almost no live conversations.
For the sort of box you're talking about (quad core++), this isn't lots; it's hardly any.. --Dave
It just doesn't belong in user space or kernel space in the machine for true performance you should do it in hardware... I'm pretty sure the poor box would die if you tried it on 32 E1's at the same time. /b On Nov 18, 2009, at 5:39 PM, David Knell wrote:
For the sort of box you're talking about (quad core++), this isn't lots; it's hardly any..
--Dave
Hi Brian,
It just doesn't belong in user space or kernel space in the machine for true performance you should do it in hardware... I'm pretty sure the poor box would die if you tried it on 32 E1's at the same time.
Disagree somewhat. The challenge that echo cancellers further from the hardware face is having some idea of the size of the buffers between the canceller and the wire; provided that this is known, or is small in comparison to the canceller's tail length, it can, in principle, go anywhere. All other things being equal, the right place for a software EC is in user space: can be done in a cross-platform way, can use FPU/MMX/SSE without guilt and voodoo, etc. And there is no reason why the same algorithm would perform differently if implemented in "hardware" or on the host CPU. And the OP only needed four E1s.. --Dave
/b
On Nov 18, 2009, at 5:39 PM, David Knell wrote:
For the sort of box you're talking about (quad core++), this isn't lots; it's hardly any..
--Dave
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 11/19/2009 11:54 PM, David Knell wrote:
Hi Brian,
It just doesn't belong in user space or kernel space in the machine for true performance you should do it in hardware... I'm pretty sure the poor box would die if you tried it on 32 E1's at the same time.
Disagree somewhat. The challenge that echo cancellers further from the hardware face is having some idea of the size of the buffers between the canceller and the wire; provided that this is known, or is small in comparison to the canceller's tail length, it can, in principle, go anywhere. All other things being equal, the right place for a software EC is in user space: can be done in a cross-platform way, can use FPU/MMX/SSE without guilt and voodoo, etc. And there is no reason why the same algorithm would perform differently if implemented in "hardware" or on the host CPU.
And the OP only needed four E1s..
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. There is an Intel development platform which tries to do EC with OSLEC in user space. That's the only delivered system I know that tries to do this. Its very quirky. Steve
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. --Dave
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. 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. Steve
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
greetings, I have sangoma analog card without echo cancellation hardware, I have problems with echo on calls, does FreeSwitch support echo cancellation software on windows ? Thanks Diego Toro http://lacarretade.blogspot.com
The important thing is that if you are using wanpipe native interface there is no software echo canceler. Sangoma only supports a hardware echo canceler so its not a matter of the cpu compensating for it, if you don't get the cards with the echo can you won't have any unless you run the card in zaptel mode, something we have aspired to avoid. On Wed, Nov 18, 2009 at 5:39 PM, David Knell <dave@3c.co.uk> wrote:
Hi Tim,
In (very) brief: maybe, no, and depends on the definition of 'lots'.
By lots I mean somewhere between 50 to a 100 but it's mostly an IVR application so all it will be doing is either playing prompts or recording messages. Almost no live conversations.
For the sort of box you're talking about (quad core++), this isn't lots; it's hardly any..
--Dave
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Wed, 2009-11-18 at 14:04 -0700, David Knell wrote:
In (very) brief: maybe, no, and depends on the definition of 'lots'.
Most people say yes. -- http://nicegear.co.nz New Zealand's Open Source Hardware Supplier
participants (10)
-
Anthony Minessale
-
Brian West
-
David Knell
-
Diego Toro
-
Hadley Rich
-
Mathieu Rene
-
Michael Collins
-
Shelby Ramsey
-
Steve Underwood
-
Tim Uckun