similar to: Attempting to shrink speex: Are these functions necessary?

I'm glad to hear that my data size can be shrunk considerably, however I do not know the minimum values that I would set the static arrays to be. I hate to be a bother but could you tell me the minimum values for these arrays/structures in the state structure? Thanks! encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch

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.

I noticed that in the narrow band and wide band destroy functions only the main pointer is being freed. I think that it should be: void nb_decoder_destroy(void *state) { DecState *st; st=(DecState*)state; speex_free (st->inBuf); speex_free (st->excBuf); speex_free (st->innov); speex_free (st->interp_qlpc); speex_free (st->qlsp); speex_free

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

> 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

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

When updating the speex sources from svn tree, I found that the following revision has corrupted the deallocation (segmentation fault): ------------------------------------------------------------------------ r9320 | jm | 2005-05-27 15:05:05 -0300 (Fri, 27 May 2005) | 2 lines Proper de-allocation When compiling with the 9316, everything works fine. but when I update with later

Hi, So 9316 works and 9320 doesn't? How about latest SVN. I just ran everything in valgrind and saw no error at all. Can you give more info on how to reproduce (with speexenc)? Jean-Marc Le mercredi 22 juin 2005 ? 21:19 -0300, Dario Andrade a ?crit : > > > When updating the speex sources from svn tree, I found that the > following revision has corrupted the deallocation

for the bits init I am using speex_bits_set_bit_buffer and I don't use the write to or read from because the data is already in the buffer I am reading from and I am writing to the final buffer so I don't need to move arrays around. what part is the vocoder part of the decode? Thanks for your help! -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/06/07

Hi, I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has a severe program space problem and will not fit speex in its normal operation. In an attempt to shrink speex I placed a breakpoint in every function and ran a decode and encode and removed the breakpoints that I hit. in the functions that had a breakpoint that I didn't hit I commented out those functions (as well as

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

On 02/20/2018 06:48 PM, Rodriguez, Vince wrote: > I am trying to get the library to build without using the pseudostack > define, and use either VAR_ARRAYS or ALLOC, but it seems the global > stack is not defined. Not sure what you mean here. If your compiler supports C99 VLAs, then by all means just define VAR_ARRAYS and you're good to go. If not, the second best option is alloca(),

Description =========== This patch adds support of CMake meta build system, so you can generate Unix makefiles, VS 6.0-2017 projects and many more. Features ======== * Win32 and Linux tested * Travis CI test added * Generates working Visual Studio 6.0-2017 solutions * Generates working Unix Makefile * Supported options (<option> - <default value>): * `ENABLE_FLOATING_POINT` - on

I am trying to implement a relatively high number of encoders (24/32) on a single DSP and would like to minimize the memory requirements. Has anyone optimized the persistent EncState memory allocation for multiple channels. The default C64x fixed point implementation allocates 5280 bytes of persistent memory per encoder. I'm willing to restrict my settings to complexity 1, quality 3. It

Did you try replacing the create() with separate malloc() and init() steps. If so, which of the two was causing the problems? BTW, you need a C99 compiler for VAR_ARRAYS to work, although you may be able to use USE_ALLOCA. Jean-Marc On 05/27/2013 08:36 AM, Fezin E T wrote: > Guys, > > Program stack is getting overflowed when I create and destroy encoder > instance continuously for

Hi All, Another issue is the memory allocations distributed so many places that it's hard to provide a single memory initial function interface. In a VoIP case on ARM, the total memory size for speex codec should be known at the inital stage since all the memories are allocated at the initial stage. In my current implementation, all the memory allocations are collected together to form

Tom Harper a ?crit : > 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) While looking for the problem, I ended up fixing two other things that could be

eds to drag in the source and header files from the libcelt directory into = the project and define HAVE_CONFIG_H is the project's pre-processor definit= ion. The tricky part is to build a config.h file. To get it to work on VS some = of the important settings include. =20 #define CELT_BUILD #define USE_ALLOCA #undef VAR_ARRAYS #undef restrict #undef HAVE_STDINT_H #undef inline #define

Jean-Marc Valin wrote: > That's quite strange. The only thing I can say is that the bug is most > likely *not* around line 414. It's probably some sort of memory > corruption somewhere else (quite possibly outside of Speex). Do you have > any more information? What CPU? What's the value of best_ntarget[j]? Is > SSE enabled? What's the allocation method

> Another issue is the memory allocations distributed so many places that > it's hard to provide a single memory initial function interface. > > In a VoIP case on ARM, the total memory size for speex codec should be > known at the inital stage since all the memories are allocated > at the initial stage. If you want everything in the same big block, all you need to do is