Hi Craig My opinion about "forcing a specific codec module as there seems to be no point" is a little different.
Some reasons for instance: 1. quite a few servers deployed. No need to copy intel lib everywhere 2. intel library may have version dependancy. ie. when upgrading codec module newly compiled, it's possible to re-install all library. 3. not suitable for embedded application. example: running on x86-based uclinux 4. what happens when running on amd processors? will it guess right? and some others last but not least, IIRC there's options in intel Makefile to force processor type. So I think it should not be difficult. regards Franz Wu ----- Original Message ----- From: "Craig Guy" <[EMAIL PROTECTED]> To: "'Developers Mailing List'" <[email protected]> Sent: Tuesday, May 22, 2007 7:00 PM Subject: Re: [Callweaver-dev] [Openpbx-dev] G729 Licensing thread > Hi Franz, > > There is an option in the makefile to allow you to compile as either of > static or shared. If you compile the shared libraries version then the > codec determines at runtime the cpu and the correct library to run against > automatically, you just need to have the intel redistributables installed > on > your machine. The static version determines the cpu at compile time and > again compiles the correct library for the cpu into the codec. > > I have not looked at forcing a specific codec module as there seems to be > no > point - compiling the shared libraries version and installing the intel > redistributable gives you equivalent functionality. > > The codec has been updated for the namechange to CallWeaver, G723.1 has > been > added and better documentation and makefile has been written. I am just > waiting on a performance test and then I'll announce the codec properly to > the masses. > > Craig > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Franz Wu > Sent: Tuesday, 22 May 2007 1:18 PM > To: [email protected] > Subject: Re: [Callweaver-dev] [Openpbx-dev] G729 Licensing thread > > 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 > > _______________________________________________ > Callweaver-dev mailing list > [email protected] > http://lists.callweaver.org/mailman/listinfo/callweaver-dev _______________________________________________ Callweaver-dev mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-dev
