search for: leak_estimate

Hi I have a question about the AEC and preprocessor. I have seen that when near end is talking for a longer time (about 10 s) without being interrupted by the far end the residual echo (or rather leak_estimate) increases making the preprocessor suppress the near end talk when it shouldn't. Is there a way to make the leakage estimate only update when far-end is present or similar in order to avoid this behavior? If I need to implement this myself, does it make sense to put some kind of far_end thres...

...mate over time) Pey += Eh*Yh; Pyy += Yh*Yh; it goes too large for floating point, which seems to be caused by extremely large values in st->Rf[j], st->Yf[j] and smaller values in st->Eh[j], st->Yh[j]- things were relatively quiet environmentally speaking. Anyhow, leak_estimate would then go to undefined, which would mess up r, which would mess up power_1[], which would then mess up some things in weighted_spectral_mul_conj, etc. There may be other issues but this is the one that makes the most sense as to causing the silence issue- for now, I just put a finite check on...

...this function Is this intentional? In any case here is a simple fix: Index: libspeex/mdf.c =================================================================== --- libspeex/mdf.c (revision 10357) +++ libspeex/mdf.c (working copy) @@ -314,11 +314,10 @@ /*printf ("%f\n", leak_estimate);*/ } - float adapt_rate; + float adapt_rate = 0; if (!st->adapted) { float Sxx; - adapt_rate; Sxx = inner_prod(st->x+st->frame_size, st->x+st->frame_size, st->frame_size); /* We consider that the filter is adapted if the following...

...t; Pyy += Yh*Yh; > > it goes too large for floating point, which seems to be caused by > extremely > large values in st->Rf[j], st->Yf[j] and smaller values in st->Eh[j], > st->Yh[j]- > things were relatively quiet environmentally speaking. > > Anyhow, leak_estimate would then go to undefined, which would mess up > r, which would mess up power_1[], which would then mess up some > things in weighted_spectral_mul_conj, etc. > > There may be other issues but this is the one that makes the > most sense as to causing the silence issue- for now, I j...

Hi, I've added visualization of the speex noise cancellation to my program. I did this by taking st->noise[] and st->ps[], scale both by 1.0/(st->ps_size * 32768.0) (to get a value between 0.0 and 1.0), and then draw them as a realtime lineplot. This works well, and my users like being able to see roughly what frequency bands they have noise in and compare it to their input

Hello Jean-Marc, When you count the adaptation step size in case where the filter has already had minimal adaptation, you use the following expression: r = (0.7*r + 0.3*15*RER*e)/e*(power[i] + 10) = (0.7*leak_estimate*Yf[i] + 0.3*15*RER*(Rf[i] + 1))/((Rf[i] + 1)*(power[i] + 10)). Why do we need this weighted sum and the component 0.3*15*RER*(Rf[i] + 1)? Why use the correlation-based RER if we can do the same in the frequency domain? If we removed this component, the expression would be exactly like in the met...

Jean-Marc, I have traced the second infinite loop further. When st->adapted becomes true (mdf.c line 623), the first Yf[i] value is 4, the leak_estimate is 0xd4e, the resulting r is 3. The first value in st->Rf is 0, so e is 1, and r is set to e>>1, or 0. A little later there is a divide by r, and there is the hang. It seems that the 0 in Rf[0] is the problem, but I am not sure what else to look at there. The first few 32-bit value...

> When you count the adaptation step size in case where the filter has already had > minimal adaptation, you use the following expression: > > r = (0.7*r + 0.3*15*RER*e)/e*(power[i] + 10) = (0.7*leak_estimate*Yf[i] + > 0.3*15*RER*(Rf[i] + 1))/((Rf[i] + 1)*(power[i] + 10)). Actually, the QCONST16(.3,15) doesn't mean (.3*15), but the value .3 in Q15 format (fixed-point). > Why do we need this weighted sum and the component 0.3*15*RER*(Rf[i] + 1)? First, the reason for multiplying by (Rf[i]+...

> I am writing to gain a better understanding of the limitations of speex echo > cancellation, esp. with respect to the fixed point implementation. > If these limitations have been documented elsewhere already, please let me > know! Nothing officially documented, sorry. > I observe experimentally that when one or both of the echo or ref data for > speex_echo_cancel() have

Hi: I'm using speex to perform echo cancellation in Windows. I'm aware of the problem about out of sync clocks in record and play sample rates in usual sound cards . In order to have an idea of how good is my echo cancelation working I would like to know if there is any #define thing i can pass to speex_echo_ctl to get the actual level of echo cancellation. If not, how can i extract that

...n FLOAT_DIVU() it hangs at the following: > while (a.m >= b.m) > { > e++; > a.m >>= 1; > } > for the case where a and b are both zero (yes, division by zero). > This happens from mdf.c: True, that needs to be fixed even after I fix the rest. > leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); > where st->Pey and st->Pyy are both zero, which happens for the following input > data to testecho program: > -- first arg is file containing sine wave of magnitude +/- 32767 > -- 2nd arg is file containing all...

Thanks for your prompt and helpful reply. In FLOAT_DIVU() it hangs at the following: while (a.m >= b.m) { e++; a.m >>= 1; } for the case where a and b are both zero (yes, division by zero). This happens from mdf.c: leak_estimate = FLOAT_EXTRACT16(FLOAT_SHL(FLOAT_DIVU(st->Pey, st->Pyy),14)); where st->Pey and st->Pyy are both zero, which happens for the following input data to testecho program: -- first arg is file containing sine wave of magnitude +/- 32767 -- 2nd arg is file containing all zeroes The divisio...