search for: very_small

Hi Jeff, Hi Jean-Marc, I first modified the FPU control word to raise an exception whenever a denormal is used. Then I used the debugger to locate the exceptions and added VERY_SMALLs where they seem to fit well. Although I got CPU usage as low as 10%, I seriously lack knowledge of how things work inside speex. So just changing some code is not the best idea for me. My second attempt was to follow Jeff's suggestion to modify the MXCSR register and recompile with _USE_SSE....

...-dev] High CPU usage Hi, Sound like it could be the good old denormalised float problem on the Intel chips. Just to make sure, can you try compiling in fixed-point (FIXED_POINT) and see if the problem goes away (it's not a fix, just a test)? If that's the case, there's probably a few VERY_SMALL's to add to some signals. Cheers, Jean-Marc Mark Schilling a ?crit : > Hi, > > I have a curious problem with speex. As long as I'm talking, it takes about 2-5% of my CPU. This seems ok. > But as soon as I stop talking, CPU utilization rises to about 30-45% and stays there...

...nly goes to zero, then the filter's output value becomes smaller and smaller until it reaches ~1e-37. At that point, your CPU takes >10x the normal time to make calculations (why is beyond me). Now, the work-around is to prevent some signals from going to exacly zero. Have a look at how the VERY_SMALL macro is currently being used. It's defined as 0 for fixed-point, but 1e-15f for float. By adding that value to the right signal(s), you can prevent denormalized numbers from being generated. The key is to find that place or those places. A profiler may be able to tell you where the problem hap...

...the patches, next week isn't too late. >> >> Also, I've started looking at your patches. So far there's one thing >> that puzzles me a bit. In the OPUS_CHECK_ASM section of patch 0004, you >> have: >> >> + celt_assert(ABS32(xy1_c - *xy1) <= VERY_SMALL); >> >> Given the normal range of the values (the xy values are often much >> larger than one) and the precision involved here (24-bit mantissa), it >> seems like this test can only succeed if the two values are actually >> equal. Is the float patch actually bit-exact?...

Hi Jean-Marc, I tried to add VERY_SMALL at the input of the encoder, but that did not change much. Here's a list of source code locations where denormals appear for the first time as calculation results. This list is based on a 4 minutes recording of ambient sound that is passed to speexenc 1.2rc1 with the command line --narrowband...

...for 1.2 release. Assuming there's no issue with the patches, next week isn't too late. Also, I've started looking at your patches. So far there's one thing that puzzles me a bit. In the OPUS_CHECK_ASM section of patch 0004, you have: + celt_assert(ABS32(xy1_c - *xy1) <= VERY_SMALL); Given the normal range of the values (the xy values are often much larger than one) and the precision involved here (24-bit mantissa), it seems like this test can only succeed if the two values are actually equal. Is the float patch actually bit-exact? If so, then maybe you should be using actua...

...spx_coef_t; typedef spx_word16_t spx_lsp_t; typedef spx_word32_t spx_sig_t; #define LPC_SCALING 8192 #define SIG_SCALING 16384 #define LSP_SCALING 8192. #define GAMMA_SCALING 32768. #define GAIN_SCALING 64 #define GAIN_SCALING_1 0.015625 #define LPC_SHIFT 13 #define SIG_SHIFT 14 #define VERY_SMALL 0 #ifdef ARM_ASM #include "fixed_arm.h" #elif defined (FIXED_DEBUG) #include "fixed_debug.h" #else #include "fixed_generic.h" #endif #else typedef float spx_mem_t; typedef float spx_coef_t; typedef float spx_lsp_t; typedef float spx_sig_t; typedef float spx_word1...

...is calculated. Again, this I think stems from the lpc function producing some INF and IND values so I think that is just a symptom. I can add bounds checking to the SSE code but I don't know what to do regarding the lpc code. When this happens the easy fix is to just reset the upper band to VERY_SMALL and also to reset mem_sp but I am hoping that this won't be needed if the lpc values were in the right range. Tom At 07:29 AM 3/14/2007, you wrote: >While looking for the problem, I ended up fixing two other things that >could be related. Can you test current svn and tell me if the pro...

Thank Ulrich! Yes, using celt_assert(1.0 + celt_inner_prod_neon_float_c_simulation(x, y, N) == 1.0 + xy); celt_assert(1.0 + xy1_c == 1.0 + *xy1); celt_assert(1.0 + xy2_c == 1.0 + *xy2); can avoid the useage of VERY_SMALL. Hi Jean-Marc, I added { const opus_val32 xy_c = celt_inner_prod_neon_float_c_simulation(x, y, N); const int32_t *x_bin = (int32_t*)x; const int32_t *y_bin = (int32_t*)y; const int32_t *xy_bin = (int32_t*)&xy; const int32_t *xy_bin_c = (int32_t*)&am...

Hi Jean-Marc, Based on the wonderful Speex project, I've created SpeexOutLoud, essentially a Speex codec port for Windows Mobile 2003 devices. I've included a sample project intended to show the usage of SpeexOutLoud codec in a Pocket PC application based on .NET Compact Framework. I'd request you to please go through the attached build, and include it as a contribution to the

...I think stems from the lpc function > producing some INF and IND values so I think that is just a symptom. > > I can add bounds checking to the SSE code but I don't know > what to do regarding the lpc code. > When this happens the easy fix is to just reset the upper band to > VERY_SMALL and also to reset mem_sp but I am hoping that this > won't be needed if the lpc values were in the right range. Bounds checking and resets aren't the way to go. Fixing the source of the problem is. Did you actually test with speexenc/speexdec BTW. I'm beginning to suspect you're...

Hi, I have a curious problem with speex. As long as I'm talking, it takes about 2-5% of my CPU. This seems ok. But as soon as I stop talking, CPU utilization rises to about 30-45% and stays there until I start talking again. I compiled speex from source and use it with these settings: - Preprocessor: Denoiser = ON, AGC = ON - Encoder: ABR = 15000, DTX = 1, Mode = narrowband, Rate = 8000 Hz.

A little more info on this: I backtracked deeper into this and it looks like excBuf is corrupted, which is corrupted by low_innov_alias being invalid. However it is not entirely clear where that gets initialized (in sb_celp it is set to out+st->frame_size) Tom

...here's no issue with the patches, next week isn't too late. > > Also, I've started looking at your patches. So far there's one thing > that puzzles me a bit. In the OPUS_CHECK_ASM section of patch 0004, you > have: > > + celt_assert(ABS32(xy1_c - *xy1) <= VERY_SMALL); > > Given the normal range of the values (the xy values are often much > larger than one) and the precision involved here (24-bit mantissa), it > seems like this test can only succeed if the two values are actually > equal. Is the float patch actually bit-exact? If so, then maybe y...

...spx_coef_t; typedef spx_word16_t spx_lsp_t; typedef spx_word32_t spx_sig_t; #define LPC_SCALING 8192 #define SIG_SCALING 16384 #define LSP_SCALING 8192. #define GAMMA_SCALING 32768. #define GAIN_SCALING 64 #define GAIN_SCALING_1 0.015625 #define LPC_SHIFT 13 #define SIG_SHIFT 14 #define VERY_SMALL 0 #ifdef ARM5E_ASM #include "fixed_arm5e.h" #elif defined (ARM4_ASM) #include "fixed_arm4.h" #elif defined (FIXED_DEBUG) #include "fixed_debug.h" #elif defined (C55X_ASM) #include "fixed_c55x.h" #else #include "fixed_generic.h" #endif #else ty...

Hi Jean-Marc, I attached the new version in inner_prod_5patches_v2.zip which synced to the current master. For fixed-point ARM, only 0003-Optimize-fixed-point-celt _inner_prod-and-dual_inner_.patch changes the performance. For floating-point ARM, only 0004-Optimize-floating-point-c elt_inner_prod-and-dual_inn.patch changes the performance. Patch 1 and 2 are code clean-up and can only affect x86