FW: Re: [Speex-dev] Problem with Blackfin assembly optimizations
-- bug in fixed_bfin.h / resampler saturation???
jean-marc.valin at usherbrooke.ca
Fri Feb 1 03:11:49 PST 2008
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.
More information about the Speex-dev