search for: normalize16

Alexander Chemeris a ?crit : > Ok, if I comment out inclusion of "filters_arm4.h" (or comment out its > only overridden function - normalize16()) it works fine. > > Also it works fine if I use -O0 for compilation. Specifying -O1 or -O2 lead > to segfault (if "filters_arm4.h" is included, sure). OK, so either I screwed up the alignment/constraints in the assembly or you've hit a compiler bug. The former is far more...

...ly, 8khz, 8kbps) To get a feel for the computational load, I am running 1 second (50 frames) of voice through the encoder. My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on inner_prod() and normalize16() and I'm confident I can get 32 channels by optimizing 5 or 6 functions. I expect these numbers to translate over the DM642. Symbol Name Count cycle.Total: Incl. cycle.Total:Excl. compute_weighted_codebook 200 4511420 4511420 iir_mem2 599 3338308 3338308 filter_mem2 799 232365...

...s function and the BlackFin has a corresponding instruction. Using this instruction saved me about 10% of my total encoder instructions. It would probably make sense to have a NORM macro that maps to _norm() on TI platforms or whatever the processor specific instruction is available. In filters.c normalize16() searches for the largest value using the following loop: for (i=0;i<len;i++) { spx_sig_t tmp = x[i]; if (tmp<0) tmp = NEG32(tmp); if (tmp >= max_val) max_val = tmp; } It should really use tmp=NEG32(tmp+1), since the range of negative fixed po...

Hi, Basically, inner_prod() can and should be adapted to the architecture it will run on. It is not really sensitive to noise, so it's possible to tweak it a lot. Also, in the current code, I saturate it to +-16384, which is OK to prevent overflows. I'm not concerned with the case of a constant -16384 value because it can't really happen in practice (especially after filtering). BTW,

...can add the results of the two _dotp2()s together before the long add without worrying about overflow. I didn't understand that inner_prod() was always passed scaled vectors. That's the danger of optimizing routines without knowing how they are called. I split a norm_shift() out of your normalize16(). This function can also be used twice in pitch_gain_search_3tap(). Are there any other places that would benefit from this optimized routine? /* Returns number of shifts to normalize a 32 bit vector to [-16384,+16384). */ static inline int norm_shift(const spx_sig_t *x, spx_sig_t max_scale,...

Dan Everton a ?crit : > Just one minor issue while building for ARM4 targets. The prototype for > the normalize16 function hasn't been updated in filters_arm4.h. The > attached patch should fix that. Patch applied. Thanks. In case you're interested, there's plenty of ARM4 optimisations that need to be updated (since 1.1.12) :-) > Apart from that, the 1.2beta2 release is about 0.6% faster on...

...or iOS with inline assembly enabled. --- libspeex/filters_arm4.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libspeex/filters_arm4.h b/libspeex/filters_arm4.h index 7a74042..2c64625 100644 --- a/libspeex/filters_arm4.h +++ b/libspeex/filters_arm4.h @@ -46,9 +46,9 @@ int normalize16(const spx_sig_t *x, spx_word16_t *y, spx_sig_t max_scale, int le ".normalize16loop1%=: \n" "\tldr %4, [%0], #4 \n" - "\tcmps %4, %1 \n" + "\tcmp %4, %1 \n" "\tmovgt %1, %4 \n" - "\tcmps %4...

Hello, I am from a small Czech software company (circletech.net) working on software for mobile phones. We are currently starting a development of an Voice IP software, and consider using speex for voice compression and decompression. The software will be Symbian OS C++ program. Is there anyone who has actually used speex Symbian OS port for realtime voice compression and decompression on mobile

You might not be doing anything wrong. Speex is stateful and can get into a bad state sometimes. It's happened to me too, but not recently. And I've seen such bugs reported on this list and fixed. I suggest several approaches to solving the problem: 1) Try compiling Speex without compiler optimizations and see if the problem still occurs. Most likely it will, but this is an

On 12/13/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > Did you test what happens if you only enable arm4 assembly? Sure. I tested with "--enable-arm4-asm" and there was no difference. > Also, if you can do some investigation, it would be useful to check what bit > of assembly is causing the crash. Can you disable one at a time and check? ok. I'll try

Hi everyone, I'm planning on releasing Speex 1.2beta2 in the next few days. I'd appreciate if everyone could try and test the current svn to make sure no bug crept in for your favourite plarform/application. Cheers, Jean-Marc

...e encoder. You might want to use a bit more just so you don't see the initialization complexity at all. > My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought th...

Hello! I'v downloaded speex lib 1.1.11.1. I am trying to port speex lib to Blackfin processor. I am using VisualDSP++ 4.0. If I am compiling source codes with using floating point everything ok. When I am compiling with FIXED_POINT defined everything's ok and code works about two times faster. But when I am defining BFIN_ASM I am getting several compiling errors in Blackfin assembler

...); } diff --git a/libspeex/filters_bfin.h b/libspeex/filters_bfin.h index 1e433ee..ccd57b9 100644 --- a/libspeex/filters_bfin.h +++ b/libspeex/filters_bfin.h @@ -32,6 +32,8 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ +#include "bfin.h" + #define OVERRIDE_NORMALIZE16 int normalize16(const spx_sig_t *x, spx_word16_t *y, spx_sig_t max_scale, int len) { @@ -50,7 +52,7 @@ int normalize16(const spx_sig_t *x, spx_word16_t *y, spx_sig_t max_scale, int le "LOOP_END norm_max%=;\n\t" : "=&d" (max_val) : "a" (x), "a&quo...

...e encoder. You might want to use a bit more just so you don't see the initialization complexity at all. > My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought th...

...like that. any idea? I used 1. sampleenc test.wav > test.spx 2. sampleenc test.raw > test.spx Alex Quoting Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>: > Dan Everton a ?crit : > > Just one minor issue while building for ARM4 targets. The prototype for > > the normalize16 function hasn't been updated in filters_arm4.h. The > > attached patch should fix that. > > Patch applied. Thanks. In case you're interested, there's plenty of ARM4 > optimisations that need to be updated (since 1.1.12) :-) > > > Apart from that, the 1.2beta2 rel...

...e encoder. You might want to use a bit more just so you don't see the initialization complexity at all. > My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought tha...

...e encoder. You might want to use a bit more just so you don't see the initialization complexity at all. > My profile of the 6416 indicates I'm at 27.4M cycles/channel. I need to get > below 720Mhz/32 channels = 22.5M cycles per channel. I did a little work on > inner_prod() and normalize16() and I'm confident I can get 32 channels by > optimizing 5 or 6 functions. I expect these numbers to translate over the > DM642. have you tried defining PRECISION16? That should reduce the computation cost. > A lower cost option would be to use a floating point 6713. I thought tha...

...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_ma...

...> /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...