search for: bitptr

...or packing bits together... the original one is : ------------------------------------------------------------------------------------------------------------- void speex_bits_pack(SpeexBits *bits, int data, int nbBits) { int i; unsigned int d=data; if (bits->bytePtr+((nbBits+bits->bitPtr)>>3) >= bits->buf_size) { //remain unchanged.... } while(nbBits) { int bit; bit = (d>>(nbBits-1))&1; bits->bytes[bits->bytePtr] |= bit<<(7-bits->bitPtr); bits->bitPtr++; if (bits->bitPtr==8) {...

i'm optimizing some features....for exemple why not doing this : ------------------------------------------------------------------------------- void speex_bits_advance(SpeexBits *bits, int n) { if (((bits->bytePtr<<3)+bits->bitPtr+n>bits->nbBits) || bits->overflow){ bits->overflow=1; return; } bits->bytePtr += (bits->bitPtr+nbBits) >> 3; //divide by 8 bits->bitPtr = (bits->bitPtr+nbBits) & 7; // modulo by 8 } ----------------------------------------------------------...

After searching the mailing list archive (I forgot to do that before posting, sorry!) I found the solutions: 1) The documentation has a mistake: The bit terminator is NOT set automatically! (I'm using the latest speex version!) It has to be set manually using speex_bits_insert_terminator(&bits); 2) speex_decoder_int() has to be called as long, as it returns -1. After that, all frames

...RT void speex_bits_reset(SpeexBits *bits) { /* We only need to clear the first byte now */ bits->chars[0]=0; @@ -99,14 +99,14 @@ bits->overflow=0; } -void speex_bits_rewind(SpeexBits *bits) +EXPORT void speex_bits_rewind(SpeexBits *bits) { bits->charPtr=0; bits->bitPtr=0; bits->overflow=0; } -void speex_bits_read_from(SpeexBits *bits, char *chars, int len) +EXPORT void speex_bits_read_from(SpeexBits *bits, char *chars, int len) { int i; int nchars = len / BYTES_PER_CHAR; @@ -153,7 +153,7 @@ bits->charPtr=0; } -void speex_bits_read_who...

...RT void speex_bits_reset(SpeexBits *bits) { /* We only need to clear the first byte now */ bits->chars[0]=0; @@ -99,14 +99,14 @@ bits->overflow=0; } -void speex_bits_rewind(SpeexBits *bits) +EXPORT void speex_bits_rewind(SpeexBits *bits) { bits->charPtr=0; bits->bitPtr=0; bits->overflow=0; } -void speex_bits_read_from(SpeexBits *bits, char *chars, int len) +EXPORT void speex_bits_read_from(SpeexBits *bits, char *chars, int len) { int i; int nchars = len / BYTES_PER_CHAR; @@ -153,7 +153,7 @@ bits->charPtr=0; } -void speex_bits_read_who...

...he speex bits... void speex_bits_read_from_buffer( SpeexBits * const bits, void * const buff, const int buf_size) { bits->bytes = (char*)buff; bits->buf_size = buf_size; bits->nbBits = buf_size << 3; bits->bytePtr = 0; bits->bitPtr = 0; bits->owner = 0; bits->overflow = 0; } ... so a bitstream can be assigned to a SpeexBits structure for processing by a decoder rather than unnecessarily copying the data. As an aside, I'm working on a certain high profile embedded game's console at the moment and...

An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20091029/e587399d/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: tmezo.vcf Type: text/x-vcard Size: 345 bytes Desc: not available Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20091029/e587399d/attachment.vcf

...de looks like this void speex_bits_read_from(SpeexBits *bits, char *chars, int len) { ////////////////// bla-bla-bla /////////////////// for (i=0;i<len;i++) bits->chars[i]=chars[i]; bits->nbBits=len<<3; //!!!!!!!!!!!!!!!!!!! bits->charPtr=0; bits->bitPtr=0; bits->overflow=0; } What is bits->nbBits=len<<3 ? Shouldn't it be bits->nbBits=len<<3 LOG2_BITS_PER_CHAR ? And another question. What is the difference between functions speex_bits_read_from and speex_bits_read_whole_bytes ? Thanks! -------------- next part -...

...nit(mode); } Maybe following codes that I have been using in a class can help you. /* structs */ public struct SpeexBits { char *chars; /* "raw" data */ int nbBits; /* Total number of bits stored in the stream*/ int charPtr; /* Position of the byte "cursor" */ int bitPtr; /* Position of the bit "cursor" within the current char */ int owner; /* Does the struct "own" the "raw" buffer (member "chars") */ int overflow; /* Set to one if we try to read past the valid data */ int buf_size; /* Allocated size for buffer *...

...ime >> to >> figure out what that means or what causes it, but will if I get time. > > I just fixed a but in bits.c (see Jim's previous email), maybe that was > the cause. Yes, that's right. speex_bits_insert_terminator keeps calling speex_pack_bits forever, because bitPtr never reaches 15. Eventually the bit buffer runs out of room. >> 5) Re: stack memory allocations, yes, a compile-time option would be >> great >> to reduce the stack sizes. Ideally what is needed is the minimum stack >> usage >> so that us embedded developers can...

...uffer( > SpeexBits * const bits, > void * const buff, > const int buf_size) > { > bits->bytes = (char*)buff; > bits->buf_size = buf_size; > bits->nbBits = buf_size << 3; > bits->bytePtr = 0; > bits->bitPtr = 0; > bits->owner = 0; > bits->overflow = 0; > } > > ... so a bitstream can be assigned to a SpeexBits structure for > processing by a decoder rather than unnecessarily copying the data. > > > As an aside, I'm working on a certain high profile...

...to use P/Invoke to use speex in C#. This is a part of my code. [StructLayout(LayoutKind.Sequential)] public struct SpeexBits { IntPtr chars; // "raw" data int nbBits; // Total number of bits stored in the stream int charPtr; // Position of the byte "cursor" int bitPtr; // Position of the bit "cursor" within the current char int owner; // Does the struct "own" the "raw" buffer (member "chars") int overflow; // Set to one if we try to read past the valid data int buf_size; // Allocated size for buffer int res...

...ons change the results, since there is a > significant performance penalty in using them. I'm sure you'll still get a low MIPS count after we find the fix to fixed_generic.h. > Yes, that's right. speex_bits_insert_terminator keeps calling > speex_pack_bits forever, because bitPtr never reaches 15. Eventually the > bit buffer runs out of room. Good, that explains other problems I've seen. Jean-Marc -- Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> Universite de Sherbrooke

...<<((b)&31)) ^ (((b)&32)>>5) ) ) -1 ) \ + & 0xffffffff ) /* spans forward, skipping as many bytes as headend is negative; if headend is zero, simply finds next byte. If we're up to the end @@ -80,7 +74,7 @@ /* Read in bits without advancing the bitptr; bits <= 32 */ long oggpack_look(oggpack_buffer *b,int bits){ - unsigned long m=mask[bits]; + unsigned long m=MASK(bits); unsigned long ret; bits+=b->headbit; @@ -229,15 +223,15 @@ int tbit=bits?bits:ilog(b[i]); if((test=oggpack_look(&r,tbit))==0xffffffff) repo...

...st int Speex_nb_Mode = 3; //create the structure that will hold the speexbits public struct SpeexBits { public char *chars; /* "raw" data */ public int nbBits; /* Total number of bits stored in thestream*/ public int charPtr; /* Position of the byte "cursor" */ public int bitPtr; /* Position of the bit "cursor" within thecurrent char */ public int owner; /* Does the struct "own" the "raw" buffer(member "chars") */ public int overflow; /* Set to one if we try to read past thevalid data */ public int buf_size; /* Allocated size for...

...tructure SpeexBits Public chars As IntPtr ' "raw" data Public nbBits As Integer ' Total number of bits stored in thestream Public charPtr As Integer ' Position of the byte "cursor" Public bitPtr As Integer ' Position of the bit "cursor" within thecurrent char Public owner As Integer ' Does the struct "own" the "raw" buffer(member "chars") Public overflow As Integer ' Set to one if w...

...>> a >> significant performance penalty in using them. > > I'm sure you'll still get a low MIPS count after we find the fix to > fixed_generic.h. > >> Yes, that's right. speex_bits_insert_terminator keeps calling >> speex_pack_bits forever, because bitPtr never reaches 15. Eventually the >> bit buffer runs out of room. > > Good, that explains other problems I've seen. - Jim Crichton

...will hold the speexbits > > public struct SpeexBits > > { > > public char *chars; /* "raw" data */ > > public int nbBits; /* Total number of bits stored in thestream*/ > > public int charPtr; /* Position of the byte "cursor" */ > > public int bitPtr; /* Position of the bit "cursor" within thecurrent char */ > > public int owner; /* Does the struct "own" the "raw" buffer(member "chars") */ > > public int overflow; /* Set to one if we try to read past thevalid data */ > > public int buf_s...

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.