You appear to be misinformed in several ways, first and foremost of
which is this idea that kernel drivers only get to run on one CPU. I
suggest you take a look at the md_raid set of modules, and tell me how
they start a task for each md device they are attached to. I would
suggest to you that moving the echo canceler to userspace would only
serve to increase latency, due to the userspace-kernelspace context
switch time. Of course, you also have to copy the samples out to
userspace, though that's kind of trivial for the amount of data per
channel we're talking about.
Anyway, making it G.168 compliant is likely to be very costly,
because, of course, noone's going to believe you unless someone else
does the testing. Guess how much they charge...
The other thing about it all, of course, is "native bridging". Native
bridging becomes the same thing as non-native bridging if you move the
echo cancellation into user space.
But yeah, I suspect four E1 echo canceling would remove any doubts
about software EC - though I suspect you're already there if you use a
dual-CPU quad core machine ;)
OSLEC on a DSP sounds like fun, and would be an excellent way to
convince Telcos to contribute to your salary :)
Finally, I'm not sure anyone else has attempted RTP echo canceling...
The usual place to do it is on the end of your potentially echoing
On Fri, May 16, 2008 at 4:52 PM, Stelios Koroneos
> First of all thanks for all the good work put into OSLEC
> It would be good from a marketing point, if OSLEC could be made G.168
> compliant and also faster so it can support up to 4 PRI channels
> Unfortunatelly the zaptel driver design has a lot of drawbacks and I am not
> 100% sure than spending so much of the cpu time in a kernel driver is a very
> good idea.
> This is probably why the hardware echo cancellers are very popular in
> So, taking into account the need you mention for RTP echo cancelling (IP) I
> was wondering if OLSEC could be moved partially from kernel space to
> userspace, so it could scale better and also handle RTP echo cancelling.
> (For those who are not aware, kernel drivers use only one cpu regardless of
> how many you have in your system)
> Probably that would also require an additional zaptel module, something
> similar to the zttranscode driver.
> One of the ideas we had is to somehow put a 'timming stamp' on the zaptel
> 'chunks' the moment they arrive, so it would be easier for a userspace
> program to process them, but never found time to work on something like that
> For me what OSLEC has proved once again is that asterisk although a great
> piece of software, has design flaws (or issues) that clearly show up when
> you scale your system either up (multiple pri's for example) or down
> (embedded appliances)
> Stelios S. Koroneos
> Digital OPSiS - Embedded Intelligence
>> -----Original Message-----
>> From: freetel-oslec-bounces@...
>> [mailto:freetel-oslec-bounces@...] On
>> Behalf Of David Rowe
>> Sent: Friday, May 16, 2008 2:56 AM
>> To: Open Source Line Echo Canceller
>> Subject: [freetel-oslec] OSLEC road map
>> Hi list,
>> I would be interested in all your thoughts for an Oslec
>> roadmap. I don't have much idea myself, but here are some
>> initial thoughts:
>> 1/ Make it easy to install for anyone. This probably means a
>> way to lose the Zaptel patching step, as discussed earlier this week.
>> 2/ Market it a bit more. I am never sure how many people are
>> actually aware of Oslec or using it - I get very little
>> feedback. But then again I never email Linus when Linux works....
>> 3/ The algorithm could be improved for example (i) faster convergence
>> (ii) working with poorer lines (ii) tails longer than 32ms.
>> Although I feel (iii) is unnecessary right now. Experience
>> has shown that the need for 128ms echo can tails is marketing
>> foo, at least in our domain (FXO/FXS lines for voice
>> connected to IP-PBXes).
>> 4/ IP echo cancellation. For example cancelling echo at the
>> remote end of an IP link:
>> SIP phone - Oslec - Asterisk - Internet - remote FXO device with echo
>> A few people have asked for this. The challenge is that
>> there tends to be jitter (variable delay) in the tx and rx
>> signals which is hell on echo cancellers.
>> 5/ The algorithm could be made faster. This is an interesting one.
>> With some MMX and/or SIMD assembler work in a few functions
>> Oslec it could run much faster. If we can run Oslec
>> comfortably with a quad E1 then I would suggest "hardware"
>> echo cancellation could be made obsolete.
>> That is a controversial statement I know, given (a) how the
>> "myth" of hardware echo cancellation is entrenched and (b)
>> that perpetrating this myth is how many companies make their
>> money in the Asterisk world :-)
>> 6/ Oslec on a DSP. Oslec could be ported to a DSP chip (like the
>> Blackfin) to make a $10 "hardware" echo canceller, e.g. as a
>> co-processor for a T1 or E1 PCI card. Similar silicon costs
>> up to $100/chip at the moment.
>> Comments invited!
>> On Thu, 2008-05-15 at 16:12 +0300, Tzafrir Cohen wrote:
>> > Hi
>> > A new version of the package Zaptel has just been uploaded
>> to Debian
>> > Unstable (22.214.171.124~dfsg-1). It has finally become the default echo
>> > canceller in this version.
>> > So once again, thank David for making this possible.
>> Free Telephony Project
>> open embedded IP-PBX hardware and software
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> freetel-oslec mailing list
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> freetel-oslec mailing list