similar to: AEC init crashes

Sorry, I've forgot to mention init params: Frame_size is 441 samples and filter_length is 4096. ..don't think it makes any sense though.. Regards, Anton A. Shpakovsky From: speex-dev-bounces at xiph.org [mailto:speex-dev-bounces at xiph.org] On Behalf Of Anton A. Shpakovsky Sent: Tuesday, June 15, 2010 4:15 PM To: speex-dev at xiph.org Subject: [Speex-dev] AEC init crashes

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

Jean-Marc, >> I incorporated Stuarts fixed_c55x.h file, and that eliminated the >> artifacts, >> at the expense of a ~30% increase in MIPs. Now the male.wav file through >> encoder/decoder produces a bit-exact match with the C64x test that I did >> earlier. I will do some more testing to isolate the, but it may be a few >> days before I get to this task. As

> I was wrong, it is the encoder that is not working, and it stopped working > in build 11103. The log message for this build is "another 640 bytes > removed from the encoder state (using the input data instead of copying it > to st->frame/st->inBuf)". Only nb_celp.c/h are changed in this build. What > I am seeing out of the decoder is an extremely low signal

Hi Jean-Marc, As I told you, bank is a reserved keyword in Analog Devices compiler for Blackfin architecture. So we need to change the variables named bank to something else. Here's a patch that changes bank to bnk in the 3 concerned files. (Hope the format is OK) About my previous problems with the Blackfin: -> strange block repetition that could be cancelled by the AEC I was busy

Jean-Marc, Last week I tried the SVN code (build 11700) on the TI C55x DSP, and found that operation was broken again. I traced this to build 11522, committed on 5 June. The problem is in lsp.c, function lsp_to_lpc(). The line (lsp.c line 461 in build 11700): xin = 1<<(QIMP-1); /* 0.5 in QIMP format */ evaluates to zero. The following change corrects the problem: xin =

Hi all, This is Linfeng Zhang from Google. I'll work on ARM NEON optimization in the next few months. I'm submitting 2 patches in the following couple of emails, which have the new created celt_fir_neon(). I revised celt_fir_c() to not pass in argument "mem" in Patch 1. If there are concerns to this change, please let me know. Many thanks to your comments. Linfeng Zhang

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

> Nice call. The culprit is SHRL32. This is not used in many places, and in > most of those, the operand comes from EXTEND32. The only really suspicious > instances is in lsp.c (lsp_interpolate): > > spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); > (subframe is an int) > ... > I see that your changes include adding an EXTEND32 to the line above.

Hi Anton Thanks for the info... What if I use this function do I still need to sync the playback and capture? Assuming that the captured voice (*rec) already contains the echo which I need to cancel out... -------------------------------- void speex_echo_capture (SpeexEchoState *st, const spx_int16_t *rec, spx_int16_t *out) Parameters: st Echo canceller state rec signal

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

Hello, I would like to test the echo cancel algorithm available in unstable version 1.1.4. This echo canceller can be used with other codecs like G711? Somebody could send me some documentation or sample, or explain the next functions: SpeexEchoState *speex_echo_state_init(int frame_size, int filter_length); void speex_echo_state_destroy(SpeexEchoState *st); void

If more than one speaker receives the *same* signal, it doesn't matter the number of speakers. It only gets tricky when the speakers are playing slightly different signals (e.g. from a stereo song). Jean-Marc Quoting Greger Burman <greger at mobile-robotics.com>: > One thing I can think of is if you are using two or more speakers. If the > speakers are not at the exact same

Hi Jean-Marc, I did what you proposed. I changed the levinson durbin algorithm to: { int i, j; spx_word16_t r; spx_word16_t error = ac[0]; for (i = 0; i < p; i++) lpc[i] = 0; if (ac[0] == 0) { //for (i = 0; i < p; i++) // lpc[i] = 0; return 0; } for (i = 0; i < p; i++) { /* Sum up this iteration's reflection coefficient

Hi Jean-Marc, Hi Jim, I have also seen some problems with the 1.1.8 release on the C55x. So far I have boiled down the issues to the following: 1) We need our own "fixed_xx.h" header file. I don't know why, and haven't had time to investigate, but there is a definite improvement when I use the attached fixed_c55x.h file which has turned all the maths into inline functions.

>> Nice call. The culprit is SHRL32. This is not used in many places, and >> in >> most of those, the operand comes from EXTEND32. The only really >> suspicious >> instances is in lsp.c (lsp_interpolate): >> >> spx_word16_t tmp = DIV32_16(SHL32(1 + subframe,14),nb_subframes); >> (subframe is an int) >> ... >> I see that your

Hi, I'm using speex 1.1.4 and when I query SPEEX_GET_SAMPLING_RATE as in speex_encoder_ctl ( m_pEncoderState, SPEEX_GET_SAMPLING_RATE, &m_SampleRate ); I get 2 The encoder is initialized with m_pEncoderState = speex_encoder_init ( &speex_wb_mode ); On the decoder side, the correct sampling rate is returned: m_pDecoderState = speex_decoder_init ( &speex_wb_mode );

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Hello. I have the following situation. AEC is used in network chat software over DirectSound API. Echo and reference signals are almost aligned (delay is no more than 30ms). When echo is emulated in notebook (built-in speakers + mic) everything goes fine and echo is cancelled. But when configuration includes stand-alone speakers and mic no echo is removed. Audio is in 22050 hz at 16 bit

Hi, Ref the disucussion on IRC yesterday; here's a patch which makes a bit more data from the analysis of the preprocessor and the echo canceller available. For the preprocessor: - Size of power spectrum. - Power spectrum and noise estimate of the previous frame. These are given as squared values, so sqrt() to get values in the 0->32767 range. - Current amplification level