similar to: Re: Problem with Blackfin assembly optimizations -- bug in fixed_bfin.h / resampler saturation???

Hi, when I compile with FIXED_DEBUG enabled, I get an error -- both when make tries to build testenc.o and when I try to link my app against the speex lib: lorenz@panelmaker:~/Blackfin/tests/speex_loopthrough$ make bfin-uclinux-gcc -c -g -I/home/lorenz/include -o main.o main.c bfin-uclinux-gcc -gl -elf2flt -L/home/lorenz/lib -o speex_through main.o -lspeex_debug -lspeexdsp -lm

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

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Hi, 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!) best

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex

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

Hi Jean-Marc, I did some further checks with 1.2 beta 3: The problematic function is DIV32_16 inside fixed_bfin.h. When I comment it out (i.e. replace it by the generic version of the routine), the quality improves significantly. Nevertheless, there is still a horrible distortion when there is some overdrive/saturation in the input signal. For me, it looks like there's an instable filter

Hello everybody, I'm currently trying to run speex on the Blackfin (BF-537) STAMP evaluation board unter uCLinux. Using 1.2 beta 3, I encountered problems when activating the Blackfin assembler optimizations. Without optimizations for blackfin, i.e. calling ./configure --enable-fixed-point --host=bfin-uclinux everything seems to work fine. But when I add the --enable-blackfin-asm flag to

Hi Marc, I encountered the problems even with older versions of speex, including 1.2beta2 and 1.1.12, too. I had no time in the last weeks to investigate this issue further, sorry. Hopefully, I'm able to do some more test the next days, but I have no real idea how to proceed Performance and quality seem to be o.k. for me if I deactivate the Blackfin optimizations inside the file

Hi Jean-Marc, As I told you, bank is a reserved keyword in Analog Devices compiler for Blackfin architecture. So we need to change the variables named bank to something else. Here's a patch that changes bank to bnk in the 3 concerned files. (Hope the format is OK) About my previous problems with the Blackfin: -> strange block repetition that could be cancelled by the AEC I was busy

Hi Jean-Marc, yes, problem exists in narrowband-mode, too. I already twiddled with max_gain, but did not have real success. I changed line 337 of ltp.c (function pitch_gain_search_3tap_vq) if (sum>best_sum && gain_sum<=max_gain) { to if (sum>best_sum && gain_sum<max_gain) { -- that stabilizes speex for 2000 Hz and 2200 Hz input on quality setting 7 (23800

Hi All, We are using speex for linphone in blackfin fixed point platform. The speex version we are using is svn-14525. If we don't disable vbr by "--disable-vbr", the sound quality will be very bad in linphone. But if we disable it, sound will be perfect. I noticed in the speex.org, there is a comment like this: > >Speex 1.2beta3 is out >December 11, 2007 >The most

<body bgcolor="#ffffff" background="https://img.web.de/v/p.gif" class="bgRepeatYes" style="background-repeat: repeat; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0); font-size: 9pt; padding-left: 0px;" ><span style="font-size: 9pt;"><span style="font-family: verdana,geneva;"><span

<body bgcolor="#ffffff" background="https://img.web.de/v/p.gif" class="bgRepeatYes" style="background-repeat: repeat; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0); font-size: 9pt; padding-left: 0px;" ><p>Hi Jean-Marc,</p> <p>&nbsp;</p> <p>yes, I tested with floating point. It is only a fixed point

Hi Jean-Marc I'm trying to integrate your speex codec on our custom Blackfin board. The board is not uCLinux compatible and there is no chance that it will ever be. I am using ADI-supplied VisualDSP++ IDE and corresponding toolchain. As long as I am compiling "C"-only version of the library everything is fine. VisualDSP++ produces working library. There is only one not so minor

Hi Jean-Marc, do you have any other ideas what to look for? Or do you currently debug yourself? As I already wrote, I'm out of ideas... best regards, Frank Frank Lorenz <Frank_wtal at web.de> hat am 18. Januar 2010 um 16:39 geschrieben: > Yes, I did. > > As mentioned earlier, only the enhancer inside the docoder produces a lot of overflow messages (it points to lines 68

-----Original Message----- From: Robin Getz [mailto:rgetz@blackfin.uclinux.org] Sent: Saturday, June 16, 2007 12:11 AM To: Michael Shatz Cc: speex-dev@xiph.org Subject: Re: [Speex-dev] Blackfin inline assembler and VisualDSP++ toolchain >On Wed 13 Jun 2007 12:37, Michael Shatz pondered: >> >> Hi Jean-Marc >> >> I'm trying to integrate your speex codec on our

Hi all, i'm using speex under symbian. When i have compiled the lib for ARM platform i have obtained the follow error: "Error: Can not represent OFFSET_IMM8 relocation in this object file format (1)" I have defined FIXED_POINT 1 and ARM4_ASM. The error is in the function forced_pitch_quant contained in ltp.c. The line that produce the error is:

What happens if you change that line: if (cumul_gain > 262144) to use a smaller value? What value works OK (if any)? One more thing, when things go wrong, do they eventually go back to normal or does the codec never recover? It's unavoidable that the audio goes bad for a short period of time because of the long-term predictor. Jean-Marc On 2010-01-14 05:57, Frank Lorenz wrote: >

Hi Frank, Sorry, I *do* care about the problem and just happen to be overworked at the moment. What I suspect is that the pitch gain gets close enough to unity that the loss makes it bust. Did you test with the floating-point code? Jean-Marc On 2010-01-13 03:45, Frank Lorenz wrote: > Hi, > > is no one willing to spent some effort on this topic? At least it would > be good >