similar to: Bug from revision 9316: SB_ENC_STACK misdefined

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

I am hoping to use Speex for a embedded project using Philips Arm processor (50 mips) 512kb flash 32kb ram. I found in the manual that decode takes about 0.5 mips so I should have enough processing power and I compiled the lib and it seems to take less then 64K so the only issue is memory usage. I have been testing the speex decode on windows looking at the stack usage and how much is malloc.

> > I have tested lowering these values and then running the speexdec > > program and looking for errors. By trial and error it appears that I > > can lower MAX_CHARS_PER_FRAME = 750, SB_DEC_STACK = > > 750*sizeof(spx_sig_t) and NB_DEC_STACK = 250*sizeof(spx_sig_t) > > and not get any memory errors but have no idea if these are safe > > values or not. I

On Mon, 2006-01-02 at 22:37 -0500, tom abcd wrote: > I am hoping to use Speex for a embedded project using Philips Arm > processor (50 mips) 512kb flash 32kb ram. I found in the manual that > decode takes about 0.5 mips so I should have enough processing power > and I compiled the lib and it seems to take less then 64K so the only > issue is memory usage. I have been testing 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 Mon, 2005-02-28 at 19:42 -0500, Jean-Marc Valin wrote: > > jean-marc: i think we can remove spx_sig_t *orig. > > but am not sure about exc2Buf. is it for extension? > > orig is already removed in SVN (which you should probably use). As for > exc2, it can be removed, but I'm not sure if you can just use exc > instead (maybe yes). > when removing "spx_sig_t

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 's' suffix on the cmp instruction is deprecated and superfluous since the cmp instruction always sets conditional flags. This fixes building for iOS with inline assembly enabled. --- libspeex/filters_arm4.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libspeex/filters_arm4.h b/libspeex/filters_arm4.h index 7a74042..2c64625 100644 ---

hi, jean-marc: i think we can remove spx_sig_t *orig. but am not sure about exc2Buf. is it for extension? rgds, tk On Mon, 28 Feb 2005 12:42:38 -0500, Jean-Marc Valin <Jean-Marc.Valin@usherbrooke.ca> wrote: > Hi, > > I looked at the code I think there are still places where you can reduce > memory. For example, I think bufSize can be reduced to around 400 > (instead of

Happy new year all! I have had a few issues with this sort of stuff- you could adjust NB_ENC_STACK or SB_ENC_STACK (which ever you may be fiddling with) and see if the problem goes away- could be the allocation for the vorbis psy tables takes up more space than the current stack size allows (not sure how allocated? Could be your settings for supporting alloca/etc. are set different than jm,

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

To close debian bug #271052, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271052 I went ahead and did the following: $ diff -u ../original/speex-1.1.6/libspeex/nb_celp.c libspeex/nb_celp.c --- ../original/speex-1.1.6/libspeex/nb_celp.c 2004-07-15 01:16:52.000000000 -0400 +++ libspeex/nb_celp.c 2005-02-27 08:24:49.000000000 -0500 @@ -1746,6 +1746,21 @@ st->submodeSelect =

Hi, I am bring SPEEX up on Analog Device's Blackfin (using Visual DSP++ tool set). The floating point was too slow on this fixed-point processor so I am going for the integer version. The floating point library build was very clean, but when I build with FIXED_POINT defined, the compiler exits when it find this discrepancy in \libspeex\cb_search.c : ".\libspeex\cb_search.c",

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

Hi, Jean-Marc, I have another quick question, I got following message when compile speexdec.exe: Linking... libspeex.lib(sb_celp.obj) : error LNK2001: unresolved external symbol _lpc_window Release/speexdec.exe : fatal error LNK1120: 1 unresolved externals Where does this lpc_window declare? Thanks a lot, -Allen On 8/8/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: >

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.

First, let me say that I think the speex code is incredible in the way it supports floating and fixed point code from one set of code. The same is true for supporting multiple processors, etc... I've used speex with the PC, TI 64xx and 55xx. Please view the following comments not as an attack on speex (which I think is incredible!) but as my contribution to an open source project. I know

You might not be doing anything wrong. Speex is stateful and can get into a bad state sometimes. It's happened to me too, but not recently. And I've seen such bugs reported on this list and fixed. I suggest several approaches to solving the problem: 1) Try compiling Speex without compiler optimizations and see if the problem still occurs. Most likely it will, but this is an

Most asm statements clobber ASTAT bits (shifts, maxes, etc...) but do declare the register as clobbered. Same thing with CC in a few places. Some places make an attempt at clobbering some hardware loop registers, but it's very incomplete compared with how many asm statements actually use hardware loops. Signed-off-by: Mike Frysinger <vapier at gentoo.org> --- libspeex/bfin.h

Speex 1.0 - in file sb_celp.c line 218 change speex_decoder_ctl(...) to speex_encoder_ctl(...): void *sb_encoder_init(SpeexMode *m) { . . . --> speex_decoder_ctl(st->st_low, SPEEX_GET_SAMPLING_RATE, &st->sampling_rate); // Replace <-- speex_encoder_ctl(st->st_low, SPEEX_GET_SAMPLING_RATE, &st->sampling_rate); st->sampling_rate*=2; return st; } --