From the site: Oslec is an open source high performance line echo canceller. When used with Asterisk it works well on lines where the built-in Zaptel echo canceller fails. No tweaks like rxgain/txgain or fxotrain are required. Oslec is supplied as GPL licensed C source code and is free as in speech. In my opinion it performs better (quality wise) than any of the other echo cancelers that I've tried (all the soft ones, sec, sec2, mg2, kb1 and jpah, HPEC wasn't tested as I don't have a license, as well as the VPMADT HW echo can). CPU wise it's obviously heavier than HW echo can. Reproducible: Always Steps to Reproduce:
Created attachment 212802 [details, diff] dahdi-2.2.0.2.ebuild-osclec.patch Patch to apply against current in-tree dahdi-2.2.0.2.ebuild file in order to get oslec support.
(In reply to comment #1) > Created an attachment (id=212802) [details] > dahdi-2.2.0.2.ebuild-osclec.patch > > Patch to apply against current in-tree dahdi-2.2.0.2.ebuild file in order to > get oslec support. > This worked for me, when CONFIG_STAGING=y and CONFIG_ECHO=m. # lsmod | grep oslec dahdi_echocan_oslec 1455 0 echo 4254 1 dahdi_echocan_oslec dahdi 181397 9 dahdi_echocan_oslec,wctdm,dahdi_dummy # uname -r 2.6.31.6-grsec2.1.14-vs2.3.0.36.24 # gcc -v Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/specs Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.4/work/gcc-4.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --with-arch=i686 --enable-languages=c,c++,treelang --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.4 p1.0, pie-10.1.5' Thread model: posix gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) # emerge --info Portage 2.1.6.13 (hardened/linux/x86/10.0, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.31.6-grsec2.1.14-vs2.3.0.36.24 i686) ================================================================= System uname: Linux-2.6.31.6-grsec2.1.14-vs2.3.0.36.24-i686-Intel-R-_Xeon-TM-_CPU_3.20GHz-with-glibc2.0 Timestamp of tree: Sun, 13 Dec 2009 23:30:02 +0000 app-shells/bash: 4.0_p28 dev-lang/python: 2.5.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=i686 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.exetel.com.au/pub/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/layman/voip /usr/portage/layman /usr/local/portage-idb" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl berkdb bzip2 cli cracklib crypt cups cxx dri gdbm gnome gpm gtk hardened iconv jpeg modules mudflap ncurses nls nptl nptlonly openmp pam pcre perl pic ppds pppd python readline reflection session spl ssl sysfs tcpd tiff urandom x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="vesa mach64 mga r128 radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hmm, is there a simple way to add checks for those options in my patch? In other words, I would like to enhance the patch to issue an efail with "You require CONFIG_STAGING=y and CONFIG_ECHO=m in your kernel configuration in order to compile oslec support". These options are (as you have found) required (I should have mentioned that but have forgotten since these were already set on my system since they became available).
Created attachment 213446 [details, diff] dahdi-2.2.0.2.ebuild-osclec.patch Updated to add a check for CONFIG_ECHO (CONFIG_STAGING will go away eventually and is required to get to CONFIG_ECHO). This check is based on the checks in the ppp ebuild, so I hope they're good. They check out in my testing.
(In reply to comment #4) > Created an attachment (id=213446) [details] > dahdi-2.2.0.2.ebuild-osclec.patch > > Updated to add a check for CONFIG_ECHO (CONFIG_STAGING will go away eventually > and is required to get to CONFIG_ECHO). This check is based on the checks in > the ppp ebuild, so I hope they're good. They check out in my testing. > Thanks for doing this. There was one problem I caught (a mkdir needs a "-p"), and I added a massive diff to a different branch which I'll post it here for the curious, since it applies cleanly. Also, I added some depmod stuff, since the problem I was having loading the module -- which looks a LOT like this: https://issues.asterisk.org/view.php?id=14995 --went away when I ran depmod... (IDK if the suggestion there applies, really, but I did that too.)
Created attachment 215452 [details, diff] Another patch for oslec with some fixes (maybe.. WFM)
Created attachment 215453 [details, diff] An option to patch... from a branch [1] [1] http://www.mail-archive.com/asterisk-users@lists.digium.com/msg234918.html
None of that seems to be OSLEC related, can you please open a diffirent bug report for adding support for other cards to the dahdi ebuild instead of the oslec one? I'm personally very interested in some of that support (HFS for one) but that should be on a different thread. Admins - is it possible to split these two bugs or what can we do?
(In reply to comment #8) > None of that seems to be OSLEC related, You must mean something specific, perhaps something I posted as an attachment? I'll assume you mean the diff from tzafir branch. > can you please open a diffirent bug > report for adding support for other cards to the dahdi ebuild instead of the > oslec one? For me, I want OSLEC in my Asterisk mix. I don't care how, as long as it's not involving my direct input at build time. Just trying to get to a point where it works. FWIW, no one mentioned an oslec ebuild here. Not sure why you did [see below]. > > I'm personally very interested in some of that support (HFS for one) but that > should be on a different thread. I *didn't look* at the patch I posted any more than to get it applied cleanly to the tarball and see it built oslec. I think the problem I encountered at my first effort had mostly to do with, perhaps, a missing 'depmod' call at the end of the DAHDI ebuild, and nothing to do with any new or different code for dahdi. The symptom BTW is well described here: https://issues.asterisk.org/view.php?id=14995 (is a Gentoo-specific issue.) Anyway, the point is that OSLEC is superior to either mg2 or hpec and is free. So, should be, probably, the default Gentoo packages with the DAHDI ebuild, IMO. Or, at the least, it should be a viable (build with use flag enabled) option. > Admins - is it possible to split these two > bugs or what can we do? > If you saw something that interests you in the code I cobbled together, why not open a bug? (FWIW, I posted the diff here *by request*, as it seems harmless, and for all I know, wholly unrelated.) Just to be clear, I'm not asking for anything beyond "net-misc/dahdi - oslec (echocan) support".
(In reply to comment #9) > (In reply to comment #8) > > None of that seems to be OSLEC related, > > You must mean something specific, perhaps something I posted as an attachment? > I'll assume you mean the diff from tzafir branch. Yes I do. I've read the patch. Or most of it. It adds support for other DAHDI cards. If you're telling me that's coming from the tzafrir branch and it's a straight diff from his branch then I back the patch. However: > > can you please open a diffirent bug > > report for adding support for other cards to the dahdi ebuild instead of the > > oslec one? > > For me, I want OSLEC in my Asterisk mix. I don't care how, as long as it's not > involving my direct input at build time. Just trying to get to a point where it > works. > > FWIW, no one mentioned an oslec ebuild here. Not sure why you did [see below]. Actually, the subject of the bug is "net-misc/dahdi - oslec (echocan) support" - note the word oslec. > If you saw something that interests you in the code I cobbled together, why not > open a bug? (FWIW, I posted the diff here *by request*, as it seems harmless, > and for all I know, wholly unrelated.) Keyword: unrelated. Yet you decided to high-jack a bug that's for something else. I fully back your suggested changes, but what you've told me here indicates that you should open two separate bugs: 1. For the tzafrir patch (please rather call it "dahdi-tzafrir-branch.patch" rather than dahdi_linux_extra.diff - it's more descriptive). 2. One for the depmod issue. Neither of these two issues has anything to do with oslec. > Just to be clear, I'm not asking for anything beyond "net-misc/dahdi - oslec > (echocan) support". Yes, you are. The proposed patch and depmod issue should be logged separately, even if you do end up adding yourself as a Cc to this bug. Additionally, I suspect the ECHO option that the patch adds unconditionally may very well conflict with the in-kernel ECHO config option. Just to be clear: I have absolutely no objection to the patch in principle (may need some cleanup and I'll be willing to test for you), nor to the depmod issue, however, they should both be logged in separate bugs.
Filed two new bugs for the non-oslec issues mentioned in this report: bug #302313 - depmod issue bug #215453 - the tzafrir patch
Wrong bug # in previous comment, secondary bug is bug #302316
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > None of that seems to be OSLEC related, > > [...] > Just to be clear: I have absolutely no objection to the patch in principle > (may need some cleanup and I'll be willing to test for you), nor to the depmod > issue, however, they should both be logged in separate bugs. > Okay, I think the issue is that the patch was not needed, just the changes to the ebuild. Since we're a bit past this version now, I'll just put the diff to latest version. Maybe you can wrap it up into the next ebuild for dahdi.
Created attachment 225787 [details, diff] patch to provide oslec echocan This also bumps to the latest version. See bug 302874 for any extra files, like patches missing.
+*dahdi-2.2.1.1 (13 Apr 2010) + + 13 Apr 2010; <chainsaw@gentoo.org> +dahdi-2.2.1.1.ebuild: + Version bump, incorporating patches, bug reports, suggestions & other + helpful input from Stefan Flemming, Michael Higgins, Oliver Jaksch, Jaco + Kroon, Kerin "kerframil" Millar & Diego E. "Flameeyes" Pettenò. Closes + bugs #296637, #302316, #302874, #305533, #308099 & #308467.
