search for: very_smalls

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

Hi Jean-Marc, I recompiled with FIXED_POINT and CPU utilization stays below 4%. This is a great improvement. So how can I fix this to work with floating point ? Thanks. Mark -----Urspr?ngliche Nachricht----- Von: Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] Betreff: Re: [Speex-dev] High CPU usage Hi, Sound like it could be the good old denormalised float problem on the Intel

Mark Schilling a ?crit : > I recompiled with FIXED_POINT and CPU utilization stays below 4%. This is a great improvement. > So how can I fix this to work with floating point ? OK, so it looks a lot like a denorm problem. The issue is basically that there are filters that decay exponentially, so when the input suddenly goes to zero, then the filter's output value becomes smaller and

>>> Linfeng Zhang <linfengz at google.com> schrieb am 06.06.2017 um 06:46 in Nachricht <CAKoqLCAfj+fDUMLfN4dLNSZ4NNAZpaSt_BWZRp+7XBqfhiSqiQ at mail.gmail.com>: > Hi Jean-Marc, > > I tried "==" before, and it failed when both results are 0.0. Maybe the > exponent or sign has difference because of the different 0.0 representation > in NEON. If anybody

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 --denoise --agc --abr 15000

Hi Linfeng, On 05/06/17 03:31 PM, Linfeng Zhang wrote: > Yes we'll have one more patch set related to xcorr in next week. Please > don't wait if it's too late 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

I emailed Jean-Marc the arch.h about one week ago, not quite sure whether he actually received that email. Anyway, here I have an improved version of arch.h that I believe that it would be better, to use __int64 only if compiling on eMbedded Visual C++ compiler, so for any other compiler, keep it the same (use long long) ---------------------------------- Chan Kei Yuen (Kenji)

Jean Marc- Thanks for looking into this- I think I needed to give you a bit more info! Sorry for such a vague initial report. So most of these problems seem to be coming from the lsp_to_lpc function. In particular the following: xout1 = xin1 - 2.f*x_freq[i2] * *n1 + *n2; xout2 = xin2 - 2.f*x_freq[i2+1] * *n3 + *n4; ... in the floating point version this code can

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 =

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

> Thanks for looking into this- I think I needed to give you a > bit more info! Sorry for such a vague initial report. > > So most of these problems seem to be coming > from the lsp_to_lpc function. In particular the following: > xout1 = xin1 - 2.f*x_freq[i2] * *n1 + *n2; > xout2 = xin2 - 2.f*x_freq[i2+1] * *n3 + *n4; > > ... in the floating

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

Hi Jean-Marc, I tried "==" before, and it failed when both results are 0.0. Maybe the exponent or sign has difference because of the different 0.0 representation in NEON. If anybody know how to handle this 0.0 comparison, that would be great. Or just use if(a==b || (a==0.0 && b==0.0)) ... but I haven't try this. Thanks, Linfeng On Mon, Jun 5, 2017 at 8:43 PM Jean-Marc

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 1) We need our own "fixed_xx.h" header file. I don't know why, and haven't had time to investigate, but there is a definite improvement when I use the attached fixed_c55x.h file which has turned all the maths into inline functions.

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