Hi Craig Arkadi on http://www.readytechnology.co.uk web does static linking by defining cpu type in Makefile. The outcome is a bunch of .so each for a specific processor. I think it's a good way to add to Makefile make targets like
make pentium4 make pentium4-sse3 and those who build themselves can decide on what they need. regards Franz ----- Original Message ----- From: "Craig Guy" <[EMAIL PROTECTED]> To: "'OpenPBX.org Developers Mailing List'" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Sunday, April 29, 2007 12:37 PM Subject: Re: [Openpbx-dev] G729 Licensing thread > Hi Jac, > > No problem, I had originally spoken to Readytechnology and asked if he had > a > version for OpenPBX and IPP 5. He replied that he was holding out for > someone to fund a codec based on IPP5, and there is certainly nothing > wrong > with that position. I replied that if ZettaServe did develop an IPP5 > codec > we would send him a copy of our code, which we will do shortly. I ported > his IPP 4.1 to OpenPBX, but was then unable to determine from the Intel > website if licenses for IPP 4.1 were still available. I then looked at > porting his codec to IPP5 but it was determined that we were better off > starting from scratch, which we did. We then also took the opportunity to > see if the timer changes in OpenPBX would allow the support of annex b > which > in fact they do. The diff file for OpenPBX enables support of annex b - > further details regarding the diff file are available at the ZettaServe > page > at http://www.zettaserve.com/default.asp?catid=78. Again, I believe that > annex b support is significant as I have seen documentation implying that > it > can triple the amount of calls per given bandwidth - see > http://www.connect802.com/voip_bandwidth.php and calculate for g729 with > and > without VAD enabled. > > We are going to add g723.1 very shortly now that we have pretty much > sorted > out g729 - my developer assures me that adding g723.1 support is 'trivial' > using the IPP libraries. > > The code currently on the website will compile optimised static and shared > libraries versions of the codec based on the makefile selection. Any > version downloaded earlier than about 48 hours ago does not produce > optimised static binaries. For the benefit of others reading this thread, > the transcoding times using the optimised libraries have improved > significantly, by approx 40% across the board (eg 12ms to 7ms on a P4 > 3.0Ghz). The static version (default) will determine the cpu at compile > time and add the appropriate libraries to the binary. The shared library > version will determine the cpu at runtime and load as appropriate, > although > it requires the full intel redistributable to be installed and in the > ld.so.conf search path in order to work. > > Craig > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jac Barben > Sent: Sunday, 29 April 2007 1:28 AM > To: 'OpenPBX.org Developers Mailing List' > Cc: [email protected] > Subject: Re: [Openpbx-dev] G729 Licensing thread > > Since we know what the licensing will cost and that there is enough > "interest" to support the costs, what remains is to: > 1. Select a technology > 2. Figure out how to control licensing > 3. Build a legal structure that will satisfy Sipro, Lucent, NEC and Nokia > > I have my lawyers investigating #3 and I'm currently tackling #1. I'm > pretty sure we need to figure out which technology we're going to use > before we land on how to control license distribution. > > Below are the solutions I've tested so far. My testing has not been > particularly scientific. I've merely caused the system to load up with > "live" calls, including myself in one or more of the calls (listening > for quality), and monitoring CPU utilization (looking for an upper limit > of 70% on a single processor AMD duo core). Relative to transcoding, > most of the calls were g.711/g.729. > > ZettaServe solution (thank you Craig): > This is an Intel IPP 5 based solution. > It clearly works. > I've found no incompatibilities. > I was able to process 200 simultaneous transcoded calls. > > ReadyTechnology solutions (thank you Sam): > This is an Intel IPP 4 based solution. > It works. > It also has g.723 properties that were interesting. > I was able to get 163 simultaneous g.729 transcoded calls. > I was able to get 144 simulatneous g.723 transcoded calls > (g.729/g.723). > > If there is more "scientific" approach y'all would like to see, please > advise your parameters and I'll see what I can do to report on them. > > I would like to "test" other solutions as well. There have been several > "off-line" posts suggesting various solutions. While options are > good... I really want to select the "best-of-breed". > > _______________________________________________ > Openpbx-dev mailing list > [EMAIL PROTECTED] > http://lists.openpbx.org/mailman/listinfo/openpbx-dev > > _______________________________________________ > Openpbx-dev mailing list > [EMAIL PROTECTED] > http://lists.openpbx.org/mailman/listinfo/openpbx-dev _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
