Stephane Menard
2008-Mar-05 11:55 UTC
[Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
Jean-Marc, Frank, I have stumbled across a similar situation regarding optimization. I seem to have a similar setup as Frank does with a fixed 48khz in and out. The wideband mode and ultra-wideband modes are really what I?m looking for. I have a test application that reads audio, downsample to 16kHz (or 32kHz), speex encode, speex decode, upsample back to 48kHz, and playback. If I remove the speex encode and decode, I get perfect audio, up and down resampling is great. When I use the encoder/decoder pass, and I use the non-asm-optimized speex library, I get good results (aside using a lot of CPU). Audio is good. When I used the asm-optimized library, I seem to get good audio only if I configure the encoder in mode 10. Anything below results in noisy speech). These results are similar for 1.2beta3 and 1.2beta2. Changing the complexity doesn?t seem to affect the results. I tried the most recent git/svn trunk, and I get a bus error in the encoder. I noticed that the only thing that seem different (for what I?m using) is the file quant_lsp_bfin.h. So I replaced that file only in a 1.2beta3 package and I got the same bus error. (this patched version works fine if I don?t use asm-optimization). I?m in a similar situation as Frank once again where I need both the libspeex and libspeexdsp, so I have not been able to enable fixed-debug. Please let me know if you have any clues on how to fix the issue and if there?s anything I can do to help. Kind Regards, Stephane> 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 <http://lists.xiph.org/mailman/listinfo/speex-dev> > Gesendet: 12.02.08 22:49:49 An: > Frank Lorenz <Frank_wtal at web.de <http://lists.xiph.org/mailman/listinfo/speex-dev> > CC: speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 <http://lists.xiph.org/mailman/listinfo/speex-dev> :~/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 <http://lists.xiph.org/mailman/listinfo/speex-dev> > Gesendet: 08.02.08 21:50:56 An: >> Frank Lorenz <Frank_wtal at web.de <http://lists.xiph.org/mailman/listinfo/speex-dev> > CC: speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 <http://lists.xiph.org/mailman/listinfo/speex-dev> > Gesendet: 06.02.08 11:07:46 An: >>> Frank Lorenz <Frank_wtal at web.de <http://lists.xiph.org/mailman/listinfo/speex-dev> > CC: speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 <http://lists.xiph.org/mailman/listinfo/speex-dev> > Gesendet: 02.02.08 06:26:08 >>>> An: speex-dev <speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> > 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 <http://lists.xiph.org/mailman/listinfo/speex-dev> > Gesendet: 01.02.08 12:11:39 >>>>> An: Frank Lorenz <Frank_wtal at web.de <http://lists.xiph.org/mailman/listinfo/speex-dev> > CC: speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> >>>>> 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> 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> http://www.maildomain.web.de/?mc=021114 >> >> _______________________________________________ Speex-dev mailing >> list Speex-dev at xiph.org <http://lists.xiph.org/mailman/listinfo/speex-dev> >> 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 > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20080305/35846ee4/attachment.html
Jean-Marc Valin
2008-Mar-05 13:22 UTC
[Speex-dev] Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???
Can you also try disabling the DIV* macros from fixed_bfin.h and see if it makes a difference? I've asked other people using Speex on the Blackfin whether they were having problems and they said no, so maybe it's toolchain-related (bug could be in the toolchain or just exposed by the toolchain). Can you try with a different version of gcc? Also, if there's any actual regression, it should be relatively easy to track down by doing a bisection, either manually using svn or using git-bisect (I can show you how to use that). Jean-Marc Stephane Menard a ?crit :> Jean-Marc, Frank, > > > > I have stumbled across a similar situation regarding optimization. > > > > I seem to have a similar setup as Frank does with a fixed 48khz in > and out. The wideband mode and ultra-wideband modes are really what > I?m looking for. > > > > I have a test application that reads audio, downsample to 16kHz (or > 32kHz), speex encode, speex decode, upsample back to 48kHz, and > playback. > > > > If I remove the speex encode and decode, I get perfect audio, up and > down resampling is great. > > > > When I use the encoder/decoder pass, and I use the non-asm-optimized > speex library, I get good results (aside using a lot of CPU). Audio > is good. > > > > When I used the asm-optimized library, I seem to get good audio only > if I configure the encoder in mode 10. Anything below results in > noisy speech). These results are similar for 1.2beta3 and 1.2beta2. > Changing the complexity doesn?t seem to affect the results. > > > > I tried the most recent git/svn trunk, and I get a bus error in the > encoder. I noticed that the only thing that seem different (for what > I?m using) is the file quant_lsp_bfin.h. So I replaced that file only > in a 1.2beta3 package and I got the same bus error. (this patched > version works fine if I don?t use asm-optimization). > > > > I?m in a similar situation as Frank once again where I need both the > libspeex and libspeexdsp, so I have not been able to enable > fixed-debug. > > > > Please let me know if you have any clues on how to fix the issue and > if there?s anything I can do to help. > > > > Kind Regards, > > > > Stephane > > > > > >> / 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 >> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet: >> 12.02.08 22:49:49 An:/ > >> / Frank Lorenz <Frank_wtal at web.de >> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le Service >> des Technologies de l'Information de l'UdeS veut vous mettre en >> garde contre "lists.xiph.org" qui semble ?tre une tentative de >> fraude envers* speex-dev at xiph.org >> <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 >>> <http://lists.xiph.org/mailman/listinfo/speex-dev>:~/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 >>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet: >>> 08.02.08 21:50:56 An:/ > >>> / Frank Lorenz <Frank_wtal at web.de >>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le >>> Service des Technologies de l'Information de l'UdeS veut vous >>> mettre en garde contre "lists.xiph.org" qui semble ?tre une >>> tentative de fraude envers* speex-dev at xiph.org >>> <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 >>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet: >>>> 06.02.08 11:07:46 An: / > >>>> / Frank Lorenz <Frank_wtal at web.de >>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le >>>> Service des Technologies de l'Information de l'UdeS veut vous >>>> mettre en garde contre "lists.xiph.org" qui semble ?tre une >>>> tentative de fraude envers* speex-dev at xiph.org >>>> <http://lists.xiph.org/mailman/listinfo/speex-dev> 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 >>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> Gesendet: >>>>> 02.02.08 06:26:08/ > >>>>> / An: speex-dev <*Le Service des Technologies de >>>>> l'Information de l'UdeS veut vous mettre en garde contre >>>>> "lists.xiph.org" qui semble ?tre une tentative de fraude >>>>> envers* speex-dev at xiph.org >>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> 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 >>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> >>>>>> Gesendet: 01.02.08 12:11:39/ > >>>>>> / An: Frank Lorenz <Frank_wtal at web.de >>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>> CC: *Le >>>>>> Service des Technologies de l'Information de l'UdeS veut >>>>>> vous mettre en garde contre "lists.xiph.org" qui semble >>>>>> ?tre une tentative de fraude envers* speex-dev at xiph.org >>>>>> <http://lists.xiph.org/mailman/listinfo/speex-dev>/ > >>>>>> / 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 *Le Service des Technologies de l'Information de l'UdeS >>> veut vous mettre en garde contre "lists.xiph.org" qui semble ?tre >>> une tentative de fraude envers* Speex-dev at xiph.org >>> <http://lists.xiph.org/mailman/listinfo/speex-dev> / > >>> / 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/ > >> / / > >> / / > >> / / > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Speex-dev mailing > list Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev
Reasonably Related Threads
- 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???
- 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???