search for: max_bytes_per_fram

..._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. SYMPTOM: You can only go up to MAX_BYTES_PER_FRAME-1 due an incorrect calculation in the function. LINES THAT ARE THE PROBLEM: ((bits->nbBits>>3)+len+1 should read ((bits->nbBits+7)>>3)+len otherwise if nbBits is 0 or a full byte, the buffer will never get to MAX_BYTES_PER_FRAME. __________________________________ Do you Yahoo!...

...hat is a good frame size to use if I capture the entire audio stream first and then want to compress it for later playback. I noticed that the example encoder code calls: speex_bits_init(&bits); and I notice that this has the following memory allocation: bits->bytes = (char*)speex_alloc(MAX_BYTES_PER_FRAME); bits->buf_size = MAX_BYTES_PER_FRAME; Somewhere else I noticed that MAX_BYTES_PER_FRAME is #defined to be 2000. So I think the maximum practical value for a frame size is around 1000 samples although we could go higher if we could predict the compression. So what is a good practical value...

...of the library are released as the old code with the magic allocation size will fail. Determining whether an allocation is possible at compile time is far more preferable than at run-time. Which leads me to another point of irritation. I noticed that you stated that people shouldn't be using MAX_BYTES_PER_FRAME to reserve space for the output of the encoder and that it's far better to just allow speex_bits to realloc it's out of space http://lists.xiph.org/pipermail/speex-dev/2003-August/000515.html . For a lot of embedded systems it's very important to know ahead of time how much memory is...

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

...I have merged the diff in $ svn merge-r 8996:8997 http://svn.xiph.org/trunk/speex to my codebase. it works as expected, nb_celp.c stacksize is reduced to: encoder: stack usage: 8811 stack size : 9000 decoder: stack usage: 2719 stack size : 2800 what about this value in bits.c: #define MAX_BYTES_PER_FRAME 2000 now there is _almost_ enough RAM to allocate both encoder and decoder ;) /alfred > > when removing "spx_sig_t *orig;" in the encoder, the stack usage > > went from 17091 to 16451 bytes, > > > > I have already got a working decoder running on my Ubico...

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

...remaining to support the various fixed point TI DSPs after the work that you did at the end of May (thank you for this). arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x and older C64x does not) bits.c: Allow external definition for max buffer size, change MAX_BYTES_PER_FRAME to MAX_CHARS_PER_FRAME for consistency misc.c: Added override switches to alloc routines, conditional include of user file changes to allow manual memory allocation rather than using heap Note that none of these changes are necessary to get Speex to run on C55x. The arch.h chang...

...xed > point TI DSPs after the work that you did at the end of May (thank you for > this). > > arch.h: Add switch for compilers not supporting "long long" (C55x does, C54x > and older C64x does not) > bits.c: Allow external definition for max buffer size, change > MAX_BYTES_PER_FRAME > to MAX_CHARS_PER_FRAME for consistency > misc.c: Added override switches to alloc routines, conditional include of > user file > changes to allow manual memory allocation rather than using heap > > Note that none of these changes are necessary to get Speex to...

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