1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you had a PIAF Forum account in the vBulletin days, log in with your old credentials. Otherwise, sign up again and we'll get you back in business as soon as we can.
  3. A serious FreePBX vulnerability has been reported. Update your Framework Module immediately. Click here for details.

OSLEC support

Discussion in 'Wish List' started by lthown, Nov 16, 2007.

  1. lthown New Member

    I've been using it with 3 different production boxen for several months and love the results.
  2. cvschleich Member

    Please allow me to <ahem> echo this sentiment. ;)

    If someone could point us to an oslec patch against zaptel 1.4.7, that could be just as good.

  3. Titanous New Member

    I'd like to third this request.

    Maybe I'll work on a script if I get some time...
  4. cvschleich Member

    Don't even really need a script, it's really straightforward once someone has made a patch against zaptel 1.4.7. <subtle>Hint, Hint??</subtle>
  5. jdaustin New Member

  6. Alex728 Guru

    just done it - got there in the end but could do with a script for us linux newbies (or those of us who have migrated from Trixbox and are used to having the packages just delivered rather than recompiling from source)

    I managed to compile the modules as described on the rowetel site, but got caught out as although when you do insmod foo.ko it works then, when you restart the zaptel modules are picked up from elsewhere

    had me confused for a while as I was wondering why the system was reverting back to MG2 echo canceller...

    I found out in the end what was happening is that these modules are loaded up from

    /lib/modules/(some number which i think is the kernel version)/misc/

    so I copied the newly compiled modules here and also had to edit modules.dep to show oslec.ko as a dependency of zaptel.ko

    maybe there is a more elegant way of doing this but it worked in the end....

    is there a wiki or some place where we could put up "how to" guides like this?
  7. james Guru

    I think oslec is a bad trend. PIAF being source based allows for it to be easily added for those who feel the need but seriously when you get over a certain amount of channels it craps, I am not sure whats wrong with zaptels built in, if you need more you probably should go with HWEC. Echo has become such a buzz word prople dont even understand echo just that someone said that if they lick the bottom of the toilet it would make them happy. DUDE just cause everyone else is licking the toilet well whatever lick it if you want...
  8. Alex728 Guru

    I understand that OSLEC or any other software echo canceller will obviously have performance issues with a large amount of channels, (for instance if I was deploying a system with a multi-channel E1 trunk I'd certainly use hardware EC!) I accept from an engineering standpoint tried, tested and solid hardware will always have the edge.

    However, I disagree with the assertion that OSLEC is a bad trend or that those deploying it "do not understand echo".

    My background also includes traditional telephony and electronics and the professional broadcast industry, as well as 20+ years of experience, plus (perhaps most important) a constant willingness to learn. I wouldn't have bothered with the extra effort of revisiting skills from college days to install and compile OSLEC were there not a gain in doing so.

    I tested both MG2 and OSLEC with both Trixbox and PIaF and there wasn't much difference, but OSLEC had the edge as it converges a lot quicker on my system.

    No, it isn't 100% perfect, but Dave Rowe admits this on his own website (and even the developer of MG2 says OSLEC is the better performer)

    I have had the system in live test for some weeks now, have told users to listen out for and report objectionable levels of echo, and have had no complaints whatsoever. (There is far less echo on this system than some mobile phone calls in this country, or on other VOIP-based phone systems provided by British Telecom!)

    if you were any other random person on here I wouldn't have made this following comment, but because you are representing your brand on here it does sound like you are a bit cross as some other chap has developed a product for "free" which competes with a product your company makes, even if its not 100% as good.

    But thats the way it is with open source and a free market, and its a price sensitive market these days. BTW I'm not a reseller or system integrator trying to screw the last penny out of my customers by skimping on the system, I'm an in-house IT/telecoms engineer for a small business looking for best value with tight budgets. Even the current £100-150 or so price premium for hardware echo cancel is a lot of money to a small business, especially in the early stages of a project.

    I'm also dealing with a business culture in a rural area of a country where we only got broadband a couple years ago, and it wasn't so long ago there were no DTMF phones, mobiles were horrendously expensive and people queued up outside red telephone boxes...

    My office didn't even have a LAN until I arrived, and every bit of spend on technology has to be justified.

    This is also a broad church of users - not everyone has big bucks and there are a lot of smalller SOHO users with only 1-4 PSTN lines for whom OSLEC seems to be working very well, or well enough. If you don't want to deal with these "small fish" or are unhappy they aren't spending the few extra bucks to buy your product then fair enough (and I accept the Rhino analogue cards are quite a good price for what you get!), but don't berate people (who may even one day be potential customers!) for their own informed choices...
  9. james Guru

    If you read my post on here or any other forum and/or interact with me on irc or in person you will know my opinions do not come from a competitor standpoint. I do work for a manufacturer who tries to be heavily involved in the community. I come from working with many open projects including Ubuntu. When asked I do not pimp out any one distro that is why you will see me everywhere. I do believe the trix folks, piaf, elastix etc all have their place and they get recommended based on the situation and user. I could frankly care less if you use HWEC or SWEC. I often tell folks to avoid HWEC if they don't need it. I come from a family of legitimate mechanics. Like them I believe the best option is to keep an open mind and work on all products. Just cause you work at ford doesn't mean you shouldn't know how to fix a toyota. I am a techie not a sales person. Like the mechanics in my family I don't believe in throwing unneeded parts weather software or hardware at ghosts. If someone doesn't have echo they shouldn't use any EC . Weather paid for or free. If you have mild echo and a small setup you should use the stuff built in as it is designed in to the software. I also understand you should have options so you should be free to add OSLEC if you feel the need. You should not be forced however to use OSLEC if you don't want or need it. It is allot easier to add OSLEC then remove it. When you force people to do it your way rather than allowing them to do it if they want your no better than those other guys. So I have no objections to an install-oslec script. I have no objections to the oslec project or mr rowe. I do object to software being forced on people.
    I was a linux guy before I was an asterisk guy. I have friends in the FSF and we dont debate :) Just because a manufacturer tag is attached don't assume evil. We work with many projects. I have civil conversations with the digium boys daily this isn't a cut throat business. I hope it never gets to that (at least on the hardware)
  10. darmock PIAF Developer

    :iagree: with James. He is one of the better resource persons out there for stuff. I can't say I have ever heard him "pimping" his companies stuff. The install-oslec is on my drawing boards however this is not a script I will release without an uninstall-oslec script.

    As James mentioned it is harder to take out than install and I can just hear people whining "it ate my machine and it's Tom's fault" :mad5: Thus this won't be coming out till the uninstall and cleanup portion is ready.

    In the meantime it appears we have a forum that contains a group of "hearty individualists". This generally is the best type of thing for a growing community and I must say our forums are much better than "some" I used to contribute to. :eek: Let's keep it down to a dull roar please.

    BTW thanks James for the code snippets from the other forum post I will be looking at it tonight.

  11. Alex728 Guru

    fair enough, but AFAIK there seems to be only one other distro which is (or was?) appearing to "force" people to use OSLEC and its not this one!

    if you wanted to switch off echo cancelling altogether simply setting "echocancel=no" in zapata.conf quickly does this (just tried it!)

    Although I can't think of any place round here where you could get away with this other than the quaint country cottages on the same street as the local Telephone Exchange :rolleyes:

    I haven't delved that closely but (at least for those with a bit of coding knowledge) there still appears to be a lot of choice to use other echo cancellers if you so wish by making the relevant alterations in the source code.

    Although I haven't got any reason to do so as yet I would think even if you wanted to go back to MG2 for whatever reason reloading the tarball for zaptel and recompiling with clean (unpatched) source should do the trick, though there may of course be other issues and a script would be a good thing to have

    What we do all need then in the meantime is some sort of document/thread of exactly what echo cancellers are available in Asterisk/PiAF, how to compile/install them if desired and any caveats with regard to using them...
  12. drowe67 New Member

    Hi Guys,

    It's David Rowe here, the maintainer of Oslec. Thanks to those who have tried Oslec and for your kind words.

    I agree that the installation process needs work, it's a bit complex for many people and an install/uninstall script is a good idea just in case it doesn't work out.

    Re the CPU load it doesn't seem to be an issue on modern x86 boxes - e.g. I have reports of people using Oslec on dual E1s. It seems to scale happily between humble X100 cards and E1/T1s. If it needs to run faster we can always do a little software optimisation.

    I have not had a single complaint of it being "too slow" or running out of channels, although I guess it's possible if you add enough spans.

    Even with a low end modern x86 box you just have so many MIPs available that running Oslec consumes negligable CPU.

    BTW if anyone has had problems with Oslec and would like to work with me pls email me. Inside Oslec is the ability to remotely sample echo problems and I use this data to improve Oslec.

    If you would like to read a little more about echo cancellation I have a series of blog posts that explains it:



  13. james Guru

    You know now that Mr Rowe has graced the forums Maybe he can throw in a skeliton script or give some tips on the automation of add/remove. I think if to and david put their heads together a script may come pretty quick
  14. tomsyr Guru

    OSLEC for a T1?

    I seem to remember that when this was first released, it was not reccommended for T1's, and that you should just go with HWEC.
    Has this changed? The performance with 4 port FXO cards have been excellent.
    I will be rebuilding my PBX from a more vanilla verison of Asterisk to PiaF after the training class in Febuary. It would be great to use OSLEC since I already have a T1 card w/o the EC.
    While I have 23 channels coming in, it rarely peaks over 12 channels at one time. If we were always near capacity, I would be more concerned about the performance.
  15. drowe67 New Member

    Hi Tom,

    Well I must say I was surprised when people started using Oslec for T1's but I guess that's just how open source goes - people experiment :)

    I have some notes on performance here:

    If the MMX optimisations are enabled, Oslec uses about 20 MIPs/channel. So with 24 channels thats about 480 MIPs, or about 500MHz of CPU. So if you have a 2-3GHz CPU its still a small fraction of your system's capability.

    With 4-8 channel analog cards you can see that the amount of CPU used is trivial on even a low end modern CPU.

    BTW most of Oslec is in vanilla C, with a little more MMX assembler we could halve those numbers.


  16. jdaustin New Member

    Oslec makes a huge difference; it should be part of the zaptel core.
    I wish it were more straight forward to install and that PIAF update-source didn't screw it up ;)
    Hardware echo cancellation is way more expensive than it should be.
  17. wardmundy Nerd Uno

    Maybe we wouldn't screw it up if someone posted a bit more information about the problem and assisted in resolving it. :nopity:
  18. jdaustin New Member

  19. jroper Guru

    Dear JDAustin

    You are running into one of the main problems of running a Distro like this.

    The problem is striking a balance between making it easy for people without the Linux skills, and flexible enough for those who know what they are doing to be able to do stuff.

    Oslec would be undesirable to include as standard, because it may cause havoc with hardware EC, and say HPEC if installed on the same machine.

    The aim of this Distro is to give you choice, and to get the best out of it, you need to learn it, which presumably you now have. I doubt whether you will be doing update source again, when you have Oslec compiled, rather you will know to update zaptel by hand.

  20. jdaustin New Member

    There are a couple of gotchas that they don't document.
    You have to copy the /usr/src/oslec/kernel/oslec.ko to /lib/modules/<kernelversion>/misc/oslec.ko
    and add
    to the zaptel line in /lib/modules/<kernel version>/modules.dep

    /etc/init.d/asterisk stop
    /etc/init.d/zaptel stop
    amportal stop
    cd /usr/src
    svn co http://svn.astfin.org/software/oslec/trunk/ oslec
    cd oslec
    cp kernel/oslec.ko /lib/modules/`uname -r`/misc/.
    insmod kernel/oslec.ko
    cd ../zaptel
    cp /usr/src/oslec/kernel/Module.symvers .
    patch -p1 < ../oslec/kernel/../oslec/kernel/zaptel-
    make install
    grep /lib/modules/`uname -r`/misc/zaptel.ko: /lib/modules/`uname -r`/modules.dep
    #if oslec.ko isn't shown add it to
    /lib/modules/`uname -r`/modules.dep as a dependency for zaptel.

Share This Page