search for: nb_modes

Sorry. First error file is not "modes.c" but "modes_noglobals.c". ________________________________ From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of ¼Õ½Â¿ø Sent: Friday, January 20, 2006 11:40 AM To: speex-dev@xiph.org Subject: [Speex-dev] Compile error (svn 10743) Hi, I've received svn 10743 revision. But there are compile errors at

Hi, I've received svn 10743 revision. But there are compile errors at three files with VS2005. Please check these reports. Sohn, Platform system engineer. ============================================================================= 1. modes.c - nb_mode_new() SpeexNBMode * nb_mode; nb_mode = (SpeexNBMode *) speex_alloc (sizeof (SpeexNBMode)); if (nb_mode == NULL) return NULL;

Hi, If I use --enable-fixed-point-debug I can't use --enable-fixed-point and vice versa? Because when I try to copile with these two option an error occur as follows: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I.. -I/home/liselene/projects/speex/speex-1.1.11.1/bin-fixed/include -g -O2 -MT modes.lo -MD -MP -MF .deps/modes.Tpo -c modes.c -fPIC -DPIC -o .libs/modes.o

Hi I am currently trying to port speex v1.1.6 to a microcontroller with very limited memory (<64Kbyte RAM). what I found when initialising the encoder, a chunk of 32Kb was attempted to be alloced, which failed: src/nb_celp.c: void *nb_encoder_init(const SpeexMode *m) { /* snip */ st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(spx_sig_t)); /* snip */ } same goes for the

> The C5x and C6x output diverges in build 10143, which has log message "lpc > floor converted to fixed-point." Also, the measured SNR changed from 11.05 > in builds 9854-10141 to 9.22 and 9.24 in 10143. Actually, build 10143 introduced another bug, that was the reason for the 1.1.11.1 release. > There is just four lines in modes.c which declare the constant, and one

This is going to take some explaining and I apologize in advance if any of this is found in the manual or sample code but I couldn't find it. I just graduated last may and this is my first experience with vocoders and dissecting a professional's code. I work for a company that is currently using a G729A vocoder from a 3rd party software company and is looking into speex so they no

...still be some tuning do to on > the DTX. > > Jean-Marc > > > diff -u -r1.118 sb_celp.c > --- sb_celp.c 18 Mar 2003 06:13:30 -0000 1.118 > +++ sb_celp.c 4 May 2003 04:58:16 -0000 > @@ -351,6 +351,8 @@ > int modeid; > modeid = mode->nb_modes-1; > st->relative_quality+=1.0*(ratio+2); > + if (st->relative_quality<-1) > + st->relative_quality=-1; > while (modeid) > { > int v1; > @@ -361,7 +363,7 @@ > else > thre...

Hi Alfred, First thing I'd like to ask is whether you're trying to achieve real-time performance, as I find it very unlikely that Speex could run in real-time on a micro-controller. Regarding bufSize, no you can't just make it the size you like. Now, it's possible to decrease the amount of memory allocated if e.g. you only use complexity 1. You can also assume that the stack is

On Tue, 2005-12-06 at 16:30 -0400, Liselene Borges wrote: > Hi, > > If I use --enable-fixed-point-debug I can't use --enable-fixed-point > and vice versa? Because when I try to copile with these two option an > error occur > as follows: No, you really need to enable both. This is a bug in 1.1.11 and I just fixed it in svn. I haven't tested the fix, so can you confirm

Jean Marc, >> The C5x and C6x output diverges in build 10143, which has log message >> "lpc >> floor converted to fixed-point." Also, the measured SNR changed from >> 11.05 >> in builds 9854-10141 to 9.22 and 9.24 in 10143. > >Actually, build 10143 introduced another bug, that was the reason for >the 1.1.11.1 release. > >> There is just

Hello opus-dev, I've been cooking up this patchset to integrate NE10 library into opus. Current patchset focuses on encode use case mainly effecting performance of clt_mdct_forward() and opus_fft() (for float only) Glad to report the following on Encode use case: (Measured on my Beaglebone Black Cortex-A8 board) - Performance improvement for encode use case ~= 12.34% (Based on time -p

...HIS + SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +*/ + +#include <stdio.h> +#include <stdlib.h> +#include "modes.h" +#include "dump_modes_arch.h" +#include <NE10_dsp.h> + +static FILE *file; + +void dump_modes_arch_init(CELTMode **modes, int nb_modes) +{ + int i; + + file = fopen(ARM_NE10_ARCH_FILE_NAME, "w"); + fprintf(file, "/* The contents of this file was automatically generated by\n"); + fprintf(file, " * dump_mode_arm_ne10.c with arguments:"); + for (i=0;i<nb_modes;i++) + { + CELTMode *mod...

Jean-Marc, >> Build 11169 in SVN works correctly. > > Good. I'll try not to forget the EXTEND32 from now on. > >> I have attached a zip file (renamed >> .txt) with a patch to bits.c to make the byteswapping for TI DSPs >> consistent. > > Seems like unzip can't read it. Either it's in an unknown format or the > file got corrupted. Could simply

...NE10_ARCH_FILE_NAME); > + fprintf(file, "#endif\n"); At least if you do generate the files on a system without NE10, and then build on a system with NE10, this will fail, which is probably the right thing. > @@ -205,7 +220,6 @@ void dump_modes(FILE *file, CELTMode **modes, int nb_modes) > fprintf(file, "#endif\n"); > fprintf(file, "\n"); > > - > /* Print the actual mode data */ > fprintf(file, "static const CELTMode mode%d_%d_%d = {\n", mode->Fs, mdctSize, mode->overlap); > fprintf(fi...

...ump_modes/dump_modes.c @@ -35,6 +35,7 @@ #include "modes.h" #include "celt.h" #include "rate.h" +#include "dump_modes_arch.h" #define INT16 "%d" #define INT32 "%d" @@ -62,6 +63,10 @@ void dump_modes(FILE *file, CELTMode **modes, int nb_modes) fprintf(file, "\n It contains static definitions for some pre-defined modes. */\n"); fprintf(file, "#include \"modes.h\"\n"); fprintf(file, "#include \"rate.h\"\n"); + fprintf(file, "\n#ifdef HAVE_ARM_NE10\n"); + fprintf...

...ump_modes/dump_modes.c @@ -35,6 +35,7 @@ #include "modes.h" #include "celt.h" #include "rate.h" +#include "dump_modes_arch.h" #define INT16 "%d" #define INT32 "%d" @@ -62,6 +63,10 @@ void dump_modes(FILE *file, CELTMode **modes, int nb_modes) fprintf(file, "\n It contains static definitions for some pre-defined modes. */\n"); fprintf(file, "#include \"modes.h\"\n"); fprintf(file, "#include \"rate.h\"\n"); + fprintf(file, "\n#ifdef HAVE_ARM_NE10\n"); + fprintf...

...ump_modes/dump_modes.c @@ -35,6 +35,7 @@ #include "modes.h" #include "celt.h" #include "rate.h" +#include "dump_modes_arch.h" #define INT16 "%d" #define INT32 "%d" @@ -62,6 +63,10 @@ void dump_modes(FILE *file, CELTMode **modes, int nb_modes) fprintf(file, "\n It contains static definitions for some pre-defined modes. */\n"); fprintf(file, "#include \"modes.h\"\n"); fprintf(file, "#include \"rate.h\"\n"); + fprintf(file, "\n#ifdef HAVE_ARM_NE10\n"); + fprintf...

Jean-Marc was correct in that the 16bit value was the culprit for my encoding woes. after I changed that to a 32 bit value I believe it encodes correctly, but I really don't have much of any way to know this absolutely. I am using the 1.2beta2. I would use the enctest program, I have looked it over and based a lot of what I am doing on that code but the project I am developing this on is

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You