[Speex-dev] Problem with Blackfin assembly optimizations -- bug
in fixed_bfin.h / resampler saturation???
Jean-Marc Valin
jean-marc.valin at usherbrooke.ca
Fri Feb 8 12:51:07 PST 2008
Frank Lorenz a écrit :
> Yes, this is another point: I wrote that the resampler breaks, but
> this is not the case. Instead, the speex encoder corrupts its input
> buffer when the "DIV32_16 bug" described above happens. Do you have
> any idea how to proceed?
Can you try enabling --enable-fixed-point-debug (FIXED_DEBUG) and see if
any error gets printed. I suspect there might be a place where the
assumptions of DIV32_16 are violated, i.e. either the right hand side
doesn't fit in 16 bits or the result doesn't fit in 16 bits. Can you check?
Jean-Marc
> best regards, Frank
>
>
> -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"
> <jean-marc.valin at usherbrooke.ca> Gesendet: 06.02.08 11:07:46 An:
> Frank Lorenz <Frank_wtal at web.de> CC: speex-dev at xiph.org Betreff: Re:
> [Speex-dev] Problem with Blackfin assembly optimizations -- bug in
> fixed_bfin.h / resampler saturation???
>
>
> Frank Lorenz a écrit :
>> I just started to examine the DIV32_16 function (Blackfin ASM
>> version), and wondered why the return value of the function inside
>> 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable
>> 'res' which is returned by this function is of type 'spx_word32_t'.
>> Is this a trick of optimization or a bug? (Same question for
>> PDIV32_16 and MAX16, too!)
>
> Neither (AFAIK). The idea is that sometimes gcc does
> silly/counter-intuitive things when I specify a 16-bit variable as a
> constraint. That way, I force the top 16 bits to be zero.
>
> Jean-Marc
>
>> best regards, Frank
>>
>>
>> -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"
>> <jean-marc.valin at usherbrooke.ca> Gesendet: 02.02.08 06:26:08 An:
>> speex-dev <speex-dev at xiph.org> Betreff: Re: FW: Re: [Speex-dev]
>> Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h
>> / resampler saturation???
>>
>>
>> Frank Lorenz a écrit :
>>> And yes, the same "overflow" happens even when I disable Blackfin
>>> ASM optimizations.
>> Indeed, that shouldn't happen. Just to make sure I understand, so
>> far there's two problems: 1) DIV32_16() in Blackfin assembly causes
>> problems 2) The resampler overflows
>>
>> When you fix/workaround those two, is the encoder/decoder working
>> correctly or are there other issues?
>>
>> About the DIV32_16() issue, could you try and replace it with a
>> function that compares the Blackfin-asm result with the real
>> division and dumps the args and output when they don't match. I'd
>> like to understand for what inputs that functions fails. That would
>> help in fixing the problem.
>>
>> Thanks,
>>
>> Jean-Marc
>>
>>> best regards, Frank
>>>
>>> -----Ursprüngliche Nachricht----- Von: "Jean-Marc Valin"
>>> <jean-marc.valin at usherbrooke.ca> Gesendet: 01.02.08 12:11:39 An:
>>> Frank Lorenz <Frank_wtal at web.de> CC: speex-dev at xiph.org Betreff:
>>> Re: FW: Re: [Speex-dev] Problem with Blackfin assembly
>>> optimizations -- bug in fixed_bfin.h / resampler saturation???
>>>
>>>
>>> Frank Lorenz a écrit :
>>>> didn't get a reply to my last post (see below) -- do you have
>>>> no idea what happens here?
>>> Sorry, been quite busy lately. Still have a backlog of things to
>>> respond to (sorry to others as well), some of it quite old.
>>>
>>>> After some more tests, I disabled the DIV32_16 Blackfin
>>>> optimizations and now get good quality on the Blackfin.
>>> OK, I'll need to investigate that one. It's mostly taken from the
>>> ADI manual, so I don't see what could have happened.
>>>
>>>> But when I have overdrive on the input, things become very bad
>>> Does that happen without any assembly. Some amount of badness is
>>> expected from the fixed-point because of saturation issues. It
>>> shouldn't overflow though (can you check?)
>>>
>>>> -- I'm not sure if this is really a filter stability issue like
>>>> I wrote some weeks ago.
>>> I don't think it has to do with filters.
>>>
>>>> I use the speex resampler to downsample from 48 to 16 kHz. When
>>>> I look to the downsampled signal before passing it to the
>>>> encoder, there seems to be a bug in saturation. On overdrive,
>>>> instead of holding a too big signal value at maximum (e.g.
>>>> 32767) for some samples, the sample values I get from the
>>>> resampler are [-32768,32767,-32768,...], i.e. the output of the
>>>> resampler alters between the biggest possible negative value
>>>> and the biggest possible positive value.
>>> This is definitely bad. Can you send me an example file. Also,
>>> can you reproduce that problem without the Blackfin assembly?
>>>
>>>> Does the resampler use the hardware saturation available on
>>>> Blackfin, or does it saturate by software? Can you point me to
>>>> the place I have to look at inside the resampler function for
>>>> saturation?
>>> Saturation is entirely done in software. The resampler does the
>>> conversion using the WORD2INT macro.
>>>
>>> Jean-Marc
>>>
>>>
>>>
>>> _______________________________________________________________________
>>> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
>>> kostenlos testen.
>>> http://www.pc-sicherheit.web.de/startseite/?mc=022220
>>>
>>>
>>>
>>
>>
>> _________________________________________________________________________
>> In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und
>> gestalten! Nur 3,99 EUR/Monat!
>> http://www.maildomain.web.de/?mc=021114
>>
>>
>>
>
>
>
> _______________________________________________________________________
> Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
> kostenlos testen.
> http://www.pc-sicherheit.web.de/startseite/?mc=022220
>
>
>
More information about the Speex-dev
mailing list