Hi all, After reading great things about the OSLEC Echo Canceller (http://www.rowetel.com/ucasterisk/oslec) and seeing the reactions of people who have tried it on a recent Trixbox thread (http://www.trixbox.org/forums/trixbox-forums/open-discussion/need-people-echo-problems), it sounds like it is the "bees knees" for sorting out echo problems with cards like the x100p. Has anyone managed to get oslec to work with recent zaptel and kernel (I'm running 2.6.23)? Lots of information below. Comments/suggestions welcome. Having followed the instructions on the oslec site, and ensuring the patch for zaptel takes O.K (I manually installed the patch into the zaptel source tree just to make sure). I can build the oslec module, and build a patched zaptel-1.4.5.1-oslec without any compilation issues. However when I reload the system during boot-up dmesg tells me: Zapata Telephony Interface Registered on major 196 Zaptel Version: 1.4.5.1 Zaptel Echo Canceller: MG2 Zaptap registered 'sample' char driver on major 33 (This means the patch went in O.K.) ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 17 (level, low) -> IRQ 22 wcfxo: DAA mode is 'FCC' Found a Wildcard FXO: Wildcard X100P Notice the choice of echo canceller.... If I look at what modules are installed: # lsmod Module Size Used by zttranscode 6280 0 ztdummy 3432 0 wcfxo 9760 0 zaptel 200120 7 zttranscode,ztdummy,wcfxo crc_ccitt 1792 1 zaptel No oslec :-( In my kernel modules/misc directory I have: -rw-r--r-- 1 root root 10727 2007-10-24 14:44 oslec.ko -rw-r--r-- 1 root root 65372 2007-10-24 14:41 pciradio.ko -rw-r--r-- 1 root root 91321 2007-10-24 14:41 tor2.ko -rw-r--r-- 1 root root 18901 2007-10-24 14:41 torisa.ko -rw-r--r-- 1 root root 12605 2007-10-24 14:41 wcfxo.ko -rw-r--r-- 1 root root 15989 2007-10-24 14:41 wct1xxp.ko drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wct4xxp drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wctc4xxp drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wctdm24xxp -rw-r--r-- 1 root root 41046 2007-10-24 14:41 wctdm.ko -rw-r--r-- 1 root root 32882 2007-10-24 14:41 wcte11xp.ko -rw-r--r-- 1 root root 45804 2007-10-24 14:41 wcte12xp.ko -rw-r--r-- 1 root root 16527 2007-10-24 14:41 wcusb.ko drwxr-xr-x 2 root root 4096 2007-10-24 14:41 xpp -rw-r--r-- 1 root root 81616 2007-10-24 14:41 zaptel.ko -rw-r--r-- 1 root root 8270 2007-10-24 14:41 ztd-eth.ko -rw-r--r-- 1 root root 5530 2007-10-24 14:41 ztd-loc.ko -rw-r--r-- 1 root root 5297 2007-10-24 14:41 ztdummy.ko -rw-r--r-- 1 root root 11687 2007-10-24 14:41 ztdynamic.ko -rw-r--r-- 1 root root 8639 2007-10-24 14:41 zttranscode.ko My /etc/zaptel.conf is: loadzone=uk defaultzone=uk fxsks=1 My /etc/asterisk/zapata.conf is ; Zapata telephony interface ; ; Configuration file [channels] ;Hardware defaults for the x100p card ;usecallerid=yes ;hidecallerid=no ;callwaiting=no ;threewaycalling=yes ;usedistinctiveringdetection=yes ;transfer=yes ;usecallingpres=yes ;callwaitingcallerid=yes ;cancallforward=yes ;callreturn=yes echocancel=yes echotrainingwhenbridged=no ;echotraining=400 rxwink=300 ; Atlas seems to use long (250ms) winks ;cidsignalling=v23 ; Added for UK CLI detection ;cidstart=usehist ; After patching the driver from here : ; http://www.lusyn.com/resources/asterisk/usehist.htm ;callerid=asreceived ; propagate the CID received from BT ;rxgain=1.0 ;txgain=1.0 ;define channel context=main_menu language=en signalling=fxs_ks channel => 1 ;Our x100p -------------------------- Alan -- The way out is open! http://www.theopensourcerer.com
Replies/Comments inline... Alan Lord wrote:> Hi all, > > After reading great things about the OSLEC Echo Canceller > (http://www.rowetel.com/ucasterisk/oslec) and seeing the reactions of > people who have tried it on a recent Trixbox thread > (http://www.trixbox.org/forums/trixbox-forums/open-discussion/need-people-echo-problems), > it sounds like it is the "bees knees" for sorting out echo problems with > cards like the x100p.I am using OSLEC on my home pbx. I used to have echo on some calls prior to OSLEC but have been echo free since I installed it.> Has anyone managed to get oslec to work with recent zaptel and kernel > (I'm running 2.6.23)?I'm only using 2.6.17 and zaptel-1.4.4 at the moment. But if the patches apply it should work.> Having followed the instructions on the oslec site, and ensuring the > patch for zaptel takes O.K (I manually installed the patch into the > zaptel source tree just to make sure). I can build the oslec module, and > build a patched zaptel-1.4.5.1-oslec without any compilation issues. > > However when I reload the system during boot-up dmesg tells me: > > Zapata Telephony Interface Registered on major 196 > Zaptel Version: 1.4.5.1 > Zaptel Echo Canceller: MG2 > Zaptap registered 'sample' char driver on major 33 (This means the patch > went in O.K.) > ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 17 (level, low) -> IRQ 22 > wcfxo: DAA mode is 'FCC' > Found a Wildcard FXO: Wildcard X100P > > Notice the choice of echo canceller....Check the zconfig.h file in the zaptel source and make sure that the line: #define ECHO_CAN_OSLEC is not commented out but all the lines for the other echo cancelers are. Did you start with a clean source (or at least did a make clean) before you compiled? Are you using the zaptel-1.4.4.patch from the oslec SVN or some other patch?> If I look at what modules are installed: > > # lsmod > Module Size Used by > zttranscode 6280 0 > ztdummy 3432 0 > wcfxo 9760 0 > zaptel 200120 7 zttranscode,ztdummy,wcfxo > crc_ccitt 1792 1 zaptelJust for kicks, try inserting the oslec module by hand (insmod oslec) and see if that makes a difference. > In my kernel modules/misc directory I have: <snip> Hope that helps. -Dave
Hi Alan. I've installed OSLEC with zaptel-1.4.5.1 applying the patches made for the 1.4 version and I have had the same problem. Looking at the compiler options I've found that the symbol ECHO_CAN_FROMENV is defined by default and this prevents the echo selection from zconfig.h. I've solved changing the first part of Makefile.kernel26 (in the zaptel directory) this way: ifndef ECHO_CAN_NAME ECHO_CAN_NAME := OSLEC endif This forces the compiler to include OSLEC as echo cancellation engine (probably there is a better way but I don't know it). I've then rebuilt zaptel and installed through normal make procedures. To be able to modprobe it I've then copied the oslec.ko file build by the OSLEC distribution in the kernel driver directory (my own is /lib/modules/2.6.18.8-0.5-default/misc and it's where zaptel drivers are installed). I've then run the depmod command to regenerate the modules dependencies. I'm now able to modprobe zaptel and to have oslec automatically installed as you can see below:> lsmod | grep zaptelzaptel 199992 6 zttranscode,wctdm oslec 23332 1 zaptel crc_ccitt 6272 1 zaptel I hope this could help you. Best regards, Marco Signorini.> > Hi all, > > After reading great things about the OSLEC Echo Canceller > (http://www.rowetel.com/ucasterisk/oslec) and seeing the reactions of > people who have tried it on a recent Trixbox thread > (http://www.trixbox.org/forums/trixbox-forums/open-discussion/need-people-echo-problems), > it sounds like it is the "bees knees" for sorting out echo problems with > cards like the x100p. > > Has anyone managed to get oslec to work with recent zaptel and kernel > (I'm running 2.6.23)? > > Lots of information below. Comments/suggestions welcome. > > Having followed the instructions on the oslec site, and ensuring the > patch for zaptel takes O.K (I manually installed the patch into the > zaptel source tree just to make sure). I can build the oslec module, and > build a patched zaptel-1.4.5.1-oslec without any compilation issues. > > However when I reload the system during boot-up dmesg tells me: > > Zapata Telephony Interface Registered on major 196 > Zaptel Version: 1.4.5.1 > Zaptel Echo Canceller: MG2 > Zaptap registered 'sample' char driver on major 33 (This means the patch > went in O.K.) > ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 17 (level, low) -> IRQ 22 > wcfxo: DAA mode is 'FCC' > Found a Wildcard FXO: Wildcard X100P > > Notice the choice of echo canceller.... > > If I look at what modules are installed: > > # lsmod > Module Size Used by > zttranscode 6280 0 > ztdummy 3432 0 > wcfxo 9760 0 > zaptel 200120 7 zttranscode,ztdummy,wcfxo > crc_ccitt 1792 1 zaptel > > No oslec :-( > > In my kernel modules/misc directory I have: > -rw-r--r-- 1 root root 10727 2007-10-24 14:44 oslec.ko > -rw-r--r-- 1 root root 65372 2007-10-24 14:41 pciradio.ko > -rw-r--r-- 1 root root 91321 2007-10-24 14:41 tor2.ko > -rw-r--r-- 1 root root 18901 2007-10-24 14:41 torisa.ko > -rw-r--r-- 1 root root 12605 2007-10-24 14:41 wcfxo.ko > -rw-r--r-- 1 root root 15989 2007-10-24 14:41 wct1xxp.ko > drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wct4xxp > drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wctc4xxp > drwxr-xr-x 2 root root 4096 2007-10-24 14:41 wctdm24xxp > -rw-r--r-- 1 root root 41046 2007-10-24 14:41 wctdm.ko > -rw-r--r-- 1 root root 32882 2007-10-24 14:41 wcte11xp.ko > -rw-r--r-- 1 root root 45804 2007-10-24 14:41 wcte12xp.ko > -rw-r--r-- 1 root root 16527 2007-10-24 14:41 wcusb.ko > drwxr-xr-x 2 root root 4096 2007-10-24 14:41 xpp > -rw-r--r-- 1 root root 81616 2007-10-24 14:41 zaptel.ko > -rw-r--r-- 1 root root 8270 2007-10-24 14:41 ztd-eth.ko > -rw-r--r-- 1 root root 5530 2007-10-24 14:41 ztd-loc.ko > -rw-r--r-- 1 root root 5297 2007-10-24 14:41 ztdummy.ko > -rw-r--r-- 1 root root 11687 2007-10-24 14:41 ztdynamic.ko > -rw-r--r-- 1 root root 8639 2007-10-24 14:41 zttranscode.ko > > My /etc/zaptel.conf is: > loadzone=uk > defaultzone=uk > > fxsks=1 > > My /etc/asterisk/zapata.conf is > > ; Zapata telephony interface ; > ; Configuration file > [channels] > ;Hardware defaults for the x100p card > ;usecallerid=yes > ;hidecallerid=no > ;callwaiting=no > ;threewaycalling=yes > ;usedistinctiveringdetection=yes > ;transfer=yes > ;usecallingpres=yes > ;callwaitingcallerid=yes > ;cancallforward=yes > ;callreturn=yes > echocancel=yes > echotrainingwhenbridged=no > ;echotraining=400 > rxwink=300 ; Atlas seems to use long (250ms) winks > > ;cidsignalling=v23 ; Added for UK CLI detection > ;cidstart=usehist ; After patching the driver from here : > ; http://www.lusyn.com/resources/asterisk/usehist.htm > ;callerid=asreceived ; propagate the CID received from BT > ;rxgain=1.0 > ;txgain=1.0 > > ;define channel > context=main_menu > language=en > signalling=fxs_ks > channel => 1 ;Our x100p > > -------------------------- > > Alan > > -- > The way out is open! > http://www.theopensourcerer.com > > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > >
On Wed, Oct 24, 2007 at 03:03:01PM +0100, Alan Lord wrote:> Hi all, > > After reading great things about the OSLEC Echo Canceller > (http://www.rowetel.com/ucasterisk/oslec) and seeing the reactions of > people who have tried it on a recent Trixbox thread > (http://www.trixbox.org/forums/trixbox-forums/open-discussion/need-people-echo-problems), > it sounds like it is the "bees knees" for sorting out echo problems with > cards like the x100p. > > Has anyone managed to get oslec to work with recent zaptel and kernel > (I'm running 2.6.23)?I use it at home iwth zaptel 1.4.5.1 and kernel 2.6.18 of Debian Etch. I know it to build successfully with 2.6.22 . You can find up-to-date OSLEC support (minimal patch an d an oslec subdirectory) in recent zaptel packages of Debian. You need to set ECHO_CAN_NAME=OSLEC to build OSLEC as the echo canceller. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
Alan, I'm glad to see that you are able to run zaptel and OSLEC following my tweak! Some days ago I've sent to David Rowe a little patch that preserves the echo cancel status between calls. I'm using it since several weeks with my TDM400P home based PBX and I think that's a really effective solution. Unfortunately I can't test patches in all possible environments because I've only a single channel FXO. I think David is still testing the patch before releasing it on the official OSLEC repository. Thank you and best regards, Marco Signorini.> Hi all. > > The small tweak suggested by Marco Signorini did the trick. > > I have oslec running on my cloned x100p card and it is fantastic. We > have no more echo! * > > * Well, I am using a Linux Ubuntu Desktop with the Twinkle Soft SIP > phone and my audio device is the Polycom Communicator. Now the Polycom > was built mainly for Skype and they have considerable echo cancellation > technology built into their Windows *only* driver software. So it used > to be the cause of much echo unless I connected a headset to the socket > on the Communicator itself. > > However, with the OSLEC running I can now use the Polycom handsfree and > I hear almost zero echo (almost imperceptible). > > I will drop the author a note and suggest that someone who understands > this stuff, try and build a USB driver for devices like the Polycom > using the OSLEC technology... > > Thanks for the initial response Marco. > > And anyone who has echo problems with x100p or other analogue cards > should really give this a try. Most of the experiences I have read about > have been very positive. Mine also :-) > > Alan > > > -- > The way out is open! > http://www.theopensourcerer.com >
Hi Steve. What I did was to allocate one EC instance the first time a channel asks for it and reuse the same memory area for the same channel every time a new call is coming. The memory is then freed when the channel is unloaded. I've done this with my TDM400P in mind and I don't know what could be wrong in other setups. What I'm thinking is that, probably, the old EC should converge faster than a new one because the external conditions (even if different) are slightly similar. I'm open to every possible suggestion and solution (compatible with my setup and my spare time). Thank you and bye, Marco.> On 10/24/07, marcotasto <marcotasto at libero.it> wrote: > > > > Some days ago I've sent to David Rowe a little patch that preserves the > echo cancel > > status between calls. > > Surely this is only appropriate where you have a local analogue device > that is unchanging - If you retained the EC status between calls on a > trunk line (where the far end will be different for each call), the > chances are that it would be inappropriate. > > I assume you enable/disable this feature per-channel? Or perhaps I am > misunderstanding the feature you describe? > > Thanks, > Steve >