similar to: Speex-dev Digest, Vol 83, Issue 10

Hi Steve, > I don't know if this has only recently been put on line, but I never > noticed it until today - > www.iwaenc.org/proceedings/*2008*/contents/papers/9044.pdf > > That paper is from people at MS describing, in some detail, what the > Windows kernel echo canceller does to handle synchronisation issues. It > tracks both time varying sample clock drift and hiccups

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,

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

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 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

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, Speex devs, I apologize in advance if this is not the proper venue for this question, but I had seen in the archives that other threads of this nature had been discussed. In brief, I'm trying to get AEC working on a simple Android NDK app. It's a basic "play from a file, record from the mic to file" loopback test. I'm using OpenSL ES. I establish a player and a

Hi, Rhett, echo_diagnostic.m can produce an echo canceled file along with the possible warning messages. Can it cancel the echo properly? It may announce the "Drift estimate is ..." message if the recorded sound contains not only echo but also other sound like a near-end speech. In other cases, it may truly indicate a mismatch of the sampling frequency. Regards Kaiyu On Thu, Feb 6,

Hello everyone, I'm a new comer to this mailing list. I found that the echo_diagnostic.m included in speex-1.2rc1 seems to have grammar mistakes which cause parse error in octave 3.6.2. I wonder if anyone have ever executed this code under octave/matlab. I also made some minor modifications to the file to correct those errors and publish it here. If it can helps the project to be more

2011/4/20 Li Maoquan <limaoquan2000 at 126.com> > 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

>> Actually, the jitter buffer in Speex tends to cope relatively well with >> non-synchronised clocks. > > Can you explain why? > > My problem is not at all related to local input/output non-synchronised > clocks: my problem is really between non-synchronised clock between one > PC and another... What happens is that my jitter buffer is designed without any

>> 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

Hi ? I used this "sample counting " method to?resample and put my audio signals in synch. It worked perfectly?in XP machines using a SoundMax?audio card, but it failed in other XPs using Realtek cards. As seen on http://lists.xiph.org/pipermail/speex-dev/2008-September/006889.html?my application?continously checked my AEC level to slighly modify resample frequency, but convergence was

Hi all, We all know that mismatch between clocks of ADCs of far-end voice and near-end voice is not allowed in a time-domain or frequency-domain LMS based AEC system. It means that capture and render audio streams must be synchronized to a same sample rate. However, I found that this restriction is removed in microsoft AEC from Windows XP SP1. Anyone knows how microsoft AEC do it? This technology

AFAIK, that's a common point for all AECs. But some of them solve the problem by resampling on of the end to keep it in sync with the other. On Tue, Jul 7, 2009 at 5:14 PM, ggb<ggb at tid.es> wrote: > Thank you John. > > On 07/06/2009 11:03 PM, John Ridges wrote: > > ly synchronized, and therefore the clock drift adds a non-linear > factor to the audio path. The AEC

Definitely! It tells me that my delay is fine but drifting is -15. I use the same onboard sound to record the near end and far end voice. So I can assume it should be fine? But I don't see the any different between input and output the echo_canceller function for this recording. Maybe there is some nonlinearity issue there? The link of this file(Capture1.zip) is in

All I can say for now is that: 1) My diagnostic tool does funny things that need to be fixed 2) It was probably also getting confused by the clicks at the end of the files 3) There seems to be odd things with your recordings, though I can't say what that would be. Are you changing something during the recording by any chance? Note that if a person close to the mic of speaker moves, that

The problem with different sound cards is that their clocks are not usually synchronized, and therefore the clock drift adds a non-linear factor to the audio path. The AEC can only cancel linear changes to the audio path, and so the AEC never converges.One solution is to measure the clock drift and resample either the input or output signal so that they *are* synchronized, and then the AEC

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

> 1) Is it ok if the audio is encoded (using Nelly Moser ASAO) and sent > to the client and decoded when it is recevied so the AEC is always > performed on raw PCM16 8KHZ ? No. The entire path from AEC to loudspeaker and from mic back to AEC must be free of any non-linearity, codec, drift, ... > 2) The audio is moved in 32ms (512 byte) chunks and the reading and > writing to the