similar to: WebRTC

Speaking of AEC (thought not quite on topic for this thread), Has anyone on this list played with the GIPS code that google just open-sourced? It looks like their AEC also has code to handle differential sample rates, though I haven't really evaluated it thoroughly. There is really a lot of code in the drop ? basically all of the GIPS DSP stuff (AGC, VAD, Denoise, echo canceller, etc),

On 06/22/2011 09:30 AM, Steve Kann wrote: > Speaking of AEC (thought not quite on topic for this thread), > > Has anyone on this list played with the GIPS code that google just > open-sourced? It looks like their AEC also has code to handle > differential sample rates, though I haven't really evaluated it > thoroughly. > > There is really a lot of code in the drop ?

On 06/22/2011 04:57 AM, Arun Raghavan wrote: > On Tue, 2011-06-21 at 11:39 -0700, Arun Raghavan wrote: > [...] >> I'm also running this on x86 (x86_64, technically), and it's all >> floating-point, so I guess this is a regression somewhere. Will try to >> see if I can run it without any optimisations if possible, which I >> assume should serve as an adequate

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

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

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

Recently, we were notified that the mechanism included in our Asterisk source code releases to download and build support for the iLBC codec had stopped working correctly; a little investigation revealed that this occurred because of some changes on the ilbcfreeware.org website. These changes occurred as result of Google's acquisition of GIPS, who produced (and provided licenses for) the iLBC

Recently, we were notified that the mechanism included in our Asterisk source code releases to download and build support for the iLBC codec had stopped working correctly; a little investigation revealed that this occurred because of some changes on the ilbcfreeware.org website. These changes occurred as result of Google's acquisition of GIPS, who produced (and provided licenses for) the iLBC

Hi Underwood, Thank you for your help. I agree with your opinion. But it is almost impossible to further reduce the frequent difference between play and capture. 1. I used a 2^18 step FFT to analyse the echo frequency. So the freq resolution is 8000HZ/(2^17)=0.0625Hz. The analyser need at least 2^18/8000=32 seconds acoustic echo record signal from the microphone. Better freq resolution relies

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

>>> Steve Underwood <steveu@coppice.org> 9/6/05 2:05:53 AM >>> > However, most other systems either don't support iLBC, > or throw it in as an extra because they have the ROM space, and it costs > them nothing. It costs them nothing as long as they can afford to run real time floating point code, which is the only one released as open source and

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

Hi, I implemented a small patch that allows the internal convergence state of the echo canceller to be saved in a file for later use, especially after a process restart or machine reboot. This enables immediate echo cancellation the second time the AEC is run. Of course this works only if the acoustic environment of the device doesn't change and if the soundcard latency is constant. To use

From: Steve Underwood <steveu at coppice.org> > It seems some cards use a PLL for their ADC, so they can lock to an > incoming SPDIF signal, but always use a local crystal clock source for > their DAC. These cards do not have their ADC and DAC synchronised. Do common on-board or PCI sound card lock to some incoming signal? Yes, there is a crystal oscillator and a PLL or divider to

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

Hi list, I'm running current SpanDSP http://www.soft-switch.org/downloads/spandsp/spandsp-0.0.4pre6.tgz with Asterisk 1.2.22 somewhat successfully. Most Fax machines do work but I have problems with people having Tobit FaxWare and Shamrock CapiFax. http://www.tobit.com/login/mrd.asp?CategoryID=120 http://www.shamrock.de/ I've got black bars over the pages. In Tobit some content is Ok,

Hello Opus community, I'd like to ask you for advice and recommendations. WebRTC uses Opus, and I noticed https://webrtc-codereview.appspot.com/5549004 started referring to currently internal Opus headers. This is possible because for Chromium the Opus sources are just checked in, so any header can be #included. I detected this when trying to package Chromium for Linux distributions with

I honestly couldn't tell you if it would resolve it but there aren't many people going to be willing to help problem solve anything if you're running 13 - you'll get more support on 17 for example. Very easy to bring up a new instance or VM in the grand scheme of things to test the theory and get it working on most recent version of Asterisk On Tue, Apr 28, 2020 at 11:37 AM

Hi, I've run into a slight issue when using WebRTC and two Asterisk boxes. I am using SIPml as the test WebRTC client. My two asterisk boxes, one of them is configured for WebRTC with websockets, etc (asteriskrtc.local) and the other is just a standard asterisk server (asteriskgary.local). Dealing with just the WebRTC asterisk server, asteriskrtc.local, I am able to log in to the SIPml