[asterisk-dev] Building codec_gsm against Spandsp

[Philip Prindeville]

  On 7/21/10 2:20 PM, Philip Prindeville wrote:
>    On 7/21/10 11:34 AM, Philip Prindeville wrote:
>>     On 2/3/10 6:52 PM, Steve Underwood wrote:
>>> On 02/04/2010 08:17 AM, Tzafrir Cohen wrote:
>>>> On Wed, Feb 03, 2010 at 03:53:00PM -0800, Philip A. Prindeville wrote:
>>>>
>>>>> Does anyone have patches (or otherwise know what would be involved) to
>>>>> build Asterisk's codec_gsm against the Spandsp library?
>>>>>
>>>> Why would you want that?
>>>>
>>> The libgsm with some distributions is quite slow, and some won't pass
>>> the test vectors, so there are good reasons to choose an alternative. I
>>> think the Asterisk one actually fails a couple of the test vectors, but
>>> its close to correct.
>>>> libgsm is a separate library. Most distributions include it nowadays.
>>>> Asterisk can either use its internal copy or the system copy of it.
>>>>
>>> I know people were in denial for ages, blaming GCC for being faulty, but
>>> I thought the GSM codec in the Asterisk was eventually fixed. The
>>> problem is just an error in embedded assembly language code, where the
>>> better optimiser in GCC 4.2 made there error show up for the first time.
>> Do you remember what the bug # was?  We need to reopen this bug...  At the very least, it can't be too difficult to through in a pragma to cause GCC to not optimize and rewrite the code, yes?
>>
>> BTW:  I still like the idea of patching Asterisk to allow it to build --with-spandsp much more.
>>
>> -Philip
> Looking at trunk/codecs/gsm/Makefile, I see:
>
> # add k6-specific code only if not on a non-k6 hardware or proc.
> # XXX Keep a space after each findstring argument
> # XXX should merge with GSM_OBJECTS
> ifeq ($(OSARCH),linux-gnu)
> ifeq (,$(findstring $(shell uname -m) , x86_64 amd64 ppc ppc64 alpha armv4l sparc64 parisc s390 ))
> ifeq (,$(findstring $(PROC) , arm armv5b armeb powerpc ia64 s390 bfin mipsel mips ))
> GSM_SOURCES+= $(SRC)/k6opt.s
> endif
> endif
> endif
>
>
> This is non-good.  It's assuming that the machine the compile is being done on is the same as the machine the generated object will run on.
>
> -Philip
>

I borrowed one of the patches from 11243 and tweaked it a little.  Attaching.

We might need to reopen this bug.  Qwell committed the private.h asm patch, but as Coppice pointed out that may not have been enough.

-Philip

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: asterisk-trunk-bugid11243.patch
Url: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100722/08ee97ea/attachment.txt