CN111933168A - 基于binder的软回路动态消回声方法及移动终端 - Google Patents

Abstract

本申请公开了基于binder的软回路动态消回声方法及移动终端，移动终端的android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，混合音频流包括：播放的音频和唤醒语音；android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入native层的binder server；binder client获取麦克风的混合音频流，并将获取的混合音频流送入binder server；binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入java层。

Description

基于binder的软回路动态消回声方法及移动终端

技术领域

本申请涉及回声消除技术领域，特别是涉及基于binder的软回路动态消回声方法及移动终端。

背景技术

本部分的陈述仅仅是提到了与本申请相关的背景技术，并不必然构成现有技术。

回声消除(Echo Cancellation)又称回声抑制(Echo Suppression)，是远程通话和对讲过程中必须的技术。回声本质上是自己的声音经过一段时延又传到自己耳朵中，如果回声时延小于10ms则称为侧音(sidetone)，时延如果在50ms左右则称为合声(choruseffect)，无论哪种回声都严重影响通话双方的主观感受，仿佛在空旷的房间里说话。从回声产生的角度来说分为两类：声学回声(Acoustic Echo)及线路回声(Line Echo)，前者是由于声音从远端的扬声器传至麦克风导致，后者是由于线路上阻抗不匹配引起的信号反馈所产生。若通话过程中没有处理好消回声，轻则影响通话质量，重则产生严重啸叫。在智能硬件领域，消回声的效果也直接影响到了语音识别的准确性。

在实现本申请的过程中，发明人发现现有技术中存在以下技术问题：

消回声算法对硬件电路的依赖性较强，要么使用消回声芯片，但对麦克风mic和扬声器speaker的设计要求极为严格。即使使用软件消回声，也需要硬件设计上保留麦克风mic和扬声器speaker的回路，灵活性较差。

发明内容

为了解决现有技术的不足，本申请提供了基于binder的软回路动态消回声方法及移动终端；

第一方面，本申请提供了基于binder的软回路动态消回声方法；

基于binder的软回路动态消回声方法，应用于android操作系统的移动终端，所述方法包括：

android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

第二方面，本申请提供了移动终端；

一种移动终端，其上搭载android操作系统，所述移动终端还包括扬声器和麦克风；其中，android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

与现有技术相比，本申请的有益效果是：

(1)本申请可不受硬件电路限制，市面上的产品消回声方案都是基于mic与speaker，缺一不可，而且对mic与speaker的电路连接要求严格，本申请完全不受此限制；

(2)本申请针对智能硬件设备，可更好的减少成本，优化设计，尤其对那些对体积非常敏感的产品；

(3)本申请的基于android底层binder通信，更加稳定。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。

图1为本申请实施例一的binder分层；

图2为本申请实施例一的binder架构；

图3为本申请实施例一的软件消回声架构示意图；

图4为本申请实施例一的音频流程示意图。

具体实施方式

应该指出，以下详细说明都是示例性的，旨在对本申请提供进一步的说明。除非另有指明，本文使用的所有技术和科学术语具有与本申请所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请本实施例中，“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请的描述中，“多个”是指两个或多于两个。

另外，为了便于清楚描述本申请实施例的技术方案，在本申请实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例一

本实施例提供了基于binder的软回路动态消回声方法；

基于binder的软回路动态消回声方法，应用于android操作系统的移动终端，所述方法包括：

S100：android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

S101：android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

S102：android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

S103：android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

作为一个或多个实施例，所述方法还包括：

S104：android操作系统的java层获取处理后的音频，对处理后的音频进行声音识别，根据识别结果对移动终端进行唤醒。

作为一个或多个实施例，所述S101：android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binderserver；具体步骤包括：

android操作系统native层的binder client获取扬声器的音频流；

从扬声器截获的音频流为pcm格式，并将获取的音频流送入android操作系统native层的binder server；

由于pcm并不携带采样率、通道数等信息，所以android的native在处理pcm时，会将音频参数一并传输。所以在截获音频流的同时，也需要提取音频参数，如通道数、采样率等。

作为一个或多个实施例，所述S102：android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；具体步骤包括：

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流由模拟信号转换后数字信号后，送入android操作系统native层的binderserver。

本实例测试时使用的是单mic，当然，为了更好的效果，可以采用mic阵列。从mic获取的混合音频为模拟信号，由android内部的ADC(模拟数字转换器))转换为数字信号。这里要注意的是，实验使用android默认的ADC参数，转换后的数字信号为单通道，采样率9600，16bit。

进一步地，android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server步骤之后，所述android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层之前；还包括：

S102-3：判断接收到的扬声器的音频流和麦克风的音频流的通道数是否一致，如果一致，进一步判断接收到的扬声器的音频流和麦克风的音频流的采样率是否一致；如果通道数一致且采样率一致，则不进行格式转换；否则进行格式转换，将声器的音频流和麦克风的音频流的二者的通道数和采样率均转换成一样的。

作为一个或多个实施例，所述S103：android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层；具体步骤包括：

将扬声器音频视为参照音频(参数1)，将麦克风视为基准音频(参数2)，将参照音频和基准音频作为两个参数值送入回声算法进行处理；将处理后的音频送入android操作系统的java层。

进一步地，将参照音频和基准音频作为两个参数值送入回声算法进行处理，包括：

将参照音频和基准音频进行时间同步，同步后再送入回声算法进行处理。

进一步地，所述将参照音频和基准音频进行时间同步，是通过cool-edit软件中的时间坐标，计算出两路音频的延迟值，通过消除延迟值来实现二者的时间同步。

回声算法对两路音频的同步要求严格，必须进行时间的同步优化。由于android自身的延迟，截取的扬声器音频和麦克风音频同步性较差。这里通过大量测试，计算出扬声器与麦克风的延迟值大概是150ms，所以将150ms作为同步时间的默认值；

延迟值的计算方式，通过cool-edit软件，打开扬声器和麦克风的pcm文件，通过cool-edit软件中的时间坐标，计算出两路音频的延迟值。

消除回声算法的delay参数是影响消回声效果的重要参数，实际应用中一般依赖产品架构和大量测试数据进行预估，本申请提出一种动态调整delay值的方法。

Delay值通过大量测试得出平均值150ms，但android是多进程多线程操作系统，delay会在150ms的上下波动，这里使用“静音检测”的方式，去动态调整delay值；

“静音检测”即mute probe，原理是，在音乐未播放前，若环境没有噪音，则两路信号的音频值都接近于0，当有音乐播放时，音频值会突然增大。

消回声算法，用的是开源算法库(webrtc中的消回声算法)。

应理解的，本申请解决了消除回声的过程对于硬件电路的依赖，采用纯软件方式，不依赖硬件mic回路，使用软件过滤的方式提取消回声算法的参照音源，打破了对硬件电路的限制和依赖，从而更加灵活的应用于智能硬件，适配不同产品。

消回声的一个很重要应用就是语音识别，例如智能音箱类产品正在播放音乐，如果音乐声过大，会非常影响语音的识别，加入消回音后，可大大解决这个问题；

消回声和消噪密不可分，给予软回路的回声系统也加入了噪声的优化；

进一步地，所述S100中还包括：消噪处理。

消噪处理，同样使用开源算法webwrt中的消噪算法。消噪是在S100中执行的，因为只有麦克风拾音时会掺杂噪声。

采用android6.0作为测试基线，测试模型搭建如下所述：

(1)考虑到android jni传输数据的时延较大，在framework的native层直接截取参照音频数据流；

(2)为了更直观的对比测试效果，采用科大讯飞的语音唤醒来做唤醒率的对比(开启消回声算法的唤醒率和未开启消回声算法的唤醒率)；

(3)Mic音频流的截取同样放到native层做；

测试的流程，当android智能设备播放音乐时，调高音乐音量，此时很难使用语音命令唤醒设备，因为从android智能设备speaker播放出的音乐，会通过android智能设备的mic，重新进入android智能设备，我们喊出语音唤醒指令时，android智能设备的mic接收到了音乐和语音唤醒词的混合音，若不做消回声处理，两种声音会完全混在一起，自然无法顺利的唤醒android智能设备。

本申请的软回路消回声，将native截取的speaker音源作为参照音，去除掉mic收到的混合音频，只剩下干净的语音唤醒词，这样就能确保更顺利的唤醒语音设备。测试时也会基于上述原因进行对比测试。

考虑到消回声模型在音频处理领域的广泛应用，本申请以android系统为基础，深入解剖binder架构，binder是android系统底层使用的进程通信方式，拥有很多优点，利用binder进行android系统底层的进程间通信，可取代硬件电路回路。原本参照音的回路要求硬件上必须将speaker的输出接到消回声芯片或ADC电路，由外部重新采集并进行AD转换后，重新送入DSP或消回声芯片中，进行算法处理，增加了处理的复杂度，也大大增加了硬件和开发成本。

本申请不需要外部消回声芯片或硬件回路，也不需要ADC等电路，完全通过软件回路，获取参照音，mic混音，然后在内部运行软件消回声算法，摆脱了对硬件电路和结构设计的依赖；

首先是原始音频的采集。当android智能设备播放音频时，是通过android的MediaServer播放音频，在MediaServer的native层截取音频流。平常我们看到的音频格式都是mp3、wma等，但在native层的数据流为pcm格式，pcm是原始的音频格式，在处理时要注意采样率、通道数等，因为pcm中并不包含这些信息，需要通过底层源码分析；

然后是从mic获取要处理的混音。以语音唤醒场景为例，mic拾音包括自己播放的音乐及唤醒词，当播放的音乐声音较大，会完全掩盖住唤醒词，我们需要从混音中去掉自身播放的音乐声，只留下唤醒词的音频。同样需要在android的native层捕获音频，也同样是pcm格式。

需要注意的是，麦克风mic从native获取的pcm格式的音频流，要根据native层传递的参数分辨是单声道或双声道，及其准确的采样率；

在android截获pcm时，也可以同时拿到准确的采样率。因为pcm并不包含采样率等参数，android播放pcm时也是需要采样率等参数的，所以android在传输pcm时，也会同步传递采样率等参数，截取pcm时，将采样率从android系统中一并截取就可以；

mic及speaker截取的pcm音频，保证通道数和采样率一致就可以了，如果不一致，还需要进行格式转换。因为mic与speaker数据在android的不同进程，我们还需要借助binder，将两组音频同时送入软件消回声进程；

Binder在android中的架构，如图1所示，binder由下到上分别为binder驱动、native层、framework层、Java层。本申请的主要工作在native层进行，在native创建一个binder server，两个binder clinet。binder架构如图2所示。

Binder server用来接收音频及进行消回声算法处理，两个binder client分别用来捕获mic音频和speaker音频，并将捕获到的数据传递到binder server。Binder server将消回声处理后的音频，通过jni的方式，传递给java应用层，用于语音识别。在java层，我们借助科大讯飞的app进行测试。

图3为音频流处理示意图，可以看到，speaker播放的音频流，通过软件的方式截取。Mic的拾音为speaker的音频和语音唤醒词的混和音频，可以看到途中两路音频分别送入消回音算法处理模块。这里需要注意的是，speaker截取的音频和mic拾音虽然都是pcm信号，但其通道数，采样率可能不相同。在将两路音频送入消回声模块前，需要做好检查。

图4为binder处理进程，两个binder client分别截取mic和speaker的音频，binder sever负责接收两路音频流，并且进行消回声的处理。delay值是消回声算法中非常重要的参数，当使用硬件消回声通道时，所有用的delay值一般为[50,～170]ms和[150,～270]ms，取决于延时估计得两种工作模式，分别对应LowLatencyMode和kHighLatencyMode两种模式。由于我们使用的是软件回路，delay值远远小于硬件回路的delay值。

本申请使用动态delay值，因为使用软件音频回路，主要考虑的是speaker与mic音频的同步，测试时默认使用30ms的delay值。

综合本专利所提出的软件消回声方法，其包括如下步骤：

步骤1：在android native层编写截取speaker音频的binder client，实时获取音频流送入binder server(单通道，采样率44.1k)；

步骤2：在android natvie层编写截取mic音频的binder client，实时获取音频流送入binder server，默认获取的pcm为单通道，8k采样率，这里需要进行8k转44.1k采样率的变换；

步骤3：在android native层编写binder server实例，接收两路binder client的数据，并送入消回声算法处理，测试时使用的delay值为30ms；

步骤4：其中，binder client的音频流均增加时间戳，binder server端定时的进行同步；

步骤5：binder server消回声处理后的音频，通过jni送入java层，通过科大讯飞的SDK进行语音唤醒测试；

表1测试对比表

我们固定测试环境相同，使用PC合成的语音唤醒词。

测试数据对比：

该测试共300次，其中每一项测试各100次。测试时在相同的密闭环境，由电脑模拟在相同的频率下发出唤醒指令，记录设备的唤醒率。

表2设备的唤醒率

上述测试是在密闭的房间进行，测试设备使用较高音量播放音乐，由电脑播放模拟语音唤醒词，测试设备与电脑的直线距离为1米。通过测试可以发现，在不使用算法时，唤醒率非常低。使用硬件和本申请的软回路消回声算法(webrtc开源算法)时，对语音唤醒的识别率都有非常大的提升。

需要说明的是，通常硬件消回声芯片都会增加消噪等其他算法，本申请的软回路消回声算法中也可以增加消噪等算法。

实施例二

本实施例提供了移动终端；

一种移动终端，其上搭载android操作系统，所述移动终端还包括扬声器和麦克风；其中，android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.基于binder的软回路动态消回声方法，其特征是，应用于android操作系统的移动终端，所述方法包括：

android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

2.如权利要求1所述的方法，其特征是，所述方法还包括：

android操作系统的java层获取处理后的音频，对处理后的音频进行声音识别，根据识别结果对移动终端进行唤醒。

3.如权利要求1所述的方法，其特征是，android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；具体步骤包括：

android操作系统native层的binder client获取扬声器的音频流；从扬声器截获的音频流为pcm格式，并将获取的音频流送入android操作系统native层的binder server。

4.如权利要求1所述的方法，其特征是，android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binderserver；具体步骤包括：

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流由模拟信号转换后数字信号后，送入android操作系统native层的binderserver。

5.如权利要求1所述的方法，其特征是，android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binderserver步骤之后，所述android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层之前；还包括：

判断接收到的扬声器的音频流和麦克风的音频流的通道数是否一致，如果一致，进一步判断接收到的扬声器的音频流和麦克风的音频流的采样率是否一致；如果通道数一致且采样率一致，则不进行格式转换；否则进行格式转换，将声器的音频流和麦克风的音频流的二者的通道数和采样率均转换成一样的。

6.如权利要求1所述的方法，其特征是，android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层；具体步骤包括：

将扬声器音频视为参照音频，将麦克风视为基准音频，将参照音频和基准音频作为两个参数值送入回声算法进行处理；将处理后的音频送入android操作系统的java层。

7.如权利要求6所述的方法，其特征是，将参照音频和基准音频作为两个参数值送入回声算法进行处理，包括：

将参照音频和基准音频进行时间同步，同步后再送入回声算法进行处理。

8.如权利要求7所述的方法，其特征是，所述将参照音频和基准音频进行时间同步，是通过cool-edit软件中的时间坐标，计算出两路音频的延迟值，通过消除延迟值来实现二者的时间同步。

9.如权利要求1所述的方法，其特征是，android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，还包括：消噪处理。

10.一种移动终端，其特征是，其上搭载android操作系统，所述移动终端还包括扬声器和麦克风；其中，android操作系统的多媒体服务MediaServer播放音频；扬声器对音频进行播放，麦克风接收混合音频流，所述混合音频流，包括：播放的音频和唤醒语音；

android操作系统native层的binder client获取扬声器的音频流，并将获取的音频流送入android操作系统native层的binder server；

android操作系统native层的binder client获取麦克风的混合音频流，并将获取的混合音频流送入android操作系统native层的binder server；

android操作系统native层的binder server将接收到的扬声器的音频流和麦克风的混合音频流，基于消除回声算法进行处理，将处理后的音频送入android操作系统的java层。

Images