similar to: Optimal frame size to use for file compression?

> -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, December 14, 2006 2:51 AM > To: Miles, Stewart > Cc: speex-dev@xiph.org > Subject: Re: [Speex-dev] Would be nice to conditionally > compile out coding modes and code tables... > > Miles, Stewart a ?crit : > > I'm only using the narrow-band encoder

Hello there, I thought I would contribute to this wonderful project but noting a simple but problematic bug in speex_bits_read_whole_bytes(). SITUATION: I have a large stream of frames with NO breaks or length indicators inbetween each frame. For this reason, I call speex_bits_read_whole_bytes() and fill it to MAXIMUM in a loop while calling speex_decode() until there are no more bytes to read.

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

diffed against http://svn.xiph.org/trunk/speex r9583 Index: libspeex/sb_celp.c =================================================================== --- libspeex/sb_celp.c (revision 9583) +++ libspeex/sb_celp.c (working copy) @@ -272,7 +272,6 @@ st->g0_mem=speex_alloc((QMF_ORDER)*sizeof(spx_word32_t)); st->g1_mem=speex_alloc((QMF_ORDER)*sizeof(spx_word32_t)); -

Itay, >I am trying these things, but the main problem that has been bothering >me recently is that the fixed-point algorithm works "sometimes". Meaning >that sometimes it will work well, and other times it will not work at >all. > >I think I've found the source of the problem. The speex_alloc() >function, called by speex_echo_state_init(), calls calloc() and

Hi, I'm trying a quick port of this terrific codec to uClinux, a Linux-derivate for mmu-less systems. I'm particulary interested in the alloc()'s the library does, and it's stack usage. In nb_celp.c I found two lines of code doing memory allocation : nb_celp.c: st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(float)); nb_celp.c: st =

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

>> There is a bit of work remaining to get the memory usage down for a >> multichannel application. There have been some good posts over the >> last couple of months about reducing memory usage. > > I think 1.1.8 incorporates all memory reductions proposed. Let me know > otherwise. For the persistent storage, the only change that I have made is to MAX_CHARS_PER_FRAME,

On Tue, 2005-03-01 at 04:31 -0500, Jean-Marc Valin wrote: > Hi, > > I just checked in some changes that remove some unnecessary buffers > (exc2 and buf2) and that reduce other buffers to the minimum. That > should save 7800 bytes for the encoder. > > Jean-Marc > thanks, I have merged the diff in $ svn merge-r 8996:8997 http://svn.xiph.org/trunk/speex to my codebase.

Can anyone tell me why the size of st is defined as: st = (EncState*)speex_alloc(sizeof(EncState)+8000*sizeof(float)); Reference: nb_encode_init function. Specifically, I would like to know why 8000 floats are allocated? Thanks and regards, Vinay -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks Jean-Marc, >What you want is simply to override some of the functions in misc.c. I >made it easy to do by wrapping malloc() a speex_alloc() call. Aside from >what's in misc.c, the only other thing I use are some of the math >functions like cos(). That makes sense. But how does the DLL version, which is not linked to the C runtime, get access to C's transcendental

For me, this was a memory allocation problem. I am using a private heap, and somewhere between build 11522 and 11700, the allocation for two large buffers was changed from calloc to speex_alloc (I am sure that this was a cleanup change, and I have not had a chance to locate it yet). This was overrunning my heap, and enlarging the heap solved the problem. I suspect that Itay is having a

OK, I fixed it but: 1) you shouldn't be using the MAX_BYTES_PER_FRAME constant (just moved it to the .c where it belongs) 2) if you read more than MAX_BYTES_PER_FRAME the buffer will resize automatically, so there's no problem. Just use the size you want. Jean-Marc Le lun 25/08/2003 à 02:27, Thomas S a écrit : > Hello there, > I thought I would contribute to this wonderful

Hi, I am facing a problem with my Voice Communication application. I am using the Speex API, and have based my application on the given example files sampleenc.c and sampledec.c. I'm using the OpenAL SDK for voice capture. I have provided below the two main functions within which the problem exists. "Compress()" and "Decompress()". Below the code for these functions, I

In speex_alloc.h The following code #ifdef USE_ALLOCA #include <alloca.h> #endif should be: #ifdef USE_ALLOCA #ifdef WIN32 #include <malloc.h> #else #include <alloca.h> #endif #endif for visual studio at least. Not sure about mingw Aron Rosenberg www.sightspeed.com

> -----Message d'origine----- > De : Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca] > Envoy? : lundi, 15. juin 2009 01:30 > ? : Stephane Lesage > Cc : speex-dev at xiph.org > Objet : Re: [Speex-dev] Resampler saturation, blackfin performance > > - are there buffers who could be placed in scratch memory ? > > (I don't see any speex_scratch_alloc

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

> I followed your advice on running the trivial case. The float version > started cancelling sounds out within a second. The fixed point > version also worked, but took a little longer before the effect was > noticeable. Since I now realized the fixed point version might need a > little more tweaking than the float version, I started modifying some > things and ended up with the

Hi, Just a couple tips to reduce complexity. First, I think you'd get a good speedup by enabling the PRECISION16 switch (if it's not done already). This (very) slightly reduces quality, but means you convert a lot of "emulated" 16x32 multiplications into 16x16. There are also several routines that would benefit from platform-specific optimizations. There are already