On Fri, 8 Apr 2005 17:17:31 -0700, you wrote:
>>Out of curiosity, have you used the HSS interface using the
>> intel access library to do PSTN interfacing through the SiLabs SLIC?
>
>Ah, there's a rub. The intel access library has a non-gpl compatible
>license, and only works on the 2.4 kernel. It's a bletcherous port
>from a vxworks product, without a clean interface to userspace, and it
>is well despised (see item #2 in
>http://www.arm.linux.org.uk/mailinglists/faq.php).
>
>Not using it is as problematic as using it.
Interesting. vxWorks was supported first so the whole user / kernel
breakdown was an after thought. But most customers try to do as much
as possible in kernel space anyway.
>Given that asterisk already had some support for these slics we
>thought about bypassing the access library and porting the zaptel
>stuff over.
The access library encapsulates the interface to the NPE firmware
which does some of the TDM work for you such as aggregating timeslots
into 10ms samples without having to use any XScale cycles.
>At one point, we had trinity convergence's phone gateway software
>talking to the slics and talking to asterisk via localhost. Trinity's
>sip support was awfully primitive, and the phone quality nowhere near
>as a good as a dedicated sip phone...
>
>In the final evaluation we decided that everybody else was thinking
>that the analog->voip port market was going to explode, and we didn't
>need to be part of the debris. So we dropped the slics, put a big (but
>optional) memory mapped FPGA on the board, brought out the HSS port
>and 60 other pins, and connected the FPGA up to another board... to
>do something really neat that hasn't been done before that I can't
>talk about in this forum, yet.
>
>> Also, have you used DSR to do codec accelerations or are you just
>> letting Asterisk do it native?
>
>See aformentioned licencing issue.
>
>Just letting asterisk do it native. The Xscale is one of the fastest
>embedded chips out there - aside from needing to one day soon replace
>the floating point routines in the tone generator and maybe in plc.c,
>it keeps up with a lot of sip/iax phones at our desired level of
>loading (which is less than a T1) on the gsm, ulaw and slinear codecs.
>The arm-integer only version of speex 1.1.7 is eating about 10% of cpu
>going to slinear. G726 is pretty good, but I haven't measured it. I'm
>told there's an int only reference stack for G729...
>
>(I keep thinking that in higher loaded situations the real issue is
>not the codec path but the threading overhead of linuxthreads vs nptl.
>anybody have hard data on asterisk on linuxthreads vs nptl)
>
>Now, if we were to shoot for 4T1s off the board, and willing to shift
>a lot more work to kernel space than we currently do, and cross
>license the code so that both Intel and Digium would be happy... to
>enter the really small pbx market as say a competitor to panasonic -
>with like a ton of funding - then using the full access library and
>the DSR routines becomes more appealing.
>
>If intel would GPL those libs, tho' - they would make a lot of people
>happy.
It would make Intel happy too. But Intel has key customers who will
not use the libraries (or buy the chips) if doing so forces them to
open source their proprietary code by linking it against Intel's GPL'd
code.
There was an initiative to do a dual license access library - I must
check its status to see if it is generally available.
This is unlikely to happen for DSR though - last I heard it was set to
remain closed.
--
Mark Burkley ([EMAIL PROTECTED])
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
