similar to: SV: How to detect SpeexBits corruption

Hi, Basically, inner_prod() can and should be adapted to the architecture it will run on. It is not really sensitive to noise, so it's possible to tweak it a lot. Also, in the current code, I saturate it to +-16384, which is OK to prevent overflows. I'm not concerned with the case of a constant -16384 value because it can't really happen in practice (especially after filtering). BTW,

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

Ok, I hadn't verified inner product was called with values scaled to <= +-16384. That would make it safe to do a 32 bit add of the intermediate terms. I have implemented the 40-bit accumulator. > by the shift. I also see a FIXED_POINT danger with the summation of four > mults overflowing the 32 bit before the shift. > > I can fix this by accumulating each term into a long,

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

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Move the plane clip rectangle handling into drm_atomic_helper_check_plane_state(). Drivers no longer have to worry about such mundane details. v2: Convert armada, rcar, and sun4i as well Cc: Liviu Dudau <liviu.dudau at arm.com> Cc: Brian Starkey <brian.starkey at arm.com> Cc: Mali DP Maintainers <malidp at

Hello, I am from a small Czech software company (circletech.net) working on software for mobile phones. We are currently starting a development of an Voice IP software, and consider using speex for voice compression and decompression. The software will be Symbian OS C++ program. Is there anyone who has actually used speex Symbian OS port for realtime voice compression and decompression on mobile

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

Hello, im using speex library on my vo ip project, but some times, after it works ok, it begins to play noises (like voice hits) decoding the packets of one source (the others sound ok). I finally found that reseting SpeexBits and decoder state it solves. If i cant avoid this problem, i wish to solve when it occours, but ?how to detect this? Please, if anyone has experiment this issue i

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

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.

Revision 9316 introduced SB_ENC_STACK and friends, but misdefines SB_ENC_STACK to be too small, resulting in quite noticable artifacts in wideband mode as well as memory corruption and a crash (sooner or later). The patch below should return SB_ENC_STACK to be equal to what it replaced. Index: sb_celp.c =================================================================== --- sb_celp.c

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

Tom Grandgent a ?crit : > 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: Tom, can you give an example of how Speex can enter a "bad state"? I don't

Jean-Marc, I hate to say such things about Speex, especially when I've been unable to make such problems consistently reproducible. It takes a great deal of patience and effort to track down a rarely occurring problem like this in a production VOIP system. I ended up solving my problems by being more careful with the input to the encoder and switching to an SVN version of Speex. This

Greetings, I've just started porting speex to a TI C5509 DSP. It doesn't look like it's going to be too painful, but there are a couple of quirks about the C5x. 1) chars are 16 bits because memory addresses are for 16bit words 2) ints and short are also 16 bits (so sizeof(char) = sizeof(short) = sizeof(int) = 1) 3) the c5x is essentially big endian My plan is to change int and

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

You're doing something wrong. Read the documentation and check speechenc/dec just one more time. If that wouldn't help I'd suggest posting samples of your source code and describe what platform/compiler/os you're using. //JT -----Ursprungligt meddelande----- Fr?n: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] F?r jesus Skickat: den 22 januari 2007 19:43 Till:

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