Frank Lorenz
2008-Feb-22 05:38 UTC
Re: [Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
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@usherbrooke.ca> Gesendet: 12.02.08 22:49:49 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??? 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 > >_______________________________________________________________________ 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
Jean-Marc Valin
2008-Feb-22 13:07 UTC
[Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
> 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@usherbrooke.ca> Gesendet: 12.02.08 22:49:49 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??? > > > 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 >> >> > > > > _______________________________________________________________________ > 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 > > >
Maybe Matching Threads
- Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
- Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
- Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
- Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
- FW: Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???