similar to: Deallocation of buffers

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

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

Thank you, I really appreciate the help. -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/07/07 8:34 AM >>> Michael Jacobson a ?crit : > 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 >

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

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

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

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

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

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 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 Alfred, >I am currently trying to port speex v1.1.6 to a microcontroller with >very limited memory (<64Kbyte RAM). if forced to the wall, you can try below (need to "rewrite" the code a little): unless i am very much mistaken, you can do "dynamic allocation" for some of the memory. these memories are only required when you are running eg speex_encode for the

Hi Steve, thanks for the advice. I placed the appropriate functions outside the while statement but I still get this error at the while loop: First-chance exception at 0x004010fa in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. Unhandled exception at 0x004010fa in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. It looks like the same error. I've

hey guys, I just compiled an application similar to sampledec.c (for speex 1.1.10) and it was fine but when I executed it, the app exited without doing anything. I'm using MS VC 6.0 and this was all I got - First-chance exception in sampledec.exe : 0xC0000005: Access Violation. Has anyone encountered this / does anyone know how to deal with it? by the way, sampleenc executed perfectly... When

Hello! I was using Speex all the time, and I am now moving to Opus. I had encapsulated the decoder a bit, I had the following cpp file: #include "StdAfx.h" #include "spxcodec.h" #define MAX_FRAME_SIZE 2000 #define MAX_FRAME_BYTES 2000 CSpxCodec::CSpxCodec() : enh(1), rate(8000) { } CSpxCodec::~CSpxCodec() { } void CSpxCodec::Init() { speex_bits_init(&bits);

Hello, some misc. cleanup patches for speexdsp, nothing big I'm not sure about how to submit patches, so this is a test balloon :) ultimately, I'd like to fix the FIXED_POINT issue, see http://lists.xiph.org/pipermail/speex-dev/2013-December/008465.html currently, I think the only way to find out how speexdsp has been compiled is to resample some bytes and observe the output; which is

Hi, I'm one of the people working on the Rockbox project (http://www.rockbox.org) which is an open source alternative firmware for a range Digital Audio Players. Recently we integrated support for the Speex codec using libspeex and seems to work well. If you could add Rockbox to your list of software that supports Speex, that'd be great. So that's the introduction done. Now for