search for: speex_pack_bit

...ot; messages. I haven't had time >> 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...

...at why Stuart's inline functions 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

...hange 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. - Jim Crichton

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.