similar to: AEC max sampling rate

I've looked at some partial examples and read in the pdf Manual that the Acoustic Echo Canceller can be used outside of the speex codec as a preprocessor. I currently have a java app that uses the ffmpeg api for live streaming. I'm exploring integrating echo cancellation & I'd like to use the speexdsp AEC by mapping a javacpp library to communicate between java & speex. Audio

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

On 01/20/2011 04:26 AM, Steve Underwood wrote: > 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

>> There is also a IEEE paper, Adaptive Sampling Rate Correction for >> Acoustic Echo Control in Voice-Over-IP, which introduced a complex >> method to estimate the frequency offset and resynchronize the signals >> using arbitrary sampling rate conversion. I wonder if it can provide >> enough performance. Because I have also designed a sampling rate >>

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,

Hi Julien, Quote from : http://dspguru.com/dsp/faqs/multirate/resampling "The problem is that for resampling factors close to 1.0, the interpolation factor can be quite large. For example, in the case described above of changing from the sampling rate from 48 kHz to 44.1 kHz, the ratio is only 0.91875, yet the interpolation factor is 147!" My guess is that Opus would perform similar to

The encoder and decoder can handle, 8, 12, 16, 24 and 48 kHz input/output. If doesn't matter what it gets encoded to/decoded from. you can initialize a decoder at 8 kHz and it'll still decode 48 kHz audio fine (you just won't get the high frequencies obviously). For sampling rates other than 8/12/16/24/48, then you'll have to do resampling. Have a look at the speexdsp resampler if

Try using SPEEX_ECHO_SET_SAMPLING_RATE to specify your sampling rate. Also, don't forget that the tail need to be longer (proportional to the sampling rate). Last thing, if you use resampling, make sure you use a decent resampler (the Speex one is fine) because otherwise, any aliasing left will not be cancelled. Jean-Marc Mihai Balea a ?crit : > Hi all, > > I am attempting to test

Hi, another question on the same topic Speex resampler at 44.1kHz seems to be very CPU intensive on Android (even more than the Opus encoder) While Speex at 48kHz is just fine. I wonder any alternate solutions or ideas ? Improve it, look for alternate solution ... I am guessing the NEON optimization are still used for both, etc. On Thu, Apr 2, 2015 at 4:46 PM, Jean-Marc Valin <jmvalin at

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,

It is a good idea not to use sample rates other than 44100 or 48000 Hz for your final audio I/O. The chipset people just do not give a crap about rates other than that. They don't see a problem with giving you 11100 Hz when you ask for 11025, for instance, even though that's a huge problem for VoIP. Ultimately you need to be prepared to resample to one of the de-facto 'standard'

Hi all, I am attempting to test AEC behavior at various sample rates. I ran a little experiment: I recorded a 10 seconds voice clip and the resampled at 8000, 11025, 16000, 22050, 24000, 32000, 44100 and 48000. I have a small applications that plays a wave file, records whatever comes in from the microphone and applies the Speex AEC and preprocessor on the input. It then saves the raw

Hi, is there any way to tell the decoder the output sampling Fz we want ? opus_decoder_create = Sampling rate of input signal (Hz) Considering this example (VoIP-out from WebRTC/RTP) MICROPHONE(44.1/48kHz) >> [encoder created at 48kHz but with internalSampleRate set to 8kHz]>> INTERNET >> [decoder(created with 48kHz)] >> 48kHz(?) >> G.711(8kHz) This leaves us with

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

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

I can only evaluate this with my subjective point of view. I had a special test scenario doing chat with cheap webcam microphones and loudspeakers. Fraunhofers solution was the only one that could eliminate the echo. In double talk the quality gets lower but is still very good. You might want to ask Fraunhofer for a demo version to test for yourself. I have no details on the algorithms being

On Mar 15, 2010, at 8:46 AM, Jean-Marc Valin wrote: > 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). > Does "tricky" mean that the Speex AEC won't handle such situations well? Or just that you had to be

One thing I can think of is if you are using two or more speakers. If the speakers are not at the exact same distance from the mic, you will get more than one echo. AEC can not handle that. Try disconnecting all but one speaker and see if it makes any difference. cheers Greger 2010/3/15 Anton A. Shpakovsky <saa at tomsksoft.com> > Hello. > > I have the following situation. AEC

Ok. Thanks J-M for clearing that up. What if you mix up the polarity on one speaker (180 degree phase change), would that matter? cheers Greger 2010/3/15 Jean-Marc Valin <Jean-Marc.Valin at usherbrooke.ca> > 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 >

On 2010-03-16 06:35, Greger Burman wrote: > Ok. Thanks J-M for clearing that up. > What if you mix up the polarity on one speaker (180 degree phase > change), would that matter? Not at all. It's still all linear. You can even apply a different equalizer to each speaker and it'll still be linear. Jean-Marc > cheers > Greger > > 2010/3/15 Jean-Marc Valin