具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述。以下实施例中所使用的术语只是为了描述特定实施例的目的,而并非旨在作为对本申请的限制。如在本申请的说明书和所附权利要求书中所使用的那样,单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括例如“一个或多个”这种表达形式,除非其上下文中明确地有相反指示。还应当理解,在本申请实施例中,“一个或多个”是指一个、两个或两个以上;“和/或”,描述关联对象的关联关系,表示可以存在三种关系;例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此,在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例,而是意味着“一个或多个但不是所有的实施例”,除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”,除非是以其他方式另外特别强调。
本申请实施例涉及的多个,是指大于或等于两个。需要说明的是,在本申请实施例的描述中,“第一”、“第二”等词汇,仅用于区分描述的目的,而不能理解为指示或暗示相对重要性,也不能理解为指示或暗示顺序。
图1展示的应用场景中,用户耳戴降噪耳机处于户外场景时,用户周围的声音会被降噪耳机屏蔽掉。若用户周围出现危险,如图1展示的用户后方有车靠近,由于降噪耳机屏蔽周围声音的作用,用户并不能听到车辆的鸣笛声,导致出现安全问题。
并且,即便降噪耳机具有通透模式,在该模式下,降噪耳机并不会完全屏蔽周围声音,但若周围声音较为嘈杂,仍然无法保护用户的安全。
基于上述问题,本申请实施例提出音频信息的处理方法。本申请实施例提供的音频信息的处理方法,可应用于图1展示的应用场景。在本应用场景中,用户通过手机和降噪耳机的交互,可实现在用户周边出现危险的告警声时,进行提醒。
图2a展示了本申请实施例提供的一种电子设备的组成示例。本应用场景中提出的手机的组成结构,同样如图2a所示。并且,本申请实施例,除了通过手机和降噪耳机进行交互,完成告警声提醒之外,还可通过其他电子设备和降噪耳机进行交互完成。如平板电脑,桌面型、膝上型、笔记本电脑,超级移动个人计算机(Ultra-mobile Personal Computer,UMPC),手持计算机,上网本,个人数字助理(Personal Digital Assistant,PDA),可穿戴电子设备等,其组件结构也如图2a所示。
电子设备200可以包括处理器210,外部存储器接口220,内部存储器221,显示屏230,天线1,天线2,移动通信模块240,无线通信模块250以及音频模块260等。
可以理解的是,本实施例示意的结构并不构成对该电子设备的具体限定。在另一些实施例中,该电子设备可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件的组合实现。
处理器210可以包括一个或多个处理单元,例如:处理器210可以包括应用处理器(application processor,AP),调制解调处理器,图形处理器(graphics processingunit,GPU),图像信号处理器(image signal processor,ISP),控制器,视频编解码器,数字信号处理器(digital signal processor,DSP),基带处理器,和/或神经网络处理器(neural-network processing unit,NPU)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
处理器210中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器210中的存储器为高速缓冲存储器。该存储器可以保存处理器210刚用过或循环使用的指令或数据。如果处理器210需要再次使用该指令或数据,可从所述存储器中直接调用。避免了重复存取,减少了处理器210的等待时间,因而提高了***的效率。
外部存储器接口220可以用于连接外部存储卡,例如Micro SD卡,实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口220与处理器210通信,实现数据存储功能。例如将音乐,视频等文件保存在外部存储卡中。
内部存储器221可以用于存储计算机可执行程序代码,可执行程序代码包括指令。处理器210通过运行存储在内部存储器221的指令,从而执行电子设备200的各种功能应用以及数据处理。内部存储器221可以包括存储程序区和存储数据区。其中,存储程序区可存储操作***,至少一个功能所需的应用程序(比如声音播放功能,图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据,电话本等)等。此外,内部存储器221可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件,闪存器件,通用闪存存储器(universal flash storage,UFS)等。处理器210通过运行存储在内部存储器221的指令,和/或存储在设置于处理器中的存储器的指令,执行电子设备的各种功能应用以及数据处理。
电子设备通过GPU,显示屏230,以及应用处理器等实现显示功能。GPU为图像处理的微处理器,连接显示屏230和应用处理器。GPU用于执行数学和几何计算,用于图形渲染。处理器210可包括一个或多个GPU,其执行程序指令以生成或改变显示信息。
电子设备可以通过ISP,摄像头,视频编解码器,GPU,显示屏230以及应用处理器等实现拍摄功能。
电子设备的无线通信功能可以通过天线1,天线2,移动通信模块240,无线通信模块250,调制解调处理器以及基带处理器等实现。
移动通信模块240可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块240可以由天线1接收电磁波,并对接收的电磁波进行滤波,放大等处理,传送至调制解调处理器进行解调。移动通信模块240还可以对经调制解调处理器调制后的信号放大,经天线1转为电磁波辐射出去。
无线通信模块250可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks,WLAN)(如无线保真(wireless fidelity,Wi-Fi)网络),蓝牙(bluetooth,BT),全球导航卫星***(global navigation satellite system,GNSS),调频(frequency modulation,FM),近距离无线通信技术(near field communication,NFC),红外技术(infrared,IR)等无线通信的解决方案。无线通信模块250可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块250经由天线2接收电磁波,将电磁波信号调频以及滤波处理,将处理后的信号发送到处理器210。无线通信模块250还可以从处理器210接收待发送的信号,对其进行调频,放大,经天线2转为电磁波辐射出去。
一些实施例中,无线通信模块250中的蓝牙模块用于实现电子设备200与其他电子设备之间的短距离通信,如电子设备200和降噪耳机通过蓝牙模块进行交互。蓝牙模块可以是集成电路或者蓝牙芯片等。
电子设备200可以通过音频模块260,扬声器270A,受话器270B,麦克风270C,耳机接口270D,以及应用处理器等实现音频功能。例如音乐播放,录音等。
音频模块260用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。音频模块260还可以用于对音频信号编码和解码。在一些实施例中,音频模块260可以设置于处理器210中,或将音频模块260的部分功能模块设置于处理器210中。
扬声器270A,也称“喇叭”,用于将音频电信号转换为声音信号。电子设备200可以通过扬声器270A收听音乐,或收听免提通话。
一些实施例中,扬声器270A可用于播放本申请实施例提及的三维提醒声。
受话器270B,也称“听筒”,用于将音频电信号转换成声音信号。当电子设备200接听电话或语音信息时,可以通过将受话器270B靠近人耳接听语音。
麦克风270C,也称“话筒”,“传声器”,用于将声音信号转换为电信号。当拨打电话或发送语音信息时,用户可以通过人嘴靠近麦克风270C发声,将声音信号输入到麦克风270C。电子设备200可以设置至少一个麦克风270C。在另一些实施例中,电子设备200可以设置两个麦克风270C,除了采集声音信号,还可以实现降噪功能。在另一些实施例中,电子设备200还可以设置三个,四个或更多麦克风270C,形成麦克风阵列,实现采集声音信号,降噪,还可以识别声音来源,实现定向录音功能等。
一些实施例中,麦克风270C用于采集电子设备所处的外界环境的声音。
另外,在上述部件之上,运行有操作***。例如iOS操作***,Android操作***,Windows操作***等。在操作***上可以安装运行应用程序。
图2b是本申请实施例的电子设备的软件结构框图。
分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,将Android***分为四层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和***库,以及内核层。
应用程序层可以包括一系列应用程序包。如图2b所示,应用程序包可以包括相机,图库,日历,通话,地图,导航,WLAN,以及蓝牙等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface,API)和编程框架。应用程序框架层包括一些预先定义的函数。如图2b所示,应用程序框架层可以包括窗口管理器,内容提供器,电话管理器,资源管理器,通知管理器,视图***等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小,判断是否有状态栏,锁定屏幕,截取屏幕等。
内容提供器用来存放和获取数据,并使这些数据可以被应用程序访问。所述数据可以包括视频,图像,音频,拨打和接听的电话,浏览历史和书签,电话簿等。
电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通,挂断等)。
资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息,可以用于传达告知类型的消息,可以短暂停留后自动消失,无需用户交互。比如通知管理器被用于告知下载完成,消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在***顶部状态栏的通知,例如后台运行的应用程序的通知,还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息,发出提示音,电子设备振动,指示灯闪烁等。
视图***包括可视控件,例如显示文字的控件,显示图片的控件等。视图***可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如,包括短信通知图标的显示界面,可以包括显示文字的视图以及显示图片的视图。
Android Runtime包括核心库和虚拟机。Android runtime负责安卓***的调度和管理。在本申请一些实施例中,应用冷启动会在Android runtime中运行,Android runtime由此获取到应用的优化文件状态参数,进而Android runtime可以通过优化文件状态参数判断优化文件是否因***升级而导致过时,并将判断结果返回给应用管控模块。
核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。
***库可以包括多个功能模块。例如:表面管理器(surface manager),媒体库(Media Libraries),三维图形处理库(例如:OpenGL ES),二维图形引擎(例如:SGL)等。
表面管理器用于对显示子***进行管理,并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的音频,视频格式回放和录制,以及静态图像文件等。媒体库可以支持多种音视频编码格式,例如:MPEG2,H.262,MP3,AAC,AMR,JPG,PNG等。
三维图形处理库用于实现三维图形绘图,图像渲染、合成和图层处理等。
二维图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层。内核层至少包含显示驱动,摄像头驱动,音频驱动,和传感器驱动等。
需要说明的是,本申请实施例虽然以Android***为例进行说明,但是其基本原理同样适用于基于iOS、Windows等操作***的电子设备。
本申请实施例中,降噪耳机通常可为蓝牙耳机。蓝牙耳机为支持蓝牙通信协议的耳机。其中,蓝牙通信协议可以为ER传统蓝牙协议,也可以为BDR传统蓝牙协议,还可以为BLE低功耗蓝牙协议。当然,还可以是未来推出的其他新的蓝牙协议类型。从蓝牙协议的版本角度,蓝牙通信协议的版本可以为下述中的任一:1.0系列版本、2.0系列版本、3.0系列版本、4.0系列版本、基于未来推出的其他系列版本。
本申请实施例的蓝牙耳机,通常指由左耳机和右耳机组成的双蓝牙耳机,能够为用户提供立体声的音效。常见的双蓝牙耳机有传统入耳式蓝牙耳机和真无线立体声(truewireless stereo,TWS)蓝牙耳机。传统入耳式蓝牙耳机虽然省去了两个耳机与音源之间的连接线,但是左耳机和右耳机之间仍然需要通过连接线连接,才能进行音频信号的同步。而TWS蓝牙耳机不仅省去了两个耳机与音源之间的连接线缆,还省去了左耳机和右耳机之间的连接线。
左耳机和右耳机内均设置有蓝牙模块,左耳机和右耳机可以之间通过蓝牙协议进行数据传输。左耳机和右耳机均包括麦克风,也就是说,主耳机和副耳机除了具有音频播放的功能外,主耳机和副耳机还具有音频采集的功能。
本申请实施例中的蓝牙耳机可以为下述应用中的一种或多种:HSP(HeadsetProfile)应用、HFP(Hands-free Profile)应用、A2DP(Advanced Audio DistributionProfile)应用、AVRCP(Audio/Video Remote Control Profile)应用。
其中,HSP应用代表耳机应用,提供电子设备与耳机之间通信所需的基本功能。蓝牙耳机可以作为电子设备的音频输入和输出接口。
HFP应用代表免提应用,HFP应用在HSP应用的基础上增加了某些扩展功能,蓝牙耳机可以控制终端的通话过程,例如:接听、挂断、拒接、语音拨号等。
A2DP应用为高级音频传送应用,A2DP能够采用耳机内的芯片来堆栈数据,达到声音的高清晰度。
AVRCP应用为音频视频遥控应用,AVRCP应用定义了如何控制流媒体的特征,包括:暂停、停止、启动重放、音量控制及其它类型的远程控制操作。
还需要说明的是,本申请实施例中,降噪耳机可设置耳机智能提醒告警声功能的启动按钮。如图3a所示的一种示例中,右耳机上设置耳机智能提醒告警声功能的启动按钮101,启动按钮101可包含第一位置11和第二位置22。启动按钮101位于第一位置11,耳机智能提醒告警声功能被启动;启动按钮101位于第二位置22,耳机智能提醒告警声功能被关闭。
其中,耳机智能提醒告警声功能的启动按钮,可以为降噪耳机的其他功能的按钮为同一个按钮,也可为一个单独的按钮。
在降噪耳机启动耳机智能提醒告警声功能后,在降噪耳机确定用户周围有告警声时,降噪耳机可向用户播放告警声。降噪耳机向用户播放的告警声的种类,可进行设定。同样参见图3a的示例,左耳机上设置告警声选择按钮102。通过告警声选择按钮102的触发,进行告警声的选择。
一些实施例中,用户点击告警声选择按钮102,降噪耳机响应用户的点击操作进行语音播报,进行告警声的选择。一个示例中,告警声可分三种模式:默认告警声、智能推荐告警声和手动选择告警声。其中,默认告警声为***设定的告警声,智能推荐告警声可结合降噪耳机的运行状态提供不同的告警声,手动选择告警声,用户可通过点击告警声选择按钮102选择手动选择不同的告警声,如不同种类的车辆的鸣笛声。
需要说明的是,图3a以头戴式蓝牙耳机为例进行说明,但这并不构成对本申请实施例所涉蓝牙耳机的限定。并且,图3a展示的启动按钮101和告警声选择按钮102是物理按键,在一些实施例中,启动按钮101和告警声选择按钮102也可以是虚拟按键。
蓝牙耳机的左耳机或右耳机可设置虚拟按键,通过对虚拟按键的触发来启动耳机智能提醒告警声功能。虚拟按键的触发也可设置为多种形式,一些实施例中,通过不同时长的触摸来实现启动或关闭耳机智能提醒告警声功能;另一些实施例中,也可以通过不同次数的触摸来实现启动或关闭耳机智能提醒告警声功能;另一些实施例中,还可通过触发不同位置来实现启动或关闭耳机智能提醒告警声功能。
同理,蓝牙耳机的左耳机或右耳机也可设置虚拟按键,通过对虚拟按键的触发来不同的告警声的选择。虚拟按键的触发也可设置为多种形式,一些实施例中,通过不同时长的触摸来选择不同的告警声;另一些实施例中,也可以通过不同次数的触摸来择不同的告警声;另一些实施例中,还可通过触发不同位置来实现择不同的告警声。
耳机智能提醒告警声功能的控制启动和关闭,以及不同告警声的控制选择,还可以通过电子设备来实现。
参见图3b的一种示例,电子设备的蓝牙耳机的设置界面上呈现有耳机智能提醒告警声、主动降噪、手势和告警声选择四种项目,用户可通过每一条项目的启动按钮来启动该项目对应的功能。图3b的展示的示例中,耳机智能提醒告警声处于启动状态,其他三个项目的功能处于关闭状态。
需要指出的是,耳机智能提醒告警声被启动,与手机蓝牙连接的降噪耳机可与手机进行交互,实现在用户周边出现危险的告警声时,进行告警声提醒。
告警声的选择被启动,用户可通过手动输入操作,完成在用户周边出现危险的告警声时,进行告警声提醒时的告警声的选择。
告警声的选择是具有子界面的项目,用户通过滑动点击告警声的选择的启动按钮,告警声的选择功能被启动,并且,告警声的选择的子界面被显示。图3b的示例中,告警声的选择的子界面展示了四种模式,分别为默认告警声、智能推荐告警声、自定义和手动选择告警声。默认告警声、智能推荐告警声和手动选择告警声可如前所述。自定义可以理解成用户可编辑完成自定义的告警声。图3b的展示的示例中,默认告警声处于启动状态,其他三个模式处于关闭状态。
若用户启动手动选择告警声,即用户滑动点击手动选择告警声的启动按钮,手动选择告警声的子界面被显示,如图3b的示例。在本示例中,手动选择告警声的子界面包括四种车辆的告警声,用户可通过不同车辆的启动按钮,来选择告警声。图3b展示的示例中,车辆1处于被启动状态,其他三种车辆处于关闭状态。
还需要说明的是,前述提出的如手机等电子设备以及降噪耳机,还可设置告警声检测模型,告警声检测模型具有预测输入到告警声检测模型的音频信息中是否包含告警声的功能。告警声检测模型可采用卷积神经网络(Convolutional Neural Network,CNN)、长短期记忆人工神经网络(Long-Short Term Memory,LSTM)等基础网络模型。
卷积神经网络通常包括:输入层、卷积层(Convolution Layer)、池化层(Poolinglayer)、全连接层(Fully Connected Layer,FC)和输出层。一般来说,卷积神经网络的第一层是输入层,最后一层是输出层。
卷积层(Convolution Layer)是指卷积神经网络中对输入信号进行卷积处理的神经元层。在卷积神经网络的卷积层中,一个神经元可以只与部分邻层神经元连接。一个卷积层中,通常包含若干个特征平面,每个特征平面可以由一些矩形排列的神经单元组成。同一特征平面的神经单元共享权重,这里共享的权重就是卷积核。
池化层(Pooling layer),通常在卷积层之后会得到维度很大的特征,将特征切成几个区域,取其最大值或平均值,得到新的、维度较小的特征。
全连接层(Fully-Connected layer),把所有局部特征结合变成全局特征,用来计算最后每一类的得分。
长短期记忆人工神经网络(Long-Short Term Memory,LSTM)通常包括输入层、隐含层以及输出层。其中,输入层由至少一个输入节点组成;当LSTM网络为单向网络时,隐含层仅包括前向隐含层,当LSTM网络为双向网络时,隐含层包括前向隐含层以及后向隐含层。对于每个输入节点分别与前向隐含层节点以及后向隐含层节点连接,用于分别向前向隐含层节点以及后向隐含层节点输出输入数据,每个隐含层中的隐含节点分别与输出节点连接,用于向输出节点输出自己的计算结果,输出节点根据隐含层的输出节点进行计算,并输出数据。
告警声检测模型可采用下述方式进行训练:
构建告警声检测原始模型。其中,告警声检测原始模型可选择CNN、LSTM等基础网络模型。
获取大量的训练样本,训练样本包括:包含告警声的样本以及不包含告警声的样本,并且,训练样本被标记出样本中是否包含告警声。训练样本中的告警声,可如车辆的鸣笛声。当然,为了训练出告警声检测模型能够预测的告警声更多样,可获取包含汽车、摩托车等不同种类的机动车的鸣笛声的训练样本,以及包含警铃声等其他告警声的训练样本。警铃声可以理解成是救护车、警车、以及消防车等特殊车辆行驶时的警报声。
将训练样本输入到告警声检测原始模型,由告警声检测原始模型对训练样本是否包含告警声进行检测,得到检测结果。
利用损失函数对检测结果和每个训练样本的标记结果进行损失值的计算,得到模型的损失值。一些实施例中,可采用交叉熵损失函数、加权损失函数等损失函数进行损失值计算,或者采用多种损失函数组合的方式,计算多种损失值。
判断模型的损失值是否符合模型的收敛条件。
一些实施例中,模型收敛条件可以是,模型的损失值小于或等于预先设定的损失阈值。也就是说,可以将模型的损失值和损失阈值进行比较,若模型的损失值大于损失阈值,则可以判断出模型的损失值不符合模型收敛条件,反之,若模型的损失值小于或等于损失阈值,则可以判断出模型损失值符合模型收敛条件。
需要说明的是,多个训练样本,可以针对每一个训练样本计算得到对应的模型的损失值,这种情况下,只有在每一个训练样本的模型损失值均符合模型收敛条件的情况下才会执行,反之,只要有一个训练样本的模型损失值不符合模型收敛条件,则执行后续步骤。
若模型的损失值符合模型的收敛条件,则说明模型训练结束。训练结束的模型则可用于下述实施例提出的音频信息的处理方法,对输入到模型的音频信息是否包含告警声的检测。
若模型的损失值不符合模型的手链条件,则根据模型的损失值计算得到模型的参数更新值,并以模型的参数更新值,更新告警声检测原始模型。并利用更新后的模型,继续对训练样本进行处理,得到检测结果,继续执行后续过程,直至模型的损失值符合模型的收敛条件。
还需要说明的是,本申请实施例中,可基于麦克风阵列的声源定位算法等,对声音进行定位。声源定位算法是利用麦克风阵列进行声音定位。常用的声源定位算法主要有三大类:基于高分辨率谱估计的定位技术、基于可控波束形成(Beamforming)的定位技术和基于TDOA的定位技术。
基于TDOA的声音定位算法实现原理简单,一般分为延时估计和声源定位两个部分,延时估计可计算出来自于不同麦克风的两路信号的到达时间差,声源定位可根据时间差计算出声源发出的声音的角度。
时延估计的算法主要有基于相关分析的时延估计方法,基于相位谱估计的时延估计方法,基于参数估计的时延估计方法等,应用最广泛的方法主要为基于相关分析的时延估计方法中的广义互相关函数法(GCC)。基于相关分析的时延估计方法中的广义互相关函数法(GCC)引入了一个加权函数,对互功率谱密度进行调整,从而优化时延估计的性能。根据加权函数的不同,广义互相关函数有多种不同的变形,广义互相关-相位变换方法(Generalized Cross Correlation PHASE Transformation,GCC-PHAT)方法应用最为广泛。
广义互相关函数时延估计算法,根据两路麦克风信号的互相关函数峰值来估计时延值。在声源定位***中,麦克风阵列的每个阵元接收到的目标信号都来自于同一个声源。因此,各通道信号之间具有较强的相关性。理想情况下,通过计算每两路信号之间的相关函数,就可以确定两个麦克风观测信号之间的时延。
阵列中两个麦克风的接收信号x1(t)和x2(t),如公式一所示,为:
公式一
x1(t)=a1s(t-τ1)+n1(t)
x2(t)=a2s(t-τ2)+n2(t)
其中,t指代时间,s(t)为声源信号,n1(t)和n2(t)为环境噪声,τ1和τ2是信号从声源处传播到两个麦克风阵元的传播时间。
广义互相关时延估计算法的原理可参见图3c。
图3c中,X1(ω)为对x1(t)进行傅里叶变换FFT的结果,X2(ω)为对x2(t)进行傅里叶变换FFT的结果,ω指代麦克风的接收信号的角频率,(.)*指代对X2(ω)进行共轭处理,φ(ω)为相位变换加权函数,用于对X1(ω)和X2(ω)的共轭做相位变换加权,得到计算结果。计算结果再反傅里叶变换IFFT之后进行峰值检测,利用峰值检测结果输出τ12。
其中,τ12=τ1-τ2,为两路麦克风信号的时间差。
GCC-PHAT只利用了两个麦克风的信号,如果麦克风数量多于两个,就可以使用其他方法进行延时估计,比如基于相位变换加权的可控响应功率的声源定位算法(SteeredResponse Power-Phase Transform,SRP-PHAT)。SRP-PHAT算法的基本原理是在假想声源位置计算所有麦克风对接收信号的相位变换加权的广义互相关GCC-PHAT函数之和,在整个声源空间寻找使SRP值最大的点即为声源位置估计。
实施例一
基于前述内容,本实施例提供了一种音频信息的处理方法,本实施例提供的音频信息的处理方法,可用于图1的应用场景。参见图4,该音频信息的处理方法,包括步骤:
S401、手机获取音频信息。
其中,音频信息为采集外界环境的声音而得到,可通过麦克风采集外界环境的声音。在图1所示的应用场景中,手机和降噪耳机均设置有麦克风,因此,可由手机中的麦克风或降噪耳机中的麦克风采集外界环境的声音,得到音频信息。
还需要说明的是,耳机智能提醒告警声功能被启动之后,在降噪耳机处于运行状态,手机或降噪耳机可周期性或实时的采集外界环境的声音,得到音频信息。
降噪耳机采集外界环境的声音,得到音频信息,可通过蓝牙通道等与手机连接的通道,将音频信息传输到手机。
本实施例以降噪耳机采集外界环境的声音,得到音频信息,手机获取降噪耳机得到的音频信息,并执行下述步骤为例进行说明。
S402、手机调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果,该检测结果用于指示音频信息是否包含告警声。
如前所述,告警声检测模型具有预测输入到告警声检测模型的音频信息中是否包含告警声的功能。因此,在获取外界环境的音频信息后,可利用告警声检测模型,对音频信息进行是否包含告警声的检测,并得到检测结果。
本实施例中,手机获取音频信息后,调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果。
另一些实施例中,也可由降噪耳机调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果,再将检测结果传输到手机。如此,手机可不执行步骤S402。
若检测结果指示音频信息包含告警声,则执行步骤S403和步骤S404;若检测结果指示音频信息不包含告警声,则返回执行步骤S401。
需要说明的是,本申请实施例提及的告警声,均可以理解成前述内容提及的告警声,如多种类型的机动车的鸣笛声或者警铃声。
S403、手机利用音频信息对告警声进行定位,得到告警声相对于用户的位置信息。
本实施例中,手机可利用前述内容提出的基于麦克风阵列的声源定位算法,利用音频信息对告警声进行声源定位。具体的,手机利用降噪耳机的左耳机的麦克风采集的音频信息,以及右耳机的麦克风采集的音频信息,对告警声进行声源定位,得到告警声相对于用户的位置信息,该位置信息一般包括告警声相对于用户的水平方向角θ。图5展示了告警声相对于用户(指代用户人头的中心点)的水平方向角θ的一种示例。
需要说明的是,因手机利用耳机采集的音频信息进行定位,因此本步骤得到的告警声相对于用户的位置信息,是指告警声相对于耳机的位置信息。同理,下述内容中提出的告警声相对于用户的位置信息均指代告警声相对于耳机的位置信息。
还需要说明的是,采用基于麦克风阵列的声源定位算法,得到的告警声相对于用户的位置信息可以理解成是告警声的相对位置信息。当然,步骤S403中,手机利用音频信息对告警声进行定位,得到告警声相对于用户的位置信息,也可以是指得到告警声的绝对位置。
另一些实施例中,也可由降噪耳机利用左耳机的麦克风采集的音频信息和右耳机的麦克风采集的音频信息,前述内容提出的基于麦克风阵列的声源定位算法,对告警声进行声源定位,得到告警声相对于用户的位置信息。降噪耳机可将得到的告警声相对于用户的方向角传输到手机。如此,手机可不执行步骤S403。
还需要说明的是,由于手机的麦克风也可采集外界环境的声音,得到音频信息,因此,本申请的另一些实施例中,手机可获取手机内置的麦克风阵列采集的音频信息,并利用麦克风阵列采集的音频信息,对告警声进行声源定位,得到告警声相对于手机的位置信息。
由于手机和用户可能会存在相对角度,因此,手机利用自身的麦克风阵列采集的音频信息,得到告警声相对于手机的位置信息之后,还需要对告警声相对于手机的位置信息进行坐标转换,得到告警声相对于用户的位置信息。
其中,可基于手机和降噪耳机相对的同一个的坐标系,对告警声相对于手机的位置信息进行坐标转换,得到告警声相对于用户的位置信息。一些实施例中,因手机和降噪耳机相对于大地坐标系已知,因此,可基于大地坐标系,对告警声相对于手机的位置信息进行坐标转换,得到告警声相对于用户的位置信息。当然,还可以基于其他手机和降噪耳机均统一的坐标系进行坐标转换。
为了适配坐标转换,需要降噪耳机计算出相对大地坐标系的姿态角,因此,降噪耳机内需设置加速度传感器和角速度传感器,通常需要设置与手机同种类的加速度传感器和角速度传感器。
具体的,手机利用自身的加速度传感器以及角速度传感器的检测数据,计算得到手机的姿态角。降噪耳机利用自身的加速度传感器以及角速度传感器的检测数据,计算得到耳机的姿态角。手机获取耳机的姿态角,并利用手机的姿态角和耳机的姿态角,确定耳机和手机的坐标系的转换关系,利用该转换关系,处理告警声相对手机的位置信息,得到告警声相对于用户的位置信息。
需要说明的是,手机和降噪耳机利用自身的加速度传感器以及角速度传感器的检测数据,计算得到姿态角的具体方式,可参见常规方式,此处不展开说明。同理,手机利用手机的姿态角和耳机的姿态角,确定耳机和手机的坐标系的转换关系,利用该转换关系,处理告警声相对手机的位置信息,得到告警声相对于用户的位置信息,也可参见常规方式,此处不展开说明。
还需要说明的是,本申请的另一些实施例中,手机获取手机内置的麦克风阵列采集的音频信息,手机将获取的音频信息,传输到降噪耳机。降噪耳机利用音频信息,对告警声进行定位,得到告警声相对于用户的位置信息。
具体的,手机的麦克风阵列采集外界环境的音频信息,因此,降噪耳机利用该音频信息,采用前述内容提出的基于麦克风阵列的声源定位算法,对告警声进行声源定位时,得到的是告警声相对于手机的位置信息。降噪耳机再采用前述内容,对告警声相对于手机的位置信息进行坐标转换,得到告警声相对于用户的位置信息。
S404、手机检测音频信息,与前一个包含告警声的音频信息是否在预设时间段内获取。
若手机检测音频信息与前一个包含告警声的音频信息不是在预设时间段内获取,则执行步骤S405至S407;若手机检测音频信息,与前一个包含告警声的音频信息的时间差在预设时间段内获取,则执行步骤S408至S413。
因手机是周期性获取音频信息,因此,前一个包含告警声的音频信息是指:手机针对本次确定包含告警声的音频信息之前进行告警声检测时,最邻近的一次确定包含告警声的音频信息。
手机检测音频信息和前一个包含告警声的音频信息在预设时间段内获取,说明手机在一个时间段内连续检测到两个告警声,因此可能需要重点提醒用户该告警声。
需要说明的是,可根据实际需求设定预设时间段,因需要通过步骤S404来筛选出连续的两个告警声,因此预设时间段不宜设定过长。在一个示例中,预设时间段可设定为30秒。
S405、手机基于告警声相对于用户的位置信息,处理标准提醒声得到三维提醒声。
其中,三维提醒声可以理解成是携带有方向的告警声。可通过三维声音技术处理标准提醒声,得到携带方位的告警声。携带方向的告警声输出给用户后,可以让用户感受到告警声的方向。
需要说明的是,本实施例中,手机预先存储有多个标准提醒声,用户可采用前述内容提出的告警声选择方式,预先设定进行告警提醒的标准提醒声。当然,也可以在执行本步骤之前,通过手机展示图3b的告警声的选择的界面,提醒用户进行标准提醒声的设定。
标准提醒声,可以理解成是不包含杂音的告警声,通常可为车辆的鸣笛声。
一些本实施例中,手机还预先存储多个头部相关变换函数(Head-ResponseTransfer Function,HRTF)值;其中,多个头部相关变换函数(Head-Response TransferFunction,HRTF)值,通常按照左右耳机成对设置。即多个的HRTF值被分为多个左耳机的HRTF值和每个左耳机的HRTF值对应的右耳机的HRTF值。一对左、右耳机的HRTF值分别对应一个告警声相对于用户的一个角度值。
通常可以人头为中心点,间隔中心点一定距离的360°可被划分为多个角度值,每一个角度值设置两个对应的头部相关变换函数(Head-Response Transfer Function,HRTF)值,一个HRTF值对应左耳机,一个HRTF值对应右耳机。一些实施例中,可将中心点***的360°进行等分,划分为多个角度值。并且,划分角度的数量,可根据实际情况进行设定。
头部相关变换函数(Head-Response Transfer Function,HRTF)是一种声音定位的处理技术,通过测量人耳对不同方位声音变换数据,统计并计算得出的人耳感知模型。
本实施例中,头部相关变换函数(Head-Response Transfer Function,HRTF)值的计算方式如公式二所示:
公式二
PL和PR分别是声源在左右耳产生的频域复数声压;P0是人头移开后,声源在头部中心的频域的声压,P0的定义如公式三所示:
公式三
其中,ρ0是介质(空气)的密度,c代表声音的速度,常温下空气中的c为344m/s,Q0是声源的强度,k=2πf/c是声波的波数,r代表声源距离人的相对距离,如1.5米,f代表声音的频率。
基于前述内容,本步骤的一个可能的实施方式,包括:
获取用户设定的标准提醒声。
利用告警声相对于用户的位置信息,获取该位置信息对应的左耳机的HRTF值和右耳机的HRTF值。
一些实施例中,告警声相对于用户的位置信息包括:告警声相对于用户水平方向角。将告警声相对于用户的水平方向角为筛选因子,在手机内存储的多个HRTF值进行筛选,得到告警声相对于用户的水平方向角相匹配的左耳机的HRTF值和右耳机的HRTF值。
将标准提醒声,分别与位置信息对应的左耳机的HRTF值和右耳机的HRTF值进行傅里叶变换乘积处理,得到双耳输出信号,即左耳机的三维提醒声和右耳机的三维提醒声。
另一些实施例中,手机还可预先存储多个头相关冲击响应(Head RelatedInpulse Response,HRIR)值;其中,多个头相关冲击响应(Head Related InpulseResponse,HRIR)值,通常按照左右耳机成对设置。即多个的HRIR值被分为多个左耳机的HRIR值和每个左耳机的HRIR值对应的右耳机的HRIR值。一对左、右耳机的HRIR值分别对应一个告警声相对于用户的一个角度值。
头相关冲击响应(Head Related Inpulse Response,HRIR)属于时域信号,头部相关变换函数(Head-Response Transfer Function,HRTF)属于HRIR对应的频域信号。
基于此,本步骤的另一个可能的实施方式,包括:
获取用户设定的标准提醒声。
利用告警声相对于用户的位置信息,获取该位置信息对应的左耳机的HRIR值和右耳机的HRIR值。
一些实施例中,告警声相对于用户的位置信息包括:告警声相对于用户的水平方向角。将告警声相对于用户的水平方向角为筛选因子,在手机内存储的多个HRIR值进行筛选,得到告警声相对于用户的水平方向角相匹配的左耳机的HRIR值和右耳机的HRIR值。
将标准提醒声,分别与位置信息对应的左耳机的HRIR值和右耳机的HRIR值进行卷积处理,得到双耳输出信号,即左耳机的三维提醒声和右耳机的三维提醒声。
还需要说明的是,前述内容提出的基于告警声相对于用户的位置信息,可以与步骤S403中得到的告警声相对于用户的位置信息完全相同,也可以近似相同,或两者差值在一定的范围内。
S406、手机向降噪耳机发送三维提醒声。
一些实施例中,手机可通过蓝牙等连接通道,向降噪耳机发送左耳机的三维提醒声和右耳机的三维提醒声。
S407、降噪耳机播放三维提醒声。
其中,降噪耳机的左耳机输出左耳机的三维提醒声,右耳机输出右耳机的三维提醒声。
本实施例中,在外界环境的音频中检测到告警声,手机利用音频信息对告警声进行定位,得到告警声相对于用户的位置信息,并基于告警声相对于用户的位置信息,处理标准提醒声得到三维提醒声,再由降噪耳机播放三维提醒声,可提醒用户周围出现告警声,存在安全问题。
S408、手机判断音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值,是否在预设范围内。
若手机判断出音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值未在预设范围内,则执行步骤S405。
若手机判断出音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值在预设范围内,则执行步骤S409。
其中,音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值在预设范围内,说明在同一个范围内先后出现了两次告警声,需要重点提醒用户该告警声。
预设范围可根据实际情况进行设定,一般可设定告警声相对于用户的水平方向角之差小于第一阈值。当然,第一阈值可根据实际情况进行设定,一个示例中,第一阈值可为5°。
S409、手机检测音频信息与前一个包含告警声的音频信息,是否属于相同声音。
一些实施例中,手机检测音频信息与前一个包含告警声的音频信息,是否属于相同声音是指:手机检测音频信息中的告警声,与前一个包含告警声的音频信息中的告警声,是否属于同一告警声。
本步骤中,对音频信息中的告警声,与前一个包含告警声的音频信息中的告警声是否属于同一告警声的检测方式,可包含下述两种。
第一种:检测音频信息与前一个包含告警声的音频信息,是否属于相同声音。
第二种:从音频信息以及前一个包含告警声的音频信息中,分别提出告警声;判断提取得到的两个告警声是否属于同一个告警声。
其中,告警声检测模型检测音频信息包含告警声时,告警声检测模型可得到音频信息中的告警声的位置信息,因此,可利用该告警声的位置信息,从音频信息以及前一个包含告警声的音频信息中提取告警声。
以下以第一种方式为例,对音频信息中的告警声,与前一个包含告警声的音频信息中的告警声是否属于同一告警声的过程进行具体说明。当然,在第二种方式中,判断两个告警声是否属于同一个告警声的方式,也可参见下述内容。
还需要说明的是,前后两个告警声,告警声的强度可能不同,但若两者属于同一声源的告警声,那告警声的频率应是相同的,因此,一个可能的实施方式中,可利用幅度谱进行判断前后两个包含告警声的音频信息是否属于相同声音。具体实施方式如下:
获取前后两个包含告警声的音频信息。
对每个包含告警声的音频信息进行时域到频域的转换,得到每个包含告警声的音频信息的幅度谱。其中,可通过对包含告警声的音频信息进行傅里叶变换,得到音频信息的幅度谱。
需要说明的是,幅度谱的x轴是频率,y轴是音频信息的幅度。利用幅度谱可以查看指定频率端的能量分布。
利用前后两个包含告警声的音频信息的幅度谱,对前后两个音频信息进行相似度计算,得到计算结果,该计算结果用于表征前后两个音频信息是否属于同一声音。
一些实施例中,可采用皮尔逊相关函数,对前后两个包含告警声的音频信息进行相似度计算,得到相似度值。
具体的,对前后两个包含告警声的音频信息进行采样点采集,得到每个包含告警声的音频信息的n个采样点,前后两个包含告警声的音频信息的采样点可称之为(Xi,Yi),利用前后两个包含告警声的音频信息的采样点代入下述公式四,可计算得到皮尔逊相关系数r。
公式四
当计算出皮尔逊相关系数r后,可以通过表一判断前后两个包含告警声的音频信息的相关强度。
表一
r |
相关强度 |
0.8-1.0 |
极强相关 |
0.6-0.8 |
强相关 |
0.4-0.6 |
中等程度相关 |
0.2-0.4 |
弱相关 |
0.0-0.2 |
极弱相关 |
需要说明的是,可按照表一提供的皮尔逊相关系数r和相关强度的关系,设定一个阈值,如设定阈值为0.8。前后两个包含告警声的音频信息的相似度值大于该阈值,则前后两个包含告警声的音频信息属于同一声音,前后两个包含告警声的音频信息的相似度值不大于阈值,则前后两个包含告警声的音频信息不属于同一个声音。
另一些实施例中,可通过分类模型预测两个音频信息是否属于相同声音,如二分类模型、som模型、SVM模型等。本实施例中,分类模型的训练过程可参见前述内容提出的告警声检测模型的内容,此处不展开说明。
训练结束的分类模型,具有预测输入到分类模型的两路输入信号,如本实施例的前后两个包含告警声的音频信息,是否为同一类的分类结果,得到预测结果。一种示例中,预测结果为1,前后两个包含告警声的音频信息属于同一声音;预测结果为0,前后两个包含告警声的音频信息不属于同一个声音。
其中,若检测音频信息与前一个包含告警声的音频信息属于相同声音,则执行步骤S410。若检测音频信息与前一个包含告警声的音频信息不属于相同声音,则执行步骤S405。
还需要说明的是,手机检测音频信息与前一个包含告警声的音频信息属于相同声音,说明用户在同一个方位,连续两次出现了同一声源的告警声,因此,需要重点提醒用户该告警声。
还需要说明的是,步骤S403,与步骤S404、步骤S408和步骤S409可不限于图4展示的执行顺序,可并行执行。并且,步骤S404、步骤S408和步骤S409也可不限于图4展示的执行顺序,可并行执行或采用其他执行顺序。
S410、手机生成距离系数,该距离系数用于表征音频信息相对于前一个包含告警声的音频信息的能量增益。
需要说明的是,若音频信息的能量大于前一个包含告警声的音频信息的能量,则该能量增益为正,即距离系数为大于1的数值;若音频信息的能量小于前一个包含告警声的音频信息的能量,则该能量增益为负,即距离系数为小于1的数值;若音频信息的能量与前一个包含告警声的音频信息的能量相同,则该能量增益为0,即距离系数为1。
一些实施例中,假设音频信息的能量值为z1,后一个包含告警声的音频信息的能量值为z2,距离系数gain可采用公式五计算得到。
公式五
gain=log(z2+k)/log(z1+k)
式中,k为常数。
还需要说明的是,预先可设定距离系数的范围,如0.1到10。在步骤S410计算得到距离系数后,比对该距离系数是否位于距离系数的范围内。若距离系数位于距离系数的范围,则可执行下述步骤,若距离系数超过距离系数的范围,则以距离系数的范围的端点值(即距离系数的范围的最大值或最小值)作为本步骤的距离系数执行下述步骤。当然,要以生成的距离系数最接近的端点值,作为本步骤的距离系数执行下述步骤。
在步骤S410生成的距离系数超过距离系数的范围时,以距离系数的范围的端点值作为本步骤的距离系数执行下述步骤,可以避免生成的距离系数过大或过小,导致下述步骤生成的带有能量增益的三维提醒声的音量多大或多小。
S411、手机基于告警声相对于用户的位置信息和距离系数,处理标准提醒声得到携带能量增益的三维提醒声。
本步骤中,获取标准提醒声,以及确定HRTF值和HRIR值的方式与前述步骤S405的内容相同,此处不展开说明。
在一个可能的实施方式中,将标准提醒声进行傅里叶变换处理,再分别与位置信息对应的左耳机的HRTF值和右耳机的HRTF值进行乘积,得到双耳输出信号,即左耳机的三维提醒声和右耳机的三维提醒声,再将左耳机的三维提醒声和右耳机的三维提醒声分别与距离系数gain作乘,得到左、右耳机携带能量增益的三维提醒声。
在另一个可能的实施方式中,将标准提醒声,分别与位置信息对应的左耳机的HRIR值和右耳机的HRIR值进行卷积处理,得到双耳输出信号,即左耳机的三维提醒声和右耳机的三维提醒声,再将左耳机的三维提醒声和右耳机的三维提醒声分别与距离系数gain作乘,得到左、右耳机的携带能量增益的三维提醒声。
本实施例中,手机处理标准提醒声得到携带能量增益的三维提醒声,若告警声的声源不断靠近用户,则手机后一次获取的音频信息的能量,要大于前一次获取的音频信息的能量,因此,能量增益为正,距离系数大于1,携带能量增益的三维提醒声要比前一次三维提醒声能量大,可以保证以该携带能量增益的三维提醒声重点提醒用户。
S412、手机向降噪耳机发送携带能量增益的三维提醒声。
一些实施例中,手机可通过蓝牙等连接通道,向降噪耳机发送左耳机的携带能量增益的三维提醒声以及右耳机的携带能量增益的三维提醒声。
S413、降噪耳机播放携带能量增益的三维提醒声。
其中,降噪耳机的左耳机输出左耳机的携带能量增益的三维提醒声,右耳机输出右耳机的携带能量增益的三维提醒声。
需要说明的是,前述步骤S404,步骤S408至步骤S413是可选性执行的步骤。一些实施例中,若需要在用户所处环境出现告警声,通过降噪耳机提醒用户告警声,则可不执行步骤S404,步骤S408至步骤S413。在执行步骤S403之后直接执行步骤S405至步骤S407。
还需要说明的是,实施例一提供的音频信息的处理方法,也可由降噪耳机来执行。
一些实施例中,降噪耳机完全替代手机,完整执行图4展示的音频信息的处理方法。即耳机智能提醒告警声功能被启动之后,降噪耳机运行过程中,利用自身的麦克风采集外界环境的声音,得到音频信息,并利用音频信息执行步骤S402至步骤S405,步骤S407至步骤S411,以及步骤S413。
另一些实施例中,耳机智能提醒告警声功能被启动,手机的麦克风阵列采集外界环境的声音,得到音频信息。降噪耳机利用音频信息执行步骤S402至步骤S405,步骤S407至步骤S411,以及步骤S413。
实施例二
参见图6,本实施例提供的另一种应用场景中,用户耳戴降噪耳机,手腕处戴有智能手表,手机分别与智能手表和降噪耳机建立有蓝牙连接。在本应用场景中,降噪耳机和智能手表也可以通过蓝牙等连接通道进行信息的交互,实现在用户周边出现危险的告警声时,进行提醒。
需要说明的是,降噪耳机和智能手表的基本组成部件和软件结构,可参见前述内容,此处不再赘述。
本实施例提供的一种音频信息的处理方法,参见图7,包括:
S701、智能手表获取降噪耳机得到的音频信息。
其中,降噪耳机的麦克风采集外界环境的声音,得到音频信息,智能手表可通过蓝牙通道等获取音频信息。
一些实施例中,降噪耳机可通过蓝牙通道等,将音频信息传输到智能手表,再由智能手表通过蓝牙通道将音频信息传输到智能手表。
另一些实施例中,降噪耳机可通过蓝牙通道等,将音频信息传输到智能手表。
S702、智能手表调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果,该检测结果用于表征音频信息是否包含告警声。
如前所述,告警声检测模型具有预测输入到告警声检测模型的音频信息中是否包含告警声的功能。因此,在获取外界环境的音频信息后,智能手表可利用告警声检测模型,对音频信息进行是否包含告警声的检测。本实施例中,智能手表预选存储有训练好的告警声检测模型,智能手表获取音频信息后,调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果。
另一些实施例中,也可由降噪耳机调用告警声检测模型,对音频信息是否包含告警声进行检测,得到检测结果,再将检测结果传输到智能手表。如此,智能手表可不执行步骤S702。
若检测结果指示音频信息包含告警声,则执行步骤S703和步骤S704;若检测结果指示音频信息不包含告警声,则返回执行步骤S701。
S703、智能手表利用音频信息对告警声进行定位,得到告警声相对于用户的位置信息。
本实施例中,智能手表可利用前述内容提出的基于麦克风阵列的声源定位算法,利用音频信息对告警声进行声源定位。具体的,智能手表利用降噪耳机的左耳机的麦克风采集的音频信息,以及右耳机的麦克风采集的音频信息,对告警声进行声源定位,得到告警声相对于用户的位置信息,该位置信息一般包括告警声相对于用户的水平方向角θ。
另一些实施例中,也可由降噪耳机利用左耳机的麦克风采集的音频信息和右耳机的麦克风采集的音频信息,前述内容提出的基于麦克风阵列的声源定位算法,对告警声进行声源定位,得到告警声相对于用户的位置信息。降噪耳机可将得到的告警声相对于用户的方向角传输到智能手表。如此,智能手表可不执行步骤S703。
还需要说明的是,由于手机的麦克风也可采集外界环境的声音,得到音频信息,因此,本申请的另一些实施例中,智能手表可获取手机内置的麦克风阵列采集的音频信息,如通过蓝牙通道获取手机的麦克风阵列采集的音频信息。智能手表再利用麦克风阵列采集的音频信息,对告警声进行声源定位,得到告警声相对于用户的位置信息。
智能手表利用手机的麦克风阵列采集的音频信息,对告警声进行声源定位,得到告警声相对于用户的位置信息的方式,可如实施例一的步骤S403内容,此处不再赘述。
S704、智能手表检测音频信息,与前一个包含告警声的音频信息是否在预设时间段内获取。
若智能手表检测音频信息与前一个包含告警声的音频信息不是在预设时间段内获取,则执行步骤S705至S707;若智能手表检测音频信息,与前一个包含告警声的音频信息的时间差在预设时间段内获取,则执行步骤S708至S713。
S705、智能手表基于告警声相对于用户的位置信息,处理标准提醒声得到三维提醒声。
需要说明的是,用户可采用前述内容提出的告警声选择方式,预先设定进行告警提醒的标准提醒声。当然,也可以在执行本步骤之前,通过手机展示图3b的告警声的选择的界面,提醒用户进行标准提醒声的设定。
一些本实施例中,智能手表还预先存储多个头部相关变换函数(Head-ResponseTransfer Function,HRTF)值;其中,多个头部相关变换函数(Head-Response TransferFunction,HRTF)值,通常按照左右耳机成对设置。即多个的HRTF值被分为多个左耳机的HRTF值和每个左耳机的HRTF值对应的右耳机的HRTF值。一对左、右耳机的HRTF值分别对应一个告警声相对于用户的一个角度值。
另一些实施例中,智能手表还可预先存储多个头相关冲击响应(Head RelatedInpulse Response,HRIR)值;其中,多个头相关冲击响应(Head Related InpulseResponse,HRIR)值,通常按照左右耳机成对设置。即多个的HRIR值被分为多个左耳机的HRIR值和每个左耳机的HRIR值对应的右耳机的HRIR值。一对左、右耳机的HRIR值分别对应一个告警声相对于用户的一个角度值。
智能手表执行步骤S705,处理标准提醒声得到三维提醒声的方式,可如前述实施例一的步骤S405两种可能的实施方式,此处不再赘述。
S706、智能手表向降噪耳机发送三维提醒声。
一些实施例中,智能手表向降噪耳机发送左耳机的三维提醒声和右耳机的三维提醒声。
另一些实施例中,智能手表通过手机向降噪耳机发送左耳机的三维提醒声和右耳机的三维提醒声。
S707、降噪耳机播放三维提醒声。
其中,降噪耳机的左耳机输出左耳机的三维提醒声,右耳机输出右耳机的三维提醒声。
本实施例中,在外界环境的音频中检测到告警声,智能手表利用音频信息对告警声进行定位,得到告警声相对于用户的位置信息,并基于告警声相对于用户的位置信息,处理标准提醒声得到三维提醒声,再由降噪耳机播放三维提醒声,可提醒用户周围出现告警声,存在安全问题。
S708、智能手表判断音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值,是否在预设范围内。
若智能手表判断出音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值,未在预设范围内,则执行步骤S705。
若智能手表判断出音频信息中告警声相对于用户的位置信息,与前一个包含告警声的音频信息中告警声相对于用户的位置信息的差值,在预设范围内,则执行步骤S709。
智能手表执行步骤S708的具体过程,可参见前述实施例一的步骤S408内容,此处不再赘述。
S709、智能手表检测音频信息,与前一个包含告警声的音频信息是否属于相同声音。
智能手表检测音频信息与前一个包含告警声的音频是否属于相同声音的实施方式,可参见前述实施例一的步骤S409的内容,此处不再赘述。
若智能手表检测音频信息与前一个包含告警声的音频信息属于相同声音,则执行步骤S710。若检测音频信息与前一个包含告警声的音频信息不属于相同声音,则执行步骤S705。
S710、智能手表生成距离系数,该距离系数用于表征音频信息相对于前一个包含告警声的音频信息的能量增益。
智能手表生成距离系数的实施方式,可参见前述实施例一的步骤S410的内容,此处不再赘述。
S711、智能手表基于告警声相对于用户的位置信息和距离系数,处理标准提醒声得到携带能量增益的三维提醒声。
智能手表基于告警声相对于用户的位置信息和距离系数,处理标准提醒声得到携带能量增益的三维提醒声的实施方式,可参见前述实施例一的步骤S411的内容,此处不再赘述。
S712、智能手表向降噪耳机发送携带能量增益的三维提醒声。
一些实施例中,智能手表向降噪耳机发送左耳机的携带能量增益的三维提醒声,以及右耳机的携带能量增益的三维提醒声。
另一些实施例中,智能手表通过手机向降噪耳机发送左耳机的携带能量增益的三维提醒声和右耳机的携带能量增益的三维提醒声。
S713、降噪耳机播放携带能量增益的三维提醒声。
其中,降噪耳机的左耳机输出左耳机的携带能量增益的三维提醒声,右耳机输出右耳机的携带能量增益的三维提醒声。
本申请另一实施例还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机或处理器上运行时,使得计算机或处理器执行上述任一个方法中的一个或多个步骤。
本申请另一实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时,使得计算机或处理器执行上述任一个方法中的一个或多个步骤。
本申请另一实施例还提供了一种音频处理***,该***包括电子设备和耳机,电子设备如手机,智能手表等,耳机可以为降噪耳机,其中,电子设备和耳机的工作过程可如前述实施例一和实施例二的内容,此处不展开说明。