揭秘智能音箱里那些神秘的声学技术

音箱行业有着悠久的历史,但是在过去十多年里,传统的音箱行业面临着极大的市场困境,例如蓝牙音箱刚出现各个厂商便直接杀成了一片红海。而2015年随着智能音箱的涌现,特别是亚马逊的Echo、京东的叮咚、阿里的小飞,不仅对外展现出了智能音箱行业百花齐放的局面,也使沉闷的音箱市场看到了突破性发展的希望。但是,随着这些巨头们的集体涌入,这也让在智能音箱行业摸爬滚打的创业者倍感艰难。

  音箱特别是中高端音箱,本来就是强调品牌且技术门槛较高的领域。而智能音箱将声学设计、无线技术、语音识别、远场拾音、语义分析等众多技术融合在一起,不仅技术更为复杂,而且更加依赖音乐内容平台的支持,这些诸多因素都是创业者需要直面解决的难题。当然,技术还是其中的根本,本文希望从市面上现有的流行产品分析其中的几项关键技术,以及一些不可规避的用户体验问题,也给正在创业或者准备进入这个领域的创业者一些参考。

  (1)小型便携与低音增强技术

  音箱行业早在数年前就开始流行小型便携化,最具代表性的就是蓝牙音箱的持续热销。随后的WiFi音箱并没有复制蓝牙音箱的奇迹,主要还是受制于内容平台和技术的缺陷,并没有带来比蓝牙音箱更好的用户体验。智能音箱实际上还是在WiFi音箱的基础上发展的,除了继承其小型便携和无线连接的特点,其本质毕竟还是音箱,其音质设计还应该是第一位的。但是现在看来,市面上的智能音箱基本都忽略了这个问题,在笔者看来,目前还没有音质上乘的智能音箱出现。反而销量并不理想的WiFi音箱更加专注于音质设计,这其中不乏有传统的消费级音箱巨头Bose、JBL和Sony等品牌,也逐渐形成了两大风格派系。以Bose为代表的欧美系更加注重低音的增强体验,而以Sony为代表的日系则尤为看重中高频的细节呈现。我们知道小型箱体设计中很难同时兼具中高频和低频的双重音质保证,而对于大部分消费用户来说,感受最为明显的则是低音的提升,这也是小型箱体设计中的技术难点。

  小型箱体的低音增强主要有两类方法:其一是箱体的结构设计,例如结构上可采用密封式、倒相式、迷宫式、声波管式和多腔谐振式等等,这些结构需要专业计算确定,适当的设计可以有效提升音箱的音质和低音效果。

  另外,音箱结构设计中还包括了被动振膜技术。通常来说小型箱体比如智能音箱一般常用3寸以下的喇叭,这种喇叭本身低频下潜就不是太好,至少也要在100Hz以上。但是小型音箱受制于体积也无法采用更大的喇叭,而被动振膜的出现就是为了更好的弥补这个缺陷。实际上,被动振膜的结构与喇叭有几分相似之处,都有推动空气的振膜和让振膜恢复正常位置所需要的折环。但不同的是,被动振膜没有喇叭那类驱动机构,也就是说,它自身并不能发出声音。那么,被动振膜是如何工作的?由于被动振膜和喇叭单元是安装在密封的箱体内,这样,当喇叭工作发出声音时,喇叭振膜的运动,会导致箱体内的空气被压缩和扩展,在气压变化的作用下,被动振膜也伴随产生振动,推动箱体外的空气,这样就可以发出声音来。被动振膜可以根据需求设计在音箱的不同位置,其振动面积往往可以做得比较大。这样,推动空气的体积也随之增加,这就大大提升了低音的量感,获得更好的低音下潜深度。 

  其二是算法方面的低音增强,比如常用的虚拟低音增强技术。虚拟低音增强的原理是采用了人耳的生理学特点来虚拟低音效果,人耳能够把低音基频中高频段谐波的差频声音听成原来低音基频的音调,这就给我们实现虚拟低音提供了理论基础。通过低音信号基频的谐波序列在人耳中再现普通扬声器无法达到的低频音调,从而在听感上就会让人觉得低音分量更足了,有效弥补了小口径扬声器重放低频不足的问题。这种虚拟低音增强方法也是耳机中常用的低音增强方法,特点是只需要嵌入特定算法,在播放前对音频处理即可。

  (2)无线技术及声音对码技术

  前面提到,智能音箱是由WiFi音箱发展而来,因此无线技术特别是WiFi的连接尤为重要,但是我们也知道,WiFi连接的过程比较复杂,连接成功后也会经常出现掉线、堵塞、延迟较大、切换太慢等问题,而这些都是导致WiFi音箱体验较差的重要因素。另外智能音箱一般还是黑盒子产品,通常不安装触摸操作屏,而WiFi初始连接则要求用户选择网络、输入用户和密码等操作,这显然不是智能音箱的特长。可是若无法联网,那么智能音箱的语音识别也无法发挥作用,这反而成了一个场景悖论。那么有什么技术可以解决上述的这些问题呢?

  首先我们看WiFi的初始连接问题,这如同当初的路由器配置一样麻烦,何况大部分用户根本没有配置过路由器的经验,因此让用户按照配置路由器的逻辑去配置智能音箱显然不现实,但是目前很多产品其实就是这种模态,就连智能音箱中的翘楚——亚马逊Echo,也是如此。配置路由器,一个熟知技术的人员尚且还要折腾一段时间,把如此复杂的产品甩给用户简直就是一种折磨!

  声学总是这么奇妙,对此,聪明的声学研究人员早就找到了应对方法:声波通讯对码技术。这种技术是利用声波调制技术,将WiFi连接需要的信息通过手机的喇叭发送到智能音箱上,利用智能音箱本身配置的麦克风接收声音信号进行解调获取信息,从而完成配置联网,用户仅仅需要在手机屏幕上输入信息即可,这成功解决了智能音箱缺乏屏幕显示和操控的问题。声音对码技术难度实际不是太大,但是要做的稳定可靠也需要长时间积累,这个领域目前市场上几乎没有成熟的方案,据说小声科技公司正在准备这项技术的开源工作,相信不久这项技术也将很快普及。

  下面接着再说WiFi的切换及延迟问题,除了在硬件和协议上做些优化,也可以通过声学方法进一步优化。我们知道大部分WiFi音频传递的都是解码后的音频流,这很容易造成丢帧现象,其实传输过程中少量丢帧对语音甚至音乐播放来说影响并不大,因此这可以采用一定的算法进行适配。另外,随着智能音箱浮点运算能力的加强,我们也可以考虑传递编码的音频文件流,当编码的时候就将WiFi的问题考虑进去提前做出冗余,自然会大幅提高WiFi方面的性能。

  (3)远场语音唤醒和识别技术

  “Alexa”,这是激活Echo音箱的默认唤醒词,而“叮咚”这是激活京东叮咚音箱的唤醒词。那么为什么音箱需要这种专用词语唤醒呢?实际上这也是语音识别中的技术难题,有时候也称为语音识别启动特定词。我们知道如果要想识别用户说出的命令,麦克风必须一直在录音状态,并且语音识别算法也要一直在工作,这就是连续语音识别的基本前提。那么总要告知一下对方,什么时候才算开始。当然机器是非常愚笨的,一个眼神或者一个动作显然不可能引起“她”的注意,自然就需要定义一个特别适合切换进入语音识别状态的词语,我们称这种技术为语音唤醒,也就是把音箱从其他状态切换到了语音识别工作状态。

  显然上面提到的唤醒问题在Siri上是使用触摸按键来解决的,但是智能音箱就不行了,因为我们不可能总在音箱旁边,而一般都会距离音箱一段距离欣赏音乐。这就产生了一个更加困难的问题:远场语音识别。远场实际是声学领域常用的一个概念,一般在智能音箱领域来说是指混响起主要作用的声场。这个概念怎么解释呢?这么说吧,我们听到的声音简单分为两种,一种是直接到达耳朵的,称为直达声。另外一种是墙壁反射后到达耳朵的,称为反射声,乱七八糟混在一起的声场就理解为混响声吧。显然当距离声源较近的时候,直达声将起主要作用,而当距离声源较远以后,混响的影响就会增大。不要轻视这种混响,当混响严重到一定程度的时候,我们是很难听清对方说话的。事实上,混响对于语音识别的影响是非常严重的,直接导致了识别率的下降。

  那怎么解决这个问题呢?当然我们也有主动和被动两种方法。主动的方法我们这里先暂且卖个官司,请您关注声学在线的后续文章,我们会详细介绍。下面我们来说被动的方法,就是我们常常说到的麦克风阵列技术,麦克风阵列的具体技术我们这里也不再赘述,声学在线已经发布了很多相关文章,您可以重温回忆一下。这里我们只说下麦克风阵列的技术难点。当然很多同学会首先想到算法的问题,多个麦克风协同工作确实是一个技术难点。另外,结构设计和器件方面也是一直制约麦克风阵列应用普及的重要因素,之所以这项技术到现在才能实用,也是因为MEMS技术很好的解决了目前麦克风器件的一致性问题。当然多声道的采集技术也是非常重要的基础技术。

  这部分笔者觉得对于智能音箱来说极其重要,因此我们也拆解了市场上两款流行的智能音箱做些麦克风阵列方面的比较。

  第一款就是亚马逊的Echo音箱,下图绿色圈中的地方就是7个麦克风组成的阵列,型号是S10530090。Echo音箱并没有采用多声道采集处理芯片,而是用了4个立体声ADC实现7个麦克风声音的采集,这款ADC型号是TI的TLV320ADC3101。显然Echo将来还会有更好的远场语音识别性能方面的提升。亚马逊Echo使用的是自家的语音识别引擎,因此国内使用的时候非常麻烦,需要连接到国外的服务器。

  第二款便是京东的叮咚音箱,这款音箱采用了8个麦克风和4个喇叭以PK亚马逊的Echo,但实际上意义不大,这个口径的情况下,8个麦克风和7个麦克风并没有本质上的区别,甚至4个也就够用了。而且我们通过两幅拆解图对比就可以看到,叮咚所用的麦克风显然没有像Echo那样升级到MEMS,传统驻极体麦克风的一致性很难保证,这不利于阵列信号处理。叮咚采用的是CONEXANT科胜讯的CX20810-11Z芯片,这款芯片是4通道远场语音捕获的ADC,专门用于语音识别,控制和网络会议等,因此叮咚只需要两片ADC即可实现对8个麦克风的采集。很明显,CONEXANT的芯片相比TI还是略逊一筹。不过,即便有如此逊色之处,叮咚音箱也属于国内当前水平较高的智能音箱。另外,叮咚采用的是科大讯飞的语音识别引擎,因此国内使用起来特别方便。

  (4)内容集成与智能学习技术

  智能音箱一开始就被认为是家庭互联网的入口之一,各个巨头抢占这个领域也有这方面的考虑,所以与智能家居的融合一直是智能音箱的使命之一。但是声音似乎和控制系统相差甚远,这方面的集成并非那么简单。智能音箱解决的仅仅是语音的识别问题,而这个功能,手机和电视同样也可以实现,那么智能音箱还有什么优势呢?

  笔者认为亚马逊的战略考虑应该更值得借鉴。诚然,接入更多智能家居的控制功能自然是个好事,但智能家居还没发展起来,也不是用户的刚需,目前来做这块用户似乎也不会买账。亚马逊的Echo除了和自身的音乐内容匹配,最主要还是看重了Echo将来在音乐内容方面的购买功能,所以Shopping自然就成为了Echo最重要的使命。想想也是,一个公司做硬件不考虑赚钱怎么行,软件可以随着用户数量的无限增加而将成本摊薄为零,但是硬件的成本是永远存在的啊。虽然目前还不了解京东有没有这方面的考虑,但是自家没有专有语音识别引擎,若想和自家产品无缝对接也非常困难。阿里就聪明很多,阿里做的小飞必然要和自家的音乐内容紧密相连。其他的厂商如QQ音乐、百度音乐、酷狗音乐还未发布自家产品,酷狗笔者有所了解,他们的智能硬件之路走得相当缓慢,现在转去搞中国好声音了。

  除了内容方面的集成,智能音箱还面临一个更大的挑战。我们仔细想一下,用户对智能音箱的要求其实远非语音识别所能做到的那样简单,显然还需要深入的语言交互才行,而且这种交互还应该是你日常生活中的场景。天哪,即便解决某个特定领域的语音交互就让众多科研人员心力交瘁了,更何况如此广泛的领域。笔者一听到这个需求大脑几乎就要爆掉,但是如果做不到这点,怎么又能称得上智能音箱呢?充其量不过是个语音控制的音箱而已。很多时候笔者觉得,语音识别还不如手势识别更为简单好用!当然对于那些流媒体的音乐内容提供商来说,这种前端产品或许是不得不做的产品,至少抢个赛道再说。

  写了那么多,笔者也是真的累了,五千多字伏案了一下午,也是不易。但是还不能就此收笔打住,还得多说几句,那就是未来智能音箱的用户体验问题。

  我们一直强调,智能音箱还是一个音箱,但是为什么大多数厂商都把这个基本诉求给忽略了呢?一味强调智能而不扎实做好音箱的品质,如此这般,还不如干脆做个智能盒子好了。笔者相信,就是因为有如此多的问题,说明智能音箱领域还存在众多机会,若在这个领域创业创新,有必要思考下面的3个问题:

  (1)回归音箱本质,发烧音质才是智能的基础

  网上早已不止笔者一人批评智能音箱的音质了。无论智能音箱的产品元素是音箱多一点,还是智能多一点,作为一款音箱产品,就必须拥有音箱的特点,那就是拥有音箱的优质体验,这才是智能音箱被人们长期使用的关键。因此,智能音箱的开发,首先要回归本质,先将其作为一款高品质的音箱,然后再谈及智能化程度。

  (2)重新定义人机对话,增强开放互联能力

  智能是智能音箱的核心属性,但是最近几年是很难看到语音交互技术方面的突破了。但是智能音箱不能裹足不前,可以从特定领域入手,定制特别的算法和技术。比如针对音乐购买场景开发的音乐检索技术等,尽快让智能音箱贴近地气,至少某个领域解决用户的需求,这样,智能音箱就不仅仅是用户一时兴起的一个玩具了。

  另外,智能音箱毕竟也是移动互联网时代的一个入口。若智能音箱要成为控制智能家居的重要工具,其也需要拥有庞大的用户基数,而这就需要通过开放接口的方式,获得更多合作伙伴的支持。然后再获取更多的用户基数优势,也就能够方便其对智能家居的控制。

  (3)强调便携,电池续航和快速充电尤为重要

  智能音箱是一类移动互联网时代的智能硬件,方便携带是其作为智能硬件的重要因素。但是这个特点,实际上当前的智能音箱做的都不好,就像Echo那样总要拖个电源线,这算哪门子事情呢?另外智能音箱加装电池也存在很多问题,就像叮咚那样加装4个喇叭,还有WiFi和麦克风阵列,这耗电也不是一般的了,而且体积也很大。

  因此,智能音箱的体积还需要变得更小,并且将电池做成标配,并且具有较长的电池续航和快速充电的能力。据悉,小声科技一直从事超级电容音箱技术的基础研究,目前已经成功开发出了秒充和长久续航的核心技术。这项技术可以使智能音箱对于锂电池的依赖降到最低,甚至根本不再需要安装锂电池,这对于智能音箱未来的发展将是一个极大的促进。

本文为OFweek公众号作者发布,不代表OFweek立场。如有侵权或其他问题,请联系举报。
0条评论

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://xiahunao.cn/news/1381982.html

如若内容造成侵权/违法违规/事实不符,请联系瞎胡闹网进行投诉反馈,一经查实,立即删除!

相关文章

智能家居控制系统MECOOL KA1智能音响

MECOOL KA1是智能音箱和4K安卓电视流媒体设备的结合。该设备采用Amlogic S905Y4 SoC四核ARM Cortex -A35处理器,支持远场语音和免提电视控制。 MECOOL KA1通过ART(谷歌智能语音测试) ART 旨在验证集成了 Google 助理的设备的助理功能。要被…

AI智能音箱五大功能中应用的数字功放芯片

AI智能音箱多基于语音控制,其基本交互流程可以用下图概括:1)用户通过自然语言向音箱提出服务请求或问题 2)音箱拾取用户声音(音箱本地完成)并分析(一般在服务器端完成)3)…

Talk | ICCV‘23清华大学刘世隆:From Detection to Grounding-迈向更强的开集目标检测

本期为TechBeat人工智能社区第521期线上Talk! 北京时间8月10日(周四)20:00,清华大学博士生—刘世隆的Talk已准时在TechBeat人工智能社区开播! 他与大家分享的主题是: “From Detection to Grounding-迈向更强的开集目标检测”,他分…

5个PPT素材、模板网站,建议收藏~

做PPT绝对不能错过这5个网站,建议收藏~ 1、菜鸟图库 https://www.sucai999.com/search/ppt/0_0_0_1.html?vNTYxMjky 菜鸟图库素材非常齐全,设计、办公、图片、视频等素材这里都能找到,PPT模板数量很可观,模板样式多&#xff0c…

数据结构和算法——散列表的性能分析(开放地址法的查找性能、期望探测次数与装填因子的关系、分离链接法的查找性能)

目录 开放地址法的查找性能 线性探测法 平方探测法和双散列探测法 期望探测次数与装填因子的关系 分离链接法的查找性能 总结 散列表的性能分析 平均查找长度(ASL)用来度量散列表查找效率:成功、不成功关键词的比较次数,取…

Dataloader数据集的制作

数据集Dataloader制作 如何自定义数据集: 1.数据和标签的目录结构先搞定(得知道到哪读数据)2.写好读取数据和标签路径的函数(根据自己数据集情况来写)3.完成单个数据与标签读取函数(给dataloader举一个例子) 咱们以花朵数据集为例: 原来数据集都是以…

RabbitMQ 消息队列(Spring boot AMQP)

文章目录 🍰有几个原因可以解释为什么要选择 RabbitMQ:🥩mq之间的对比🌽RabbitMQ vs Apache Kafka🌽RabbitMQ vs ActiveMQ🌽RabbitMQ vs RocketMQ🌽RabbitMQ vs Redis 🥩linux docke…

Android App消息推送 实现原理

https://www.jianshu.com/p/b61a49e0279f 1.消息推送的实质 实际上,是当服务器有新消息需推送给用户时,先发送给应用App,应用App再发送给用户 2. 作用产品角度:功能需要,如:资讯类产品的新闻推送、工具类…

App消息推送 实现原理

1.消息推送的实质 实际上,是当服务器有新消息需推送给用户时,先发送给应用App,应用App再发送给用户 2. 作用 产品角度:功能需要,如:资讯类产品的新闻推送、工具类产品的公告推送等等 运营角度:活…

浏览器及app消息推送

消息推送 什么是消息推送PC端的实现方法1:Notification方法2:pushjs APP端实现打包设置 什么是消息推送 消息推送可以存在于浏览器端,也存在APP端。浏览器的推送,会在电脑通知中显示,app中显示在通知栏 PC端的实现 方法1:Notif…

IOS推送-pushy

iOS 引入jar包创建APNSConnect进行发送报错对照表 引入jar包 创建APNSConnect 创建APNSConnect,与APNs进行链接 public class APNSConnect { private static ApnsClient apnsClient null;public static ApnsClient getAPNSConnectP8(String path,String teamId,S…

unipush+java+个推实现app消息推送

“ 你现在的气质里,藏着你走过的路,读过的书,和爱过的人。 ” 整体还是比较简单地,就是有一些需要注意的地方,很多问题官方文档里面也写了,这里总结一下 对于安卓,谷歌本来有专门的推送通道&…

uniapp - App 超详细消息推送功能实现,从 0-1 实现官方 unipush 推送全步骤稳定性毋庸置疑(附带详细的可运行示例源码和注释,保证 100% 完美接入)苹果安卓手机

效果图 网上的教程太乱用不了,无法改造成自己想要的效果。 在uniapp中开发的app(安卓苹果),使用 unipush 官方推送,从0-1实现完整过程及功能开发。 你可以直接复制示例源码,跟着教程一步步配置,注释详细! 准备 消息

Android 项目必备(三十八)-->APP 消息推送

文章目录 前言推送的实现方式1. C2DM2. 轮询3. SMS信令推送4. MQTT协议5. XMPP协议6. 使用第三方平台 Android 中 MQTT 的使用1. 集成2. 具体代码3. 项目地址 前言 今天来讲讲推送这件小事,事虽小,要做好却不容易。 推送难,难于上青天。 我们…

APP消息推送(APP Push)解决方案-服务端工作逻辑和实现

一、APP 推送概述: App推送消息是我们常见的一种app消息提醒方式。 我们的实现需要第三方的支持,实现方式是后台通过接口将Push请求发送至第三方,第三方实现在App所在设备上的推送。 二、APP推送后台处理逻辑: 在与推送平台交互时…

app消息推送的详细实现教程

实现的主要思想 app实现消息推送,利用的是第三方的个推平台,后端将需要推送的内容通过第三方个推服务器传递给手机端。 具体前端打包配置 根据上图可知,采用的打包软件是Hbuilder X,在模块配置的时候,勾选push模块中的uniPush。…

App消息推送的原理

文章目录 1. 基本概念2. iOS和Android消息推送原理对比2.1 iOS2.1.1 基本原理2.1.2 优劣势 2.2 Android2.2.1 基本原理2.2.2 优劣势 3. Android消息推送原理3.1 操作系统有自身的消息推送功能(系统级别)3.2 三种基本的推送方式:Push、Pull 和…

php实现app消息推送

如何用php实现APP消息推送 现在有很多的消息推送厂商,比如阿里云的消息推送,极光推送,融云的消息推送。他们的原理都是把sdk内置在app里面,达到消息推送的目的,通过一张图来了解一下,看不懂不要紧&#xf…

Android,ios,安卓app推送消息通知,java后台向手机推送app的通知教程

文章目录 一、业务介绍1.1 产品简介1.2 名词解释1.3 消息推送流程 二、应用创建三、客户端 SDK 集成3.1 Android3.2 iOS 四、服务端推送4.1 服务端消息下发流程(必读)4.2 开发者中心后台4.3 推送代码 五、参数说明 一、业务介绍 1.1 产品简介 个推是商…

App消息推送概述

消息推送介绍 消息推送(Push),是指从云端服务器到手机终端的消息推送通道,运营人员可以通过自己产品后台或者第三方推送通道对用户移动设备进行主动的消息推送。通过消息推送,目标用户可以在移动设备通知和状态栏看到…