FW: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???

[Jean-Marc Valin]

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