CN117858057A - 播放蓝牙音频的方法、控制音频播放的方法和系统 - Google Patents

播放蓝牙音频的方法、控制音频播放的方法和系统 Download PDF

Info

Publication number
CN117858057A
CN117858057A CN202410142417.5A CN202410142417A CN117858057A CN 117858057 A CN117858057 A CN 117858057A CN 202410142417 A CN202410142417 A CN 202410142417A CN 117858057 A CN117858057 A CN 117858057A
Authority
CN
China
Prior art keywords
audio
bluetooth
application
focus
audio focus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202410142417.5A
Other languages
English (en)
Inventor
黄勤波
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hubei Xingji Meizu Group Co ltd
Original Assignee
Hubei Xingji Meizu Group Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hubei Xingji Meizu Group Co ltd filed Critical Hubei Xingji Meizu Group Co ltd
Priority to CN202410142417.5A priority Critical patent/CN117858057A/zh
Publication of CN117858057A publication Critical patent/CN117858057A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/16Discovering, processing access restriction or access information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephone Function (AREA)

Abstract

本公开涉及播放蓝牙音频的方法、控制音频播放的方法和系统等。一种在第一设备中播放蓝牙音频的方法包括:从第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备。利用本公开的方法,能够准确地控制音频的播放,提高用户体验。

Description

播放蓝牙音频的方法、控制音频播放的方法和系统
技术领域
本公开涉及蓝牙音频切换领域,特别涉及播放蓝牙音频的方法、控制音频播放的方法、系统、计算机程序产品和存储介质等。
背景技术
目前,随着技术的成熟和产品的迭代,越来越多的人们会在日常使用智能眼镜(如AR眼镜),尤其是通过智能眼镜来听歌、看电影、玩游戏等媒体观看及交互,然后由于智能眼镜设备性能和硬件的限制,音视频内容没有手机等设备丰富,这就需要大量将音频从手机流转到智能眼镜,比如进行导航、音乐播放、视频投屏等,这样用户可以将穿戴方便和丰富的音视频结合起来,有了大量的音视频视听场景。
发明内容
本公开实施例提供了播放蓝牙音频的方法、控制音频播放的方法以及相应的执行这些方法的电子设备、系统、计算机程序产品和非暂时性机器可读存储介质等。
根据本公开实施例的第一个方面,提供了一种在第一设备中播放蓝牙音频的方法,包括:从第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备。
可选地,响应于所述蓝牙应用丢失所述第一音频焦点,包括:在所述蓝牙应用持有所述第一音频焦点期间,响应于所述第一设备的非蓝牙应用抢占所述第一音频焦点,所述蓝牙应用丢失所述第一音频焦点。
可选地,所述方法还包括:响应于所述非蓝牙应用释放所述第一音频焦点,所述蓝牙应用恢复获取所述第一音频焦点;将所述蓝牙应用对所述第一音频焦点的恢复信息发送给所述第二设备。
可选地,所述方法还包括:监听所述第一设备中的音频焦点管理器上报的音频焦点切换信息,获得所述蓝牙应用对所述第一音频焦点的恢复信息或丢失信息。
可选地,所述音频焦点切换信息是利用所述第一设备的桌面应用在所述音频焦点管理器注册监视器来监听的。
可选地,所述第一设备通过A2DP连接接收所述第二设备发送的所述蓝牙音频;并且/或者所述第一设备通过低功耗蓝牙或者WiFi将所述恢复信息或所述丢失信息发送给所述第二设备。
可选地,所述第一设备通过AVRCP连接将所述丢失信息发送给所述第二设备,并且所述第一设备通过非AVRCP连接将所述恢复信息发送给所述第二设备。
可选地,所述方法还包括:响应于所述蓝牙应用终止播放所述蓝牙音频,所述蓝牙应用释放所述第一音频焦点。
根据本公开实施例的第二个方面,提供了一种在第二设备中控制音频播放的方法,包括:向第一设备发送蓝牙音频;接收所述第一设备发送的丢失信息,其中,所述丢失信息表示所述第一设备的蓝牙应用丢失所述第一设备的第一音频焦点;以及根据所述丢失信息控制所述第二设备的非音频应用申请所述第二设备的第二音频焦点。
可选地,所述方法还包括:从接收所述第一设备发送的蓝牙应用对所述第一音频焦点的恢复信息;根据所述恢复信息来控制所述非音频应用释放所述第二音频焦点。
可选地,所述非音频应用为所述第二设备中的安装应用或者所述第二设备的系统应用。
可选地,所述第二设备通过A2DP连接向所述第一设备发送所述蓝牙音频;并且/或者所述第二设备通过低功耗蓝牙或者WiFi接收所述第一设备发送的所述恢复信息或所述丢失信息。
可选地,所述第二设备通过AVRCP连接接收所述第一设备发送的所述丢失信息,并且所述第二设备通过非AVRCP连接接收所述第一设备发送的所述恢复信息。
可选地,所述第二设备的一个或多个音频应用在所述第二设备的媒体会话框架注册事件回调。
根据本公开实施例的第三个方面,提供了一种第一设备,包括:第一通信单元,至少用于与第二设备进行蓝牙通信;处理器;以及存储器,其上存储有可执行代码,当所述可执行代码被所述处理器执行时,使所述处理器执行如上述第一个方面中的任一方案所述的方法。
根据本公开实施例的第四个方面,提供了一种第二设备,包括:第二通信单元,至少用于与如上述第三个方面中的任一方案所述的第一设备进行蓝牙通信;处理器;以及存储器,其上存储有可执行代码,当所述可执行代码被所述处理器执行时,使所述处理器执行如上述第二个方面中的任一方案所述的方法。
根据本公开实施例的第五个方面,提供了一种蓝牙音频播放系统,包括:
第一设备和第二设备,其中所述第一设备包括:第一通信单元,至少用于与所述第二设备进行蓝牙通信;所述第一设备被配置为:从所述第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备;
其中所述第二设备包括:第二通信单元,至少用于与所述第一设备进行蓝牙通信;所述第二设备被配置为:向所述第一设备发送蓝牙音频;接收所述第一设备发送的丢失信息,其中,所述丢失信息表示所述第一设备的蓝牙应用丢失所述第一设备的第一音频焦点;以及根据所述丢失信息控制所述第二设备的非音频应用申请所述第二设备的第二音频焦点。
可选地,所述第一设备还被配置为:在所述蓝牙应用持有所述第一音频焦点期间,响应于所述第一设备的非蓝牙应用抢占所述第一音频焦点,所述蓝牙应用丢失所述第一音频焦点。
可选地,所述第一设备还被配置为:响应于所述非蓝牙应用释放所述第一音频焦点,所述蓝牙应用恢复获取所述第一音频焦点;将所述蓝牙应用对所述第一音频焦点的恢复信息发送给所述第二设备;
所述第二设备还被配置为:接收所述第一设备发送的蓝牙应用对所述第一音频焦点的恢复信息;根据所述恢复信息来控制所述非音频应用释放所述第二音频焦点。
根据本公开实施例的第六个方面,提供了一种非暂时性机器可读存储介质,其上存储有可执行代码,当可执行代码被电子设备的处理器执行时,使处理器执行如上述第一个方面或第二个方面中的任一方案所述的方法。
根据本公开实施例的第七个方面,提供了一种计算机程序产品,包括可执行代码,当所述可执行代码被电子设备的处理器执行时,使所述处理器执行如上述第一个方面或第二个方面中的任一方案所述的方法。
附图说明
通过结合附图对本公开示例性实施方式进行更详细的描述,本公开的上述以及其它目的、特征和优势将变得更加明显,其中,在本公开示例性实施方式中,相同的参考标号通常代表相同部件。
图1示例性地示出了根据本公开至少一个实施例的手机的结构示意图。
图2示例性地示出了根据本公开至少一个实施例的包括第一设备和第二设备的音频播放系统的结构示意图。
图3示例性地示出了根据本公开至少一个实施例的在第一设备中播放蓝牙音频的方法的示意性流程图。
图4示例性地示出了根据本公开至少一个实施例的在第二设备中控制音频播放的方法的示意性流程图。
图5示例性地示出了根据本公开至少一个实施例提供的音频播放方法的示意性时序图。
图6示例性地示出了根据本公开至少一个实施例的在第一设备和第二设备之间流转蓝牙音频的方法的示意性流程图。
图7示例性地示出了根据本公开至少一个实施例的计算设备的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
在一些情况下,在将音频从手机流转到例如智能眼镜或者车载终端(例如车机),例如进行导航音频播放、音乐播放、视频投屏等的情况下,受限于所采用的通信协议(比如蓝牙A2DP及AVRCP等),会造成一些不好的用户体验。
应理解,上述的A2DP全称是高质量音频分发协议(Advanced Audio DistributionProfile),其定义了传送单声道或立体声等高质量音频(区别于蓝牙SCO链路上传输的普通语音)信息的协议和过程。A2DP的典型应用是将音乐播放器的音频数据发送到智能眼镜、耳机、音箱或其他设备(例如车载设备)等。
AVRCP全称是音视频远程控制协议(Audio Video Remote Control Protocol),用于远程控制音视频设备,在蓝牙通信中,主要用于蓝牙音频的控制,比如播放/暂停/下一曲/上一曲、以及获取播放状态等。AVRCP将相关设备分为控制设备Controller(CT)(本文中描述为第一设备)、和目标设备Target(TG)(本文中描述为第二设备)。CT是负责发送命令帧到目标设备发起传输的设备,通常情形下例如可以是智能眼镜、蓝牙耳机、蓝牙音箱、车载设备(例如车机)等;TG是负责接收命令并按命令响应的设备,通常情形下例如可以是PC、平板电脑、手机等。
例如,在车载设备(例如车机)播放手机列表中的歌曲的场景下,当用户点击车载设备上的下一曲时,车载设备会向手机请求播放列表中下一曲,此时车载设备为CT角色,手机为TG角色。
再例如,在智能眼镜或者蓝牙耳机播放手机歌单中歌曲的场景下,智能眼镜或者蓝牙耳机会向手机订阅通知(notification),以获取手机中歌曲播放状态;当用户在手机上点击播放下一曲时,智能眼镜或者蓝牙耳机基于通知获取这一状态变化,并请求手机向智能眼镜或者蓝牙耳机发送下一曲的相关信息(音频数据、歌曲信息等),使智能眼镜或者蓝牙耳机也切换至下一曲。此时,智能眼镜或者蓝牙耳机为CT角色,手机为TG角色
具体而言,目前的安卓(android)设备安装的系统音乐应用或者三方音乐应用,都可以在系统的媒体会话框架注册事件回调,从而实现响应和安卓设备蓝牙互联的例如智能眼镜端的AVRCP的控制(例如暂停/继续播放)。而由于用户的操作及应用自身的切换,经常会导致MediaSession的回调对象频繁切换,从而导致手机侧音乐类应用会异常播放,引起不好的用户体验。
MediaSession框架是安卓系统引入的一个媒体会话框架,用来解决音乐界面和服务之间的通信问题。通常在安卓设备中需要蓝牙控制或其它客户端远程控制暂停/播放/上一首/下一首的一些音乐类应用可以注册到该媒体会话框架,而作为类似短音频、语音播放、导航音频这类音频的来源的应用不会注册到该媒体会话框架。
然而在实际使用场景中,除了投送音乐播放之外,安卓设备例如手机经常也会把类似导航音频这类音频投送到智能眼镜或者车载终端上播放,在这些音频播放的来回切换中可能导致手机侧音乐类应用异常播放,引起不好的用户体验。
下面以一个蓝牙互联的手机与智能眼镜的典型场景为例来说明该异常播放情况:
首先,手机系统自带的一个音乐应用在手机开机时即后台启动并注册了MediaSession的事件回调。
然后,手机与智能眼镜建立异步链路(Asynchronous Connection-orientedLink,ACL)连接之后,需依次和智能眼镜建立应用协议(Profile)连接,例如A2DP连接、AVRCP连接、免提规格(Hands-FreeProfile,HFP)连接等。其中,手机与智能眼镜建立A2DP连接后便可配合智能眼镜实现媒体业务的传输,手机与智能眼镜建立AVRCP连接后便可配合智能眼镜实现遥控指令的传输,手机与智能眼镜建立HFP连接后便可配合智能实现通话业务的传输。
应当说明的是,本公开也不限定手机和智能眼镜之间是否建立HFP连接,而只需要限定手机和智能眼镜之间建立传输音频资源的连接例如A2DP连接,以及在手机和智能眼镜之间建立传输遥控指令的连接例如AVRCP连接。
在手机与智能眼镜蓝牙互联期间,手机上要播放的音频都默认用蓝牙投送到智能眼镜端进行播放。
如果在手机侧使用导航语音播报,则手机将导航音频用蓝牙A2DP传输到眼镜侧播放,此时在眼镜侧用于播放A2DP音频(即流转自手机侧的导航音频)的应用申请并持有音频焦点。音频焦点表示应用对设备音频资源的控制权,一次只能有一个应用获得音频焦点,当一个应用需要播放音频时,它需要申请获得音频焦点,获得焦点后才可以播放声音。
在眼镜侧播放导航音频期间,眼镜侧使用语音助手,而语音助手也需要播放声音,因此语音助手申请了临时音频焦点,这导致眼镜侧播放A2DP音频(流转自手机侧的导航音频)的应用临时失去音频焦点,然后相应地眼镜侧蓝牙通过AVRCP发送暂停指令到手机侧的MediaSession。语音助手使用结束后,语音助手释放眼镜侧的音频焦点,因此眼镜侧播放A2DP音频的应用重新拿到音频焦点,相应地眼镜侧蓝牙又通过AVRCP发送播放指令到手机侧的MediaSession。
因为在手机侧导航应用没有注册MediaSession,而手机系统自带的音乐应用提前注册了MediaSession事件回调,所以前述通过AVRCP发回的暂停指令和播放指令对导航应用不起作用(虽然导航音频在手机侧未暂停,但是在眼镜侧其由于丢失了焦点而变成了静音音频,不会影响语音助手的音频播放),而是可能对手机系统自带的音乐应用起作用,从而使得该音乐应用被AVRCP的播放指令触发音乐播放,出现非预期的自动音频播放。
鉴于此,本公开提出了一种在第一设备中播放蓝牙音频的方法以及相应的在第二设备中控制音频播放的方法,其能够准确地控制音频的播放,提高用户体验。在一些实施例中,本公开的方法可以有效避免因第一设备中的本地音频与蓝牙音频切换播放而误触发第二设备侧音乐应用的播放,提高音视频视听及操作体验。
在本公开中,所谓的“第一设备”指的是蓝牙音频从属设备,其能通过蓝牙方式从第二设备接收音频并进行播放,所谓的“第二设备”指的是蓝牙音频输出主设备,其能通过蓝牙方式将音频发送给第一设备播放,而所谓的“蓝牙音频”指的就是通过蓝牙连接方式从第二设备传输给第一设备的音频。在一些情况下,第一设备和第二设备也可被分别称为蓝牙音频信宿(sink)和信源(source)。应理解,在本公开中,表述“第一”和“第二”是用于区别类似的对象的,而非用于描述特定的顺序或先后次序,不存在额外的限定作用。
本公开实施例可以应用于各种类型的第一设备和第二设备,只要这些设备中具有蓝牙通信单元,能与其他设备进行蓝牙通信即可。例如,第一设备可以为与其他设备蓝牙互联的智能穿戴设备、或者车载设备等。例如,第二设备可以为与第一设备建立通信连接的计算设备或电子设备,包括但不限于手机、个人数字助理(personal digital assistant,PDA)等)、各种类型的计算机(比如平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer,UMPC)、上网本、膝上型计算机等)等。
作为示例而非限定,当所述第一设备为可穿戴设备时,该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称,如配置有蓝牙通信模块的手套、手表、智能眼镜、或者AR((Augmented Reality,增强现实)头戴显示设备、VR(Virtual Reality,虚拟现实)头戴显示设备或MR(Mixed Reality,混合现实)头戴显示设备等。应理解,智能眼镜可以包括XR(Extended Reality,扩展现实)眼镜等,而XR眼镜又可以包括AR眼镜、VR眼镜、MR眼镜等。
在一些实施例中,上述第二设备可以是具备如图1所示的示例性硬件结构的示例性的手机100,如图1所示,手机100具体可以包括:射频(Radio Frequency,RF)电路110、存储器120、输入单元130、显示单元140、传感器150、音频电路160、短距离无线通信模块170、处理器180、以及电源190等部件。本领域技术人员可以理解,图1中示出的手机100的结构并不构成对电子设备的限定,电子设备可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图1对手机100的各个构成部件进行具体的介绍:
RF电路110可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器180处理;另外,将设计上行的数据发送给基站。通常,RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(LowNoiseAmplifier,LNA)、双工器等。此外,RF电路110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议,所述无线通信可以包括全球移动通讯系统(Global System For Mobile Communications,GSM),通用分组无线服务(GeneralPacket Radio Service,GPRS),码分多址接入(Code DivisionMultiple Access,CDMA),宽带码分多址(Wideband Code Division Multiple Access,WCDMA),时分码分多址(Time-Division Code Division Multiple Access,TD-SCDMA),长期演进(Long TermEvolution,LTE),新无线(New Radio,NR),GNSS,FM,低轨卫星连接和/或IR技术等。所述GNSS可以包括全球卫星定位系统(Global Positioning System,GPS),全球导航卫星系统(Global Navigation Satellite System,GLONASS),北斗卫星导航系统(BeiDouNavigation Satellite System,BDS),准天顶卫星系统(Quasi-Zenithsatellite System,QZSS)和/或星基增强系统(Satellite Based Augmentation Systems,SBAS)等。
存储器120可用于存储软件程序以及模块,处理器180通过运行存储在存储器120的软件程序以及模块,从而执行手机的各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如图片、音频数据、电话本等)等。此外,存储器120可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
输入单元130可用于接收输入的数字或字符信息,以及产生与手机100的用户设置以及功能控制有关的键信号输入。具体地,输入单元130可包括触控面板131以及其他输入设备132。触控面板131,也称为触摸屏,可收集用户在其上或附近的触摸操作(比如用户使用手指(例如单指或多指)、触笔等任何适合的物体或附件在触控面板131上或在触控面板131附近的操作),并根据预先设定的程式驱动相应的连接装置。可选的,触控面板131可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成触点坐标,再送给处理器180,并能接收处理器180发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板131。除了触控面板131,输入单元130还可以包括其他输入设备132。具体地,其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元140可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元140可包括显示面板141,可选的,可以采用液晶显示器(LiquidCrystalDisplay,LCD)、发光二极管(Light Emitting Diode,LED)、有机发光二极管(Organic Light-Emitting Diode,OLED)、有源矩阵有机发光二极管(Active-MatrixOrganic Light Emitting Diode,AMOLED)等形式来配置显示面板141。进一步的,触控面板131可覆盖显示面板141,当触控面板131检测到在其上或附近的触摸操作后,传送给处理器180以确定触摸事件的类型,随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图1中,触控面板131与显示面板141是作为两个独立的部件来实现手机的输入和输入功能,但是在某些实施例中,可以将触控面板131与显示面板141集成而实现手机的输入和输出功能。例如,在显示面板141上可以显示手机100的主界面,主界面上可以包括手机100预安装的应用的图标(例如相机的图标、电话的图标、短信的图标等),还可以包括用户下载的第三方应用的图标,例如娱乐、社交、支付应用等。
手机100还可包括至少一种传感器150,比如光传感器、运动传感器以及其他传感器。具体地,光传感器可包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板141的亮度,接近传感器可在手机移动到耳边时,关闭显示面板141和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等;至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器,在此不再赘述。
音频电路160、扬声器161,传声器162可提供用户与手机之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号,传输到扬声器161,由扬声器161转换为声音信号输出;另一方面,传声器162将收集的声音信号转换为电信号,由音频电路160接收后转换为音频数据,再将音频数据输出处理器180处理后,经RF电路110以发送给比如另一电子设备,或者将音频数据输出至存储器120以便进一步处理。
Wi-Fi、蓝牙、近距离无线通信(Near Field Communication,NFC)以及超宽带(Ultra Wide Band,UWB)等通信技术属于短距离无线传输技术,手机通过短距离无线模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等,它为用户提供了无线的宽带互联网访问。上述短距离无线模块170可以包括Wi-Fi芯片、蓝牙芯片、NFC芯片以及UWB芯片,通过该Wi-Fi芯片可以实现手机100与其他电子设备进行Wi-Fi Direct连接的功能,也可以使手机100工作在能够提供无线接入服务,允许其它无线设备接入的AP模式(AccessPoint模式)或工作在可以连接到AP不接受无线设备接入的STA模式(Station模式),从而建立手机100与其他Wi-Fi设备的点对点通信。可选地,该短距离无线模块170可以包括蓝牙芯片,利用该蓝牙芯片将手机上的音频和/或视频数据传输到各种智能穿戴设备或车载设备等进行播放。
处理器180是手机的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器120内的软件程序和/或模块,以及调用存储在存储器120内的数据,执行手机的各种功能和处理数据,从而对手机进行整体监控。可选的,处理器180可包括一个或多个处理单元;可选地,处理器180例如可以包括应用处理器(ApplicationProcessor,AP),调制解调处理器,图形处理器(Graphics ProcessingUnit,GPU),图像信号处理器(Image Signal Processor,ISP),控制器,视频编解码器,数字信号处理器(DigitalSignal Processor,DSP),基带处理器,和/或神经网络处理器(Neural-NetworkProcessing Unit,NPU)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
手机100还包括给各个部件供电的电源190(比如电池),优选的,电源可以通过电源管理系统与处理器180逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
图2示例性地示出了根据本公开至少一个实施例的包括第一设备和第二设备的音频播放系统的结构示意图。
图3示例性地示出了根据本公开至少一个实施例的在第一设备中播放蓝牙音频的方法的示意性流程图。
图4示例性地示出了根据本公开至少一个实施例的在第二设备中控制音频播放的方法的示意性流程图。
下面结合图2的结构与图3和图4的流程图来详细讨论根据本公开至少一个实施例的整体方案。
在本公开的一些实施例中,提出了一种音频播放系统,其包括第一设备和第二设备,
其中所述第一设备包括:
第一通信单元,至少用于与所述第二设备进行蓝牙通信;
所述第一设备被配置为:
从所述第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;
响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备;
其中所述第二设备包括:
第二通信单元,至少用于与所述第一设备进行蓝牙通信;
所述第二设备被配置为:
向所述第一设备发送蓝牙音频;
接收所述第一设备发送的丢失信息,其中,所述丢失信息表示所述第一设备的蓝牙应用丢失所述第一设备的第一音频焦点;以及
根据所述丢失信息控制所述第二设备的非音频应用申请所述第二设备的第二音频焦点。
在一些实施例中,所述第一设备还被配置为:
在所述蓝牙应用持有所述第一音频焦点期间,响应于所述第一设备的非蓝牙应用抢占所述第一音频焦点,所述蓝牙应用丢失所述第一音频焦点。
在一些实施例中,所述第一设备还被配置为:
响应于所述非蓝牙应用释放所述第一音频焦点,所述蓝牙应用恢复获取所述第一音频焦点;
将所述蓝牙应用对所述第一音频焦点的恢复信息发送给所述第二设备;
所述第二设备还被配置为:
接收所述第一设备发送的蓝牙应用对所述第一音频焦点的恢复信息;
根据所述恢复信息来控制所述非音频应用释放所述第二音频焦点。
如图2所示,第一设备210和第二设备220分别具有用于进行蓝牙互联的第一通信单元211和第二通信单元221。
可以理解,第一通信单元和第二通信单元可以是例如蓝牙通信单元,或者集成了多种通信单元(例如蓝牙通信单元、WiFi通信单元或者蜂窝通信单元)的通信单元,这不成为本公开的限定。
例如,第一通信单元和第二通信单元可以是双(多)模蓝牙单元,即同时支持低功耗蓝牙和经典蓝牙,第一设备和第二设备可以利用例如分时机制来使用两种不同的蓝牙模式进行通信,例如在传输蓝牙音频时使用经典蓝牙进行传输,在传输例如丢失信息/恢复信息或者其它遥控指令时使用低功耗蓝牙进行传输。这使得第一设备和第二设备都只需要一个双(多)模蓝牙芯片就可以实现数据传输和遥控指令采用不同链路进行传输。
应当说明的是,第一设备还可以包括第三通信单元(未示出),第二设备还可以包括第四通信单元(未示出),第三通信单元和第四通信单元可以是WiFi通信单元或者蜂窝通信单元等,第一设备和第二设备之间可以通过WiFi、蜂窝或者其它的通信技术来传输控制信息,以避免使用AVRCP通道传输控制信息导致第二设备的音频应用的异常播放。
在一些示例中,第一设备的蓝牙应用丢失音频焦点时可以通过AVRCP连接发送丢失信息或者暂停指令至第二设备,第一设备的蓝牙应用恢复音频焦点时则通过非AVRCP连接发送恢复信息至第二设备。可以理解,即使第二设备的媒体会话框架接收到AVRCP连接发送的丢失信息或者暂停指令,也不会导致第二设备的音频应用异常播放。
另外,第一设备210还可以包括用于管理第一设备自身的音频焦点(也称为第一音频焦点)的第一音频焦点管理器212、蓝牙应用213和桌面应用214。第二设备220还可以包括用于管理第二设备自身的音频焦点(也称为第二音频焦点)的第二音频焦点管理器222、音频应用223和非音频应用224。
应理解,在本公开中,所谓的“音频应用”指的是任何能输出音频的应用,其不仅包括单独输出音频的应用(比如音乐播放应用等),也可以包括能输出视频、包含音频内容的其他多媒体的应用、或者附带输出音频功能的应用(比如导航应用、语音助手等),等等;所谓的“非音频应用”指的是不能输出音频、或者其他包含音频内容的视频、多媒体等的应用;所谓的“蓝牙应用”指的是运行于第一设备后台的蓝牙进程,蓝牙应用和音频类应用类似会向操作系统申请音频焦点。无论是在第一设备还是第二设备中,这些音频应用、非音频应用等应用的类型不受限制,可以是用户自行安装的应用或者是系统自带/自行安装的应用等。
应当说明的是,第二设备的一个或多个音频应用被预先在第二设备的媒体会话框架注册事件回调,当第二设备的媒体会话框架通过AVRCP连接接收第一设备发送的遥控指令(例如继续播放)时,一个或多个音频应用被事件回调触发继续播放的动作。
第一设备或第二设备中的音频应用在播放音频前要向第一音频焦点管理器或第二音频焦点管理器申请音频焦点,申请到音频焦点后才能发起音频播放;在音频播放期间,如果其它应用申请了音频焦点,则该正在播放的应用会失去音频焦点,此时应该静音或暂停播放音频。
如图2所示,第一设备可以接收第二设备传输的蓝牙音频。相对应的在第一设备中的操作如图3的步骤S310所示,从第二设备获得蓝牙音频,由第一设备中的蓝牙应用申请第一音频焦点并播放该蓝牙音频。
在一些实施方式中,该蓝牙音频是第一设备通过蓝牙A2DP连接从第二设备获得的,并且第一设备是通过非AVRCP连接向第二设备发送的恢复信息或者丢失信息,例如通过低功耗蓝牙或者WiFi。
在另一些实施例中,第一设备是通过非AVRCP连接向第二设备发送的恢复信息,例如通过低功耗蓝牙或者WiFi,并且第一设备是通过AVRCP连接向第二设备发送的丢失信息。
例如,在一些情况下,第二设备中的音频应用可输出音频并通过蓝牙A2DP连接将其传送到第一设备以便其中的蓝牙应用播放,此时第一设备的发声装置(例如扬声器)输出的音频即为蓝牙音频的内容。
在第一设备收到该蓝牙音频之后,蓝牙应用可以根据情况主动停止播放该蓝牙音频,并且相应地释放第一音频焦点。
例如,第一设备不想要再播放蓝牙音频时,蓝牙应用可以释放第一音频焦点;响应于蓝牙应用释放第一音频焦点来终止播放蓝牙音频。
在一些示例中,蓝牙应用被动地丢失第一音频焦点,并且相应地静音播放/停止播放蓝牙音频。
例如,在持有第一音频焦点期间(包括播放或者不播放蓝牙音频)有第一设备中的其他非蓝牙应用(例如音频应用)要播放其他音频时,非蓝牙应用抢占第一音频焦点;响应于第一设备中的非蓝牙应用抢占到第一音频焦点,蓝牙应用临时丢失第一音频焦点。
在其他音频播放结束时,非蓝牙应用释放第一音频焦点;响应于非蓝牙应用释放第一音频焦点,蓝牙应用恢复获取第一音频焦点。
在一些实施方式中,例如上述的各种音频焦点切换事件可以被第一音频焦点管理器记录并作为音频焦点切换信息上报给系统。可以通过监听第一音频焦点管理器上报的音频焦点切换信息,获得蓝牙应用对第一音频焦点的丢失信息或恢复信息。例如,可以利用第一设备中的桌面应用在第一音频焦点管理器注册监视器来监听音频焦点切换信息。在一些示例中,第一音频焦点管理器可以为安卓系统中的AudioManager,桌面应用可以为方法requestAudioFocus()(请求音频焦点)和abandonAudioFocus()(放弃音频焦点)注册监听器“AudioManager.OnAudioFocusChangeListener”。
所获得的蓝牙应用对第一音频焦点的丢失信息可以包括音频焦点临时丢失事件或音频焦点永久丢失事件。
然后,如图2和图3中的步骤S320所示,响应于蓝牙应用丢失第一音频焦点,将蓝牙应用对第一音频焦点的丢失信息发送给第二设备。
可以理解,第二设备在接收到第一设备发送的第一音频焦点的丢失信息后,通过第二设备的非音频应用申请持有到第二设备的第二音频焦点。从而使得第二设备在音乐类应用持有第二音频焦点并播放音频的情况下,第二设备接收到丢失信息后通过非音频应用申请抢占到第二音频焦点,则音乐类应用也会相应的停止/静音播放,实现了代替AVRCP连接的暂停播放功能。
在一些示例中,在蓝牙应用持有第一音频焦点期间,响应于第一设备的非蓝牙应用抢占第一音频焦点,蓝牙应用丢失第一音频焦点。
例如第一设备的语音助手应用或者通话应用(例如通过蜂窝通信实现的通话)等抢占第一音频焦点,使得蓝牙应用在上述应用使用期间丢失第一音频焦点。
接着,响应于非蓝牙应用释放所述第一音频焦点,蓝牙应用恢复获取第一音频焦点;
将蓝牙应用对第一音频焦点的恢复信息发送给第二设备。
可以理解,当抢占第一音频焦点的非蓝牙应用结束后,非蓝牙应用会释放持有的第一音频焦点,此时蓝牙应用恢复获取到第一音频焦点。
在一些示例中,第二设备可以根据恢复信息控制非音频应用释放第二音频焦点。
可以理解,在此种情况下,蓝牙应用恢复持有第一音频焦点后,在第一设备可以继续播放蓝牙音频。第二设备控制前述抢占第二音频焦点的非音频应用释放第二音频焦点,使得前述丢失第二音频焦点的音乐类应用可以重新持有第二音频焦点,在第二设备可以继续播放音频,实现了代替AVRCP连接的继续播放功能。
应当说明的是,对于蓝牙应用丢失持有第一音频焦点前第二设备没有音频类应用持有第二音频的情况,在第二设备的非音频应用申请持有/释放第二音频焦点的动作并不会使得第二设备的音频类应用响应媒体会话框架的事件回调,而触发音频应用的播放。
然后,在图4的步骤S410中第二设备接收第一设备如前述图3中的步骤S320中发送的蓝牙应用对第一音频焦点的丢失信息之后,在步骤S420中,第二设备中的非音频应用根据该丢失信息来申请第二设备的第二音频焦点。
在一些实施方式中,该蓝牙音频是第二设备通过A2DP连接向第一设备发送的,并且第二设备是通过非AVRCP连接接收第一设备发送的恢复信息或者丢失信息,例如通过低功耗蓝牙或者WiFi。
在另一些实施方式中,第二设备是通过非AVRCP连接接收第一设备发送的恢复信息,例如通过低功耗蓝牙或者WiFi,并且第二设备是通过AVRCP连接接收第一设备发送的丢失信息。
另外,在第二设备从第一设备接收到蓝牙应用对第一音频焦点的恢复信息之后,第二设备中的非音频应用可以根据该恢复信息来释放持有的第二音频焦点。
非音频应用可以为第二设备中的安装应用或者第二设备的系统应用。非音频应用可以是已有应用中新增的一个功能模块(通过更新原有应用即可完成安装),或者也可以是新安装的一个独立应用。
由此,通过第二设备侧的非音频应用,与蓝牙应用在第一设备侧的音频焦点的丢失/恢复情况同步地申请/释放第二设备的音频焦点,在第二设备有音频播放的情况下达到控制第二设备侧暂停播放/继续播放的目的,并且第二设备没有音频播放的情况下也避免了原生的MediaSession在AVRCP控制播放状态时导致的误触发音乐播放的问题。这是因为,非音频应用实际上不进行任何音频的输出/播放操作,其申请音频焦点即可使得当前的音频应用丢失音频焦点,从而达到音频暂停的目的,而非音频应用释放音频焦点即可使得之前的音频应用重新拿回音频焦点,从而达到音频继续播放的目的。而在没有音频播放的情况下,即使有在MediaSession注册事件回调的音频应用,丢失/恢复信息也不会触发事件回调。
接着,请参阅附图5所示,其示出了本公开一个示例提供的音频播放方法的示意性时序图。
应当说明的是,如图5所示的第一设备和第二设备之间建立了如本文之前描述的例如A2DP连接用于传输蓝牙音频,并且使用非AVRCP连接例如通过WiFi、低功耗蓝牙、蜂窝、UWB(Ultra Wideband,超宽带)等通信连接传输控制信息例如上报丢失/恢复音频焦点的信息。
第一设备可以是前述的智能眼镜或者车载设备,第二设备可以是手机或者其它终端设备,由第二设备提供蓝牙音频,并在第一设备的发声装置(例如扬声器等)进行播放。
如图5所示,第一阶段:第一设备接收第二设备发送的蓝牙音频并播放。
在步骤S510中,第二设备通过例如A2DP连接向第一设备发送蓝牙音频,在本公开的示例中,蓝牙音频被定义为没有被注册到媒体会话框架的应用所提供的并且通过蓝牙传输的音频,例如短音频、语音播放、导航音频等。
可以理解,此时第二设备提供蓝牙音频的应用并没有申请第二设备的音频焦点,但本公开并不限定此时第二设备的注册到媒体会话框架的应用(例如XX音乐)持有第二设备的音频焦点。
接着,在步骤S520中,第一设备的蓝牙应用申请第一设备的音频焦点以播放接收到的蓝牙音频,可以理解,为了能够向外部(例如佩戴第一设备的用户等)播放接收到的蓝牙音频,蓝牙应用申请并且持有第一设备的音频焦点。
接着,进入第二阶段:第一设备的蓝牙应用丢失第一设备的音频焦点期间,第二设备的非音频应用持续持有第二设备的音频焦点。
在步骤S530中,第一设备的一个非蓝牙应用抢占第一设备的音频焦点,例如第一设备启动语音助手等,这使得蓝牙应用丢失了持有的第一设备的音频焦点,此时蓝牙音频被停止/静音播放。
接着,步骤S540,第一设备向第二设备上报蓝牙应用丢失音频焦点的信息。
接着,步骤S550,第二设备接收到蓝牙应用丢失音频焦点的信息后,第二设备的非音频应用申请持有第二设备的音频焦点。
可以理解,在第二设备的一个音乐应用持有音频焦点并播放音频的情况下,第二设备接收到丢失信息后通过非音频应用申请抢占音频焦点,则音乐类应用也会相应的停止/静音播放,实现了代替AVRCP连接的暂停播放功能。
或者,在第二设备当前没有应用持有音频焦点的情况下,通过非音频应用持有音频焦点也不会使得第二设备的发声设备(例如扬声器等)发出声音。
接着,步骤S560,第一设备的非蓝牙应用例如语音助手结束,非蓝牙应用释放持有的第一设备的音频焦点。
接着,步骤S570,第一设备的蓝牙应用恢复持有第一设备的音频焦点,并且通过第一设备的发声设备(例如扬声器等)继续播放蓝牙音频。
接着,步骤S580,第一设备向第二设备上报蓝牙应用恢复持有第一设备的音频焦点的消息。
可以理解,从第二设备接收到蓝牙应用丢失第一设备的音频焦点的消息开始,第二设备的非音频应用开始持有第二设备的音频焦点,直到第二设备接收到第一设备发送的恢复信息后进入第三阶段。
第三阶段:第二设备的非音频应用释放持有的音频焦点。
步骤S590,第二设备的非音频应用释放持有的音频焦点。
可以理解,在非音频应用持有音频焦点之前存在音乐类应用持有音频焦点的情况下,第二设备接收到恢复信息后非音频应用释放音频焦点,则音乐类应用也会相应恢复持有音频焦点并继续播放,实现了代替AVRCP连接的继续播放功能。
或者,在非音频应用持有音频焦点之前不存在音乐类应用持有音频焦点的情况下,非音频应用通过非AVRCP连接接收到恢复信息,也不会使得第二设备后台运行的例如音乐类应用通过事件回调触发播放。
下面将继续以第一设备为智能眼镜、第二设备为手机为例结合图6更详细地描述本公开的一个示例性方法。应理解,图6中的各步骤或操作等仅仅是示例性的而非限制性的,并不意图限制本公开的范围。图6中的各步骤或操作的细节或可替代方式等可以参照前面结合图1到图5所描述的内容,在此不再赘述。稍后描述的图6中的各种细节也可以与前面结合图1到图5描述的各个实施例或示例结合使用。
图6示例性地示出了将蓝牙音频从手机传输到智能眼镜播放期间遇到智能眼镜中的第一音频焦点切换的一个示意性过程。
图6中的智能眼镜至少可以采用蓝牙A2DP方式与手机实现互联,相互传输数据。
如图6所示,在步骤S610中,如前所述,目前在手机上安装的某个或某些音乐播放应用在手机开机时自启动并注册MediaSession,方便通过蓝牙耳机/设备来发起音乐播放。特别是厂商预置的音乐类应用会自动加载,也就是会挂在后台。在这种情况下,如前所述,智能眼镜中的第一音频焦点的切换可能会由于AVRCP连接和MediaSession的配合而引起对该自启动的音乐播放应用的误触发。后续的根据本公开的方法可以代替AVRCP进行在蓝牙A2DP音频丢失/获得音频焦点时给手机侧的暂停/继续播放操作,从而避免误触发手机侧音频播放的可能。
然后,在步骤S620中,用户在手机侧发起音频导航功能或播放其它类似的临时播放的音频。手机侧将该导航音频通过蓝牙A2DP发送到眼镜侧。
然后,在步骤S630中,眼镜侧通过蓝牙A2DP接收到导航音频,并且由蓝牙应用申请眼镜侧的第一音频焦点,从而播报导航音频。
然后,在导航播报期间,如步骤S640所示,用户通过唤醒词或眼镜侧电源键等方式唤醒语音助手。
然后,在步骤S650中,语音助手在眼镜侧申请第一音频焦点并播放语音助手的唤醒词,而眼镜侧蓝牙应用相应地临时丢失第一音频焦点。此时,眼镜侧音频焦点管理器会上报音频焦点切换数据。
然后,在步骤S660中,眼镜侧一桌面应用通过监听音频焦点管理器上报的音频焦点切换数据,得知蓝牙应用丢失第一音频焦点,并且将蓝牙应用丢失音频焦点的事件同步到手机侧。例如,该桌面应用可以通过StarryNet模块将该事件同步到手机侧,其中StarryNet模块包括但不限于通过蓝牙BLE或WiFi P2P等进行连接及数据传输的功能。
然后,在步骤S670中,手机侧的一特定的非音频应用在获得眼镜侧的该蓝牙应用丢失音频焦点的事件后,申请手机的音频焦点(即第二音频焦点)。
然后,在步骤S680中,用户在眼镜侧退出语音助手。
然后,在步骤S690中,语音助手释放眼镜侧的音频焦点,而蓝牙应用重新拿到音频焦点。此时,眼镜侧音频焦点管理器同样会上报音频焦点切换数据。
然后,在步骤S691中,与步骤S660类似,眼镜侧的桌面应用通过监听音频焦点管理器上报的音频焦点切换数据,得知蓝牙应用获取第一音频焦点,并且将蓝牙应用获取音频焦点的事件同步到手机侧。
然后,在步骤S692中,手机侧的前述非音频应用在获得眼镜侧的该蓝牙应用获取音频焦点的事件后,释放手机的音频焦点(即第二音频焦点)。
之后还可以根据实际应用场景发生多次与前述类似的眼镜侧的音频焦点切换事件,手机侧也可以进行类似的同步处理,在此不再赘述。
在前述的步骤中非音频应用在手机侧申请/释放音频焦点的同时,如果手机侧有音乐播放,则该音乐也会因此暂停/继续播放,因此本公开的操作能够替换传统系统中的AVRCP的控制功能。
由此,本公开实施例通过将眼镜侧的蓝牙应用对音频焦点的获取/丢失数据同步到蓝牙互联的手机侧,并且手机侧根据同步过来的获取/丢失数据同步在手机侧让非音频应用释放/申请音频焦点,达到控制手机侧流转到眼镜侧的音频在与眼镜本地音频交替播放时稳定的切换播放/暂停的效果,也避免了安卓原生的MediaSession在AVRCP控制播放状态时导致的误触发音乐播放的问题,从而实现更好的音频播放效果,提升用户体验。
图7示出了根据本公开至少一个实施例的可用于实现上述的播放蓝牙音频的方法或控制音频播放的方法的计算设备的结构示意图。
参见图7,计算设备700包括存储器710和处理器720。
处理器720可以是一个多核的处理器,也可以包含多个处理器。在一些实施例中,处理器720可以包含一个通用的主处理器以及一个或多个特殊的协处理器,例如图形处理器(GPU)、数字信号处理器(DSP)等等。在一些实施例中,处理器720可以使用定制的电路实现,例如特定用途集成电路(ASIC,Application Specific Integrated Circuit)或者现场可编程逻辑门阵列(FPGA,Field Programmable Gate Arrays)。
存储器710可以包括各种类型的存储单元,例如系统内存、只读存储器(ROM),和永久存储装置。其中,ROM可以存储处理器720或者计算机的其他模块需要的静态数据或者指令。永久存储装置可以是可读写的存储装置。永久存储装置可以是即使计算机断电后也不会失去存储的指令和数据的非易失性存储设备。在一些实施方式中,永久性存储装置采用大容量存储装置(例如磁或光盘、闪存)作为永久存储装置。另外一些实施方式中,永久性存储装置可以是可移除的存储设备(例如软盘、光驱)。系统内存可以是可读写存储设备或者易失性可读写存储设备,例如动态随机访问内存。系统内存可以存储一些或者所有处理器在运行时需要的指令和数据。此外,存储器710可以包括任意计算机可读存储媒介的组合,包括各种类型的半导体存储芯片(DRAM,SRAM,SDRAM,闪存,可编程只读存储器),磁盘和/或光盘也可以采用。在一些实施方式中,存储器710可以包括可读和/或写的可移除的存储设备,例如激光唱片(CD)、只读数字多功能光盘(例如DVD-ROM,双层DVD-ROM)、只读蓝光光盘、超密度光盘、闪存卡(例如SD卡、min SD卡、Micro-SD卡等等)、磁性软盘等等。计算机可读存储媒介不包含载波和通过无线或有线传输的瞬间电子信号。
存储器710上存储有可执行代码,当可执行代码被处理器720处理时,可以使处理器720执行上文述及的播放蓝牙音频的方法或控制音频播放的方法。
此外,根据本公开的方法还可以实现为一种计算机程序或计算机程序产品,该计算机程序或计算机程序产品包括用于执行本公开的上述方法中限定的上述各步骤的计算机程序代码指令。
或者,本公开还可以实施为一种非暂时性机器可读存储介质(或计算机可读存储介质、或机器可读存储介质),其上存储有可执行代码(或计算机程序、或计算机指令代码),当所述可执行代码(或计算机程序、或计算机指令代码)被电子设备(或计算设备、服务器等)的处理器执行时,使所述处理器执行根据本公开的上述方法的各个步骤。
本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
附图中的流程图和框图显示了根据本公开的多个实施例的系统和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本公开的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。

Claims (21)

1.一种在第一设备中播放蓝牙音频的方法,包括:
从第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;
响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备。
2.根据权利要求1所述的方法,其中,响应于所述蓝牙应用丢失所述第一音频焦点,包括:
在所述蓝牙应用持有所述第一音频焦点期间,响应于所述第一设备的非蓝牙应用抢占所述第一音频焦点,所述蓝牙应用丢失所述第一音频焦点。
3.根据权利要求2所述的方法,还包括:
响应于所述非蓝牙应用释放所述第一音频焦点,所述蓝牙应用恢复获取所述第一音频焦点;
将所述蓝牙应用对所述第一音频焦点的恢复信息发送给所述第二设备。
4.根据权利要求3所述的方法,还包括:
监听所述第一设备中的音频焦点管理器上报的音频焦点切换信息,获得所述蓝牙应用对所述第一音频焦点的恢复信息或丢失信息。
5.根据权利要求4所述的方法,其中,所述音频焦点切换信息是利用所述第一设备的桌面应用在所述音频焦点管理器注册监视器来监听的。
6.根据权利要求3所述的方法,其中,
所述第一设备通过A2DP连接接收所述第二设备发送的所述蓝牙音频;并且/或者
所述第一设备通过非AVRCP连接将所述恢复信息或所述丢失信息发送给所述第二设备。
7.根据权利要求3所述的方法,其中,所述第一设备通过AVRCP连接将所述丢失信息发送给所述第二设备,并且所述第一设备通过非AVRCP连接将所述恢复信息发送给所述第二设备。
8.根据权利要求1所述的方法,还包括:
响应于所述蓝牙应用终止播放所述蓝牙音频,所述蓝牙应用释放所述第一音频焦点。
9.一种在第二设备中控制音频播放的方法,包括:
向第一设备发送蓝牙音频;
接收所述第一设备发送的丢失信息,其中,所述丢失信息表示所述第一设备的蓝牙应用丢失所述第一设备的第一音频焦点;以及
根据所述丢失信息控制所述第二设备的非音频应用申请所述第二设备的第二音频焦点。
10.根据权利要求9所述的方法,还包括:
接收所述第一设备发送的蓝牙应用对所述第一音频焦点的恢复信息;
根据所述恢复信息来控制所述非音频应用释放所述第二音频焦点。
11.根据权利要求9或10所述的方法,其中,
所述非音频应用为所述第二设备中的安装应用或者所述第二设备的系统应用。
12.根据权利要求10所述的方法,其中,
所述第二设备通过A2DP连接向所述第一设备发送所述蓝牙音频;并且/或者
所述第二设备通过低功耗蓝牙或者WiFi接收所述第一设备发送的所述恢复信息或所述丢失信息。
13.根据权利要求10所述的方法,其中,所述第二设备通过AVRCP连接接收所述第一设备发送的所述丢失信息,并且所述第二设备通过非AVRCP连接接收所述第一设备发送的所述恢复信息。
14.根据权利要求9所述的方法,其中,所述第二设备的一个或多个音频应用在所述第二设备的媒体会话框架注册事件回调。
15.一种第一设备,包括:
第一通信单元,至少用于与第二设备进行蓝牙通信;
处理器;以及
存储器,其上存储有可执行代码,当所述可执行代码被所述处理器执行时,使所述处理器执行根据权利要求1-8中任一项所述的方法。
16.一种第二设备,包括:
第二通信单元,至少用于与第一设备进行蓝牙通信;
处理器;以及
存储器,其上存储有可执行代码,当所述可执行代码被所述处理器执行时,使所述处理器执行根据权利要求9-14中任一项所述的方法。
17.一种音频播放系统,包括:
第一设备和第二设备,
其中所述第一设备包括:
第一通信单元,至少用于与所述第二设备进行蓝牙通信;
所述第一设备被配置为:
从所述第二设备获得蓝牙音频,所述第一设备的蓝牙应用申请所述第一设备的第一音频焦点以播放所述蓝牙音频;
响应于所述蓝牙应用丢失所述第一音频焦点,将所述蓝牙应用对所述第一音频焦点的丢失信息发送给所述第二设备;
其中所述第二设备包括:
第二通信单元,至少用于与所述第一设备进行蓝牙通信;
所述第二设备被配置为:
向所述第一设备发送蓝牙音频;
接收所述第一设备发送的丢失信息,其中,所述丢失信息表示所述第一设备的蓝牙应用丢失所述第一设备的第一音频焦点;以及
根据所述丢失信息控制所述第二设备的非音频应用申请所述第二设备的第二音频焦点。
18.根据权利要求17所述的系统,其中,
所述第一设备还被配置为:
在所述蓝牙应用持有所述第一音频焦点期间,响应于所述第一设备的非蓝牙应用抢占所述第一音频焦点,所述蓝牙应用丢失所述第一音频焦点。
19.根据权利要求18所述的系统,其中,
所述第一设备还被配置为:
响应于所述非蓝牙应用释放所述第一音频焦点,所述蓝牙应用恢复获取所述第一音频焦点;
将所述蓝牙应用对所述第一音频焦点的恢复信息发送给所述第二设备;
所述第二设备还被配置为:
接收所述第一设备发送的蓝牙应用对所述第一音频焦点的恢复信息;
根据所述恢复信息来控制所述非音频应用释放所述第二音频焦点。
20.一种非暂时性机器可读存储介质,其上存储有可执行代码,当所述可执行代码被电子设备的处理器执行时,使所述处理器执行根据权利要求1-14中任一项所述的方法。
21.一种计算机程序产品,包括可执行代码,当所述可执行代码被电子设备的处理器执行时,使所述处理器执行如权利要求1-14中任何一项所述的方法。
CN202410142417.5A 2024-01-31 2024-01-31 播放蓝牙音频的方法、控制音频播放的方法和系统 Pending CN117858057A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410142417.5A CN117858057A (zh) 2024-01-31 2024-01-31 播放蓝牙音频的方法、控制音频播放的方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410142417.5A CN117858057A (zh) 2024-01-31 2024-01-31 播放蓝牙音频的方法、控制音频播放的方法和系统

Publications (1)

Publication Number Publication Date
CN117858057A true CN117858057A (zh) 2024-04-09

Family

ID=90534471

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410142417.5A Pending CN117858057A (zh) 2024-01-31 2024-01-31 播放蓝牙音频的方法、控制音频播放的方法和系统

Country Status (1)

Country Link
CN (1) CN117858057A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118175527A (zh) * 2024-05-13 2024-06-11 深圳市爱都科技有限公司 蓝牙手表连接手机端使用语音助手的方法、装置及设备

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118175527A (zh) * 2024-05-13 2024-06-11 深圳市爱都科技有限公司 蓝牙手表连接手机端使用语音助手的方法、装置及设备

Similar Documents

Publication Publication Date Title
US11818420B2 (en) Cross-device content projection method and electronic device
WO2020098437A1 (zh) 一种播放多媒体数据的方法及电子设备
US8265557B2 (en) Mobile terminal capable of being connected to audio output device using short-range communication and method of controlling the operation of the mobile terminal
WO2020132839A1 (zh) 应用于tws耳机单双耳切换的音频数据传输方法及设备
WO2018059352A1 (zh) 直播视频流远程控制方法及装置
WO2017008627A1 (zh) 多媒体直播方法、装置和系统
US20160373801A1 (en) Method and device for playing multimedia file
KR20140074549A (ko) 음성인식 기술을 이용한 상황 인식 서비스 제공 방법 및 장치
CN111596885B (zh) 音频数据处理方法、服务器及存储介质
CN111078448A (zh) 一种处理音频异常的方法及电子设备
WO2021000817A1 (zh) 环境音处理方法及相关装置
CN117858057A (zh) 播放蓝牙音频的方法、控制音频播放的方法和系统
CN111245854B (zh) 一种媒体传输方法、媒体控制方法及装置
WO2020107290A1 (zh) 音频输出控制方法和装置、计算机可读存储介质、电子设备
WO2024055494A1 (zh) 基于蓝牙耳机的通话方法、装置及存储介质
WO2019076250A1 (zh) 推送消息的管理方法及相关产品
KR20170043319A (ko) 전자 장치 및 전자 장치의 오디오 출력 방법
WO2024021736A1 (zh) 蓝牙多媒体包的传输方法、装置、设备和系统
KR20180129335A (ko) 사용자 정보를 획득하기 위한 방법 및 그 전자 장치
WO2020118496A1 (zh) 音频通路切换方法和装置、可读存储介质、电子设备
JP6659625B2 (ja) 同じ位置に配置されたデバイス間における会話を同期する方法、装置およびコンピュータ・プログラム・プロダクト
WO2022213689A1 (zh) 一种音频设备间语音互通的方法及设备
CN107278289B (zh) 基于系统能力的用户体验的动态调节
CN116795753A (zh) 音频数据的传输处理的方法及电子设备
WO2024021735A1 (zh) 蓝牙多媒体包的传输方法、装置、设备、系统和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination