无线音频系统、无线通讯方法及设备与流程

文档序号:27610942发布日期:2021-11-27 00:17阅读:239来源:国知局
无线音频系统、无线通讯方法及设备与流程

1.本技术实施例涉及无线技术领域,尤其涉及无线音频系统、无线通讯方法及设备。


背景技术:

2.蓝牙(bluetooth)无线技术是意图替代便携式和/或固定式电子设备之间的线缆连接的一种短距离通信系统。基于蓝牙线通信技术的蓝牙耳机,以其无线化的连接方式和良好的音质受到消费者的喜爱。其中,用户使用蓝牙在设备间互联并播放音频数据的场景越来越多,越来越普遍,例如,用户使用手机+蓝牙耳机用来听音乐或看视频,用户使用手机+车载设备用来听音乐或听导航信息,用户使用手机+蓝牙音响听音乐或看视频等等。在这些使用蓝牙技术播放音频数据的场景中,音频流可能会经过主设备(如手机或电脑)和从设备(如蓝牙耳机或蓝牙音响),主设备的音效算法和从设备的音效算法一般是两套独立的音效算法,当音频流经过主设备和从设备时,两个独立的音效算法可能会产生音效冲突,比如说主设备音效在音频信号1khz处的增益为抬高2db,从设备在音频信号1khz处增益为压低2db,这时简单的音效算法效果的叠加可能导致最终音频流的音效效果比单独使用主设备或从设备的音效算法时的生成的音效效果要差。
3.目前业界对蓝牙互联设备在媒体流上的音效算法没有协同交互的方案。而在通话流上有类似的协同交互方案,这个方案是在通话场景下通过交互命令来决策通话流使用主设备的音效算法或者使用从设备的音效算法,该方案可以部分解决通话流中主从设备音效算法的配合问题。


技术实现要素:

4.本技术技术方案提供了一种无线音频系统、无线通讯方法及设备,可实现主从设备之间的音效处理协商,充分利用主设备和从设备双侧音效处理的优势,进一步提升音效效果,满足了用户对于音频的更高音质的追求。
5.第一方面,本技术实施例提供了一种无线通讯方法,应用于无线通讯系统。该无线通讯系统包括第一设备和第二设备,第一设备可以是手机、平板电脑等电子设备,第二设备可以是无线耳机、音箱等音频输出设备,例如tws蓝牙耳机。第一设备可以是无线音频系统中的主设备,第二设备可以是无线音频系统中的从设备。
6.在该无线通讯方法中,第一设备与第二设备可以建立无线通信连接。第一设备可以向第二设备发送第一请求,以请求查询从设备的音效处理能力。相应的,第二设备可以向所述第一设备发送第一响应,第一响应中携带第一指示信息。第一指示信息可以用于指示第二设备具备的音效处理能力。第一设备可以根据第二设备反馈的指示信息确定第一设备与第二设备之间是否支持联合音效处理。具体的,第一设备可确定第一设备是否有第一音效处理算法,第一音效处理算法为适配第二设备使用的第二音效处理算法的音效处理算法,第二音效处理算法是根据第一指示信息确定,如果确定有第一音效处理算法,则:第一设备与第二设备之间可以建立音频连接,第一设备使用第一音效处理算法对第一音频数据
进行处理,得到第二音频数据。然后,第一设备可以通过音频连接向第二设备传输第二音频数据。第二设备可以使用第二音效处理算法对第二音频数据进行处理,得到第三音频数据。第二设备播放第三音频数据。
7.其中,上述无线通信量连接可以是逻辑链路控制和适配协议l2cap连接,也可以是射频通信rfcomm连接。基于这两种不同的无线通信连接,第一设备与第二设备之间交互的第一请求、第一响应的信令实现也相应不同,第一设备与第二设备之间用来传输音频数据的音频连接的实现也相应不同。后面会展开。
8.其中,第一指示信息可包括以下一项或多项设备参数:第二设备的生产厂商、产品型号。
9.其中,音效处理能力可以包括以下一项或多项:降噪能力、消回声能力,第二音效处理算法可以包括以下一项或多项:降噪算法、消回声算法。
10.实施第一方面提供的方法,可实现主从设备之间的音效处理协商,充分利用主设备和从设备双侧音效处理的优势,进一步提升音效效果,满足了用户对于音频的更高音质的追求。
11.结合第一方面中的描述,第一设备与第二设备之间是否支持联合音效处理可以概括为下述三种情况:
12.情况1:主、第二设备之间不支持联合音效处理,第二设备不支持音效处理。
13.具体的,当第一设备可以根据第二设备反馈的生产厂商、产品型号等设备参数确定第二设备不具备音效处理能力时,第一设备可确定协商音效处理的情况为情况1。第二设备是否具备音效处理能力,这一点可以根据第二设备反馈的生产厂商、产品型号等设备参数确定出来。第一设备可以根据某款耳机、音箱等第二设备的生产厂商、产品型号等设备参数,在本地或在云端查询到该款第二设备是否具有如降噪、消回声等音效处理能力,以及该款第二设备在具有音效处理能力的情况下所使用的音效处理算法是什么。
14.情况2:主、第二设备之间不支持联合音效处理,第二设备支持音效处理。
15.具体的,当第一设备根据第二设备反馈的生产厂商、产品型号等设备参数确定第二设备具备音效处理能力时,如果第一设备根据第二设备使用的音效处理算法,不能够从第一设备的多套音效处理算法中获取到与第二设备侧的音效处理算法ⅰ相适配的第一设备的音效处理算法ⅱ,则第一设备可确定协商音效处理的情况为情况2。
16.情况3:主、第二设备之间支持联合音效处理,第二设备支持音效处理。
17.具体的,当第一设备根据第二设备反馈的生产厂商、产品型号等设备参数确定第二设备支持音效处理时,如果第一设备根据第二设备使用的音效处理算法ⅰ,能够从第一设备的多套音效处理算法中获取到与音效处理算法ⅰ相适配的音效处理算法ⅱ,则第一设备可确定协商音效处理的情况为情况3。音效处理算法ⅱ可用于联合音效处理中第一设备的音效处理。
18.为了确定上述几种情况,第一设备可以通过下述几种方式确定:第一设备是否有与第二设备侧的音效处理算法ⅰ相适配的第一设备的音效处理算法ⅱ。
19.方式1.通过对测试信号进行音效处理,比对处理结果,来筛选出适配算法。
20.具体的,第一设备可从第一设备的多套音效处理算法中选择出一套音效处理算法,使用选择出来的这一套音效处理算法和第二设备侧的音效处理算法ⅰ接连对测试音频
数据进行处理。如果以下一项或多项条件被满足:处理后的测试音频数据所测出信噪比优于第一信噪比、第二信噪比,处理后的测试音频数据所测出的回声分量少于第一回声分量、第二回声分量,则确定第一设备有与音效处理算法ⅰ相适配的音效处理算法ⅱ。如果这一项或多项条件未被满足,则继续从该多套音效处理算法中选择出下一套音效处理算法,重复前述音效处理,直至筛选出满足这一项或多项条件的音效处理算法。如果多套算法全部都无法满足这一项或多项条件,则可确定第一设备没有与第二设备侧的音效处理算法ⅰ相适配的音效处理算法ⅱ。
21.第一设备可进一步从这多套音效处理算法中选择出满足前述一项或多项条件,且音效处理效果最优(例如信噪比最优、回声分量最少)的音效处理算法来适配第二设备侧的音效处理算法ⅰ。
22.其中,第一信噪比、第一回声分量可以分别为使用前述选择出来的这一套音效处理算法对所述测试音频数据处理后测出的信噪比、回声分量,第二信噪比、第二回声分量可以分别为使用第二设备侧的音效处理算法ⅰ对该测试音频数据处理后测出的信噪比、回声分量。第一设备的多套音效处理算法可以存储在第一设备本地,也可以存储在云端服务器,由第一设备访问。
23.方式2.查表获得适配算法。
24.具体的,第一设备可以存储有或者可访问到一个映射表。该映射表中可以记录有多款设备的设备参数(如生产厂商、产品型号等设备参数)和多套音效处理算法之间的对应关系。在该映射表中,某款第二设备的设备参数对应的音效处理算法,指的是第一设备的多套音效处理算法中与该款第二设备所使用的音效处理算法相适配的音效处理算法。一套音效处理算法可以包括多个音效处理算法,例如降噪算法、回声抑制算法等等。当然,一套音效处理算法也可以仅包括一个音效处理算法,例如降噪算法,本技术对此不做限制。该映射表可以是第一设备出厂前写入到存储器中,也可以是第一设备从服务器下载的,还可以是其他设备分享而来的。本技术对该映射表的来源不作限制。
25.具体的,第一设备可以判断第一映射表中是否存在第二设备的设备参数对应的音效处理算法,如果有,则可确定第一设备有与第二设备侧的音效处理算法ⅰ相适配的音效处理算法ⅱ。音效处理算法ⅱ即映射表中第二设备的设备参数对应的音效处理算法。
26.不限于生产厂商、产品型号等设备参数,第二设备向第一设备发送的音效处理能力的指示信息还可以进一步包括特定比特或特定字段,该特定比特或特定字段可用于指示第二设备是否具备音效处理能力。例如,当该特定比特为0时,指示第二设备没有音效处理能力;当该特定比特为1时,指示第二设备具有音效处理能力。这样,第一设备可以直接根据该特定比特或特定字段确定出第二设备是否具备音效处理能力,无需基于第二设备反馈的生产厂商、产品型号等设备参数去确定第二设备是否具备音效处理能力,效率更高。进一步地,如果根据该特定比特或特定字段确定出第二设备不具备音效处理能力,即上述情况1,那么第一设备就可以直接使用第一设备的某套音效处理算法在第一设备对主、第二设备之间的音频数据进行音效处理。如果确定出第二设备具备音效处理能力,那么第一设备还需要根据生产厂商、产品型号等设备参数进一步确定主、第二设备之间是否支持联合音效处理,具体可参考上述情况2、情况3。
27.结合第一方面,在一些实施例中,如果第一设备确定出第一设备没有第一音效处
理算法,且第二设备不具有音效处理能力,即上述情况1,则:第一设备与第二设备之间建立音频连接,第一设备使用第三音效处理算法对第一音频数据进行处理,得到第四音频数据,第一设备通过音频连接向第二设备传输第四音频数据。第二设备播放第四音频数据。
28.结合第一方面,在一些实施例中,如果第一设备确定出第一设备没有第一音效处理算法,且第二设备具有音效处理能力,即上述情况2,则:第一设备与第二设备之间建立音频连接,第一设备通过音频连接向第二设备传输第一音频数据,第二设备使用第二音效处理算法对第一音频数据进行处理,得到第五音频数据。第二设备播放第五音频数据。
29.结合第一方面,在一些实施例中,上述无线通信连接可以是逻辑链路控制和适配协议l2cap连接。
30.基于l2cap连接,第一设备与第二设备之间交互的第一请求、第一响应的信令实现可如下:
31.第一请求可以包括l2cap回声请求(echo request),第一响应可以包括l2cap回声响应(echo response)。
32.基于l2cap连接,第一设备与第二设备之间用来传输音频数据的音频连接的实现可如下:该音频连接可包括基于前述l2cap连接建立的媒体音频连接,例如高级音频分发应用规范a2dp连接。该音频连接传输的音频数据可包括媒体音频数据。
33.具体的,第一设备可以在检测到播放媒体音频的用户操作时,与第二设备之间建立该媒体音频连接。
34.结合第一方面,在一些实施例中,上述无线通信连接可以是射频通信rfcomm连接。
35.基于射频通信rfcomm连接,第一设备与第二设备之间用来传输音频数据的音频连接的实现可如下:
36.第一请求可以包括第一at命令,第一响应可以包括响应于第一at命令的第一at响应。
37.基于射频通信rfcomm连接,第一设备与第二设备之间用来传输音频数据的音频连接的实现可如下:
38.该音频连接可包括基于前述rfcomm连接建立的通话音频连接,例如面向连接的同步连接sco连接。该音频连接传输的音频数据可包括通话音频数据。
39.具体的,第一设备可以在检测到接听来电或拨通电话的用户操作时,与第二设备之间建立该通话音频连接。
40.第二方面,本技术提供了一种无线通讯方法,应用在上述第一设备。在该方法中,第一设备与第二设备可以建立无线通信连接。第一设备可以向第二设备发送第一请求,以请求查询从设备的音效处理能力。相应的,第一设备可以接收第二设备发送的第一响应,第一响应中携带第一指示信息。第一指示信息可以用于指示第二设备具备的音效处理能力。第一设备可以根据第二设备反馈的指示信息确定第一设备与第二设备之间是否支持联合音效处理。具体的,第一设备可确定第一设备是否有第一音效处理算法,第一音效处理算法为适配第二设备使用的第二音效处理算法的音效处理算法,第二音效处理算法是根据第一指示信息确定,如果确定有第一音效处理算法,则:第一设备与第二设备之间可以建立音频连接,第一设备使用第一音效处理算法对第一音频数据进行处理,得到第二音频数据。然后,第一设备可以通过音频连接向第二设备传输第二音频数据。
41.这样,第二设备使用第二音效处理算法对第二音频数据进行处理,得到第三音频数据。第二设备播放第三音频数据。
42.第二方面中,第一设备具有的功能以及其他说明可以参考第一方面中的内容,这里不再赘述。
43.第三方面,本技术实施例提供了一种电子设备,电子设备可包括通讯模块、存储器、一个或多个处理器、以及一个或多个程序,一个或多个处理器用于执行存储在存储器中的一个或多个计算机程序,使得电子设备可实现如第一方面中第一设备具有的任一功能,或如第二方面中第一设备具有的任一功能。
44.第四方面,本技术实施例提供了一种音频输出设备,该音频输出设备可包括蓝牙模块、音频模块、存储器和处理器。存储器中存储有一个或多个程序,一个或多个处理器用于执行存储在存储器中的一个或多个程序,使得音频输出设备可实现如第一方面中第二设备具有的任一功能,或如第二方面中第二设备具有的任一功能。
45.第五方面,本技术实施例提供了一种无线通讯系统,该无线通讯系统可包括前述各方面中描述的第一设备、第二设备。
46.第六方面,本技术实施例提供了一种芯片系统,该芯片系统可以应用于电子设备,该芯片包括一个或多个处理器,处理器用于调用计算机指令以使得电子设备实现如第一方面中任一可能的实现方式,或如第二方面中任一可能的实现方式。
47.第七方面,一种包含指令的计算机程序产品,其特征在于,当计算机程序产品在电子设备上运行时,使得电子设备执行如第一方面中任一可能的实现方式,或如第二方面中任一可能的实现方式。
48.第八方面,提供一种计算机可读存储介质,包括指令,其特征在于,当指令在电子设备上运行时,使得电子设备执行如第一方面中任一可能的实现方式,或如第二方面中任一可能的实现方式。
附图说明
49.为了更清楚地说明本技术实施例或背景技术中的技术方案,下面将对本技术实施例或背景技术中所需要使用的附图进行说明。
50.图1a示出了本技术实施例涉及的一种无线音频系统;
51.图1b示出了图1a所示无线音频系统中的音频输出设备的结构;
52.图2a示出了本技术实施例涉及的另一种无线音频系统;
53.图2b示出了图2a所示无线音频系统中的音频输出设备的结构;
54.图3示出了本技术实施例涉及的媒体音频连接的建立过程;
55.图4示出了本技术实施例涉及的通话音频连接的建立过程;
56.图5示出了本技术实施例涉及的通话音频控制连接的建立过程;
57.图6示出了本技术技术方案提供的无线通讯方法的总体流程;
58.图7a示出了开启电子设备的蓝牙功能的一种用户操作;
59.图7b示出了开启电子设备的蓝牙功能的另一种用户操作;
60.图7c示出了电子设备显示蓝牙连接的指示符;
61.图8示出了实施例一提供的无线通讯方法;
62.图9示出了实施例二提供的无线通讯方法;
63.图10示出了电子设备的结构;
64.图11示出了音频输出设备的结构。
具体实施方式
65.本技术的实施方式部分使用的术语仅用于对本技术的具体实施例进行解释,而非旨在限定本技术。
66.图1a示出了本技术实施例涉及的一种无线音频系统100。如图1a所示,无线音频系统100可包括电子设备101、音频输出设备106。
67.其中,电子设备101可以实现为以下任意一种电子设备:手机、便携式游戏机、便携式媒体播放设备、个人电脑、车载媒体播放设备等等。
68.音频输出设备106可负责将音频数据转换成声音。音频输出设备106可以是头戴式耳机、颈挂式耳机、音响等等音频输出设备。以耳机为例,如图1a所示,音频输出设备106可以包括左耳机102、右耳机103和线控104。左耳机102与线控104之间通过耳机线连接,右耳机103和线控104之间也通过耳机线连接。线控104可配置有音量增大键、音量减小键以及播放控制键等按键,线控104还可配置有受话器/麦克风等声音采集器件。
69.电子设备101和音频输出设备106之间可建立无线通信连接105。
70.在电子设备101至音频输出设备106的传输方向上,电子设备101可以通过无线通信连接105向音频输出设备106发送音频数据。此时,电子设备101的角色是音频源(audiosource),音频输出设备106的角色是音频接收方(audio sink)。这样,音频输出设备106可以将接收到的音频数据转换成声音,使得佩戴音频输出设备106的用户可以听到该声音。
71.除了音频数据,电子设备101和音频输出设备106之间还可以基于无线通信连接105交互播放控制(如上一首、下一首等)消息、通话控制(如接听、挂断)消息、音量控制消息(如音量增大、音量减小)等。具体的,电子设备101可以通过无线通信连接105向音频输出设备106发送播放控制消息、通话控制消息,可实现在电子设备101侧进行播放控制、通话控制。例如,当用户在电子设备101上点击音乐播放键时,电子设备可以通过无线通信连接105向音频输出设备106发送音频播放命令,触发音频输出设备106播放音乐。具体的,音频输出设备106可以通过无线通信连接105向电子设备101发送播放控制消息、通话控制消息,可实现在音频输出设备106侧进行播放控制、通话控制。例如,当用户按下线控104上的音量增大键时,音频输出设备106可以通过无线通信连接105向电子设备101发送音量增大命令,触发电子设备101增大音乐播放的音量。
72.不限于图1a所示,电子设备101、音频输出设备106的物理形态、尺寸还可以不同,本技术对此不做限定。
73.图1a所示的无线音频系统100可以是基于蓝牙协议实现的无线音频系统。即电子设备101、音频输出设备106之间的无线通信连接105可以采用蓝牙通信连接。
74.图1a中的音频输出设备106的结构可以如图1b所示。其中,
75.左耳机102、右耳机103均可包括:音频模块和传感器等。音频模块可以用于将音频数据转换成声音,具体可为电声转换器(electo-acoustic transducer)。传感器可用于检
测左耳机102、右耳机103当前处于的使用场景。该传感器可以是光学传感器、电容传感器、红外传感器等。该传感器可称为第一传感器。例如,左耳机102、右耳机103可以通过光电检测的方式判断耳机是否入耳,耳机中的光学传感器可以利用光学感应原理来感知用户的佩戴状态,当光学传感器检测到光信号被阻挡时,会向处理器反馈此时耳机处于佩戴状态,然后系统便会自动进入播放模式,反之,当光学传感器检测到光信号时,会向处理器反馈此时耳机未处于佩戴状态,然后系统便会自动暂停音频的播放。在用户体验上,用户可以感受到当摘下耳机时,音频自动停止播放,当戴上耳机时又会自动恢复音频播放。同理,耳机还可以根据电容传感器反馈的电容变化进行入耳检测,或者可以根据红外线传感器反馈的遮挡情况进行入耳检测。
76.线控104可包括:蓝牙模块、处理器和电池。蓝牙模块可用于接收或发射蓝牙信号。音频输出设备106可通过蓝牙模块和电子设备101之间建立蓝牙通信连接,并通过蓝牙通信连接向电子设备101发射蓝牙信号或者接收电子设备101发射的蓝牙信号。处理器可耦合蓝牙模块以及左耳机102、右耳机103中的音频模块、传感器。处理器可负责读取存储器中的指令,对指令译码并执行指令,以实现本技术技术方案提供的无线通讯方法。电池可用于对音频输出设备106中的各个部件(如处理器、音频模块、传感器、蓝牙模块等)供电。
77.不限于图1b所示,音频输出设备106还可以包括其他部件,例如线控104中可配置有存储器、受话器、指示灯等。
78.不限于图1a所示的蓝牙耳机,无线音频系统100中的左耳机102、右耳机103还可以为其他类型的音频输出设备。例如,在家庭影院场景下,无线音频系统100中的左耳机102、右耳机103还可以分别为家庭影院场景下的两个音响:左声道音响、右声道音响。这两个音响之间也可连接有一个类似线控104的控制装置。
79.图2a示出了本技术实施例涉及的另一种无线音频系统200。如图2a所示,无线音频系统200可包括电子设备201、音频输出设备202和音频输出设备203。音频输出设备202和音频输出设备203可分别为一副蓝牙耳机的左耳机、右耳机,用于将音频数据转换成声音。同样地,电子设备201可以实现为以下任意一种电子设备:手机、便携式游戏机、便携式媒体播放设备、个人电脑、车载媒体播放设备等等。
80.和图1a所示的无线音频系统100不同的是,音频输出设备202和音频输出设备203之间没有线缆连接。二者可以通过无线通信连接206而不是有线通信连接,进行通信。音频输出设备202和音频输出设备203可以为分体式真无线立体声(true wireless stereo,tws)耳机,可分别为一副tws耳机中的左耳机、右耳机。
81.在无线音频系统200中,音频输出设备202、音频输出设备203可分别和电子设备201建立无线通信连接。例如,音频输出设备202可以和电子设备201之间建立无线通信连接204,可通过无线通信连接204交互音频数据、播放控制消息、通话控制消息等。同样的,电子设备201和音频输出设备203之间可以建立无线通信连接205,并可以通过无线通信连接205交互音频数据、播放控制消息、通话控制消息等。
82.不限于图2a所示,电子设备201、音频输出设备202和音频输出设备203的物理形态、尺寸还可以不同,本技术实施例对此不做限定。
83.图2a所示的无线音频系统200可以是基于蓝牙协议实现的无线音频系统。即电子设备201、音频输出设备202和音频输出设备203之间的无线通信连接(如无线通信连接204、
无线通信连接205、无线通信连接206)可以采用蓝牙通信连接。
84.图2a中的音频输出设备202、音频输出设备203的结构可以如图2b所示。音频输出设备202、音频输出设备203均可包括:蓝牙模块、音频模块、传感器和处理器和电池。可以看出,和图1a所示的无线音频系统100中的音频输出设备106不同的是,音频输出设备202、音频输出设备203分别集成了音频输出设备106的线控104的功能。
85.蓝牙模块可用于接收或发射蓝牙信号。音频输出设备202、音频输出设备203可分别通过蓝牙模块和电子设备201之间建立蓝牙通信连接,并通过蓝牙通信连接向电子设备201发射蓝牙信号或者接收电子设备201发射的蓝牙信号。音频输出设备202和音频输出设备203之间也可以通过蓝牙模块进行通信。处理器可耦合蓝牙模块以及音频输出设备202和音频输出设备203中的音频模块、传感器。处理器可负责读取存储器中的指令,对指令译码并执行指令,以实现本技术技术方案提供的无线通讯方法。电池可用于对音频输出设备202和音频输出设备203中的各个部件(如处理器、音频模块、传感器、蓝牙模块等)供电。
86.音频模块可用于将音频数据转换成声音,具体可为电声转换器(electo-acoustic transducer)。传感器可用于检测音频输出设备202、音频输出设备203当前处于的使用场景。该传感器可以是光学传感器、电容传感器、红外传感器、加速度传感器、压力传感器、六轴传感器、骨声纹传感器等等。例如,以耳机为例,左耳机202、右耳机203可以通过光电检测的方式判断耳机是否入耳,耳机中的光学传感器可以利用光学感应原理来感知用户的佩戴状态,当光学传感器检测到光信号被阻挡时,会向处理器反馈此时耳机处于佩戴状态,然后系统便会自动进入播放模式,反之,当光学传感器检测到光信号时,会向处理器反馈此时耳机未处于佩戴状态,然后系统便会自动暂停音频的播放。在用户体验上,用户可以感受到当摘下耳机时,音频自动停止播放,当戴上耳机时又会自动恢复音频播放。同理,耳机还可以根据电容传感器反馈的电容变化进行入耳检测,或者可以根据红外线传感器反馈的遮挡情况进行入耳检测。耳机还可以通过电容传感器来检测用户触控及滑动操作,进而完成音乐控制、音量控制等操作。另外,左耳机202、右耳机203可以通过加速度传感器感知用户敲击耳机的动作及次数,进而实现唤醒语音助手、切换音乐到上一首/下一首、接听/挂断电话等操作。左耳机202、右耳机203还可以通过压力传感器感知用户按压耳机腿的动作及次数,进而来实现切换耳机音效模式(例如打开/关闭降噪模式/环境音模式)、唤醒语音助手、切换音乐到上一首/下一首、接听/挂断电话等操作。耳机还可以通过耳机内部的六轴传感器(3d加速度计和3d陀螺仪),配合头部姿态识别算法,从而识别用户的头部动作,例如当收到新来电时,用户可以通过点头或者摇头来实现接听、挂断电话。耳机中的骨声纹传感器可以根据骨声纹信息来确认机主的特征,确保耳机只听机主的命令。
87.不限于图2b所示,音频输出设备202、音频输出设备203还可以包括其他部件,例如可配置有存储器、受话器、指示灯等。
88.不限于图2a所示的蓝牙耳机,无线音频系统200中的音频输出设备202、音频输出设备203还可以为其他类型的音频输出设备。例如,在家庭影院场景下,无线音频系统200中的音频输出设备202、音频输出设备203还可以分别为家庭影院场景下的两个音响设备:左声道音响、右声道音响。
89.基于前述无线音频系统,本技术实施例提供了一种无线通讯方法。
90.本技术实施例提供的无线通讯方法中,在电子设备(即主设备)与音频输出设备
(即从设备)配对成功并建立无线连接后,主、从设备之间可以进行音效处理的协商。具体的,主设备可以向从设备发送查询请求,用于获取从设备的音效处理能力。相应的,从设备可以向主设备发送从设备的音效处理能力的指示信息。例如该指示信息可以包括多个字段,这多个字段可包括用于指示生产厂商、产品型号等设备参数的字段。主设备根据从设备反馈的指示信息,确定主、从设备之间是否能够进行联合音效处理,如果确认能够进行联合音效处理,则在主、从设备两侧协同进行相适配的音效处理。
91.本技术中,联合音效处理是指,主设备可以根据从设备反馈的生产厂商、产品型号等设备参数确定从设备所使用的音效处理算法ⅰ,并确定出与音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ。主设备会在主设备侧使用音效处理算法ⅱ对主、从设备之间的音频数据进行音效处理,接着,从设备会使用从设备侧的音效处理算法ⅰ继续对该音频数据进行音效处理。主设备侧的音效处理算法ⅱ与从设备侧的音效处理算法ⅰ相适配。
92.这里,相适配具体可表现为:使用音效处理算法ⅰ、音效处理算法ⅱ接连对某一音频数据(例如某测试音频数据)进行处理,处理后的该音频数据所测出信噪比优于第一信噪比、第二信噪比,或者,处理后的该音频数据所测出的回声分量少于第一回声分量、第二回声分量,或者,处理后的该音频数据所测出的信噪比优于第一信噪比、第二信噪比,且回声分量少于第一回声分量、第二回声分量。其中,第一信噪比、第一回声分量分别为使用音效处理算法ⅰ对该音频数据处理后测出的信噪比、回声分量,第二信噪比、第二回声分量分别为使用音效处理算法ⅱ对该音频数据处理后测出的信噪比、回声分量。
93.也即是说,相适配是指,从设备侧的音效处理算法ⅰ和主设备侧的音效处理算法ⅱ之间能够互相配合,互相补充,各自的音效处理长处更能充分地发挥出来。这样,音效处理算法ⅰ的音效处理效果与音效处理算法ⅱ的音效处理效果总体上不会相互抵消,而会相互增强,进而呈现更佳的音效效果。
94.下面先说明本技术实施例涉及的蓝牙连接、音频连接。
95.(1)蓝牙连接
96.蓝牙连接是指蓝牙物理连接,如无连接的异步连接(asynchronous connectionless link,acl)。蓝牙连接可由主设备(master,即发起连接请求的设备)和从设备(slave,即接收连接请求的设备)经过查询(inquiry)、寻呼(paging)过程建立起来。一种情况下,主设备是电子设备(如手机),从设备是蓝牙耳机。另一种情况下,主设备是蓝牙耳机,从设备是电子设备(如手机)。
97.(2)音频连接
98.音频连接(audio connection)可包括:通话音频连接(call audio connection)、媒体音频连接(media audio connection)。其中,通话音频连接可用于传输话音数据,媒体音频连接可用于传输媒体音频数据。通话音频连接可以是用于通话场景的,面向连接的同步连接(synchronous connection oriented link,sco)。媒体音频连接可以是高级音频分发应用规范(advanced audio distribution profile,a2dp)连接。
99.不同的音频连接还相应配置有不同的用于音频控制的应用规范(profile)连接。具体的,通话音频连接可配置有通话音频控制连接,可用于传输通话控制(如接听、挂断等)信令。通话音频控制连接可以是免提应用规范(hands-free profile,hfp)连接。媒体音频连接可配置有媒体音频控制连接,可用于传输媒体音频播放控制(如上一首、下一首、暂停、
播放、音量控制等)信令。媒体音频控制连接可以是音视频远程控制规范(audio/video remote control profile,avrcp)连接。
100.应用规范(profile)连接是基于逻辑链路控制和适配协议(logical link control and adaptation protocol,l2cap)信道建立的。l2cap位于基带(baseband)之上,负责将基带的数据转换为便于应用程解码的数据分组格式,并提供协议复用和服务质量交换等功能。前面(1)中描述了蓝牙物理连接的建立,但上层应用(如a2dp)若需要在主、从设备之间通信,则还需要在l2cap层上建立相应的l2cap信道,这些信道用于各种不同的应用规范进行通信。在l2cap层,一个应用规范对应的l2cap信道可通过信道标识(channel identity,cid)表示。当某个应用规范不再被使用的时候,该应用规范对应的l2cap信道要被清除掉。
101.l2cap只支持acl数据传输,不支持sco数据传输。
102.(3)媒体音频连接(media audio connection)的建立过程
103.以a2dp连接为例,如图3所示,媒体音频连接的建立过程可包括如下步骤:
104.步骤1.主、从设备基于acl连接建立l2cap信道。其中,用于a2dp的l2cap信道可包括:用来传输信令(signaling)的l2cap信道、用来传输流(stream)的l2cap信道。其中,用于信令的l2cap信道可称为avdtp信令l2cap信道,用于流的l2cap信道可称为avdtp stream l2cap信道。
105.步骤2.主、从设备基于用于a2dp的l2cap信道建立a2dp连接,具体可包括步骤2-1至步骤2-5。
106.步骤2-1.流端点(stream endpoints)发现过程。
107.例如,通过avdtp信令l2cap信道,主设备可以向从设备发送avdpt_discover命令,用于发现设备中的流端点(stream endpoints,sep)。相应的,从设备会返回一个响应,该响应中可携带从设备可提供的sep的标识(seid)。
108.步骤2-2.能力(capabilities)查询过程。
109.例如,在发现sep之后,通过avdtp信令l2cap信道,主设备可以向从设备发送avdpt_get_capabilities命令,用于获取从设备的sep所能够提供的服务。相应的,从设备会向主设备反馈自己的sep所能够提供的服务。
110.步骤2-3.流配置(stream configuration)过程。
111.例如,在查询到从设备的sep所能够提供的服务之后,通过avdtp信令l2cap信道,主设备可以向从设备发送avdpt_set_configuration命令,用于对从设备的sep所提供的服务进行配置,如配置音频的声道、采样率等等。
112.步骤2-4.流建立(stream establishment)过程。
113.例如,在流配置完成之后,通过avdtp信令l2cap信道,主设备可以向从设备发送avdpt_open命令,用于创建流。创建的流也可以称为流连接(streaming connection),即a2dp连接。至此,a2dp连接建立完成。
114.步骤2-5.流启动(stream start)过程。
115.例如,通过avdtp信令l2cap信道,主设备可以向从设备发送avdpt_start命令,用于启动流。流启动之后,就可以利用流传输媒体音频数据了。这里,媒体音频是指单声道(mono)和立体声(stereo)的音频,区别于sco连接上传输的话音音频。后续,主、从设备可通
过avdpt_close命令关闭流,即断开a2dp连接。
116.类似于a2dp连接的建立,avrcp连接也是基于蓝牙连接(acl)、l2cap信道建立的,这里不再赘述。avrcp连接的建立过程可参考avrcp规范。
117.(4)通话音频连接(call audio connection)的建立过程
118.以sco连接为例,如图4所示,通话音频连接的建立过程可包括如下步骤:
119.步骤1.主设备向从设备发送sco连接建立请求,已发起sco连接的建立。
120.步骤2.从设备向主设备返回sco连接建立请求的接受应答。
121.其中,sco连接建立请求可为lmp_sco_link_req信令,sco连接建立请求接受应答可以为lmp_accepted信令。如果从设备不能够建立sco连接,则可返回lmp_not_accepted(sco连接建立请求的拒绝应答),表示不能够建立sco连接。
122.不限于图4所示,sco连接的建立也可以由从设备发起。后续,主、从设备可通过移除sco连接建立请求(如lmp_remove_sco_link_req信令)断开(或移除)sco连接。
123.具体的,sco连接可由主、从设备响应内部事件或者用户操作(拨打电话或接听电话)而建立。当通话从蓝牙耳机接听状态切换到电子设备的听筒、扬声器来接听时,sco连接会断开。sco连接可作为hfp连接的附属连接,可用于传输话音数据。后面会提及如何建立hfp连接,这里先不赘述。仅仅在acl连接已经建立之后,才可以建立sco连接。因为,hfp连接的建立需要基于acl连接。
124.(5)通话音频控制连接的建立过程
125.以hfp连接为例,如图5所示,通话音频控制连接的建立过程可包括如下步骤:
126.步骤1.主、从设备基于acl连接建立用于射频通信(radio frequency communication,rfcomm)的l2cap信道。
127.步骤2.主、从设备基于该l2cap信道建立rfcomm连接。关于rfcomm连接的建立过程,可参考通用访问规范(generic access profile,gap)和串口规范(serial port profile,spp)。
128.步骤3.响应用户操作(拨打电话或接听电话)或内部事件,基于已有的rfcomm连接,主从设备之间可以建立服务级连接(establish service level connection)。至此,hfp连接建立完成。
129.后续,主、从设备可通过服务级连接移除过程(service level connection removal procedure)来释放服务级连接(release service level connection),即断开hfp连接。一旦已建立的服务级连接释放,其相应的rfcomm连接也会被移除。同样的,该服务级连接对应的音频连接(sco连接)也会被移除。
130.关于服务级连接建立过程、服务级连接移除过程,可参考hfp规范。
131.图6示出了本技术实施例提供的无线通讯方法的总体流程。其中,主设备是前述电子设备,从设备是音频输出设备,下面展开说明。
132.s101,主设备与从设备配对成功并建立蓝牙连接。
133.其中,配对可以在主设备与从设备之间创建共享密钥:链路密钥(link key)。该链路密钥(link key)用于主设备与从设备彼此认证设备并加密交换的数据。
134.其中,蓝牙连接可以是指蓝牙物理连接,用于音频传输,如acl连接。主设备与从设备可经过查询(inquiry)、寻呼(paging)过程建立acl连接。
135.当主设备、从设备的蓝牙开启时,主设备与从设备开始执行s101。
136.一种方式中,如图7a所示,用户可在电子设备显示的下拉状态栏701中点击蓝牙选项702来开启电子设备的蓝牙。另一种方式中,如图7b所示,用户还可以在电子设备的“设置”界面703中通过蓝牙开关704开启电子设备的蓝牙。“设置”是电子设备上的一款应用程序或服务,可负责配置电子设备所具有的各项功能,如飞行模式、无线高保真(wireless fidelity,wi-fi)、蓝牙、移动网络等等。不限于图7a、图7b所示的这两种方式,电子设备的蓝牙还可由内部事件触发开启。该内部事件可例如为“华为分享”等分享服务的开启事件。“华为分享”这种分享服务的开启会触发蓝牙、wi-fi的开启。
137.从设备,如蓝牙耳机或蓝牙音响,一般可在开机后开启蓝牙,无需用户手动额外开启蓝牙。
138.当主设备与从设备配对成功并建立蓝牙连接后,如图7c示例性所示,电子设备可以在状态栏显示指示符705,指示符705可用于指示当前主、从设备处于蓝牙连接状态。指示符705可以称为第一指示符。另外,在显示指示符705时,电子设备还可显示指示符706。指示符706可用于指示从设备的剩余电量。指示符706可以称为第二指示符。当主、从设备间的蓝牙连接断开之后,指示符705、指示符706会随之消失。不限于图7c所示的外观,第一指示符、第二指示符还可以呈现其他外观,本技术实施例对此不作限制。
139.主、从设备之间建立的音频连接可以是通话音频连接(如sco连接)、媒体音频连接(如a2dp连接)。后续实施例会详细说明,在媒体音频连接(如a2dp连接)和通话音频连接(如sco连接)的场景下,主、从设备之间是如何协商音效处理的。
140.s102,主设备可以向从设备发送查询指令,以查询从设备的音效处理能力。
141.该查询指令可以是l2cap协议中的回声请求(echo request),可以是其他类型的l2cap的扩展指令,也可以是hfp协议中扩展的at指令,以及其他自定义的扩展指令,本技术对此不作限制。后续实施例中会详细说明该请求的信令实现,这里先不展开。
142.s103,从设备向主设备反馈从设备的音效处理能力的指示信息(如生产厂商、产品型号等)。
143.该指示信息可以携带在回声响应(echo response)、扩展的at响应等消息中,具体可参考后续实施例。
144.s104,主设备可以根据从设备反馈的指示信息确定主、从设备之间是否支持联合音效处理。
145.该指示信息可包括从设备的生产厂商、产品型号等设备参数,这些参数可用于指示该款从设备所使用的音效处理算法,反映出该款从设备的音效处理能力,故可称为该款从设备的音效处理能力或所使用的音效处理算法的指示信息。
146.这里,主、从设备之间是否支持联合音效处理可以包括下述三种情况:
147.情况1:主、从设备之间不支持联合音效处理,从设备不支持音效处理,可参考步骤s105。
148.具体的,当主设备可以根据从设备反馈的生产厂商、产品型号等设备参数确定从设备不具备音效处理能力时,主设备可确定协商音效处理的情况为情况1。从设备是否具备音效处理能力,这一点可以根据从设备反馈的生产厂商、产品型号等设备参数确定出来。主设备侧可以根据某款耳机、音箱等从设备的生产厂商、产品型号等设备参数,在本地或在云
端查询到该款从设备是否具有如降噪、消回声等音效处理能力,以及该款从设备在具有音效处理能力的情况下所使用的音效处理算法是什么。
149.情况2:主、从设备之间不支持联合音效处理,从设备支持音效处理,可参考步骤s110。
150.具体的,当主设备根据从设备反馈的生产厂商、产品型号等设备参数确定从设备具备音效处理能力时,如果主设备根据从设备使用的音效处理算法,不能够从主设备侧的多套音效处理算法中获取到与从设备侧的音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ,则主设备可确定协商音效处理的情况为情况2。
151.情况3:主、从设备之间支持联合音效处理,从设备支持音效处理,可参考步骤s115。
152.具体的,当主设备根据从设备反馈的生产厂商、产品型号等设备参数确定从设备支持音效处理时,如果主设备根据从设备使用的音效处理算法ⅰ,能够从主设备侧的多套音效处理算法中获取到与音效处理算法ⅰ相适配的音效处理算法ⅱ,则主设备可确定协商音效处理的情况为情况3。音效处理算法ⅱ可用于联合音效处理中主设备侧的音效处理。
153.为了确定上述几种情况,主设备可以通过下述几种方式确定:主设备侧是否有与从设备侧的音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ。
154.方式1.通过对测试信号进行音效处理,比对处理结果,来筛选出适配算法。
155.具体的,主设备可从主设备侧的多套音效处理算法中选择出一套音效处理算法,使用选择出来的这一套音效处理算法和从设备侧的音效处理算法ⅰ接连对测试音频数据进行处理。如果以下一项或多项条件被满足:处理后的测试音频数据所测出信噪比优于第一信噪比、第二信噪比,处理后的测试音频数据所测出的回声分量少于第一回声分量、第二回声分量,则确定主设备侧有与音效处理算法ⅰ相适配的音效处理算法ⅱ。如果这一项或多项条件未被满足,则继续从该多套音效处理算法中选择出下一套音效处理算法,重复前述音效处理,直至筛选出满足这一项或多项条件的音效处理算法。如果多套算法全部都无法满足这一项或多项条件,则可确定主设备侧没有与从设备侧的音效处理算法ⅰ相适配的音效处理算法ⅱ。
156.主设备可进一步从这多套音效处理算法中选择出满足前述一项或多项条件,且音效处理效果最优(例如信噪比最优、回声分量最少)的音效处理算法来适配从设备侧的音效处理算法ⅰ。
157.其中,第一信噪比、第一回声分量可以分别为使用前述选择出来的这一套音效处理算法对所述测试音频数据处理后测出的信噪比、回声分量,第二信噪比、第二回声分量可以分别为使用从设备侧的音效处理算法ⅰ对该测试音频数据处理后测出的信噪比、回声分量。主设备侧的多套音效处理算法可以存储在主设备本地,也可以存储在云端服务器,由主设备访问。
158.方式2.查表获得适配算法。
159.具体的,主设备侧可以存储有或者可访问到一个映射表。该映射表中可以记录有多款设备的设备参数(如生产厂商、产品型号等设备参数)和多套音效处理算法之间的对应关系。在该映射表中,某款从设备的设备参数对应的音效处理算法,指的是主设备侧的多套音效处理算法中与该款从设备所使用的音效处理算法相适配的音效处理算法。一套音效处
理算法可以包括多个音效处理算法,例如降噪算法、回声抑制算法等等。当然,一套音效处理算法也可以仅包括一个音效处理算法,例如降噪算法,本技术对此不做限制。该映射表可以是主设备出厂前写入到存储器中,也可以是主设备从服务器下载的,还可以是其他设备分享而来的。本技术对该映射表的来源不作限制。
160.具体的,主设备侧可以判断第一映射表中是否存在从设备的设备参数对应的音效处理算法,如果有,则可确定第一设备有与从设备侧的音效处理算法ⅰ相适配的音效处理算法ⅱ。音效处理算法ⅱ即映射表中从设备的设备参数对应的音效处理算法。
161.在上述s103中,不限于生产厂商、产品型号等设备参数,从设备向主设备发送的音效处理能力的指示信息还可以进一步包括特定比特或特定字段,该特定比特或特定字段可用于指示从设备是否具备音效处理能力。例如,当该特定比特为0时,指示从设备没有音效处理能力;当该特定比特为1时,指示从设备具有音效处理能力。这样,主设备可以直接根据该特定比特或特定字段确定出从设备是否具备音效处理能力,无需基于从设备反馈的生产厂商、产品型号等设备参数去确定从设备是否具备音效处理能力,效率更高。进一步地,如果根据该特定比特或特定字段确定出从设备不具备音效处理能力,即上述情况1,那么主设备就可以直接使用主设备侧的某套音效处理算法在主设备侧对主、从设备之间的音频数据进行音效处理。如果确定出从设备具备音效处理能力,那么主设备还需要根据生产厂商、产品型号等设备参数进一步确定主、从设备之间是否支持联合音效处理,具体可参考上述情况2、情况3。
162.下面分别说明上述三种情况下的音效处理过程:
163.情况1下的音效处理过程(s106-s109):
164.s106,在情况1下,主设备可确定在主设备侧使用音效处理算法ⅲ对主、从设备之间的音频数据a进行音效处理。
165.音效处理算法ⅲ属于前述主设备侧的多套音效处理算法。音效处理算法ⅲ可以是主设备侧默认使用的音效处理算法,也可以是主设备针对情况1专门选择的音效处理算法。
166.s107,主设备可以使用主设备侧的音效处理算法ⅲ对音频数据a进行音效处理,得到音频数据b。
167.主、从设备之间可以建立音频连接,该音频连接可用于传输主、从设备之间的音频数据a。该音频连接可以是通话音频连接(如sco连接)、媒体音频连接(如a2dp连接)。后续实施例会详细说明,在媒体音频连接(如a2dp连接)和通话音频连接(如sco连接)的场景下,主、从设备之间是如何协商音效处理的,这里先不展开。
168.s108,主设备可以通过主、从设备之间的音频连接向从设备发送音频数据b。
169.s109,从设备播放音频数据b。
170.在情况1下,从设备不支持音效处理。在接收到来自主设备的音频数据b后,从设备不对音频数据b进行音效处理便播放音频数据b。
171.情况2下的音效处理过程(s111-s114):
172.s111,在情况2下,主设备可确定在从设备侧使用音效处理算法ⅳ对主、从设备之间的音频数据a进行音效处理。
173.音效处理算法ⅳ属于前述从设备侧的多套音效处理算法。音效处理算法ⅳ可以是从设备侧默认使用的音效处理算法,也可以是其他类型的音效处理算法。
174.s112,主设备可以通过主、从设备之间的音频连接直接向从设备发送音频数据a。
175.主、从设备之间可以建立音频连接,该音频连接可用于传输主、从设备之间的音频数据a。该音频连接可以是通话音频连接(如sco连接)、媒体音频连接(如a2dp连接),后续实施例会详细说明。
176.在情况2下,主设备确定不使用主设备侧的音效处理功能,所以主设备不对音频数据a进行音效处理便将音频数据a发送给从设备。
177.s113,从设备可以使用从设备侧的音效处理算法ⅳ对音频数据a进行音效处理,得到音频数据c。
178.s114,从设备播放音频数据c。
179.情况3下的音效处理过程(s116-s120):
180.s116,在情况3下,主设备根据从设备使用的音效处理算法ⅰ选择出与音效处理算法ⅰ相适配的音效处理算法ⅱ,确定在主设备侧使用音效处理算法ⅱ对主、从设备之间的音频数据a进行音效处理。
181.参考步骤s115,主设备可以在本地或云端获取到与从设备侧的音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ。音效处理算法ⅱ属于主设备侧的多套音效处理算法。音效处理算法ⅱ一般是主设备针对情况3专门选择的与从设备侧的音效处理算法ⅰ相适配的音效处理算法。关于主设备侧如何获取到与从设备侧的音效处理算法ⅰ相适配的音效处理算法,可以参考前述内容,这里不再赘述。
182.s117,主设备使用主设备侧的音效处理算法ⅱ对音频数据a进行音效处理,得到音频数据d。
183.主、从设备之间可以建立音频连接,该音频连接可用于传输主、从设备之间的音频数据a。该音频连接可以是通话音频连接(如sco连接)、媒体音频连接(如a2dp连接),后续实施例会详细说明。
184.s118,主设备通过主、从设备之间的音频连接向从设备发送音频数据d。
185.s119,从设备使用从设备侧的音效处理算法ⅰ对音频数据d进行音效处理,得到音频数据e。
186.s120,从设备播放音频数据e。
187.在情况3下,音频数据a在经过主设备侧的音效处理算法ⅱ和从设备侧的音效处理算法ⅰ的联合音效处理后,最终得到音频数据e。
188.可以看出,本技术提供的无线通讯方法,可根据从设备的音效处理能力更灵活的选择主、从设备之间的音效处理方式,支持主、从设备之间的联合音效处理,可使得主、从设备充分发挥各自音效处理的优势。相对于单侧音效处理的情况,联合音效处理的效果总体上不会相互抵消,而会相互增强,可以进一步提升音频的音效效果,满足了用户对于音频的更高音质的追求。
189.不限于主、从设备之间的蓝牙连接,上述各流程也可以基于主、从设备之间的其他类型的无线通信连接,例如wi-fi连接,近距离无线通信(near field communication,nfc)连接等,本技术对此不作限制。
190.下面将详细说明本技术的各个实施例提供的无线通讯方法。
191.实施例一
192.本实施例将讨论基于蓝牙l2cap协议中的信令,主设备(如手机或平板电脑)和从设备(如蓝牙耳机或蓝牙音响)在媒体音频连接的场景下是如何协同音效处理的。这里,媒体音频连接可例如为a2dp连接。
193.图8示出了实施例一提供的无线通讯方法。图8所示方法中,主设备和从设备之间建立并保持有蓝牙连接(acl连接)。如图8所示,以媒体音频连接是a2dp连接为例,该方法可包括:
194.s201,主设备和从设备之间基于acl连接建立l2cap信道,如echo l2cap信道。
195.本实施例可以基于蓝牙l2cap的信令来实现主、从设备之间的音效处理的协商。在一个示例中,可以建立echo l2cap信道,通过l2cap中的回声请求(echo request)/回声响应(echo response)指令,实现主、从设备之间的音效处理的协商。因为l2cap属于蓝牙底层连接,可支持在蓝牙profile连接建立之前协商好结果,因此,主、从设备可以在媒体音频数据到来之前完成协商。
196.具体地,回声请求(echo request)/回声响应(echo response)指令的格式,如下表1、表2所示:
[0197][0198]
表1回声请求指令格式
[0199][0200]
表2回声响应指令格式
[0201]
s202,主设备基于echo l2cap信道向从设备发送回声请求。
[0202]
主设备发送的回声请求用于请求查询从设备的音效处理能力。
[0203]
s203,从设备基于echo l2cap信道向主设备发送回声响应(包含从设备的音效处理能力的指示信息)。
[0204]
响应于主设备发送的回声请求,从设备向主设备发送回声响应。其中,回声响应中可以携带从设备的音效处理能力的指示信息,例如生产厂商、产品型号等设备参数,用于后续主、从设备之间的音效处理的协商。
[0205]
主设备可以根据从设备的音效处理能力的指示信息确定主、从设备之间是否支持联合音效处理。
[0206]
下面说明主、从设备之间是否支持联合音效处理的三种情况(具体可参考前述总体方法流程中的相关内容),以及这三种情况下的音效处理过程。
[0207]
情况1以及情况1下的音效处理过程(s204-s210):
[0208]
s204,主设备可以根据从设备的指示信息确定主、从设备之间不能进行联合音效处理。
[0209]
并且,从设备不支持音效处理,即确定协商音效处理的情况为情况1。
[0210]
具体的,当主设备根据从设备的音效处理能力的指示信息,例如生产厂商、产品型号等设备参数确定从设备不支持音效处理时,或者从设备对音频数据的音效处理效果较差,主设备可确定协商音效处理的情况为情况1。
[0211]
s205,在情况1下,主设备可以确定在主设备侧使用音效处理算法ⅲ对主、从设备之间的媒体音频数据a进行音效处理。
[0212]
音效处理算法ⅲ属于前述主设备侧的多套音效处理算法。音效处理算法ⅲ可以是主设备侧默认使用的音效处理算法,也可以是主设备针对情况1专门选择的音效处理算法。
[0213]
s206,主设备和从设备之间基于用于a2dp的l2cap信道建立a2dp连接。
[0214]
a2dp连接可以是基于蓝牙连接、用于a2dp的l2cap信道建立的流连接。关于主、从设备之间的a2dp连接的建立,可以参考前述图3所示的媒体音频连接的建立过程,在此不再赘述。
[0215]
s207,主设备检测到用户播放媒体音频a。
[0216]
用户可以在主设备上操作播放媒体音频a,此时主设备检测到用户播放媒体音频a的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户播放媒体音频a的操作,并且反馈给主设备。
[0217]
s208,主设备使用音效处理算法ⅲ对媒体音频数据a进行音效处理,得到媒体音频数据b。
[0218]
s209,主设备通过a2dp连接向从设备发送媒体音频数据b。
[0219]
主设备将音效处理后的媒体音频数据b通过a2dp连接发送给从设备。
[0220]
s210,从设备播放媒体音频数据b。
[0221]
在情况1下,从设备不支持音效处理。在接收到来自主设备的媒体音频数据b后,从设备不对媒体音频数据b进行音效处理便播放媒体音频数据b。
[0222]
情况2以及情况2下的音效处理过程(s211-s217):
[0223]
s211,主设备可以根据从设备的指示信息确定主、从设备之间不能进行联合音效处理。
[0224]
但是,从设备支持音效处理,即确定协商音效处理的情况为情况2。
[0225]
具体的,当主设备根据从设备的音效处理能力的指示信息,例如生产厂商、产品型号等设备参数确定从设备支持音效处理时,但是主设备不能够获取到与从设备使用的音效处理算法相适配的主设备侧的音效处理算法,则主设备可确定协商音效处理的情况为情况2。
[0226]
s212,在情况2下,主设备可确定在从设备侧使用音效处理算法ⅳ对主、从设备之间的媒体音频数据a进行音效处理。
[0227]
音效处理算法ⅳ属于前述从设备侧的多套音效处理算法。音效处理算法ⅳ可以是从设备侧默认使用的音效处理算法,也可以是其他类型的音效处理算法。
[0228]
s213,主设备和从设备之间基于用于a2dp的l2cap信道建立a2dp连接。
[0229]
a2dp连接可以是基于蓝牙连接、用于a2dp的l2cap信道建立的流连接。关于主、从设备之间的a2dp连接的建立,可以参考前述图3所示的媒体音频连接的建立过程,在此不再赘述。
[0230]
s214,主设备检测到用户播放媒体音频a。
[0231]
用户可以在主设备上操作播放媒体音频a,此时主设备检测到用户播放媒体音频a的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户播放媒体音频a的操作,并且反馈给主设备。
[0232]
s215,主设备通过a2dp连接向从设备发送媒体音频数据a。
[0233]
在情况2下,主设备确定不使用主设备侧的音效处理功能,所以主设备不对媒体音频数据a进行音效处理便将媒体音频数据a发送给从设备。
[0234]
s216,从设备使用音效处理算法ⅳ对媒体音频数据a进行音效处理,得到媒体音频数据c。
[0235]
s217,从设备播放媒体音频数据c。
[0236]
情况3以及情况3下的音效处理过程(s218-s225):
[0237]
s218,主设备根据从设备的指示信息确定主、从设备之间能够进行联合音效处理。
[0238]
具体的,当主设备根据从设备反馈的生产厂商、产品型号等设备参数确定从设备支持音效处理时,如果主设备根据从设备使用的音效处理算法ⅰ,能够从主设备侧的多套音效处理算法中获取到音效处理算法ⅰ相适配的音效处理算法ⅱ,则主设备可确定协商音效处理的情况为情况3。音效处理算法ⅱ可用于联合音效处理中主设备侧的音效处理。
[0239]
s219,在情况3下,主设备根据从设备使用的音效处理算法ⅰ选择出与音效处理算法ⅰ相适配的音效处理算法ⅱ,确定在主设备侧使用音效处理算法ⅱ对主、从设备之间的媒体音频数据a进行音效处理。
[0240]
主设备可以在本地或云端获取到与从设备侧的音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ。音效处理算法ⅱ属于主设备侧的多套音效处理算法。音效处理算法ⅱ一般是主设备针对情况3专门选择的与从设备侧的音效处理算法ⅰ相适配的音效处理算法。主设备侧的音效处理算法ⅱ搭配从设备侧的音效处理算法ⅰ协同对媒体音频进行处理,它们互相配合,互相补充,可以呈现出更佳的音效效果。
[0241]
s220,主设备和从设备之间基于用于a2dp的l2cap信道建立a2dp连接。
[0242]
a2dp连接可以是基于蓝牙连接、用于a2dp的l2cap信道建立的流连接。关于主、从设备之间的a2dp连接的建立,可以参考前述图3所示的媒体音频连接的建立过程,在此不再赘述。
[0243]
s221,主设备检测到用户播放媒体音频a。
[0244]
同样的,用户可以在主设备上操作播放媒体音频a,此时主设备检测到用户播放媒体音频a的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户播放媒体音频a的操作,并且反馈给主设备。
[0245]
s222,主设备使用音效处理算法ⅱ对媒体音频数据a进行音效处理,得到媒体音频数据d。
[0246]
s223,主设备通过a2dp连接向从设备发送媒体音频数据d。
[0247]
主设备将音效处理后的媒体音频数据d通过a2dp连接发送给从设备。
[0248]
s224,从设备使用音效处理算法ⅰ对媒体音频数据d进行音效处理,得到媒体音频数据e。
[0249]
s225,从设备播放媒体音频e。
[0250]
在情况3下,媒体音频数据a在经过主设备侧的音效处理算法ⅱ和从设备侧的音效处理算法ⅰ的联合音效处理后,最终得到媒体音频数据e。
[0251]
在媒体音频连接的场景下,l2cap能够和蓝牙上层音频profile进行交互,使得上层音频profile能够获取到协商结果。而且,l2cap属于蓝牙底层连接,可支持在蓝牙
profile连接建立之前协商好结果,确保媒体音频数据到来之前完成协商,并及时对媒体音频数据进行音效处理。
[0252]
另外,不限于echo l2cap,主、从设备还可以基于其他类型的l2cap建立l2cap信道进行前述音效处理协商。
[0253]
实施例二
[0254]
本实施例将讨论基于蓝牙hfp协议中的at指令,主设备(如手机或平板电脑)和从设备(如蓝牙耳机或蓝牙音响)在通话音频连接的场景下是如何协同音效处理的。at指令是hfp协议的一部分,用于在ag(audio gateway)和hf(hands-free unit)之间通过rfcomm(串口仿真协议)通道传输控制信令。at指令的编码格式为ascii码。这里,通话音频连接可例如为sco连接。和媒体音频连接不同的是,sco连接的建立需要用户操作(接听电话)或内部事件触发。即,通话音频连接需要在有通话音频业务时才建立。
[0255]
图9示出了实施例二提供的无线通讯方法。图9所示方法中,主设备和从设备之间建立并保持有蓝牙连接(acl连接)。如图9所示,以通话音频连接是sco连接为例,该方法可包括:
[0256]
s301,主设备和从设备之间基于acl连接建立用于rfcomm的l2cap信道。
[0257]
具体内容可参考前述图5中所示的通话音频控制连接的建立过程中的步骤1,此处不再赘述。
[0258]
s302,主设备和从设备之间基于rfcomm l2cap信道建立rfcomm连接。
[0259]
具体内容可参考前述图5中所示的通话音频控制连接的建立过程中的步骤2,此处不再赘述。
[0260]
s303,主设备基于rfcomm连接向从设备发送特定扩展at指令,以查询从设备的生产厂商、产品型号等设备参数。
[0261]
扩展at指令是基于ascii码的命令行实现的,其格式如下:
[0262]
at+<cmd>[op][para-1,para-2,para-3,

]<cr>。
[0263]
其中,<>表示必须包含的部分,[]表示可选的部分。at+是命令信息前缀;cmd是指令字符串;[op]是指令操作符,指定是参数设置或查询:“=”表示参数设置,“null”表示查询;[para-n]是参数设置时的输入,如查询则不需要;<cr>是结束符,回车,ascii码为0x0a或0x0d。
[0264]
扩展at指令对应的响应消息的格式:
[0265]
+<rsp>[op][para-1,para-2,para-3,

]<cr><lf><cr><lf>。
[0266]
其中,+是响应消息前缀;rsp是响应字符串,包括:“ok”表示成功,“err”表示失败;[op]为=;[para-n]是查询时的返回参数或出错时的错误码;<cr>是结束符,表示回车,ascii码为0x0d。<lf>是结束符,表示换行,ascii码为0x0a。
[0267]
例如,可以自定义一个“at+aaid”的at指令,作为主设备查询从设备音效处理能力的指示信息的at+指令,其中,“aaid”字符为示例展示的自定义的指令字符串,关于扩展at指令的形式以及内容,本实施例不作任何限制。
[0268]
s304,从设备可以基于rfcomm连接向从设备发送该特定扩展at指令的响应消息(携带从设备的音效处理能力的指示信息)。
[0269]
关于该特定扩展at指令的响应消息的格式,可参考s303中的相关内容,这里不再
赘述。
[0270]
主设备可以根据从设备反馈的生产厂商、产品型号等设备参数确定从设备是否具有音效处理能力,以及主、从设备之间是否支持联合音效处理,即主设备侧是否有音效处理算法适配于从设备侧的音效处理算法。
[0271]
下面说明主、从设备之间是否支持联合音效处理的三种情况(具体可参考前述总体方法流程中的相关内容),以及这三种情况下的音效处理过程。
[0272]
情况1以及情况1下的音效处理过程(s305-s213):
[0273]
s305,主设备可以根据从设备的指示信息确定主、从设备之间不能进行联合音效处理。
[0274]
并且,从设备不支持音效处理,即确定协商音效处理的情况为情况1。
[0275]
具体的,当主设备根据从设备的音效处理能力的指示信息,例如生产厂商、产品型号等设备参数,确定从设备不支持音效处理时,或者从设备对音频数据的音效处理效果较差,主设备可确定协商音效处理的情况为情况1。
[0276]
s306,在情况1下,主设备可以确定在主设备侧使用音效处理算法ⅲ对主、从设备之间的通话音频数据a进行音效处理。
[0277]
音效处理算法ⅲ属于前述主设备侧的多套音效处理算法。音效处理算法ⅲ可以是主设备侧默认使用的音效处理算法,也可以是主设备针对情况1专门选择的音效处理算法。
[0278]
s307,主设备和从设备之间建立服务级连接。
[0279]
具体内容可参考前述图5中所示的通话音频控制连接的建立过程中的步骤3,此处不再赘述。
[0280]
s308,主设备检测到用户接听来电或拨通电话。
[0281]
用户可以在主设备上操作接听来电或拨通电话,此时主设备检测到用户接听来电或拨通电话的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户接听来电或拨通电话的操作,并且反馈给主设备。
[0282]
s309,主设备和从设备之间建立sco连接。
[0283]
关于sco连接建立过程,可参考前述图4的相关内容,这里不再赘述。
[0284]
s310,主设备检测到通话音频数据a。
[0285]
s311,主设备使用音效处理算法ⅲ对通话音频数据a进行音效处理,得到媒体音频数据b。
[0286]
s312,主设备通过sco连接向从设备发送通话音频数据b。
[0287]
主设备将音效处理后的通话音频数据b通过sco连接发送给从设备。
[0288]
s313,从设备播放通话音频数据b。
[0289]
在情况1下,从设备不支持音效处理。在接收到来自主设备的通话音频数据b后,从设备不对通话音频数据b进行音效处理便播放通话音频数据b。
[0290]
情况2以及情况2下的音效处理过程(s314-s322):
[0291]
s314,主设备可以根据从设备的指示信息确定主、从设备之间不能进行联合音效处理。
[0292]
但是,从设备支持音效处理,即确定协商音效处理的情况为情况2。
[0293]
具体的,当主设备根据从设备的音效处理能力的指示信息,例如生产厂商、产品型
号等设备参数确定从设备支持音效处理时,但是主设备不能够获取到与从设备使用的音效处理算法相适配的主设备侧的音效处理算法,则主设备可确定协商音效处理的情况为情况2。
[0294]
s315,在情况2下,主设备可确定在从设备侧使用音效处理算法ⅳ对主、从设备之间的通话音频数据a进行音效处理。
[0295]
音效处理算法ⅳ属于前述从设备侧的多套音效处理算法。音效处理算法ⅳ可以是从设备侧默认使用的音效处理算法,也可以是其他类型的音效处理算法。
[0296]
s316,主设备和从设备之间建立服务级连接。
[0297]
具体内容可参考前述图5中所示的通话音频控制连接的建立过程中的步骤3,此处不再赘述。
[0298]
s317,主设备检测到用户接听来电或拨通电话。
[0299]
用户可以在主设备上操作接听来电或拨通电话,此时主设备检测到用户接听来电或拨通电话的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户接听来电或拨通电话的操作,并且反馈给主设备。
[0300]
s318,主设备和从设备之间建立sco连接。
[0301]
关于sco连接建立过程,可参考前述图4的相关内容,这里不再赘述。
[0302]
s319,主设备检测到通话音频数据a。
[0303]
s320,主设备通过sco连接向从设备发送通话音频数据a。
[0304]
在情况2下,主设备确定不使用主设备侧的音效处理功能,所以主设备不对通话音频数据a进行音效处理便将通话音频数据a发送给从设备。
[0305]
s321,从设备使用音效处理算法ⅳ对通话音频数据a进行音效处理,得到通话音频数据c。
[0306]
s322,从设备播放通话音频数据c。
[0307]
情况3以及情况3下的音效处理过程(s323-s332):
[0308]
s323,主设备根据从设备的指示信息确定主、从设备之间能够进行联合音效处理。
[0309]
具体的,当主设备根据从设备反馈的生产厂商、产品型号等设备参数确定从设备支持音效处理时,如果主设备根据从设备使用的音效处理算法ⅰ,能够从主设备侧的多套音效处理算法中获取到音效处理算法ⅰ相适配的音效处理算法ⅱ,则主设备可确定协商音效处理的情况为情况3。音效处理算法ⅱ可用于联合音效处理中主设备侧的音效处理。可参考步骤s115。
[0310]
s324,主设备根据从设备使用的音效处理算法ⅰ选择出与音效处理算法ⅰ相适配的音效处理算法ⅱ,确定在主设备侧使用音效处理算法ⅱ对主、从设备之间的通话音频数据a进行音效处理。
[0311]
主设备可以在本地或云端获取到与从设备侧的音效处理算法ⅰ相适配的主设备侧的音效处理算法ⅱ。音效处理算法ⅱ属于主设备侧的多套音效处理算法。音效处理算法ⅱ一般是主设备针对情况3专门选择的与从设备侧的音效处理算法ⅰ相适配的音效处理算法。主设备侧的音效处理算法ⅱ搭配从设备侧的音效处理算法ⅰ协同对通话音频进行处理,它们互相配合,互相补充,可以呈现出更佳的音效效果。
[0312]
s325,主设备和从设备之间建立服务级连接。
[0313]
具体内容可参考前述图5中所示的通话音频控制连接的建立过程中的步骤3,此处不再赘述。
[0314]
s326,主设备检测到用户接听来电或拨通电话。
[0315]
同样的,用户可以在主设备上操作接听来电或拨通电话,此时主设备检测到用户接听来电或拨通电话的操作。另外,基于从设备的传感器、线控等器件的交互反应,从设备也可以检测到用户接听来电或拨通电话的操作,并且反馈给主设备。
[0316]
s327,主设备和从设备之间建立sco连接。
[0317]
关于sco连接建立过程,可参考前述图4的相关内容,这里不再赘述。
[0318]
s328,主设备检测到通话音频数据a。
[0319]
s329,主设备使用音效处理算法ⅱ对通话音频数据a进行音效处理,得到通话音频数据d。
[0320]
s330,主设备通过sco连接向从设备发送通话音频数据d。
[0321]
主设备将将音效处理后的通话音频数据d通过sco连接发送给从设备。
[0322]
s331,从设备使用音效处理算法ⅰ对通话音频数据d进行音效处理,得到通话音频数据e。
[0323]
s332,从设备播放通话音频e。
[0324]
在情况3下,通话音频数据a在经过主设备侧的音效处理算法ⅱ和从设备侧的音效处理算法ⅰ的联合音效处理后,最终得到通话音频数据e。
[0325]
另外,在主设备或从设备检测到通话被挂断时,sco连接也会随之断开。
[0326]
在通话音频连接的场景下,主、从设备通过使用at指令进行音效处理的协商,实现效率高,而且可以使得主、从设备在服务级连接建立之前就协商好结果,确保在用户接听来电或拨通电话之前协商完成,并及时对通话音频数据进行音效处理,提高通话音频的质量。
[0327]
在一些实施例中,为了节约主设备侧、从设备的功耗,主设备可以根据主设备、从设备的剩余电量来进一步细化主、从设备两侧的音效处理过程。
[0328]
在前述情况1下,主设备单侧对音频数据进行音效处理。在发现主设备的剩余电量低于一定数值时,比如小于10%,主设备可以关闭主设备侧的音效处理算法,以节约电量。
[0329]
在前述情况2下,从设备单侧对音频数据进行音效处理。在发现从设备的剩余电量低于一定数值时,比如小于10%,主设备可以向从设备发一个通知,通知从设备不再进行音效处理,或者从设备主动关闭自身的音效处理功能,以节约从设备的电量。
[0330]
在前述情况3下,主、从设备之间支持联合音效处理,主、从设备双侧协同对音频数据进行音效处理。如果发现主设备电量或从设备电量低于一定数值,比如小于10%,可以抛弃使用联合音效处理。抛弃联合音效处理后,综合考虑降低功耗,如果是从设备电量低,则使用电量相对充足的主设备单侧的音效处理算法对音频数据进行音效处理;如果主设备电量低,则使用电量相对充足的从设备单侧的音效处理算法对音频数据进行音效处理;如果是主、从设备电量都低,那么主、从设备两侧均关闭音效处理功能,以降低功耗,节省电量。
[0331]
另外,本技术实施例还提供了一种无线通讯方法,用于低功耗蓝牙连接的情形中。具体的,与前述实施例不同的是,低功耗蓝牙连接的情形中,从设备可以发送ble广播,该广播中可以包含从设备的相关参数,比如从设备的名称,从设备的生产商,从设备具有的服务uuid等。主设备搜索到该广播后发起连接请求,建立连接后主设备可以获取到从设备的参
数。或者在建立ble连接的时候,主、从设备通过扩展指令,进行音效处理的协商。低功耗蓝牙通过广播来支持主、从设备之间的音效处理的协商,可以用更低的功耗来实现高效率的交互。
[0332]
下面介绍本技术实施例中提供的示例性电子设备10。电子设备10可以实现为上述实施例中提及的主设备,可以是图1a所示的无线音频系统100中的电子设备101或者图2a所示的无线音频系统200中的电子设备201。电子设备10通常可以用作音频源(audio source),如手机、平板电脑等,可以向其他音频接收设备(audio sink),如耳机、音箱等,传输音频数据,这样其他音频接收设备便可以将音频数据转换成声音。在一些场景下,电子设备10也可以用作音频接收方(audio sink),接收其他设备音频源(如具有麦克风的耳机)传输的音频数据(如耳机采集的用户说话的声音所转换成的音频数据)。
[0333]
图10示出了电子设备10的结构示意图。
[0334]
电子设备10可以包括处理器110,外部存储器接口120,内部存储器121,通用串行总线(universal serial bus,usb)接口130,充电管理模块140,电源管理模块141,电池142,天线1,天线2,移动通信模块150,无线通信模块160,音频模块170,扬声器170a,受话器170b,麦克风170c,耳机接口170d,传感器模块180,按键190,马达191,指示器192,摄像头193,显示屏194,以及用户标识模块(subscriber identification module,sim)卡接口195等。其中传感器模块180可以包括压力传感器180a,陀螺仪传感器180b,气压传感器180c,磁传感器180d,加速度传感器180e,距离传感器180f,接近光传感器180g,指纹传感器180h,温度传感器180j,触摸传感器180k,环境光传感器180l,骨传导传感器180m等。
[0335]
可以理解的是,本发明实施例示意的结构并不构成对电子设备10的具体限定。在本技术另一些实施例中,电子设备10可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和硬件的组合实现。
[0336]
处理器110可以包括一个或多个处理单元,例如:处理器110可以包括应用处理器(application processor,ap),调制解调处理器,图形处理器(graphics processing unit,gpu),图像信号处理器(image signal processor,isp),控制器,存储器,视频编解码器,数字信号处理器(digital signal processor,dsp),基带处理器,和/或神经网络处理器(neural-network processing unit,npu)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。在一些实施例中,电子设备10也可以包括一个或多个处理器110。
[0337]
其中,控制器可以是电子设备10的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号,产生操作控制信号,完成取指令和执行指令的控制。
[0338]
处理器110中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据,可从所述存储器中直接调用。避免了重复存取,减少了处理器110的等待时间,因而提高了电子设备10的效率。
[0339]
在一些实施例中,处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit,i2c)接口,集成电路内置音频(inter-integrated circuit sound,i2s)接口,脉冲编码调制(pulse code modulation,pcm)接口,通用异步收发传输器
(universal asynchronous receiver/transmitter,uart)接口,移动产业处理器接口(mobile industry processor interface,mipi),通用输入输出(general-purpose input/output,gpio)接口,用户标识模块(subscriber identity module,sim)接口,和/或通用串行总线(universal serial bus,usb)接口等。本发明实施例示意的各模块间的接口连接关系,只是示意性说明,并不构成对电子设备10的结构限定。在另一些实施例中,电子设备10也可以采用上述实施例中不同的接口连接方式,或多种接口连接方式的组合。
[0340]
电子设备10的无线通信功能可以通过天线1,天线2,移动通信模块150,无线通信模块160,调制解调处理器以及基带处理器等实现。
[0341]
无线通信模块160可以提供应用在电子设备10上的包括无线局域网(wireless local area networks,wlan)(如无线保真(wireless fidelity,wi-fi)网络),蓝牙(bluetooth,bt),全球导航卫星系统(global navigation satellite system,gnss),调频(frequency modulation,fm),近距离无线通信技术(near field communication,nfc),红外技术(infrared,ir)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波,将电磁波信号调频以及滤波处理,将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号,对其进行调频,放大,经天线2转为电磁波辐射出去。示例性地,无线通信模块160可以包括蓝牙模块、wi-fi模块等。
[0342]
在一些实施例中,电子设备10的天线1和移动通信模块150耦合,天线2和无线通信模块160耦合,使得电子设备10可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications,gsm),通用分组无线服务(general packet radio service,gprs),码分多址接入(code division multiple access,cdma),宽带码分多址(wideband code division multiple access,wcdma),时分码分多址(time-division code division multiple access,td-scdma),长期演进(long term evolution,lte),bt,gnss,wlan,nfc,fm,和/或ir技术等。所述gnss可以包括全球卫星定位系统(global positioning system,gps),全球导航卫星系统(global navigation satellite system,glonass),北斗卫星导航系统(beidou navigation satellite system,bds),准天顶卫星系统(quasi-zenith satellite system,qzss)和/或星基增强系统(satellite based augmentation systems,sbas)。
[0343]
电子设备10通过gpu,显示屏194,以及应用处理器等可以实现显示功能。gpu为图像处理的微处理器,连接显示屏194和应用处理器。gpu用于执行数学和几何计算,用于图形渲染。处理器110可包括一个或多个gpu,其执行指令以生成或改变显示信息。
[0344]
显示屏194用于显示图像,视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display,lcd),有机发光二极管(organic light-emitting diode,oled),有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的,amoled),柔性发光二极管(flex light-emitting diode,fled),miniled,microled,micro-oled,量子点发光二极管(quantum dot light emitting diodes,qled)等。在一些实施例中,电子设备10可以包括1个或n个显示屏194,n为大于1的正整数。
[0345]
npu为神经网络(neural-network,nn)计算处理器,通过借鉴生物神经网络结构,
例如借鉴人脑神经元之间传递模式,对输入信息快速处理,还可以不断的自学习。通过npu可以实现电子设备10的智能认知等应用,例如:图像识别,人脸识别,语音识别,文本理解等。
[0346]
外部存储器接口120可以用于连接外部存储卡,例如micro sd卡,实现扩展电子设备10的存储能力。外部存储卡通过外部存储器接口120与处理器110通信,实现数据存储功能。例如将音乐、照片、视频等数据保存在外部存储卡中。
[0347]
内部存储器121可以用于存储一个或多个计算机程序,该一个或多个计算机程序包括指令。处理器110可以通过运行存储在内部存储器121的上述指令,从而使得电子设备10执行本技术一些实施例中所提供的数据分享的方法,以及各种功能应用以及数据处理等。内部存储器121可以包括存储程序区和存储数据区。其中,存储程序区可存储操作系统;该存储程序区还可以存储一个或多个应用程序(比如图库、联系人等)等。存储数据区可存储电子设备10使用过程中所创建的数据(比如照片,联系人等)。此外,内部存储器121可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件,闪存器件,通用闪存存储器(universal flash storage,ufs)等。
[0348]
电子设备10可以通过音频模块170,扬声器170a,受话器170b,麦克风170c,耳机接口170d,以及应用处理器等实现音频功能。例如音乐播放,录音等。
[0349]
音频模块170用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中,音频模块170可以设置于处理器110中,或将音频模块170的部分功能模块设置于处理器110中。
[0350]
扬声器170a,也称“喇叭”,用于将音频电信号转换为声音信号。电子设备10可以通过扬声器170a收听音乐,或收听免提通话。
[0351]
受话器170b,也称“听筒”,用于将音频电信号转换成声音信号。当电子设备10接听电话或语音信息时,可以通过将受话器170b靠近人耳接听语音。
[0352]
麦克风170c,也称“话筒”,“传声器”,用于将声音信号转换为电信号。当拨打电话或发送语音信息时,用户可以通过人嘴靠近麦克风170c发声,将声音信号输入到麦克风170c。电子设备10可以设置至少一个麦克风170c。在另一些实施例中,电子设备10可以设置两个麦克风170c,除了采集声音信号,还可以实现降噪功能。在另一些实施例中,电子设备10还可以设置三个,四个或更多麦克风170c,实现采集声音信号,降噪,还可以识别声音来源,实现定向录音功能等。
[0353]
耳机接口170d用于连接有线耳机。耳机接口170d可以是usb接口130,也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform,omtp)标准接口,美国蜂窝电信工业协会(cellular telecommunications industry association of the usa,ctia)标准接口。
[0354]
按键190包括开机键,音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备10可以接收按键输入,产生与电子设备10的用户设置以及功能控制有关的键信号输入。马达191可以产生振动提示。马达191可以用于来电振动提示,也可以用于触摸振动反馈。指示器192可以是指示灯,可以用于指示充电状态,电量变化,也可以用于指示消息,未接来电,通知等。sim卡接口195用于连接sim卡。sim卡可以通过插入sim卡接口195,或从sim
卡接口195拔出,实现和电子设备10的接触和分离。电子设备10可以支持1个或n个sim卡接口,n为大于1的正整数。sim卡接口195可以支持nano sim卡,micro sim卡,sim卡等。在一些实施例中,电子设备10采用esim,即:嵌入式sim卡。esim卡可以嵌在电子设备10中,不能和电子设备10分离。
[0355]
图10示例性所示的电子设备10可以通过显示屏194显示以下各个实施例中所描述的各个用户界面。电子设备10可以通过触摸传感器180k在各个用户界面中检测触控操作,例如在各个用户界面中的点击操作(如在图标上的触摸操作、双击操作),又例如在各个用户界面中的向上或向下的滑动操作,或执行画圆圈手势的操作,等等。在一些实施例中,电子设备10可以通过陀螺仪传感器180b、加速度传感器180e等检测用户手持电子设备10执行的运动手势,例如晃动电子设备。在一些实施例中,电子设备10可以通过摄像头193(如3d摄像头、深度摄像头)检测非触控的手势操作。
[0356]
在一些实施中,电子设备10中包括的终端应用处理器(ap)可以实现蓝牙协议框架中的host,电子设备10中包括的蓝牙(bt)模块可以实现蓝牙协议框架中的controller,二者之间通过hci进行通信。即把蓝牙协议框架的功能分布在两颗芯片上。
[0357]
在另一些实施例中,电子设备10终端应用处理器(ap)可以实现蓝牙协议框架中的host和controller。即蓝牙协议框架的所有功能都放在一颗芯片上,也就是说,host和controller都放在同一颗芯片上,由于host和controller都在同一颗芯片上,因此物理hci就没有存在的必要性,host和controller之间直接通过应用编程接口api来交互。
[0358]
下面介绍本技术实施例中提供的示例性音频接收方设备300。音频接收方设备300可以实现为上述实施例中提及的从设备,如蓝牙耳机,可以是图1a所示的无线音频系统100中的音频输出设备106或图2a所示的无线音频系统200中的音频输出设备202或音频输出设备203。音频接收方设备300(audio sink),如耳机、音箱,可以向其他音频源(audio source),如手机、平板电脑等,传输的音频数据,并可以将接收到的音频数据转换成声音。在一些场景下,如果配置有麦克风/受话器等声音采集器件,音频接收方设备300也可以用作音频源(audio source),向其他设备音频接收方(audio sink)(如手机)传输音频数据(如耳机采集的用户说话的声音所转换成的音频数据)。
[0359]
音频接收方设备300可以是一对蓝牙耳机,包括左耳机和右耳机。该蓝牙耳机可以是颈戴式蓝牙耳机,也可以是tws蓝牙耳机。
[0360]
图11示例性示出了本技术技术方案提供的音频接收方设备300的结构示意图。
[0361]
如图11所示,音频接收方设备300可包括处理器302、存储器303、蓝牙通信处理模块304、电源305、传感器306、麦克风307和电/声转换器308。这些部件可以通过总线连接。如果音频接收方设备300是颈戴式蓝牙耳机,则音频接收方设备300还可包括线控。处理器302、存储器303、蓝牙通信处理模块304、电源305可集成在线控中。如果音频接收方设备300是tws蓝牙耳机,则两个耳机还都可集成有处理器302、存储器303、蓝牙通信处理模块304、电源305。
[0362]
处理器302可用于读取和执行计算机可读指令。具体实现中,处理器302可主要包括控制器、运算器和寄存器。其中,控制器主要负责指令译码,并为指令对应的操作发出控制信号。运算器主要负责执行定点或浮点算数运算操作、移位操作以及逻辑操作等,也可以执行地址运算和转换。寄存器主要负责保存指令执行过程中临时存放的寄存器操作数和中
间操作结果等。具体实现中,处理器302的硬件架构可以是专用集成电路(application specific integrated circuits,asic)架构、mips架构、arm架构或者np架构等等。
[0363]
在一些实施例中,处理器302可以用于解析蓝牙通信处理模块304接收到的信号,如封装有音频数据的信号、内容控制消息,流控制消息等等。处理器302可以用于根据解析结果进行相应的处理操作,如驱动电/声转换器308开始或暂停或停止将音频数据转换成声音等等。
[0364]
在一些实施例中,处理器302还可以用于生成蓝牙通信处理模块304向外发送的信号,如蓝牙广播信号、信标信号,又如采集到的声音所转换成的音频数据。
[0365]
存储器303与处理器302耦合,用于存储各种软件程序和/或多组指令。具体实现中,存储器303可包括高速随机存取的存储器,并且也可包括非易失性存储器,例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器303可以存储操作系统,例如ucos、vxworks、rtlinux等嵌入式操作系统。存储器303还可以存储通信程序,该通信程序可用于与电子设备10,一个或多个服务器,或附加设备进行通信。
[0366]
蓝牙(bt)通信处理模块304可以接收其他设备(如电子设备10)发射的信号,如扫描信号、广播信号、封装有音频数据的信号、内容控制消息、流控制消息等等。蓝牙(bt)通信处理模块304也可以发射信号,如广播信号、扫描信号、封装有音频数据的信号、内容控制消息、流控制消息等等。
[0367]
电源305可用于向处理器302、存储器303、蓝牙通信处理模块304、传感器306、电/声转换器308等其他内部部件供电。
[0368]
传感器306可以包括例如红外传感器、压力传感器、霍尔传感器、接近光传感器,等等。其中,红外传感器、压力传感器可用于检测耳机的佩戴状态。霍尔传感器、接近光传感器可用于检测左右耳机是否吸合在一起。
[0369]
麦克风307可用于采集声音,如用户说话的声音,并可以将采集到声音输出给电/声转换器308,这样电/声转换器308便可以将麦克风307采集到的声音转换成音频数据。
[0370]
电/声转换器308可用于将声音转换成电信号(音频数据),例如将麦克风307采集到的声音转换成音频数据,并可以传输音频数据至处理器302。这样,处理器302便可以触发蓝牙(bt)通信处理模块304发射该音频数据。电/声转换器308还可用于将电信号(音频数据)转换成声音,例如将处理器302输出的音频数据转换成声音。处理器302输出的音频数据可以是蓝牙(bt)通信处理模块304接收到的。
[0371]
在一些实施中,处理器302可以实现蓝牙协议框架中的host,蓝牙(bt)通信处理模块304可以实现蓝牙协议框架中的controller,二者之间通过hci进行通信。即把蓝牙协议框架的功能分布在两颗芯片上。
[0372]
在另一些实施例中,处理器302可以实现蓝牙协议框架中的host和controller。即蓝牙协议框架的所有功能都放在一颗芯片上,也就是说,host和controller都放在同一颗芯片上,由于host和controller都在同一颗芯片上,因此物理hci就没有存在的必要性,host和controller之间直接通过应用编程接口api来交互。
[0373]
可以理解的是,图11示意的结构并不构成对音频接收方设备300的具体限定。在本技术另一些实施例中,音频接收方设备300可以包括比图示更多或更少的部件,或者组合某些部件,或者拆分某些部件,或者不同的部件布置。图示的部件可以以硬件,软件或软件和
硬件的组合实现。
[0374]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,该流程可以由计算机程序来指令相关的硬件完成,该程序可存储于计算机可读取存储介质中,该程序在执行时,可包括如上述各方法实施例的流程。而前述的存储介质包括:rom或随机存储记忆体ram、磁碟或者光盘等各种可存储程序代码的介质。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1