similar to: mdf -- better adaption of W?

>> I'll need to add support for saving audio to my program, so I can give you >> the "actual" sampled loudspeaker and mic files, and I'll also need to get >> hold of a test person again. (I had a friend with a friend who has an >> exceptionally clear voice. My own "aaaaaa" is far too muddy to cause >> this). I'll try to get this done

>> Actually, computing the "power spectrum" for each frame of W shows >> how large an ammount of the original signal at time offset j the >> echo canceller thinks should be removed from the current input frame. > > Careful when looking at W because of how the real and imaginary parts > are packed in the array. Err. Ok, as I got it, 'bin 0' has it's

> Generate a test signal (10+x sine waves per frame), where x increases by > one for each iteration, and wraps around at 100. Testing with sine waves is usually not a good idea. If you intend on cancelling speech, then test with speech. > First off, it seems W is stored 'backwards'. The first values are for the > oldest frame, ok :) right. > However, when peeking at the

> Err. Ok, as I got it, 'bin 0' has it's amplitude in W[0], bin 1 to N-1 has > it's real part in W[i*2-1] and it's imag in W[i*2], and finally the > nyquist amplitude is in W[N-1] Not quite, it's packet "real, real, imag, real, imag, ...". > I took this from how power_spectrum() computes, so I might be off :) But power_spectrum() handles that

Hi, I'm still working on visualizing the echo canceller, but I discovered something that might be interresting. During testing, i did this: Generate a test signal (10+x sine waves per frame), where x increases by one for each iteration, and wraps around at 100. Set the speaker signal for the frame to the test signal. Add 0.5*test signal to the mic signal. When watching the power graph

> Actually, computing the "power spectrum" for each frame of W shows > how large an ammount of the original signal at time offset j the > echo canceller thinks should be removed from the current input frame. Careful when looking at W because of how the real and imaginary parts are packed in the array. > If you compute W*X for each j and ifft, you'll get the >

>> Generate a test signal (10+x sine waves per frame), where x increases by >> one for each iteration, and wraps around at 100. > > Testing with sine waves is usually not a good idea. If you intend on > cancelling speech, then test with speech. Ok, I tested more extensively with both music and two-way speech. More on this below. >> However, when peeking at the

Hi, I made a small error in the impulse reponse function; when doing the inverse fft in fixed point, it will overflow unless it's properly scaled. This patch uses the same scaling as that used when updating the filters, and the outputs now have the same shape and the same scale in fixed and floating point. Best regards, Thorvald -------------- next part -------------- diff -ubBwr

Actually, it looks like this is already done in Speex as of revision 7150 in SVN (7/15/2004). As long as HAVE_CONFIG_H is defined in the project settings (which it is in all of the project files in SVN), win32\config.h should be included, and this has #define inline __inline in it. Oleg - you should make sure HAVE_CONFIG_H is defined in your project settings. And, you didn't say which

Ok, I figured it out. :) This seems to work: 1) Call speex_bits_read_from() once, specifying the location in memory of the compressed data, and the total length of that data. 2) Keep calling speex_decode() until speex_bits_remaining() returns 0. Then you don't have to keep track of the # of frames per packet, or the size of each compressed frame. It's done magically by the codec.

I implemented the calcPower(). It works perfectly. The example is given you in just about 6 hours. Cant paste the whole source here and need to meet someone now. Thanks all (particulary tom). I try to figure out whitch problem exists with the #define SPEEX_PREPROCESS_SET_PROB_START 14 theese days ----- Original Message ----- From: "¼Õ½Â¿ø" <ssw0725@ncsoft.net> To: "Tom

This is a really good point, and definitely a recurring theme on this mailing list. :) I wonder, what are some better options for handling this issue, other than to keep saying "just use 8/16/32kHz"? - Extend Speex to support other sample rates (seems unlikely..?) - Integrate a resampling algorithm into libspeex - Maintain a list of recommended resampling libraries that work well

agc_gain seemed to fit with the idea of what I wanted to do, it was easy to understand its units and behavior, and freezing it produced the desired results. Also I wanted to cap it, so that's done at the same place, and that definitely works. All I want to do is be able to freeze AGC adaptation and put an upper bound on the AGC (for example, 2x amplification). Both of these things seem

Hi All, I am getting this error during make. please help me./ speexec.c: In function `speex_ec_process': speexec.c:112: syntax error before "noise" cc1: warnings being treated as errors speexec.c:133: warning: implicit declaration of function `speex_echo_state_reset' speexec.c:148: warning: passing arg 5 of `speex_echo_cancel' makes pointer from integer without a cast

Hi I just upgraded to http://svn.xiph.org/trunk/speex r10357 and got this build warning: alfredh@io:$ make -s mdf.o libspeex/mdf.c: In function 'speex_echo_cancel': libspeex/mdf.c:321: warning: statement with no effect libspeex/mdf.c:317: warning: `adapt_rate' might be used uninitialized in this function Is this intentional? In any case here is a simple fix: Index:

Hello... I want to ask you something about your software implementation of MDF filter with DTD machanism. (mdf.c speex_echo.h files) My questions are: 1. What are theoretical (using in your articles) equivalents of index symbols from your program? 2. Could you describe or give me an algorith which was using during software implementation of the MDF+DTD 3. How I could freeze MDF by means of DTD

The latest SVN version breaks mdf.c when running without fixed point. Patch: Index: mdf.c =================================================================== --- mdf.c (revision 10563) +++ mdf.c (working copy) @@ -169,6 +169,8 @@ acc[i+1] += (X[i+1]*Y[i] + X[i]*Y[i+1]); } acc[i] += X[i]*Y[i]; + X += N; + Y += N; } } #endif

Hi, I have a very large ".mdf" database (36 GB) that I want to import to R. I'm using a computer with 64 GB of RAM, running on windows server 2008 R2 with SQL. Could anyone guide me through the process. I have absolutely no idea what to do. Thanks, Mauricio Romero [[alternative HTML version deleted]]

Hi, I'm still trying to implement speex AEC into my VOIP project and I have some problrm with MDF filter response. I have plots of ref(near-end), y(filter response) signals and from plots I obtain that filter response is to small so when i substruct it from ref signal there is no efect. Is there any way to make filter giving response about ref signal amplitude? /Przemek Stajniak.

Hi, I would like to compute the inverse FFT of the MDF coefficients. I have noticed that some coefficients are obviously missing since I do not see the mirror effect, neither find the purely real frequency 0 coefficent that have to be found for a "real" signal. I guess the frequency 0 coefficient is 0 (average energy 0), but how should I do the mirroring and how many coefficients should