Free Telephony Project

Hey that's great Tzafrir - and thank YOU for your efforts in packaging
Oslec up :-)

Cheers,

David

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 (1.4.10.1~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
http://www.rowetel.com/ucasterisk

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!

Cheers,

David

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 (1.4.10.1~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
http://www.rowetel.com/ucasterisk

David,

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
asterisk.
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
http://www.digital-opsis.com
 

> -----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!
> 
> Cheers,
> 
> David
> 
> 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 (1.4.10.1~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 
> http://www.rowetel.com/ucasterisk
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> freetel-oslec mailing list
> freetel-oslec@...
> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
>

David Rowe wrote:
> 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:
> 
<snip />

I'm not a software engineer and so don't understand just how hard or not 
this would be to achieve...

I have a Polycom CS100 handsfree USB speakerphone.

Polycom provide a driver for Winblows only (and not even Vista yet) that 
contains much of their EC and noise suppression features. So even though 
the unit works on Linux, I get pretty bad echo and the levels 
(especially the mic-in) are hard to get right.

My business partner and I thought it would be a great idea to "embed" an 
OSLEC type function in the audio stream on linux between the hardware 
and the ALSA/Pulse Audio sound system to provide what other 
manufacturers will not.

This could then be used not just with the Polycom but any audio device 
that required EC.

Is this a reasonable idea or am I completely barking...

Cheers and thanks again David.

Alan
-- 
The way out is open!
http://www.theopensourcerer.com

Dear Stelios,

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 :)

Cheers,

Michael

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
line.
On Fri, May 16, 2008 at 4:52 PM, Stelios Koroneos
<skoroneos@...> wrote:
> David,
>
> 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
> asterisk.
> 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
> http://www.digital-opsis.com
>
>
>> -----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!
>>
>> Cheers,
>>
>> David
>>
>> 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 (1.4.10.1~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
>> http://www.rowetel.com/ucasterisk
>>
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> freetel-oslec mailing list
>> freetel-oslec@...
>> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> freetel-oslec mailing list
> freetel-oslec@...
> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
>

>  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.  

Have you seen zaptel doing that ? That is what I was reffering to.

> 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.

Correct, there will be an increased latency, but then it will be offset by
the better scalling that can be achieved 
Having a kernel process slowing down your entire system, is not exactly the
best thing you can hope for

> 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...

I don't have to guess I know ;)
David mentioned that OSLEC fails just a few of the G.168 tests, so getting
to pass all of them would be a first good step.
Official test (aka paid ones) could be done at a later stage,probably by
some entity that wants to use this OSLEC 'feature'


Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com

On Fri, May 16, 2008 at 11:57:04AM +0300, Stelios Koroneos wrote:
> >  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.  
> 
> Have you seen zaptel doing that ? That is what I was reffering to.

Zaptel drivers do most of their work in interrupts. Make interrupts
spread between different CPUs, and the load is spread. This is not
always a good idea (generally it is not always a good idea to be smarter
than the schedualer). Recall that echo cancelling is done on the recieve
path.

> 
> > 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.
> 
> Correct, there will be an increased latency, but then it will be offset by
> the better scalling that can be achieved 
> Having a kernel process slowing down your entire system, is not exactly the
> best thing you can hope for

If this requires a longer trail for the echo canceller, then you achived
nothing.

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen@...
+972-50-7952406           mailto:tzafrir.cohen@...
http://www.xorcom.com  iax:guest@...

Hi Alan,

> My business partner and I thought it would be a great idea to "embed" an 
> OSLEC type function in the audio stream on linux between the hardware 
> and the ALSA/Pulse Audio sound system to provide what other 
> manufacturers will not.

That is a good idea Alan.  Actually the celliax.org guys have similar
objectives for Oslec, they use USB sound cards to talk to mobile phones.

The real key here is to make sure there is a fixed delay between the tx
and rx signals, Oslec needs this to cancel echo OK.  This is generally
not guaranteed with generic sound drivers.  So a rework of some of the
USB sound driver code may also be required.

Thanks for your input Alan.....

Cheers,

David

> This could then be used not just with the Polycom but any audio device 
> that required EC.
> 
> Is this a reasonable idea or am I completely barking...
> 
> Cheers and thanks again David.
> 
> Alan
-- 
Free Telephony Project
open embedded IP-PBX hardware and software
http://www.rowetel.com/ucasterisk

Hi Guys,

> 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...

Actually I wonder how many people just print "G.168" on their brochures;
e.g. the SPA3000 actually says that it has "G.168 echo cancellation".
But then again, maybe it's possible to pass the G.168 tests but still
have echo problems for practical reasons.  I found this during Oslec
development, practical problems like DC offset and low frequency
response arose when it was tested with X100P cards and soft-phones,
despite passing most of the G.168 tests.

> OSLEC on a DSP sounds like fun, and would be an excellent way to
> convince Telcos to contribute to your salary :)

Well I'd be happy to help out with the implementation if some one wants
to sponsor this one.....

Cheers,

David

> 
> Cheers,
> 
> Michael
> 
> 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
> line.
> On Fri, May 16, 2008 at 4:52 PM, Stelios Koroneos
> <skoroneos@...> wrote:
> > David,
> >
> > 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
> > asterisk.
> > 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
> > http://www.digital-opsis.com
> >
> >
> >> -----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!
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> 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 (1.4.10.1~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
> >> http://www.rowetel.com/ucasterisk
> >>
> >>
> >> --------------------------------------------------------------
> >> -----------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2008.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> freetel-oslec mailing list
> >> freetel-oslec@...
> >> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
> >>
> >
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > freetel-oslec mailing list
> > freetel-oslec@...
> > https://lists.sourceforge.net/lists/listinfo/freetel-oslec
> >
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> freetel-oslec mailing list
> freetel-oslec@...
> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
-- 
Free Telephony Project
open embedded IP-PBX hardware and software
http://www.rowetel.com/ucasterisk

I'm about to start the second stage of live testing on my PiAF system with
OSLEC. Currently there are 3 zap channels on the card but only one is in
regular use

Eventually all 3 will be in use often at the same time

I've done some live testing with OSLEC and 3 calls at once but after some
advice about how many channels a 2.0GHZ Celeron based system with 768M RAM
can handle... 

TBH I suspect that its not even going to make much difference but just after
a bit of reassurance that OSLEC will handle this simultaneous load,
especially after seeing a post on PiaF forum claiming that Digiums HPEC
caused random lockups! 

Regards

Alex

Hi Alex,

> I'm about to start the second stage of live testing on my PiAF system with
> OSLEC. Currently there are 3 zap channels on the card but only one is in
> regular use
> 
> Eventually all 3 will be in use often at the same time

So PBX-in-a-Flash on an x86?  Three channels wont be noticeable.

> I've done some live testing with OSLEC and 3 calls at once but after some
> advice about how many channels a 2.0GHZ Celeron based system with 768M RAM
> can handle... 

There is a program user/speedtest that will tell you.  A couple of E1
spans probably.

Tzafrir, Re the Blackfin I run 8 analog channels of Oslec OK.  Need to
do a little more work there to stop the Blackfin choking at high CPU
loads - its more a cache issues than MIPs.

Cheers,

David

> TBH I suspect that its not even going to make much difference but just after
> a bit of reassurance that OSLEC will handle this simultaneous load,
> especially after seeing a post on PiaF forum claiming that Digiums HPEC
> caused random lockups! 
> 
> Regards
> 
> Alex
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> freetel-oslec mailing list
> freetel-oslec@...
> https://lists.sourceforge.net/lists/listinfo/freetel-oslec
-- 
Free Telephony Project
open embedded IP-PBX hardware and software
http://www.rowetel.com/ucasterisk