similar to: Anyone knows how microsoft AEC can deal with mismatches between clocks of capture and render streams?

Hi Shridhar, Sample rate conversion is not enough to solve this problem. I have tried this method several months ago. The first step is to measure the difference between sample rate of capturing and rendering. Then resampling (by what you said "sinc interpolation") one signal to eliminate the difference. The frequency step in my experiment is less than 0.1Hz. I have tried speex AEC

On 04/13/2011 02:58 AM, Shridhar, Vasant wrote: > I am doing this right now with no problem. I am not using speex for this at the moment though. Group delay is the biggest problem. I implemented a version where the input and output sample rates are known up front. The routine than interpolates between the jitter. This should solve the problem. The crystals used to clock the input and

Hi All, Many Thanks to Underwood for her excellent review of our big trouble which prevent LMS-based AEC algorithms to be used in most computer. Maybe it can be summaried as follows: 1. Different sample rate of sampling and rendering does exists in most low-cost soundcards (In my experiments over more than 20 soundcards, the differences range from 0.5Hz to more than 50Hz when sample rate is set

I am doing this right now with no problem. I am not using speex for this at the moment though. Group delay is the biggest problem. I implemented a version where the input and output sample rates are known up front. The routine than interpolates between the jitter. This should solve the problem. The crystals used to clock the input and output have very fine tolerances on most standard audio

Hi all, We have discussed so many about sampling rate asynchronous (or offset) between rendering (D/A converter) and capturing (A/D converter) of most PC soundcards. It seems all acoustic echo cancellers, include AEC in speex, can not deal with this trouble, because it causes a drift of echo path and also buffer overflow and underflow which jumps the delay of echo path seriously. Unfortunately,

Then why ONE sound card have different capture and playback rate? It must be ONE single physical clock generator which is used by both ADC and DAC in the sound card, isn't it? If you are a hardware engineer. Will you design two different physical clock for ADC and DAC seperately? What on earth causes this problem? Who knows its intrinsic real reason? Isn't there any other solutions? For

On 04/14/2011 07:26 PM, LiMaoquan2000 wrote: > Hi All, > Many Thanks to Underwood for her excellent review of our big trouble > which prevent LMS-based AEC algorithms to be used in most computer. > Maybe it can be summaried as follows: > 1. Different sample rate of sampling and rendering does exists in most > low-cost soundcards (In my experiments over more than 20 soundcards,

Simply to say, in a quiet room, you can play a impulse signal and then find it's impulse response signal from the microphone. For example, if the delay between the impulse signal and its response signal range from 500 to 3000 cycles, you can buffer the far-end signal to 0-300 cycles and set the filter length to 4000. It is also called to align far-end signal and near-end signal. BTW: Speex

Hi All, In order to deal with acoustic echo cancellation problems of most PCs which sound cards have different capture and play frequencies. I made a trial. At first, a 1000Hz sine wave is played for a long time via a speaker and its acoustic echo is recoreded. Seconds, get the frequency of the echo by a FFT analyser. So the difference between capture and play frequencies is obtained. Thirdly,

Okay, Not exactly the answer I was looking for. This sounds like a big change. I don't mind re-writing the LSP quantizer but re-training code books and breaking compatibility is not what I want to do. I am working on an optimization for an ARM cortex-A8. It is desirable to process things in 4 element blocks. Is there a simpler approach you could recommend? Vasant Shridhar

>I remember?I had to expose the echo cancelation level implementing a get_echo_level( ) function based on this: >http://lists.xiph.org/pipermail/speex-dev/2008-September/006889.html This is really a good idea to determine the frequency difference between capture and play of the sound card. But it need constant far-end voice and a long time because it must repeat the process of

I would like to make lpcSize a multiple of 4. In the current library for narrow band mode lpcSize is currently set to 10. I would like to increase this 12 for optimization reasons. Is it a simple matter of just changing lpcSize in the structures in mode.c or are there other implications to doing this? I did try and change the value but I seem to be getting some runtime errors indicating a

>>>> Hi, >>> >>> I have a scenario in a mobile VoIP app that requires echo cancellation but >>> is somewhat different from what's described in the docs. >>> >>> Audio is received from and sent to the network at 8000Hz. Each packet >>> contains 160 samples worth a playback of 20ms. >>> >>> But the hardware

On mer, 2011-08-10 at 09:41 -0400, Rony Nandy wrote: > Hi All, > I have downloaded libogg-1.3.0 along with speex.But,during > build speex is exiting with ogg.h missing.Any suggestions will be highly > appreciated. IIRC, speexenc encodes your data into a speex stream which is encapsulated into an OGG container, so you need to libogg to compile it. Though, it has been ages

Thank you. But it will cost you a long time to get the accurate play and capture frequencies. Does your program test two frequencies of the sound card each time? Because different sound cards have different frequency errors. And the resampling program is also time consuming because the target frequency is so close to the sampling frequency of the input signal, isn't it? I have tested program

Hi all, The conclusion of the discussion is that most sound cards indeed have different capture and playing frequencies for the unknown reasons. But we all know the adaptive filter of the AEC relies on the synchronization of the far-end and near-end sampling rates. Then Has anybody tried to use speex AEC in Windows system? How do you solve this problem? (I have tested speex AEC. In most

I have been trying to understand how to get the VAD algorithm working. I sent an input stream of all zeros into the preprocessor but still got a return value of 1 indicating that speech was detected. Is this feature not available with the latest release? I thought at the very least it would detect this as silence and return 0 but that does not seem to be the case. Does anyone have any

On Fri, Jul 8, 2011 at 6:39 AM, Ashhar Farhan <farhan at phonestack.com> wrote: > what you need to do is this: take the wireshark raw dump, read each > udp packet and write it back to another file. While writing back to > the new file skip the sizeof udp header + rtp header. I can't recall > how many bytes you need to skip, however, I suppose it would be in the > range of

On 01/19/2011 06:44 PM, LiMaoquan2000 wrote: > > Hi all, > > We have discussed so many about sampling rate asynchronous (or offset) > between rendering (D/A converter) and capturing (A/D converter) of > most PC soundcards. It seems all acoustic echo cancellers, include AEC > in speex, can not deal with this trouble, because it causes a drift of > echo path and also

Hi Steve, Have you read this paper? (Heping Ding, David I. Havelock, Drift-Compensated Adaptive Filtering for Improving Speech Intelligibility in Cases with Asynchronous Inputs. EURASIP J. Adv. Sig. Proc. 2010:) Let me call is paper-Drift. It provided a method to evaluate Relative Sample Offset (RSO, d[i]) which is omitted in the microsoft paper (Challenges and Solutions for Designing Software