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

Frank Lorenz Frank_wtal at web.de
Fri Feb 22 05:36:14 PST 2008 

Hi Jean-Marc,

after some problems with getting svn to work here I finally made it. Problem is, you write that I cannot use libspeex and libspeexdsp at the same time now -- because I use a "live" system (mic-in -> speex_enc -> speex_dec -> headphone out) and I can run the AD1836 audio codec on 48 kHz only, I cannot use my program now (because I use speex resampling...)

So I tried to do file I/O, but the described problem (that the encoder corrupts its input buffer) is gone in this configuration.

But nevertheless, when I try to encode an overdriven (saturated) signal, the strange toggling between -MAX and MAX values on a sample-by-sample basis still happens. The debug output for this is as follows:

SHL16: output is not short: 36500 in ltp.c: line 649
EXTRACT16: input is not short: 33074 in nb_celp.c: line 802
EXTRACT16: input is not short: 37708 in nb_celp.c: line 802
EXTRACT16: input is not short: 43003 in nb_celp.c: line 802
SHL16: output is not short: 34824 in ltp.c: line 649
SHL16: output is not short: -33354 in ltp.c: line 649
SHL16: output is not short: -35194 in ltp.c: line 649
SHL16: output is not short: -35290 in ltp.c: line 649
SHL16: output is not short: -33002 in ltp.c: line 649
SHL16: output is not short: 34098 in ltp.c: line 649
SHL16: output is not short: -35902 in ltp.c: line 649
SHL16: output is not short: 42266 in ltp.c: line 649
SHL16: output is not short: -33424 in ltp.c: line 649
SHL16: output is not short: -33044 in ltp.c: line 649
SHL16: output is not short: -33114 in ltp.c: line 649
SHL16: output is not short: -40918 in ltp.c: line 649
SHL16: output is not short: -36334 in ltp.c: line 649
SHL16: output is not short: 33024 in ltp.c: line 649
SHL16: output is not short: -33122 in ltp.c: line 649
SHL16: output is not short: 32844 in ltp.c: line 649
SHL16: output is not short: 34154 in ltp.c: line 649
SHL16: output is not short: -37996 in ltp.c: line 649
SHL16: output is not short: -33580 in ltp.c: line 649
EXTRACT16: input is not short: 36941 in nb_celp.c: line 802
SHL16: output is not short: -36586 in ltp.c: line 649
SHL16: output is not short: -37448 in ltp.c: line 649
EXTRACT16: input is not short: -32775 in sb_celp.c: line 1083
EXTRACT16: input is not short: 32775 in sb_celp.c: line 1083
EXTRACT16: input is not short: 39844 in sb_celp.c: line 1083
EXTRACT16: input is not short: -38669 in sb_celp.c: line 1083
EXTRACT16: input is not short: -38087 in sb_celp.c: line 1083
EXTRACT16: input is not short: -33703 in sb_celp.c: line 1083
EXTRACT16: input is not short: 42556 in sb_celp.c: line 1083
EXTRACT16: input is not short: -37341 in sb_celp.c: line 1083
EXTRACT16: input is not short: 48772 in sb_celp.c: line 1083
EXTRACT16: input is not short: -45337 in sb_celp.c: line 1083
EXTRACT16: input is not short: 51012 in nb_celp.c: line 802
SHL16: output is not short: -34808 in ltp.c: line 649
EXTRACT16: input is not short: -33646 in nb_celp.c: line 802
SHL16: output is not short: 33700 in ltp.c: line 649
SHL16: output is not short: -36982 in ltp.c: line 649
SHL16: output is not short: -33016 in ltp.c: line 649

So there seem to be three different positions in code where assumptions are "broken".
It should be pointed out that the above debug outputs occur only on frames with overdriven signal, but not every frame with overdriven signal produces a debug-output.

best regards,
Frank


-----Ursprüngliche Nachricht-----
Von: "Jean-Marc Valin" <jean-marc.valin at usherbrooke.ca>
Gesendet: 12.02.08 22:49:49
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???


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 at 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 at usherbrooke.ca>
> Gesendet: 08.02.08 21:50:56
> 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 :
>> 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
>>
>>
>>
> 
> 
> 
> _________________________________________________________________________
> 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 at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
> 
> 



_______________________________________________________________________
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