FW: Re: [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 1 21:26:46 PST 2008

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.



> 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

More information about the Speex-dev mailing list