精华内容
下载资源
问答
  • webrtc aec3效果对比aec与aecmwebrtc M64 20180115版本)

    千次阅读 热门讨论 2018-01-16 10:12:21
    1、webrtc回声消除算法aec3也出来有几个月了,下面看下最新版的aec3效果,使用读文件仿真,例子为webrtc中的audioproc_f.exe,aec3,aec,aecm均使用默认参数,没有改动。在cmd中使能aec3参数audioproc_f -i D:\Git\...

    1、webrtc回声消除算法aec3也出来有几个月了,下面看下最新版的aec3效果,使用读文件仿真,例子为webrtc中的audioproc_f.exeaec3aecaecm均使用默认参数,没有改动。

    cmd中使能aec3参数

    audioproc_f -i D:\Git\webrtc-checkout\src\out\Debug\mic.wav-ri D:\Git\webrtc-checkout\src\out\Debug\playOut.wav -oD:\Git\webrtc-checkout\src\out\Debug\outAec3.wav -aec3 1

    2、结果对比:


    3、结果分析:

    现在M64版本的aec3效果太差,还不如aecm,更不用说aec了;当然aec3还在不断更新中,等待半年后再看效果。(另听音aecm双讲有掉音掉字现象,比aec差多了)。

    其提供的peerconnection_client默认启动的是aec。

    audio_processing.h

    // Deprecated way of activating AEC3.

    // TODO(gustaf): Remove when possible.

    structEchoCanceller3 {

    boolenabled = false;

     } echo_canceller3;

     

    :仿真中只测试一组样本,aec3效果及分析只作参考,不当之处请指正。谢谢!

    回声消除答疑

    speex与webrtc回声消除小结

    QQ、YY与webRTC回声消除效果对比分析与展望


    展开全文
  • webRTC AECM工程

    2020-02-28 18:06:46
    在对AECM独立开发使用时就需要研究其源代码,AECM的主体工程文件在WebRTCaecm子文件夹中,包括delay_estimator.c、delay_estimator_wrapper.c、aecm_core.c、aecm_core_c.c、echo_control_mobile.c这五个回声消除...

    在对AECM独立开发使用时就需要研究其源代码,AECM的主体工程文件在WebRTC中aecm子文件夹中,包括delay_estimator.c、delay_estimator_wrapper.c、aecm_core.c、aecm_core_c.c、echo_control_mobile.c这五个回声消除的核心文件。
    其中,delay_estimator.c、delay_estimator_wrapper.c用于回声时延的精确估计(根据Bastiaan的专利),

    展开全文
  • WebRTC AECM时延估计

    千次阅读 2019-10-30 15:47:53
    在实际应用中一般采用大范围粗略估计加小范围精确计算的方法,例如在WebRTCAECM回声消除模块中,其API接口中有一个特殊的参数msInSoundCardBuf,要求调用者传入一个以毫秒为单位的回声时延估计值,然后又AECM内部...

    时延问题:一般基于互相关计算的自适应时延估计算法的计算复杂度为,其随计算范围的增长呈二次上升趋势,因此很难再如此大的范围内进行动态地时延计算。在实际应用中一般采用大范围粗略估计加小范围精确计算的方法,例如在WebRTC的AECM回声消除模块中,其API接口中有一个特殊的参数msInSoundCardBuf,要求调用者传入一个以毫秒为单位的回声时延估计值,然后又AECM内部在这个估计值的基础上进行**小范围内回声时延精确计算,因此该参数的准确性将直接音响到AECM内部时延计算准确性和速度,而这种影响又能直观的反映在回声消除整体性能入ERLE上。
    最常用的时延估计方法是计算两信号的互相关函数,通过遍历候选延时的互相关系数,选择取得最大值的候选时间为实际延时。但此方法在计算时计算复杂度高,尤其是应用在实时要求高的系统中。AECM算法简化了流程,在算法复杂度和性能上做了较好的权衡,远端和近端语音信号的在FFT后的频谱far_spectrum和near_spectrum,其中远端频谱将被缓存起来作为候选匹配项。选择频谱中最重要的32个频段(12-43),算法估计了频谱的均值threshold_spectrum并设其为门限值。当,某个频段值大于门限值时,将改为设置为1,反之则设为0。这样便得到了远端和近端信号二值化的频谱,通过求解两者的按位异或值,选择相似度最高的候选远端信号并计算对应的延时。
    在这里插入图片描述
    WebRTC AECM中时延估计模块为
    int WebRtc_DelayEstimatorProcessFix(
    void
    handle,
    const uint16_t
    near_spectrum,
    int spectrum_size,
    int near_q)
    它包括二进制频谱量化
    // Get binary spectra. binary_spectrum:32个频带的判别结果 近端信号的量化结果
    binary_spectrum = BinarySpectrumFix(near_spectrum,
    self->mean_near_spectrum,
    near_q,
    &(self->near_spectrum_initialized));
    和int WebRtc_ProcessBinarySpectrum(BinaryDelayEstimator
    self,
    uint32_t binary_near_spectrum),该模块主要是从候选的时延中找到一个相似度最大的,控制逻辑比较复查,将代码和简单注释贴在下面:
    int WebRtc_ProcessBinarySpectrum(BinaryDelayEstimator
    self,
    uint32_t binary_near_spectrum) {
    int i = 0;
    int candidate_delay = -1;
    int valid_candidate = 0;
    int delay_test = 0;

    int32_t value_best_candidate = kMaxBitCountsQ9;
    int32_t value_worst_candidate = 0;
    int32_t valley_depth = 0;

    assert(self != NULL); //不满足条件终止程序
    if (self->farend->history_size != self->history_size) {
    // Non matching history sizes.
    return -1;
    }
    if (self->near_history_size > 1) {
    // If we apply lookahead, shift near-end binary spectrum history. Insert
    // current |binary_near_spectrum| and pull out the delayed one.
    memmove(&(self->binary_near_history[1]), &(self->binary_near_history[0]),
    (self->near_history_size - 1) * sizeof(uint32_t));
    self->binary_near_history[0] = binary_near_spectrum;
    binary_near_spectrum = self->binary_near_history[self->lookahead];
    }

    // Compare with delayed spectra and store the |bit_counts| for each delay.
    BitCountComparison(binary_near_spectrum, self->farend->binary_far_history, //(a,b,c,d) d = sum(a(i)==b(i)) 0<ihistory_size, self->bit_counts); //返回bit_counts:两个binary对应位数不等的个数 按位异或并求结果总1的个数

    // Update |mean_bit_counts|, which is the smoothed version of |bit_counts|.
    for (i = 0; i < self->history_size; i++) {
    // |bit_counts| is constrained to [0, 32], meaning we can smooth with a
    // factor up to 2^26. We use Q9. 可以左移26位,我们左移9位
    int32_t bit_count = (self->bit_counts[i] << 9); // Q9.

    // Update |mean_bit_counts| only when far-end signal has something to
    // contribute. If |far_bit_counts| is zero the far-end signal is weak and
    // we likely have a poor echo condition, hence don't update.    
    if (self->farend->far_bit_counts[i] > 0) {     //0 远端信号较弱,不进行更新   更新时将远端信号按照强弱量化
      // Make number of right shifts piecewise linear w.r.t. |far_bit_counts|.
      //far_bit_counts 线性分段 (0:5)(6:10) (11:15) (16:21) (22:26) (27:31) (32) 对应的shifts取值为 13 12 11 10 9 8 7 
      int shifts = kShiftsAtZero;  // = 13
      shifts -= (kShiftsLinearSlope * self->farend->far_bit_counts[i]) >> 4; //13-floor(3*far_bit_counts/16)   far_bit_counts取值范围0:32  shifts 取值13:7
      WebRtc_MeanEstimatorFix(bit_count, shifts, &(self->mean_bit_counts[i]));  //(a,b,&c) c = c +|a-c|>>b  
    }
    

    }

    // Find |candidate_delay|, |value_best_candidate| and |value_worst_candidate|
    // of |mean_bit_counts|.
    for (i = 0; i < self->history_size; i++) { //
    if (self->mean_bit_counts[i] < value_best_candidate) { //找最小值 值最小相似度最高
    value_best_candidate = self->mean_bit_counts[i];
    candidate_delay = i; //候选值
    }
    if (self->mean_bit_counts[i] > value_worst_candidate) {//找最大值
    value_worst_candidate = self->mean_bit_counts[i];
    }
    }
    valley_depth = value_worst_candidate - value_best_candidate; //宽度

    // The |value_best_candidate| is a good indicator on the probability of
    // |candidate_delay| being an accurate delay (a small |value_best_candidate|
    // means a good binary match). In the following sections we make a decision
    // whether to update |last_delay| or not.
    // 1) If the difference bit counts between the best and the worst delay //最佳和最差延迟候选之间的插值太小,我们认为不可靠,不更新last_delay
    // candidates is too small we consider the situation to be unreliable and
    // don’t update |last_delay|.
    // 2) If the situation is reliable we update |last_delay| if the value of the //如果情况可靠,更新 last_delay
    // best candidate delay has a value less than //如果最优候选值小于 自适应门限minimum_probability 或 last_delay_probability 更新
    // i) an adaptive threshold |minimum_probability|, or
    // ii) this corresponding value |last_delay_probability|, but updated at
    // this time instant.

    // Update |minimum_probability|.
    if ((self->minimum_probability > kProbabilityLowerLimit) && //17
    (valley_depth > kProbabilityMinSpread)) { //5.5 深度足够大
    // The “hard” threshold can’t be lower than 17 (in Q9).
    // The valley in the curve also has to be distinct, i.e., the
    // difference between |value_worst_candidate| and |value_best_candidate| has
    // to be large enough.
    int32_t threshold = value_best_candidate + kProbabilityOffset; // +2
    if (threshold < kProbabilityLowerLimit) { //门限下限值17
    threshold = kProbabilityLowerLimit;
    }
    if (self->minimum_probability > threshold) { //更新
    self->minimum_probability = threshold;
    }
    }
    // Update |last_delay_probability|.
    // We use a Markov type model, i.e., a slowly increasing level over time.
    self->last_delay_probability++;
    // Validate |candidate_delay|. We have a reliable instantaneous delay
    // estimate if
    // 1) The valley is distinct enough (|valley_depth| > |kProbabilityOffset|)
    // and
    // 2) The depth of the valley is deep enough
    // (|value_best_candidate| < |minimum_probability|)
    // and deeper than the best estimate so far
    // (|value_best_candidate| < |last_delay_probability|)
    valid_candidate = ((valley_depth > kProbabilityOffset) && // last_delay 更新条件判断 1:更新,0:不跟新
    ((value_best_candidate < self->minimum_probability) ||
    (value_best_candidate < self->last_delay_probability)));

    if (self->robust_validation_enabled) {
    int is_histogram_valid = 0;
    UpdateRobustValidationStatistics(self, candidate_delay, valley_depth,
    value_best_candidate);
    is_histogram_valid = HistogramBasedValidation(self, candidate_delay);
    valid_candidate = RobustValidation(self, candidate_delay, valid_candidate, // last_delay 更新条件判断 1:更新,0:不跟新
    is_histogram_valid);

    }
    if (valid_candidate) {
    if (candidate_delay != self->last_delay) {
    self->last_delay_histogram =
    (self->histogram[candidate_delay] > kLastHistogramMax ?
    kLastHistogramMax : self->histogram[candidate_delay]);
    // Adjust the histogram if we made a change to |last_delay|, though it was
    // not the most likely one according to the histogram.
    if (self->histogram[candidate_delay] <
    self->histogram[self->compare_delay]) {
    self->histogram[self->compare_delay] = self->histogram[candidate_delay];
    }
    }
    self->last_delay = candidate_delay;
    if (value_best_candidate < self->last_delay_probability) {
    self->last_delay_probability = value_best_candidate;
    }
    self->compare_delay = self->last_delay;
    }

    if(self->last_delay!= -2 &&self->last_delay!= 0)
    delay_test = 1;

    return self->last_delay;

    }

    展开全文
  • webrtc aecm模块 android端

    2016-11-08 16:17:52
    亲测可用,jni内有aecm的源码,lib内有编译好的.so,并且wrapper也已经写好,如果直接使用的话请直接连package一起copy否则会报错,如果自己写wrapper自己编译jni那请自便,使用效果明显
  • 这个是bill分享在github上面的项目,github地址是:https://github.com/BillHoo/webrtc-based-android-aecm
  • Android-Webrtc AECM for android

    千次阅读 2016-12-16 10:57:37
    https://github.com/BillHoo/webrtc-based-android-aecm 这是bill在github上面分享的aecm for android的Demo,带jni源码,三年前的比较老。有兴趣的可以下载参考下。
    https://github.com/BillHoo/webrtc-based-android-aecm 这是bill在github上面分享的aecm for android的Demo,带jni源码,三年前的比较老。有兴趣的可以下载参考下。
    
    展开全文
  • 该APP 用于 android 双向语音测试 opus 编码,支持FEC
  • webrtc Android AECM 模块的使用

    千次阅读 2019-06-11 16:22:13
    平台: Rk3399Pro_Android8.1_SDK 主要这个几个函数, static void set_config(void *AEC_inst, ...int webrtc_aec_destroy(void *state ) void webrtc_aec_reset(void *state ) int webrtc_aec_cancel_echo( voi...
  • - modules/audio_processing/aecm/aecm_core.h - modules/audio_processing/aecm/aecm_defines.h - modules/audio_processing/aecm/echo_control_mobile.h - common_audio/signal_processing/include/sig
  • 最近在编译webrtc aecm模块的时候,代码中明明已经包含C文件的引用,但是编译的时候一直‘undefined reference to XXXXXX’ ,如图解决方法: 在MK文件里加多一行 LOCAL_ALLOW_UNDEFINED_SYMBOLS := true...
  • 版本VoiceEngine 4.1.0 舒适噪音生成(comfort noise generator,CNG)是一个在通话过程中...#if defined(WEBRTC_ANDROID) || defined(WEBRTC_IOS) static const EcModes kDefaultEcMode = kEcAecm; #else stati...
  • webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块:1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP(非线性滤波) 4.CNG(舒适噪声产生),一般经典aec算法还应包括双端检测(DT)。考虑到webrtc...
  • WebRTC】回声抵消(aec、aecm)算法简介 webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块:1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP(非线性滤波) 4.CNG(舒适噪声产生),一般经典aec...
  • webrtc 的回声抵消(aec、aecm)算法简介 原文链接:丢失。不好意思 webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块:1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP(非线性滤波) 4.CNG...
  • WebRTC 的回声抵消(AEC、AECM)算法简介

    千次阅读 2017-06-24 08:46:15
    Echo Canceller for Mobile,AECM)算法主要包括以下几个重要模块:回声时延估计;NLMS(归一化最小均方自适应算法);NLP(非线性滤波);CNG(舒适噪声产生)。一般经典AEC算法还应包括双端检测(DT)。 考虑到webrtc...
  • webrtc 的回声抵消(aec、aecm)算法简介 webrtc 的回声抵消(aec、aecm)算法主要包括以下几个重要模块:1.回声时延估计 2.NLMS(归一化最小均方自适应算法) 3.NLP(非线性滤波) 4.CNG(舒适噪声产生),一般经典aec...
  • Android 音频降噪 webrtc 去回声

    千次阅读 2020-11-12 11:22:00
    Android 音频降噪 webrtc 去回声集成AECM模块集成NS模块需要源码请留言 集成AECM模块 1.通过 webrtc官网下载需要模块\modules\audio_processing\aecm 2.新建eclipse工程,新建jni文件夹将webrtc aecm模块拷贝到jni...
  • WebRTC学习篇

    2019-09-18 05:26:41
    资源集合:http://blog.csdn.net/yangzhenping/article/details/51152376 http://webrtc.org.cn/aecm/
  • 1.绪论。 2.回声消除的算法研究。 2.1voip通信中回声的特点。 2.2voip中回声消除方法。 2.3声学回声消除器原理。 3.webrtcaecm算法实现。 3.1webrtc简介 3.2webrtc中aec模块 4.测试平台的搭建

空空如也

空空如也

1 2 3 4
收藏数 65
精华内容 26
关键字:

aecmwebrtc