<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16481" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>Thank you, I really appreciate the help.</DIV>
<DIV> </DIV>
<DIV>-Mike<BR><BR>>>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/07/07 8:34 AM >>><BR></DIV>
<DIV style="COLOR: #000000">Michael Jacobson a écrit :<BR>> I'm glad to hear that my data size can be shrunk considerably,<BR>> however I do not know the minimum values that I would set the static<BR>> arrays to be. I hate to be a bother but could you tell me the<BR>> minimum values for these arrays/structures in the state structure?<BR>> Thanks!<BR>> <BR>> encode: stack winBuf excBuf swBuf lagWindow old_lsp old_qlsp mem_sp <BR>> mem_sw mem_sw_whole mem_exc mem_exc2 pi_gain pitch<BR>> <BR>> decode: stack excBuf interp_qlpc old_qlsp mem_sp pi_gain<BR><BR>What I meant is that you can reduce the stack part (assuming you're not<BR>already using VAR_ARRAYS or USE_ALLOCA). The other variables above still<BR>require the same size they are currently using. For the stack, the<BR>easiest way to measure (it's platform-dependent to some extent), the<BR>easiest is to fill the memory with 0xdeadbeef and see how far gets<BR>written. The amount of stack used is exactly the same every time you<BR>encode or decode.<BR><BR> Jean-Marc<BR><BR><BR>>>>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/06/07 7:04<BR>>>>> PM >>><BR>> <BR>> Last thing. All the codebooks are stored as tables of char, so you're<BR>> probably wasting a lot of space from the fact that chars on C5x are <BR>> 16-bit long. You might be able to pack the values in one 16-bit value<BR>> and unpack in the code. As for the memory allocation in the encoder,<BR>> the best is to use C99 variable-size arrays (VAR_ARRAYS) or alloca <BR>> (USE_ALLOCA). Otherwise, you can make the static array much smaller.<BR>> For 8 kbps, the total RAM requirement (not counting code or static<BR>> tables) should be around 4 kB (2 kWords).<BR>> <BR>> Jean-Marc<BR>> <BR>> Michael Jacobson a écrit :<BR>>> Hi,<BR>>> <BR>>> I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that<BR>>> has a severe program space problem and will not fit speex in its<BR>>> normal operation. In an attempt to shrink speex I placed a<BR>>> breakpoint in every function and ran a decode and encode and<BR>>> removed the breakpoints that I hit. in the functions that had a<BR>>> breakpoint that I didn't hit I commented out those functions (as<BR>>> well as some functions that I know I won't hit).<BR>>> <BR>>> I am aware that some of these functions are only not called because<BR>>> I don't do a GET_ in the ctl functions or don't use ALLOC to<BR>>> initialize the bit buffer, but some of these I am not entirely sure<BR>>> why they would or would not be used. I would like to know if they<BR>>> are just rarely called functions and that I could be breaking the<BR>>> codec by removing them or if all that I removed is just fine.<BR>>> <BR>>> I did get a .patch file from Jim Crichton as well to shrink<BR>>> nb_celp, but is there anything else I can do to shrink the code or<BR>>> am I reaching my limit? Thanks.<BR>>> <BR>>> <BR>>> these are the functions that I removed:<BR>>> <BR>>> In bits.c: speex_bits_init speex_bits_init_buffer <BR>>> speex_bits_destroy speex_bits_reset speex_bits_rewind <BR>>> speex_bits_read_from speex_bits_flush speex_bits_read_whole_bytes <BR>>> speex_bits_write speex_bits_write_whole_bytes <BR>>> speex_bits_unpack_signed speex_bits_peek_unsigned speex_bits_peek <BR>>> speex_bits_nbytes speex_bits_insert_terminator<BR>>> <BR>>> In cd_search.c: noise_codebook_quant noise_codebook_unquant<BR>>> <BR>>> In filters.c: compute_rms syn_percep_zero16 qmf_decomp qmf_synth<BR>>> <BR>>> In ltp.c: forced_pitch_quant forced_pitch_unquant<BR>>> <BR>>> In math_approx.c: spx_ilog2 _spx_cos_pi_2 spx_cos_norm spx_exp2 <BR>>> spx_atan<BR>>> <BR>>> In nb_celp.c: nb_encoder_destroy nb_decoder_destroy<BR>>> <BR>>> In quant_lsp.c: lsp_quant_nb lsp_unquant_nb lsp_quant_high <BR>>> lsp_unquant_high<BR>>> <BR>>> In speex.c: speex_encoder_destroy speex_decoder_destroy <BR>>> speex_encode speex_decode nb_mode_query wb_mode_query speex_lib_ctl<BR>>> <BR>>> <BR>>> In speex_callbacks.c: speex_inband_handler <BR>>> speex_std_mode_request_handler speex_std_low_mode_request_handler <BR>>> speex_std_high_mode_request_handler speex_std_vbr_request_handler <BR>>> speex_std_enh_request_handler speex_std_vbr_quality_request_handler<BR>>> speex_std_char_handler speex_default_user_handler<BR>>> <BR>>> In vbr.c: vbr_analysis vbr_destroy<BR>>> <BR>>> In vq.c: vq_index vq_nbest_sign<BR>>> <BR>>> <BR>>> <BR>>> <BR>>> <BR>>> ------------------------------------------------------------------------<BR>>> <BR>>> <BR>>> _______________________________________________ Speex-dev mailing<BR>>> list Speex-dev@xiph.org <BR>>> <A href="http://lists.xiph.org/mailman/listinfo/speex-dev">http://lists.xiph.org/mailman/listinfo/speex-dev</A><BR>> <BR>> <BR>> <BR>> <BR>> ------------------------------------------------------------------------<BR>> <BR>> <BR>> _______________________________________________ Speex-dev mailing<BR>> list Speex-dev@xiph.org <BR>> <A href="http://lists.xiph.org/mailman/listinfo/speex-dev">http://lists.xiph.org/mailman/listinfo/speex-dev</A><BR></DIV></BODY></HTML>