search for: pitch_xcorr

...compute_weighted_codebook(const signed char *shape_cb, const spx_word16_t *r, ..... So it appears the arm version has arg 2 defined differently so I am getting this error. So am I missing something or is this what it should do ? I am using GCC 3.4.4. The second warning is in ltp_arm4.h in "pitch_xcorr(" getting a warning of: "matching constraint does not allow a register" on the " __asm__ __volatile__ " line. I have no idea how to fix this warning. Even with these errors I have gotten decoding to work YEAH!!. It appears to take about 10 to 11 msec to decode one fra...

> OK, I forgot to update the ARM4 code. That should definitely be fixed > (otherwise it's not going to work). If this is not going to work then why does it work on my Arm? Any quick fix I can do for now? > > The second warning is in ltp_arm4.h in "pitch_xcorr(" getting a warning of: > > "matching constraint does not allow a register" on the " __asm__ > > __volatile__ " line. I have no idea how to fix this warning. > > can you give me more info on this? Not sure what info will help but here it goes... I am us...

...all to compute_weighted_codebook of: > "passing arg 2 of 'compute_weighted_codebook' from incompatible pointer type' OK, I forgot to update the ARM4 code. That should definitely be fixed (otherwise it's not going to work). > The second warning is in ltp_arm4.h in "pitch_xcorr(" getting a warning of: > "matching constraint does not allow a register" on the " __asm__ > __volatile__ " line. I have no idea how to fix this warning. can you give me more info on this? > Even with these errors I have gotten decoding to work YEAH!!. It &g...

Hi all, i'm using speex under symbian. When i have compiled the lib for ARM platform i have obtained the follow error: "Error: Can not represent OFFSET_IMM8 relocation in this object file format (1)" I have defined FIXED_POINT 1 and ARM4_ASM. The error is in the function forced_pitch_quant contained in ltp.c. The line that produce the error is:

....Running some benchmarks for the codec i found out that i have almost 90% cpu utilisation.It was about 19 ms every 20 ms frame .Reading other posts i understood i should be waiting 60% with this core. After some research i found the main bottleneck lies in pitch calculation . The routine void pitch_xcorr(....)runs for (144-17)times and calls corr[nb_pitch-1-i]=inner_prod(_x, _y+i, len);. As i understood this is called len>>2=10 times .This function is called every 5ms.As i found out only this function needs 12 ms per 20 ms!!!!. So how is it possible to have a total utilisation of 60% with...

...x-A8. Results are: > - With xcorr_kernel_c(): 26.45s to encode > - With xcorr_kernel_neon_john1(): 24.86s to encode (~6%) > - With xcorr_kernel_neon_john2(): 24.4s to encode (~7.5%) > - With xcorr_kernel_neon_azanelli(): 24.15s to encode (~8.7%) > These functions have been inlined in pitch_xcorr(), celt_fir() and cel_iir. > > Furthermore, the funny thing is that an indirect call to > xcorr_kernel_azanelli is faster: 23.75s (~10%). However, I didin't test > the others. > > Also i fixed my assembly version to avoid read past "y" buffer and fix > register ga...

Jean-Marc Valin wrote on 8/20/2007 3:48 PM: > Hi Oleg, > > Turns out the problem was only triggered with DTX on. I just committed a > fix in svn/git. Let me know if it works for you now. > > Thanks again for reporting the bug. > > Jean-Marc > Thank you, problem is gone now! Oleg PS. I just finished math_approx.asm (speed optimized version for ARM). The code can be

..."L1", "R3" + : "P0", "P1", "P2", "R0", "R1", "A0", "I0", "I1", "L0", "L1", "R3", "ASTAT" BFIN_HWLOOP0_REGS ); return sum; } @@ -104,7 +106,8 @@ void pitch_xcorr(const spx_word16_t *_x, const spx_word16_t *_y, spx_word32_t *c "LOOP_END pitch%=;\n\t" "L0 = 0;\n\t" : : "m" (_x), "m" (_y), "m" (corr), "m" (len), "m" (nb_pitch) - : "A0", "A1", "P0&...

Unfortunately I don't have a setup that lets me easily profile ARM code, so I really can't tell which method is faster (though I suspect Mr. Zanelli's code is). Let me offer up another intrinsic version of the NEON xcorr_kernel that is almost identical to the SSE version, and more in line with Mr. Zanelli's code: static inline void xcorr_kernel_neon(const opus_val16 *x, const

...t_nb -T multicomb -T nb_decode -T nb_decoder_ctl -T nb_decoder_destroy -T nb_decoder_init -T nb_encode -T nb_encoder_ctl -T nb_encoder_destroy -T nb_encoder_init -T nb_mode_query -T noise_codebook_quant -T noise_codebook_unquant -T open_loop_nbest_pitch -T pitch_search_3tap -T pitch_unquant_3tap -T pitch_xcorr -T qmf_decomp -T qmf_synth -T residue_percep_zero16 -T sanitize_values32 -T sb_decode -T sb_decoder_ctl -T sb_decoder_destroy -T sb_decoder_init -T sb_encode -T sb_encoder_ctl -T sb_encoder_destroy -T sb_encoder_init -T scal_quant -T scal_quant32 -T signal_div -T signal_mul T speex_bits_advance T...

...t_nb -T multicomb -T nb_decode -T nb_decoder_ctl -T nb_decoder_destroy -T nb_decoder_init -T nb_encode -T nb_encoder_ctl -T nb_encoder_destroy -T nb_encoder_init -T nb_mode_query -T noise_codebook_quant -T noise_codebook_unquant -T open_loop_nbest_pitch -T pitch_search_3tap -T pitch_unquant_3tap -T pitch_xcorr -T qmf_decomp -T qmf_synth -T residue_percep_zero16 -T sanitize_values32 -T sb_decode -T sb_decoder_ctl -T sb_decoder_destroy -T sb_decoder_init -T sb_encode -T sb_encoder_ctl -T sb_encoder_destroy -T sb_encoder_init -T scal_quant -T scal_quant32 -T signal_div -T signal_mul T speex_bits_advance T...