Michael Jacobson
2007-Aug-07 06:16 UTC
[Speex-dev] Attempting to shrink speex: Are these functions necessary?
I'm glad to hear that my data size can be shrunk considerably, however I do not 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 C5x are 16-bit long. You might be able to pack the values in one 16-bit value and unpack in the code. As for the memory allocation in the encoder, the best is to use C99 variable-size arrays (VAR_ARRAYS) or alloca (USE_ALLOCA). Otherwise, you can make the static array much smaller. For 8 kbps, the total RAM requirement (not counting code or static tables) should be around 4 kB (2 kWords). Jean-Marc Michael Jacobson a ?crit :> Hi, > > I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has > a severe program space problem and will not fit speex in its normal > operation. In an attempt to shrink speex I placed a breakpoint in every > function and ran a decode and encode and removed the breakpoints that I > hit. in the functions that had a breakpoint that I didn't hit I > commented out those functions (as well as some functions that I know I > won't hit). > > I am aware that some of these functions are only not called because I > don't do a GET_ in the ctl functions or don't use ALLOC to initialize > the bit buffer, but some of these I am not entirely sure why they would > or would not be used. I would like to know if they are just rarely > called functions and that I could be breaking the codec by removing them > or if all that I removed is just fine. > > I did get a .patch file from Jim Crichton as well to shrink nb_celp, > but is there anything else I can do to shrink the code or am I reaching > my limit? Thanks. > > > these are the functions that I removed: > > In bits.c: > speex_bits_init > speex_bits_init_buffer > speex_bits_destroy > speex_bits_reset > speex_bits_rewind > speex_bits_read_from > speex_bits_flush > speex_bits_read_whole_bytes > speex_bits_write > speex_bits_write_whole_bytes > speex_bits_unpack_signed > speex_bits_peek_unsigned > speex_bits_peek > speex_bits_nbytes > speex_bits_insert_terminator > > In cd_search.c: > noise_codebook_quant > noise_codebook_unquant > > In filters.c: > compute_rms > syn_percep_zero16 > qmf_decomp > qmf_synth > > In ltp.c: > forced_pitch_quant > forced_pitch_unquant > > In math_approx.c: > spx_ilog2 > _spx_cos_pi_2 > spx_cos_norm > spx_exp2 > spx_atan > > In nb_celp.c: > nb_encoder_destroy > nb_decoder_destroy > > In quant_lsp.c: > lsp_quant_nb > lsp_unquant_nb > lsp_quant_high > lsp_unquant_high > > In speex.c: > speex_encoder_destroy > speex_decoder_destroy > speex_encode > speex_decode > nb_mode_query > wb_mode_query > speex_lib_ctl > > In speex_callbacks.c: > speex_inband_handler > speex_std_mode_request_handler > speex_std_low_mode_request_handler > speex_std_high_mode_request_handler > speex_std_vbr_request_handler > speex_std_enh_request_handler > speex_std_vbr_quality_request_handler > speex_std_char_handler > speex_default_user_handler > > In vbr.c: > vbr_analysis > vbr_destroy > > In vq.c: > vq_index > vq_nbest_sign > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20070807/030d0634/attachment.htm
Jean-Marc Valin
2007-Aug-07 06:34 UTC
[Speex-dev] Attempting to shrink speex: Are these functions necessary?
Michael Jacobson a ?crit :> I'm glad to hear that my data size can be shrunk considerably, > however I do not 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_gainWhat 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 way to measure (it's platform-dependent to some extent), the easiest is to fill the memory with 0xdeadbeef and see how far gets written. The amount of stack used is exactly the same every time you encode or decode. Jean-Marc>>>> 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 C5x are > 16-bit long. You might be able to pack the values in one 16-bit value > and unpack in the code. As for the memory allocation in the encoder, > the best is to use C99 variable-size arrays (VAR_ARRAYS) or alloca > (USE_ALLOCA). Otherwise, you can make the static array much smaller. > For 8 kbps, the total RAM requirement (not counting code or static > tables) should be around 4 kB (2 kWords). > > Jean-Marc > > Michael Jacobson a ?crit : >> Hi, >> >> I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that >> has a severe program space problem and will not fit speex in its >> normal operation. In an attempt to shrink speex I placed a >> breakpoint in every function and ran a decode and encode and >> removed the breakpoints that I hit. in the functions that had a >> breakpoint that I didn't hit I commented out those functions (as >> well as some functions that I know I won't hit). >> >> I am aware that some of these functions are only not called because >> I don't do a GET_ in the ctl functions or don't use ALLOC to >> initialize the bit buffer, but some of these I am not entirely sure >> why they would or would not be used. I would like to know if they >> are just rarely called functions and that I could be breaking the >> codec by removing them or if all that I removed is just fine. >> >> I did get a .patch file from Jim Crichton as well to shrink >> nb_celp, but is there anything else I can do to shrink the code or >> am I reaching my limit? Thanks. >> >> >> these are the functions that I removed: >> >> In bits.c: speex_bits_init speex_bits_init_buffer >> speex_bits_destroy speex_bits_reset speex_bits_rewind >> speex_bits_read_from speex_bits_flush speex_bits_read_whole_bytes >> speex_bits_write speex_bits_write_whole_bytes >> speex_bits_unpack_signed speex_bits_peek_unsigned speex_bits_peek >> speex_bits_nbytes speex_bits_insert_terminator >> >> In cd_search.c: noise_codebook_quant noise_codebook_unquant >> >> In filters.c: compute_rms syn_percep_zero16 qmf_decomp qmf_synth >> >> In ltp.c: forced_pitch_quant forced_pitch_unquant >> >> In math_approx.c: spx_ilog2 _spx_cos_pi_2 spx_cos_norm spx_exp2 >> spx_atan >> >> In nb_celp.c: nb_encoder_destroy nb_decoder_destroy >> >> In quant_lsp.c: lsp_quant_nb lsp_unquant_nb lsp_quant_high >> lsp_unquant_high >> >> In speex.c: speex_encoder_destroy speex_decoder_destroy >> speex_encode speex_decode nb_mode_query wb_mode_query speex_lib_ctl >> >> >> In speex_callbacks.c: speex_inband_handler >> speex_std_mode_request_handler speex_std_low_mode_request_handler >> speex_std_high_mode_request_handler speex_std_vbr_request_handler >> speex_std_enh_request_handler speex_std_vbr_quality_request_handler >> speex_std_char_handler speex_default_user_handler >> >> In vbr.c: vbr_analysis vbr_destroy >> >> In vq.c: vq_index vq_nbest_sign >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ Speex-dev mailing >> list Speex-dev@xiph.org >> http://lists.xiph.org/mailman/listinfo/speex-dev > > > > > ------------------------------------------------------------------------ > > > _______________________________________________ Speex-dev mailing > list Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev