[Speex-dev] Attempting to shrink speex: Are these functions necessary?

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Mon Aug 6 17:04:03 PDT 2007


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 at xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev


More information about the Speex-dev mailing list