Speex dev - Feb 2008 - Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???

Hi,

when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries
to build testenc.o and when I try to link my app against the speex lib:


lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make
bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c
bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o
-lspeex_debug -lspeexdsp -lm
/home/lorenz/lib/libspeex_debug.a(bits.o): In function
`speex_bits_set_bit_buffer':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/bits.c:72: multiple definition of
`_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(modes.o): In function `speex_mode_query':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes.c:359: multiple definition
of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(modes_wb.o): In function
`speex_lib_get_mode':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes_wb.c:293: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(nb_celp.o): In function `_ADD32':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:207: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(quant_lsp.o): In function
`compute_quant_weights':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/quant_lsp.c:72: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(sb_celp.o): In function `_DIV32':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:466: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(speex_callbacks.o): In function
`speex_default_user_handler':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex_callbacks.c:140: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(window.o):(.bss+0x0): multiple definition of
`_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(cb_search.o): In function
`compute_weighted_codebook':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/cb_search_bfin.h:38: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(filters.o): In function `normalize16':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/filters_bfin.h:37: multiple
definition of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(lsp.o): In function `lsp_enforce_margin':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/lsp.c:594: multiple definition of
`_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(ltp.o): In function `inner_prod':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/ltp_bfin.h:38: multiple definition
of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(vbr.o): In function `vbr_destroy':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/vbr.c:272: multiple definition of
`_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(vq.o): In function `vq_nbest':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/vq_bfin.h:38: multiple definition
of `_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
/home/lorenz/lib/libspeex_debug.a(lpc.o): In function `_spx_lpc':
/home/lorenz/Blackfin/speex-1.2beta3/libspeex/lpc.c:78: multiple definition of
`_spx_mips'
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
collect2: ld gab 1 als Ende-Status zur??ck
make: *** [speex_through] Fehler 1


again: any ideas how to proceed?

best regards,
Frank



-----Urspr?ngliche Nachricht-----
Von: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca>
Gesendet: 08.02.08 21:50:56
An: Frank Lorenz <Frank_wtal@web.de>
CC: speex-dev@xiph.org
Betreff: Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bug in
fixed_bfin.h / resampler saturation???


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@usherbrooke.ca> Gesendet: 06.02.08 11:07:46 An:
> Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@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@usherbrooke.ca> Gesendet: 02.02.08 06:26:08 An: 
>> speex-dev <speex-dev@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@usherbrooke.ca> Gesendet: 01.02.08 12:11:39
An:
>>>  Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@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
> 
> 
> 


_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114

OK, a few things got accidentally broken. I've partially fixed it in
svn/git (the limitation is that you can't link with both libspeex and
libspeexdsp if configured as fixed-point debug).

Can you compile/test now?

	Jean-Marc

Frank Lorenz a ?crit :
> Hi,
> 
> when I compile with FIXED_DEBUG enabled, I get an error -- both when make
tries to build testenc.o and when I try to link my app against the speex lib:
> 
> 
> lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make
> bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c
> bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o
-lspeex_debug -lspeexdsp -lm
> /home/lorenz/lib/libspeex_debug.a(bits.o): In function
`speex_bits_set_bit_buffer':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/bits.c:72: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(modes.o): In function
`speex_mode_query':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes.c:359: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(modes_wb.o): In function
`speex_lib_get_mode':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/modes_wb.c:293: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(nb_celp.o): In function `_ADD32':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:207: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(quant_lsp.o): In function
`compute_quant_weights':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/quant_lsp.c:72: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(sb_celp.o): In function `_DIV32':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/fixed_debug.h:466: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(speex_callbacks.o): In function
`speex_default_user_handler':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex_callbacks.c:140:
multiple definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(window.o):(.bss+0x0): multiple definition
of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(cb_search.o): In function
`compute_weighted_codebook':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/cb_search_bfin.h:38: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(filters.o): In function
`normalize16':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/filters_bfin.h:37: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(lsp.o): In function
`lsp_enforce_margin':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/lsp.c:594: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(ltp.o): In function `inner_prod':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/ltp_bfin.h:38: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(vbr.o): In function `vbr_destroy':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/vbr.c:272: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(vq.o): In function `vq_nbest':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/vq_bfin.h:38: multiple
definition of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> /home/lorenz/lib/libspeex_debug.a(lpc.o): In function `_spx_lpc':
> /home/lorenz/Blackfin/speex-1.2beta3/libspeex/lpc.c:78: multiple definition
of `_spx_mips'
>
/home/lorenz/lib/libspeex_debug.a(speex.o):/home/lorenz/Blackfin/speex-1.2beta3/libspeex/speex.c:52:
first defined here
> collect2: ld gab 1 als Ende-Status zur??ck
> make: *** [speex_through] Fehler 1
> 
> 
> again: any ideas how to proceed?
> 
> best regards,
> Frank
> 
> 
> 
> -----Urspr?ngliche Nachricht-----
> Von: "Jean-Marc Valin" <jean-marc.valin@usherbrooke.ca>
> Gesendet: 08.02.08 21:50:56
> An: Frank Lorenz <Frank_wtal@web.de>
> CC: speex-dev@xiph.org
> Betreff: Re: [Speex-dev] Problem with Blackfin assembly optimizations --
bug in fixed_bfin.h / resampler saturation???
> 
> 
> 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@usherbrooke.ca> Gesendet: 06.02.08 11:07:46 An:
>> Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@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@usherbrooke.ca> Gesendet: 02.02.08 06:26:08
An:
>>> speex-dev <speex-dev@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@usherbrooke.ca> Gesendet: 01.02.08
12:11:39 An:
>>>>  Frank Lorenz <Frank_wtal@web.de> CC: speex-dev@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
>>
>>
>>
> 
> 
> 
> _________________________________________________________________________
> In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten! 
> Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
> 
>