[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 22 13:09:10 PST 2008
> 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...)
Well, you can't use libspeex and libspeexdsp together *only if* you
enable fixed-point debugging. I'll fix that when I get some time.
> So I tried to do file I/O, but the described problem (that the
> encoder corrupts its input buffer) is gone in this configuration.
The encoder always corrupts its input buffer. This is not new.
> 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:
What happens if you first saturate the signal to (e.g.) +/- 32000
instead of +/- 32767? BTW, can you send the signal you were using.
...
> 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.
Yes, I've always assumed sort of a "non totally broken" input signal and
I'm not sure what to do here... Sure I could fix it, but then it would
make the code less optimal for the normal case (and it doesn't change
anything if you've got saturating arithmetic anyway).
BTW, what happens if you turn on the Blackfin assembly? Do you get the
same output (approximately) or does it get worse?
Jean-Marc
> 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