search for: pi_gain

...ot know the minimum values that I would set the static arrays to be. I hate to be a bother but could you tell me the minimum values for these arrays/structures in the state structure? Thanks! encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch decode: stack excBuf interp_qlpc old_qlsp mem_sp pi_gain >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/06/07 7:04 PM >>> Last thing. All the codebooks are stored as tables of char, so you're probably wasting a lot of space from the fact that chars on...

...t;inBuf); speex_free (st->excBuf); speex_free (st->innov); speex_free (st->interp_qlpc); speex_free (st->qlsp); speex_free (st->old_qlsp); speex_free (st->interp_qlsp); speex_free (st->mem_sp); speex_free (st->comb_mem); speex_free (st->pi_gain); speex_free (st); } This would apply to the encoder destroy functions also. -Fritz On2 Technologies, Inc. http://www.on2.com

...t I would set the static > arrays to be. I hate to be a bother but could you tell me the > minimum values for these arrays/structures in the state structure? > Thanks! > > encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp > mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch > > decode: stack excBuf interp_qlpc old_qlsp mem_sp pi_gain What I meant is that you can reduce the stack part (assuming you're not already using VAR_ARRAYS or USE_ALLOCA). The other variables above still require the same size they are currently using. For the stack, the easiest...

...tiply goes to INF (this can also happen in the non-sse code). I am working on figuring out why this is happening. With the new changes also filter_ratio went to 0 in one of my tests, in part because rh was INF. This is around the section where I think you made changes to how you calculate st->pi_gain[sub]. This caused scale to go to INF further down in the code when scale is calculated. Again, this I think stems from the lpc function producing some INF and IND values so I think that is just a symptom. I can add bounds checking to the SSE code but I don't know what to do regarding the lpc...

.... I am working on figuring out why > this is happening. Can you leave SSE out of that for now? > With the new changes also filter_ratio went to 0 in one of my > tests, in part because rh was INF. This is around the section > where I think you made changes to how you calculate st->pi_gain[sub]. > This caused scale to go to INF further down in the code when > scale is calculated. Again, this I think stems from the lpc function > producing some INF and IND values so I think that is just a symptom. > > I can add bounds checking to the SSE code but I don't know >...

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

...1); } st->mem_sp = speex_alloc((st->lpcSize)*sizeof(spx_mem_t)); st->mem_sw = speex_alloc((st->lpcSize)*sizeof(spx_mem_t)); st->mem_sw_whole = speex_alloc((st->lpcSize)*sizeof(spx_mem_t)); st->mem_exc = speex_alloc((st->lpcSize)*sizeof(spx_mem_t)); st->pi_gain = speex_alloc((st->nbSubframes)*sizeof(spx_word32_t)); st->pitch = speex_alloc((st->nbSubframes)*sizeof(int)); st->vbr = speex_alloc(sizeof(VBRState)); vbr_init(st->vbr); st->vbr_quality = 8; st->vbr_enabled = 0; st->vad_enabled = 0; st->dtx_enabled...