similar to: High CPU usage

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

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

Hello vorbis developer! I'm not very experienced in informatics, cause i'm only an audio engineer and sorry for my broken english but i have an idea... After the filterbank the maximum aplitude in each band decides about the nessesary bits, then the psychoacoustic model decides how much of the signal can be truncated without hearable noise. What do you think about quantising the

Hello, Filterbank.c does not compile on visual studio because of the declaration of : int id1; int id2; in the filterbank_new() procedure (line 45) id1 and id2 must be compiled in the begin of the procedure... Ouss

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)

This patch updates the symbian build files to latest svn trunk, and also adds a new makefile for speexdsp. Signed-off-by: Alfred E. Heggestad <aeh@db.org> --- Index: symbian/speexdsp.mmp =================================================================== --- symbian/speexdsp.mmp (revision 0) +++ symbian/speexdsp.mmp (revision 0) @@ -0,0 +1,42 @@ +/* + Copyright (C) 2003 Commonwealth

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, VS2005 project (libspeex.vcproj) seems to be missing some files, most notably filterbank.c. Also some .h files but that doesn't really matter. Gregg

Hello, I am thinking about plugging in Discrete Wavelet Transform as described in Vorbis I spec: 1.1.2. Classification Vorbis I is a forward-adaptive monolithic transform CODEC based on the Modified Discrete Cosine Transform. The codec is structured to allow addition of a hybrid wavelet filterbank in Vorbis II to offer better transient response and reproduction using a transform better suited to

Hi, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

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

Hi again, I have improved precision of my codec (on the encoder and decoder).I have also improved the -h1 quality setting.-Source code and binaries at http://nhwcodec.blogspot.com/-. I am still trying to improve precision of my codec, with keeping my low-complexity (fast) approach. I do not totally use the reference (and impressive) block prediction with different modes + residual coding scheme,

> 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 all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

hi Jean-Marc, I just updated from svn and it looks like there are some errors in the speex.mmp file. the filters.c is duplicated, and the fft/kiss.c files are still missing.. /alfred Jean-Marc Valin wrote: > Applied in svn. Thanks. > > Jean-Marc > > Alfred E. Heggestad a ?crit : >> hi, >> >> this patch should fix the symbian build. >> >> >>

Applied in svn. Thanks. Jean-Marc Alfred E. Heggestad a ?crit : > hi, > > this patch should fix the symbian build. > > > /alfred > > > ------------------------------------------------------------------------ > > Index: symbian/bld.inf > =================================================================== > --- symbian/bld.inf (revision 12114) > +++

On 5/29/07, ALEX NG <alex@gorex.com.hk> wrote: > ok I used your code > it asks me > 1. resample.c > 2. filterbank.c > > why? Seems you're using Speex 1.2beta1 or earlier. Try out 1.2beta2 or svn version. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000

Hi all, (Sorry that may be duplicated that I was not a mail-list member before, so last mail sent failed) I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC

Hello, Definitely not any (constructive) comments on the NHW Image codec? According to my tests, it can compare good with reference codecs like x264 intra and WebP. Yes, the codec is still experimental and is optimized for visual (subjective) evaluation, not PSNR.Its main feature is again that it would have a little more neatness/sharpness and a little less precision (residual coding is applied