WO2022002218A1 - 一种音频控制方法、系统及电子设备 - Google Patents

一种音频控制方法、系统及电子设备 Download PDF

Info

Publication number
WO2022002218A1
WO2022002218A1 PCT/CN2021/104105 CN2021104105W WO2022002218A1 WO 2022002218 A1 WO2022002218 A1 WO 2022002218A1 CN 2021104105 W CN2021104105 W CN 2021104105W WO 2022002218 A1 WO2022002218 A1 WO 2022002218A1
Authority
WO
WIPO (PCT)
Prior art keywords
audio
data
audio data
application
display
Prior art date
Application number
PCT/CN2021/104105
Other languages
English (en)
French (fr)
Inventor
余艳辉
孙雪
李韦露
饶邦国
朱洲
陈杨明
李昕
蔡学江
Original Assignee
华为技术有限公司
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
Priority claimed from CN202011546105.9A external-priority patent/CN113890932A/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP21833204.7A priority Critical patent/EP4167580A4/en
Priority to US18/013,904 priority patent/US20230297324A1/en
Publication of WO2022002218A1 publication Critical patent/WO2022002218A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/162—Interface to dedicated audio devices, e.g. audio drivers, interface to CODECs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/165—Management of the audio stream, e.g. setting of volume, audio stream path
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/485—End-user interface for client configuration
    • H04N21/4852—End-user interface for client configuration for modifying audio parameters, e.g. switching between mono and stereo
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R3/00—Circuits for transducers, loudspeakers or microphones
    • H04R3/12—Circuits for transducers, loudspeakers or microphones for distributing signals to two or more loudspeakers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R2420/00—Details of connection covered by H04R, not provided for in its groups
    • H04R2420/07—Applications of wireless loudspeakers or wireless microphones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04R—LOUDSPEAKERS, MICROPHONES, GRAMOPHONE PICK-UPS OR LIKE ACOUSTIC ELECTROMECHANICAL TRANSDUCERS; DEAF-AID SETS; PUBLIC ADDRESS SYSTEMS
    • H04R5/00—Stereophonic arrangements
    • H04R5/04—Circuit arrangements, e.g. for selective connection of amplifier inputs/outputs to loudspeakers, for loudspeaker detection, or for adaptation of settings to personal preferences or hearing impairments

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Multimedia (AREA)
  • Human Computer Interaction (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Otolaryngology (AREA)
  • Acoustics & Sound (AREA)
  • Circuit For Audible Band Transducer (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Abstract

本申请提供一种音频控制方法、系统及电子设备，涉及终端领域，可以灵活的将某一终端的音频数据切换至其他终端上播放。该终端可以根据用户的输入选择其他设备，结合其他设备的能力对待切换的音频数据进行处理，再将处理后的音频数据发送给其他设备，由其他设备进行直接播放，或者进一步处理后再播放。

Description

一种音频控制方法、系统及电子设备
本申请要求以下9件中国专利申请的优先权。其中，这9件中国专利申请包括：于2020年07月02日提交国家知识产权局、申请号为202010628962.7的中国专利申请；于2020年10月23日提交国家知识产权局、申请号为202011149031.5的中国专利申请；于2020年09月29日提交国家知识产权局、申请号为202011058010.2的中国专利申请；于2020年08月21日提交国家知识产权局、申请号为202010847900.5的中国专利申请；于2020年07月23日提交国家知识产权局、申请号为202010718939.7的中国专利申请；于2020年07月20日提交国家知识产权局、申请号为202010700459.8的中国专利申请；于2020年08月04日提交国家知识产权局、申请号为202010774729.X的中国专利申请；于2020年07月20日提交国家知识产权局、申请号为202010701720.6的中国专利申请；于2020年12月23日提交国家知识产权局、申请号为202011546105.9的中国专利申请。上述9件中国专利申请全部内容通过引用结合在本申请中。
技术领域
本申请涉及终端领域，尤其涉及一种音频控制方法、系统及电子设备。
背景技术
手机等智能终端一般都具有音频输入和输出功能。例如，手机可使用自身的扬声器(speaker)播放音频，也可以使用自身的麦克风(mic)录制音频。又例如，手机还可以通过有线耳机、蓝牙耳机或蓝牙音箱等音频输出设备输出音频。
由于近年来智能终端技术的飞速发展，一个用户或家庭中往往具备多个终端设备。例如，用户家中可能包括由若干手机、电视、音箱以及PC等终端组成的互联系统。在这种互联系统中，用户将某一终端上的音频投递至其他一个或多个终端上播放的需求也越来越多。那么，如何将某一终端的音频数据灵活的在其他一个或多个终端上进行播放和管控成为亟需解决的问题。
发明内容
本申请提供一种音频控制方法、系统及电子设备，可以灵活的将某一终端的音频切换至其他一个或多个终端上播放，提高用户的音频使用体验。
为达到上述目的，本申请采用如下技术方案：
第一方面，本申请提供一种音频控制方法，包括：响应于用户输入的第一操作，第一设备可显示候选设备列表，该候选设备列表中包括至少一个具有音频输出功能的候选设备；如果第一设备检测到用户在上述候选设备列表中选择第二设备，说明用户希望将第一设备的音频功能切换至第二设备上实现，此时第一设备为主设备，第二设备为从设备(第二设备可以是音箱、电视或手机等具有操作系统的电子设备)；进而，第一设备可获取第二设备的音频能力参数，该音频能力参数用于指示第二设备播放音频的硬件能力以及第二设备播放音频的软件能力；这样，第一设备可根据第二设备的音频能力参数确定第一音频播放策略，从而按照第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据；进而，第一设备可将第二音频 数据发送至第二设备播放。
可以看出，第一设备在进行音频切换时可以获取从设备(即第二设备)的音频能力参数，由于该音频能力参数能够反映出第二设备播放音频时的软件处理能力和硬件处理能力，使得第一设备能够根据第二设备的音频能力参数确定与第二设备的音频能力匹配的第一音频播放策略。其中，第二设备播放音频时的软件处理能力主要是由软件特性决定的(例如音效处理算法)，第二设备播放音频时的硬件处理能力主要是硬件特性决定(例如扬声器的器件等)，具体将在具体实施方式中进行说明。
另外，上述第一处理可以包括音效处理，根据声道数目进行混音等，以下将结合可能的实施方式进行详细说明。
这样，第一设备按照第一音频播放策略处理了来自第一音频应用的第一音频数据后，可将处理后得到的第二音频数据发送给第二设备，使得从设备可播放与自身音频能力相匹配的来自第一设备的音频数据。例如，第二设备播放接收到第二音频数据可直接播放该第二音频数据，也可以对第二音频数据进行处理后再播放。这样，第一设备能够灵活的将自身的音频播放功能切换至其他一个或多个从设备上，并根据从设备的音频能力对从设备的音频播放过程进行控制，从而为用户提供较好的音频使用体验，同时也能利用从设备的音频处理能力，与主设备协同完成音频数据的处理和播放。
在一种可能的实现方式中，上述音频能力参数具体可包括音效参数，音效参数用于指示第二设备是否开启音效模式；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：若第二设备开启了音效模式，则第一设备可在第一音频播放策略中设置对第一音频数据不进行音效处理；若第二设备没有开启音效模式，则第一设备可在第一音频播放策略中设置对第一音频数据进行音效处理。
相应的，如果第一音频播放策略中设置了对第一音频数据进行音效处理，则第一设备对第一音频数据进行的第一处理具体可以包括音效处理，例如添加重低音音效等。如果第一音频播放策略中设置了对第一音频数据不进行音效处理，则第一设备对上述第一音频数据无需进行音效处理，后续可由第二设备对接收到的音频数据进行音效处理。这样，可以避免第一设备与第二设备均对音频数据进行音效处理而导致的音效叠加现象，也可以避免第一设备与第二设备均对音频数据未进行音效处理而导致的音效缺失现象，从而提高用户的音频使用体验，也提高了设备处理音频数据的效率。
在一种可能的实现方式中，上述音频能力参数具体可以包括音效参数，音效参数用于指示第二设备支持的音效模式，例如，杜比音效、histen音效等；并且，第一音频应用中已经将音频播放的音效模式设置为第一音效模式；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：若第一音效模式为第二设备支持的音效模式，说明第二设备有能力完成上第一音效，则第一设备可在第一音频播放策略中设置对第一音频数据不进行音效处理；若第一音效模式不是第二设备支持的音效模式，说明第二设备没有能力完成上第一音效，则第一设备可在第一音频播放策略中设置对第一音频数据按第一音效模式进行音效处理。
又或者，如果第一音效模式为第一设备和第二设备均支持的音效模式，则第一设备可在第一音频播放策略中默认设置由第一设备或第二设备进行音效处理。
如果第一音频播放策略中设置了对第一音频数据按第一音效模式进行音效处理， 则第一设备对第一音频数据进行的第一处理具体可以为向第一音频数据中添加第一音效；如果第一音频播放策略中设置了对第一音频数据按第一音效模式不进行音效处理，则第一设备不需要向第一音频数据中添加第一音效，后续可由第二设备对接收到的音频数据添加第一音效。
在一种可能的实现方式中，上述音频能力参数具体可以包括目标采样率，目标采样率为第二设备支持的采样率(例如48KHz或96KHz等)；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：第一设备在第一音频播放策略中设置对第一音频数据按照目标采样率进行采样。
相应的，第一设备对第一音频数据进行的第一处理具体可以为按照上述目标采样率进行重采样。例如，将96KHz的第一音频数据下采样为48KHz的第二音频数据。又例如，将48KHz的第一音频数据上采样为96KHz的第二音频数据。
在一种可能的实现方式中，上述音频能力参数具体可以包括目标声道数，目标声道数为第二设备支持的声道个数(例如双声道、4声道等)；其中，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：第一设备在第一音频播放策略中设置对第一音频数据按照目标声道数进行混音。
相应的，第一设备对第一音频数据进行的第一处理具体可以为按照上述目标声道数进行混音。例如，将8声道的第一音频数据下混音为4声道的第二音频数据。又例如，将双声道的第一音频数据上混音为8声道的第二音频数据。
在一种可能的实现方式中，上述音频能力参数具体可以包括时延参数，时延参数用于指示第二设备是否支持低时延的音频处理能力；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：若第二设备支持低时延的音频处理能力，则第一设备可在第一音频播放策略中设置按照低时延模式处理第一音频数据；若第二设备不支持低时延的音频处理能力，则第一设备可在第一音频播放策略中设置按照非低时延模式处理第一音频数据。其中，相对于非低时延模式，在低时延模式下，第一设备可将每一帧音频数据的时长设置的较小，以缩短第二设备处理帧音频数据的时延。
在一种可能的实现方式中，上述音频能力参数可以包括时延参数，时延参数用于指示第二设备的音频播放时延，即第二设备处理一帧音频数据所需的时间，例如10ms或5ms；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：若第二设备的音频播放时延小于预设值，说明第二设备支持低时延的音频处理能力，则第一设备可在第一音频播放策略中设置按照低时延模式处理第一音频数据；若第二设备的音频播放时延大于或等于预设值，第二设备不支持低时延的音频处理能力，则第一设备在第一音频播放策略中设置按照非低时延模式处理第一音频数据。
相应的，如果第一音频播放策略中设置了低时延模式，则第一设备对第一音频数据进行的第一处理具体可以为按照第一时长将第一音频数据划分为每一帧音频数据；如果第一音频播放策略中设置了非低时延模式，则第一设备对第一音频数据进行的第一处理具体可以为按照第二时长将第一音频数据划分为每一帧音频数据，第二时长大于第一时长。
在一种可能的实现方式中，第一设备的应用程序层安装有第一预设应用，例如DV APP；其中，第一设备获取第二设备的音频能力参数，包括：第一设备通过运行第一 预设应用从第二设备中获取第二设备的音频能力参数，即通过安装的DV APP获取从设备的音频能力。相应的，第二设备中可以安装与第一预设应用适配的应用，以向第一设备提供第二设备的音频能力参数，并接收第二音频数据。由于不需要改动第二设备的操作系统，第一设备和第二设备可以由不同的厂家提供，只需要第二设备安装该对应的应用即可配合第一设备执行本方案，因此本方案可适配各种厂家提供的设备，可以广泛应用。
在一种可能的实现方式中，在第一设备获取第二设备的音频能力参数之后，还包括：第一预设应用(例如DV APP)可按照第二设备的音频能力参数在HAL创建对应的硬件抽象模块(例如DMSDP Audio HAL)；此时，第一设备将第二音频数据发送至第二设备，包括：第一设备调用DMSDP Audio HAL将第二音频数据发送至第二设备。也就是说，第一设备在进行音频切换时可动态的按照从设备的音频能力参数创建对应的DMSDP Audio HAL，以便使用该DMSDP Audio HAL向从设备发送音频数据。
在一种可能的实现方式中，第一设备的应用程序框架层包含音频策略模块(例如AudioPolicy)；此时，第一设备根据第二设备的音频能力参数确定第一音频播放策略，包括：第一预设应用将第二设备的音频能力参数发送至音频策略模块，由音频策略模块根据第二设备的音频能力参数确定第一音频播放策略。
在一种可能的实现方式中，第一设备的应用程序框架层包含音频处理器(例如AudioFlinger)；此时，第一设备按照第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据，包括：音频处理器可接收来自第一音频应用的第一音频数据；并且，音频处理器可从音频策略模块获取第一音频播放策略，进而，音频处理器可按照该第一音频播放策略对第一音频数据进行第一处理，输出处理后得到的第二音频数据。
需要说明的是，上述第一处理包括什么依赖于第一音频播放策略的具体内容，例如，第一音频播放策略中要求第一设备添加第一音效，则第一处理可以包括添加第一音效的音效处理过程。又例如，第一音频播放策略中要求第一设备按照48KHz的采样率进行采样，则48KHz的按照48KHz的采样率进行采样的处理过程。在一些情况下，第一音频播放策略也可以为空，即不需要第一设备对来自第一音频APP的第一音频数据做任何处理，此时，第一设备无需对第一音频数据进行第一处理，可直接将第一音频数据发送至第二设备。
在一种可能的实现方式中，上述方法还可以包括：当第二设备的音频能力参数更新时，例如，第二设备的音效模式从杜比音效调整为重低音音效，此时，第一预设应用可获取第二设备更新后的音频能力参数；并且，第一预设应用可将更新后的音频能力参数发送给音频策略模块，使得音频策略模块按照更新后的音频能力参数将第一音频播放策略更新为第二音频播放策略；进而，音频策略模块可将第二音频播放策略输出至音频处理器，由音频处理器按照更新后的第二音频播放策略对接收到的音频数据进行第二处理。与上述第一处理类似的，第二处理包括什么依赖于第二音频播放策略的具体内容。
另外，在第一预设应用获取到第二设备更新后的音频能力参数之后，第一预设应用还可以按照更新后的音频能力参数更新上述DMSDP Audio HAL，以使得更新后的 DMSDP Audio HAL能够支持向第二设备发送经过上述第二处理的音频数据。
也就是说，当第一设备连接的从设备(即第二设备)的音频能力发生变化时，第一设备可以动态的更新处理音频数据的音频播放策略，还可以动态的更新对应的DMSDP Audio HAL，即保持DMSDP Audio HAL与音频播放策略与从设备的能力及时的匹配，使第一设备能够按照第二设备更新后的音频能力与第二设备进行音频切换。
在一种可能的实现方式中，在第一设备将第二音频数据发送至第二设备之后，还包括：第一设备可接收用户设置音量大小的第二操作，例如点击音量+按钮或音量－按钮的操作；音频策略模块响应上述第二操作可在第一音频播放策略中设置音量等级，例如，将音量由100设置为120,设置后的音频播放策略为第三音频播放策略；进而，音频策略模块可将第三音频播放策略输出至音频处理器，以使得音频处理器按照第三音频播放策略中设置的音量等级修改接收到的音频数据的增益，从而修改第二设备后续播放的音频数据的音量大小。
也就是说，当音频数据的音量发生变化时，第一设备也可以动态的更新处理音频数据的音频播放策略，即重新定制与第二设备的音频能力相匹配的音频播放策略。
在一种可能的实现方式中，第一设备的应用程序层安装有第二音频应用；在第一设备将第二音频数据发送至第二设备之后，还包括：音频处理器接收来自第二音频应用的音频数据；当第二音频应用的音频数据与第一音频应用的音频数据的类型不同时，音频策略模块可将第一音频播放策略更新为第四音频播放策略；进而，音频策略模块将第四音频播放策略输出至音频处理器，由音频处理器按照第四音频播放策略对接收到的音频数据进行第三处理；音频处理器将经过第三处理的音频数据通过硬件抽象模块发送至第二设备。与上述第一处理类似的，第三处理的具体内容依赖于第四音频播放策略的具体内容。
也就是说，在音频切换的过程中，如果第一设备输出的音频数据发生了变化，第一设备也可以动态的更新处理音频数据的音频播放策略，使第二设备接收到的音频数据与自身的音频能力相匹配。
在一种可能的实现方式中，在第一设备将第二音频数据发送至第二设备之后，还包括：第一设备接收用户选择第三设备进行音频播放的第三操作，即用户将第一设备的从设备由第二设备改为第三设备；响应于第三操作，第一预设应用可从第三设备中获取第三设备的音频能力参数；第一预设应用将第三设备的音频能力参数发送给音频策略模块，使得音频策略模块按照第三设备的音频能力参数将第一音频播放策略更新为第五音频播放策略；音频策略模块将第五音频播放策略输出至音频处理器，以使得音频处理器按照第五音频播放策略对接收到的音频数据进行第四处理。与上述第一处理类似的，第四处理的具体内容依赖于第五音频播放策略的具体内容。
另外，在第一预设应用从第三设备中获取第三设备的音频能力参数之后，第一预设应用还可以按照第三设备的音频能力参数更新DMSDP Audio HAL，以使得更新后的DMSDP Audio HAL支持向第三设备发送经过第四处理的音频数据。
也就是说，当第一设备连接的从设备发生改变时，第一设备可以动态的更新处理音频数据的音频播放策略，还可以动态的更新对应的DMSDP Audio HAL，即保持DMSDP Audio HAL与音频播放策略与从设备的能力及时的匹配，使第一设备能够按 照新的从设备(即第三设备)的音频能力与第三设备进行音频切换。
在另一种可能的实现方式中，第一设备的应用程序层可以安装第二预设应用，第二预设应用可以与上述第一预设应用相同或不同；其中，第一设备将第二音频数据发送至第二设备，包括：第一设备将第二音频数据发送至第二预设应用，由第二预设应用将第二音频数据发送至第二设备。此时，第一预设应用无需在HAL创建对应的DMSDP Audio HAL。
在一种可能的实现方式中，在第一设备显示候选设备列表之前，还包括：第一设备显示第一音频应用的应用界面，该应用界面中可以设置音频切换按钮；此时，上述第一操作为用户点击音频切换按钮的操作。也就是说，用户可以在音频应用运行的过程中从音频应用内设置的音频切换按钮进入音频切换功能。
在一种可能的实现方式中，在第一设备显示候选设备列表之前，还包括：第一设备显示控制中心，控制中心中可以设置音频切换按钮；此时，上述第一操作为用户点击音频切换按钮的操作。也就是说，用户可以在控制中心的音频切换按钮进入音频切换功能。
在一种可能的实现方式中，第二设备的音频能力参数可以包括录制参数，录制参数用于指示第二设备的音频输入能力，即录音能力；与上述音频播放的过程类似的，上述方法还包括：第一设备根据该录制参数确定音频录制策略；第一设备接收到第二设备录制的第一录音数据后，按照该音频录制策略处理第一录音数据，得到第二录音数据；进而第一设备可将第二录音数据上报给开启录制功能的音频应用。也就是说，第一设备除了将音频输出功能分布至从设备中实现，也可以将音频输入功能分布至从设备中实现。
第二方面，本申请提供一种音频控制方法，包括：响应于用户输入的第一操作，第一设备显示候选设备列表，候选设备列表中包括至少一个具有音频输出功能的候选设备；响应于用户在候选设备列表中选择第二设备的操作，第一设备获取第二设备的音频能力参数，该音频能力参数用于指示第二设备播放音频的硬件能力以及第二设备播放音频的软件能力；第一设备可以根据第二设备的音频能力参数确定不需要对来自第一音频应用的音频数据进行处理；例如，由于第二设备的音频能力参数中指示第二设备具有采样、音效处理等能力，那么，第一设备可以确定第一设备不需要对来自第一音频应用的音频数据进行采样、添加音效等处理，而是由第二设备对来自第一音频应用的音频数据进行处理；那么，第一设备可直接将第一音频应用的音频数据发送至第二设备。第二设备接收到第一设备发送的音频数据后，可按照自身的音频能力对该音频数据进行相应的处理(例如采样、添加音效等)，并播放处理后的音频数据。当然，第二设备接收到第一设备发送的音频数据后还可以直接播放该音频数据，本申请实施例对此不做任何限制。
例如，如果第二设备的音频能力参数中指示第二设备开启了杜比音效，则第一设备可以确定不需要第一设备对上述音频数据进行杜比音效的音效处理。当第二设备接收到第一设备发来的音频数据后，可对该音频数据进行杜比音效的音效处理。又例如，如果第二设备的音频能力参数中指示第二设备具有混音能力，则第一设备可以确定不需要第一设备对上述音频数据进行混音处理。当第二设备接收到第一设备发来的音频 数据后，可对该音频数据进行混音处理。这样，在进行音频切换时第一设备可充分利用从设备的音频处理能力，与从设备更加高效、灵活的协同完成音频数据的处理过程。
也就是说，上述处理是指与第二设备的音频能力参数相关的处理操作。第一设备仍然可以对待发送的音频数据进行解析、编码、解码、封装或解封装等常规处理操作，这些处理操作通常与第二设备的音频能力参数没有直接关联。
又或者，第一设备除了向第二设备发送来自第一音频应用的音频数据外，还可以向第二设备发送第二设备处理该音频数据时的音频策略。例如，如果第一设备没有开启音效模式，而第二设备开启了音效模式，则第一设备可在音频策略中设置由第二设备对接收到的音频数据进行音效处理。那么，第二设备接收到该音频策略以及来自第一音频应用的音频数据后，可按照该音频策略对该音频数据进行音效处理，从而减轻第一设备的运行负荷。
第三方面，本申请提供一种音频控制方法，包括：响应于用户输入的第一操作，第一设备显示候选设备列表，候选设备列表中包括至少一个具有音频输出功能的候选设备；响应于用户在候选设备列表中选择第二设备和第三设备的操作，第一设备分别获取第二设备的音频能力参数以及第三设备的音频能力参数，此时，第一设备的从设备包括第二设备和第三设备这两个设备，第二设备的音频能力参数用于指示第二设备播放音频的硬件能力以及第二设备播放音频的软件能力，第三设备的音频能力参数用于指示第三设备播放音频的硬件能力以及第三设备播放音频的软件能力；进而，第一设备可根据第二设备的音频能力参数和第三设备的音频能力参数确定多设备音频播放策略；并且，第一设备可按照该多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与第二设备对应的第二音频数据以及与第三设备对应的第三音频数据；进而，第一设备可将第二音频数据发送至第二设备进行播放，并将第三音频数据发送至第三设备进行播放。
与上述第一方面或第二方面中第一设备将音频数据切换至第二设备上播放类似的，第一设备将第二音频数据发送至第二设备后，第二设备可直接播放该第二音频数据，也可以对第二音频数据进行处理后再播放。同样，第一设备将第三音频数据发送至第三设备后，第三设备可直接播放该第三音频数据，也可以对第三音频数据进行处理后再播放。这样，第一设备可将自身的音频播放功能同时切换至多个从设备上，实现跨设备的分布式音频能力。
在一种可能的实现方式中，当第二设备的音频能力参数和第三设备的音频能力参数不同时，上述多设备音频播放策略包括第一策略和第二策略；其中，第一设备按照多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与第二设备对应的第二音频数据以及与第三设备对应的第三音频数据，包括：第一设备将第一音频数据复制后得到第一数据和第二数据(第一数据与第一音频数据相同，第二数据与第一音频数据相同)；进而，第一设备可按照第一策略处理第一数据流，得到第二音频数据；并且，第一设备可按照第二策略处理第二数据流，得到第三音频数据。
示例性的，第一设备的应用程序层安装有第一预设应用(例如DV APP)；在第一设备分别获取第二设备的音频能力参数以及第三设备的音频能力参数之后，由于第二设备的音频能力参数和第三设备的音频能力参数不同，因此，第一预设应用可以按 照第二设备的音频能力参数在HAL创建第一硬件抽象模块，并且，按照第三设备的音频能力参数在HAL创建第二硬件抽象模块；此时，第一设备可通过第一硬件抽象模块将第二音频数据发送至第二设备，并且，第一设备可通过第二硬件抽象模块将第三音频数据发送至第三设备。
在一种可能的实现方式中，当第二设备的音频能力参数和第三设备的音频能力参数相同时，第一设备按照上述多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与第二设备对应的第二音频数据以及与第三设备对应的第三音频数据，包括：第一设备按照上述多设备音频播放策略对第一音频数据进行第一处理，得到第二音频数据；第一设备将第二音频数据复制后得到第三音频数据。
示例性的，当第二设备的音频能力参数和第三设备的音频能力参数相同时，第一设备安装的第一预设应用可按照第二设备的音频能力参数(或第三设备的音频能力参数)在HAL创建硬件抽象模块，此时仅需创建一个硬件抽象模块；第一设备可通过该硬件抽象模块将第二音频数据发送至第二设备，并且，第一设备可通过该硬件抽象模块将第三音频数据发送至第三设备。也就是说，第一预设应用在HAL创建的硬件抽象模块是与第一设备获取到的音频能力参数对应的，每个硬件抽象模块与一组唯一确定的音频能力参数相对应。
第四方面，本申请提供一种音频控制方法，包括：响应于用户输入的第一操作，第一设备显示候选设备列表，候选设备列表中包括至少一个具有音频输入功能的候选设备；响应于用户在候选设备列表中选择第二设备(第二设备为音箱，或电视，或手机)的操作，第一设备获取第二设备的音频能力参数，音频能力参数用于指示第二设备录制音频的硬件能力以及第二设备录制音频的软件能力；第一设备可根据第二设备的音频能力参数确定第一音频录制策略；后续，当第一设备接收到第二设备发送的第一录音数据时，第一设备可按照上述第一音频录制策略对第一录音数据进行第一处理，得到第二录音数据。
可以看出，与上述第一方面中的音频控制方法类似的，在第四方面所述的音频控制方法中，第一设备(即主设备)可以根据第二设备(即从设备)的音频能力参数中与音频输出功能相关的能力确定相应的第一音频录制策略。这样，第一设备按照第一音频录制策略可以灵活的将自身的音频输入功能切换至从设备上实现，同时也能利用从设备的音频录制能力，与主设备协同完成音频数据的录制过程。
另外，上述第一处理包括什么依赖于第一音频录制策略的具体内容，例如，第一音频录制策略中要求第一设备使用3A算法进行回声消除，则第一处理可以包括使用3A算法进行回声消除的处理过程。在一些情况下，第一音频录制策略也可以为空，即不需要第一设备对第二设备发来的第一录音数据做任何处理，此时，第一设备无需对第一录音数据进行第一处理。
在一种可能的实现方式中，在第一设备获取第二设备的音频能力参数之后，还包括：当第二设备的音频能力参数更新时，第一设备可获取第二设备更新后的音频能力参数；进而，第一设备可按照更新后的音频能力参数将第一音频录制策略更新为第二音频录制策略；后续，当第一设备接收到第二设备发送的第三录音数据时，第一设备可按照第二音频录制策略对第三录音数据进行第二处理，得到第四录音数据。
也就是说，当第一设备连接的从设备(即第二设备)的音频录制能力发生变化时，第一设备可以动态的更新处理录音数据的音频录制策略。这样，第一设备对后续接收到的录音数据的处理(即第二处理)也会相应调整，使第一设备能够按照第二设备更新后的音频录制能力与第二设备进行音频切换。与上述第一处理类似的，第二处理包括什么依赖于第二音频播放策略的具体内容。
在一种可能的实现方式中，在第一设备获取第二设备的音频能力参数之后，还包括：第一设备可接收用户选择第三设备进行音频录制的第二操作，即用户将第一设备的音频输入设备由第二设备改为第三设备；响应于第二操作，第一设备可从第三设备中获取第三设备的音频能力参数；进而，第一设备可根据第三设备的音频能力参数确定第三音频录制策略；后续，当第一设备接收到第三设备发送的第五录音数据时，第一设备按照第三音频录制策略对第五录音数据进行第三处理，得到第六录音数据。
也就是说，当第一设备连接的音频输出设备发生改变时，第一设备可以动态的更新处理录音数据的音频播放策略。这样，第一设备对后续接收到的录音数据的处理(即第三处理)也会相应调整，使第一设备能够按照第三设备的音频录制能力与第三设备进行音频切换。与上述第一处理类似的，第三处理包括什么依赖于第三音频播放策略的具体内容。
在一种可能的实现方式中，在第一设备获取第二设备的音频能力参数之后，还包括：第一设备按照第二设备的音频能力参数在HAL中创建对应的硬件抽象模块；此时，第一设备接收第二设备发送的第一录音数据，包括：第一设备通过硬件抽象模块接收第二设备发送的第一录音数据。也就是说，第一设备在进行音频切换时可动态的按照从设备的音频能力参数创建对应的DMSDP Audio HAL，以便使用该DMSDP Audio HAL接收从设备发送的录音数据。
与上述音频播放过程类似的，当第二设备的音频能力参数更新或者获取到新的从设备的音频能力参数时，第一设备还可以按照最新的音频能力参数更新上述DMSDP Audio HAL，以使得更新后的DMSDP Audio HAL能够与当前的从设备进行数据收发。
当然，与音频播放过程类似的，第一设备中也可以包括第一预设应用(例如DV APP)、音频策略模块(例如AudioPolicy)以及音频处理器(例如AudioFlinger)等，在音频录制的过程中这些功能模块与上述音频播放过程类似，故此处不予赘述。
第五方面，本申请提供一种音频控制方法，包括：第二设备向第一设备发送第一音频能力参数，第一音频能力参数用于指示第二设备播放音频的硬件能力以及第二设备播放音频的软件能力，第二设备为音箱，或电视，或手机；后续，第二设备可接收第一设备发送的第一音频数据，第一音频数据是第一设备按照第一音频能力参数处理后得到的；进而，第二设备可播放第一音频数据，或者，第二设备可对第一音频数据进行处理后播放。
在一种可能的实现方式中，第二设备中的应用程序层安装有预设应用；其中，第二设备向第一设备发送第一音频能力参数，包括：第二设备通过运行预设应用向第一设备发送第一音频能力参数；其中，第二设备接收第一设备发送的第一音频数据，包括：第二设备通过运行预设应用接收第一设备发送的第一音频数据。
也就是说，对于第二设备(即第一设备的从设备)而言，第二设备只需要安装上 述预设应用(可称为代理APP)后，便可以通过代理APP向第一设备上报自身的音频能力参数，并从第一设备获取到与自身音频能力匹配的音频数据进行播放。由于不需要改动第二设备的操作系统，第一设备和第二设备可以由不同的厂家提供，只需要第二设备安装该对应的应用即可配合第一设备执行本方案，因此本方案可适配各种厂家提供的设备，可以广泛应用。
在一种可能的实现方式中，在第二设备播放第一音频数据，或者，第二设备对第一音频数据进行处理后播放之后，还包括：第二设备将第三设备设置为音频输出设备(第三设备与第二设备不同，第三设备与第一设备不同)；第二设备向第一设备发送第二音频能力参数，第二音频能力参数用于指示第三设备播放音频的硬件能力以及第三设备播放音频的软件能力；第二设备接收第一设备发送的第二音频数据，第二音频数据为第一设备按照第二音频能力参数处理后得到的；第二设备播放第二音频数据，或者，第二设备对第二音频数据进行处理后播放。
也就是说，当第二设备连接了其他音频输出设备(例如第三设备)时，第二设备可作为第三设备的主设备，重新上报自身的音频能力参数(即第二音频能力参数)，第二音频能力参数反应的是第三设备的音频能力，使第一设备能够按照新的音频能力参数处理音频数据，实现音频切换功能。
在一种可能的实现方式中，在第二设备播放第一音频数据，或者，第二设备对第一音频数据进行处理后播放之后，还包括：当第二设备的音频能力变化时，第二设备将第一音频能力参数更新为第三音频能力参数；第二设备向第一设备发送第三音频能力参数；第二设备接收第一设备发送的第三音频数据，第三音频数据为第一设备按照第三音频能力参数处理后得到的；第二设备播放第三音频数据，或者，第二设备对第三音频数据进行处理后播放。
也就是说，当第二设备的音频能力发生变化时，第二设备可重新上报自身的音频能力参数(即第三音频能力参数)，使第一设备能够按照新的音频能力参数处理音频数据，实现音频切换功能。
在一种可能的实现方式中，上述第一音频能力参数还可以指示第二设备录制音频的硬件能力以及第二设备录制音频的软件能力，也就是说，第一音频能力参数中还可以包括可以反映第二设备的录制能力的参数，例如第二设备使用的回声消除算法等；那么，在第二设备向第一设备发送第一音频能力参数之后，还包括：第二设备开始录制音频，得到录音数据；第二设备将录音数据发送给第一设备，以使得第一设备按照第一音频能力参数对录音数据进行处理。
在一种可能的实现方式中，上述方法还包括：第二设备接收第一设备发送的音频策略，该音频策略为第一设备根据第一音频能力参数确定的，该音频策略可以包括音频播放策略和/或音频录制策略；此时，第二设备可按照该音频播放策略处理第一音频数据，并播放处理后的第一音频数据。也就是说，第一设备作为主设备可根据第二设备的音频能力参数指示第二设备在音频切换时具体需要执行哪些处理，从而充分发挥第二设备的音频能力，为用户提供更好的音频使用体验。
第六方面，本申请提供一种音频控制方法，包括：第二设备向第一设备发送第一音频能力参数，第一音频能力参数用于指示第二设备录制音频的硬件能力以及第二设 备录制音频的软件能力，第二设备可以为音箱，或电视，或手机；进而，第二设备可以调用麦克风开始录制音频，得到第一录音数据；第二设备将第一录音数据发送给第一设备，以使得第一设备按照上述第一音频能力参数处理第一录音数据。
在一种可能的实现方式中，第二设备中的应用程序层安装有预设应用；其中，第二设备向第一设备发送第一音频能力参数，包括：第二设备通过运行预设应用向第一设备发送第一音频能力参数；其中，第二设备将第一录音数据发送给第一设备，包括：第二设备通过运行预设应用将第一录音数据发送给第一设备。
也就是说，对于第二设备(即第一设备的从设备)而言，第二设备只需要安装上述预设应用(可称为代理APP)后，便可以通过代理APP向第一设备上报与自身音频录制能力相关的音频能力参数，并向第一设备发送录制得到录音数据。由于不需要改动第二设备的操作系统，第一设备和第二设备可以由不同的厂家提供，只需要第二设备安装该对应的应用即可配合第一设备执行本方案，因此本方案可适配各种厂家提供的设备，可以广泛应用。
在一种可能的实现方式中，在第二设备将第一录音数据发送给第一设备之后，还包括：第二设备将第三设备设置为音频输入设备(第三设备与第二设备不同，第三设备与第一设备不同)；第二设备向第一设备发送第二音频能力参数，第二音频能力参数用于指示第三设备录制音频的硬件能力以及第三设备录制音频的软件能力；第二设备将通过第三设备录制的第二录音数据发送给第一设备，以使得第一设备按照上述第二音频能力参数处理第二录音数据。
也就是说，当第二设备连接了其他音频输入设备(例如第三设备)时，第二设备可作为第三设备的主设备，重新向第一设备上报自身的音频能力参数(即第二音频能力参数)，第二音频能力参数反应的是第三设备的音频录制能力，使第一设备能够按照新的音频能力参数处理录音数据，实现音频切换功能。
在一种可能的实现方式中，在第二设备将第一录音数据发送给第一设备之后，还包括：当第二设备的音频录制能力变化时，第二设备将第一音频能力参数更新为第三音频能力参数；第二设备向第一设备发送第三音频能力参数；第二设备将录制的第三录音数据发送给第一设备，以使得第一设备按照上述第三音频能力参数处理第三录音数据。
也就是说，当第二设备的音频录制能力发生变化时，第二设备可重新上报自身的音频能力参数(即第三音频能力参数)，使第一设备能够按照新的音频能力参数处理第二设备上报的录音数据，实现音频切换功能。
在一种可能的实现方式中，上述方法还包括：第二设备接收第一设备发送的音频录制策略，该音频录制策略为第一设备根据第一音频能力参数确定的；此时，第二设备可按照该音频播放策略录制音频，得到上述第一录音数据。也就是说，第一设备作为主设备可根据第二设备的音频能力参数指示第二设备在录音时具体需要执行哪些处理，从而充分发挥第二设备的音频能力，为用户提供更好的音频使用体验。
第七方面，本申请提供一种音频控制方法，包括：当第一设备与第二设备建立网络连接后，第一设备可将第二设备作为从设备，获取与第二设备对应的设备选择策略；后续，当第一设备获取到待播放的第一音频数据(第一音频数据的类型为第一类型) 时，第一设备可根据第一类型以及上述设备选择策略确定第一音频数据是否允许在第二设备中播放，即确定第一音频数据的音频输出设备是否为第二设备；若第一音频数据允许在第二设备中播放，则第一设备可将第一音频数据发送至第二设备进行播放。
可以看出，第一设备(即主设备)在将音频数据输出至第二设备(即从设备)进行音频切换时，可按照对应的设备选择策略将特定类型的音频数据发送给第二设备播放，从而为用户过滤掉一些不适合在第二设备上播放的音频数据，使不同的音频输出设备能够有针对性的向用户播放相应的音频，音频数据与音频输出设备的适配性更高，提升用户的音频使用体验。
在一种可能的设计方法中，上述设备选择策略具体可以包括：第二设备允许播放的音频数据的类型以及不允许播放的音频数据的类型；此时，第一设备根据第一类型和设备选择策略确定第一音频数据是否允许在第二设备中播放，包括：第一设备在上述设备选择策略中查询第二设备是否允许播放第一类型的音频数据；若第二设备允许播放第一类型的音频数据，则第一设备确定第一音频数据允许在第二设备中播放；若第二设备不允许播放第一类型的音频数据，则第一设备确定第一音频数据不允许在第二设备中播放。
这样一来，第一设备在向第二设备切换音频时，可按照设备选择策略将第二设备允许播放的一类多多类音频数据投射至第二设备中播放，而设备选择策略中第二设备不允许播放的一类多多类音频数据将不会投射至第二设备中播放，从而从而为用户过滤掉一些不适合在第二设备上播放的音频数据。
在一种可能的设计方法中，上述设备选择策略具体可以包括：第二设备允许播放的音频数据来自的应用以及第二设备允许播放的音频数据的类型，第二设备不允许播放的音频数据来自的应用以及第二设备不允许播放的类型；也就是说，设备选择策略中可以以应用为维度设置第二设备允许或不允许播放的音频数据。
此时，第一设备根据第一类型和设备选择策略确定第一音频数据是否允许在第二设备中播放，包括：第一设备确定第一音频数据来自于第一应用；进而，第一设备可在设备选择策略中查询第二设备是否允许播放来自第一应用的第一类型的音频数据；若第二设备允许播放来自第一应用的第一类型的音频数据，则第一设备确定第一音频数据允许在第二设备中播放；若第二设备不允许播放来自第一应用的第一类型的音频数据，则第一设备确定第一音频数据不允许在第二设备中播放。
这样一来，第一设备在向第二设备切换音频时，第一设备可将一个应用产生的不同类型的音频数据按照设备选择策略输出至相应的音频输出设备中播放，使得不同的音频输出设备可有针对性的播放特定应用中特定类型的音频数据，提高用户的音频使用体验。
在一种可能的设计方法中，上述设备选择策略还包括不同类型的音频数据的音频输出设备；一般，第二设备允许播放的音频数据的音频输出设备为第二设备自身，第二设备不允许播放的音频数据的音频输出设备可以为第一设备等其他电子设备。
那么，若第一设备根据上述设备选择策略确定出第一音频数据不允许在第二设备中播放，则第一设备可根据第一音频数据的第一类型在设备选择策略中查询第一音频数据具体的音频输出设备为第三设备(第三设备与第二设备不同)；进而，第一设备 可将待播放的第一音频数据发送至第三设备进行播放。这样，不适合在第二设备中播放的第一音频数据可以被分流至第三设备中播放，避免第一设备中待播放的音频数据被遗漏。
在一种可能的设计方法中，上述第三设备可以为除第二设备外最近接入第一设备的音频输出设备。即当第一音频数据不适合在第二设备上播放时，第一设备可遵循后接入后优先的原则为第一音频数据选择音频输出设备。
在一种可能的设计方法中，上述设备选择策略具体可以包括：不同类型的音频数据与不同音频输出设备之间的对应关系；例如，音乐类型的音频数据的音频输出设备为电视、音箱和手机。此时，第一设备根据第一类型和设备选择策略确定第一音频数据是否允许在第二设备中播放，包括：第一设备可在设备选择策略中查询与第一类型的音频数据对应的音频输出设备是否包含第二设备；若包含第二设备，则第一设备确定第一音频数据允许在第二设备中播放；若不包含第二设备，则第一设备确定第一音频数据不允许在第二设备中播放。
在一种可能的设计方法中，上述设备选择策略具体可以包括：不同应用、不同类型的音频数据与不同音频输出设备之间的对应关系；例如，微信应用内产生的音乐类型的音频数据的音频输出设备为电视、音箱和手机。此时，第一设备根据第一类型和设备选择策略确定第一音频数据是否允许在第二设备中播放，包括：第一设备确定第一音频数据来自于第一应用；进而，第一设备可在设备选择策略中查询与第一类型和第一应用对应的音频输出设备是否包含第二设备；若包含第二设备，则第一设备确定第一音频数据允许在第二设备中播放；若不包含第二设备，则第一设备确定第一音频数据不允许在第二设备中播放。
示例性的，当第二设备为音箱类型的电子设备时，可在在设备选择策略中设置第二设备允许播放音乐类型的音频数据，第二设备不允许播放通知类型的音频数据；这样，第一设备可将音乐类型的音频数据投射至音箱播放，而不会将通知类型的音频数据投射至音箱播放，避免用户在使用音箱播放音频时受到第一设备中通知音的打扰。
示例性的，当第二设备为车载设备类型的电子设备时，可在设备选择策略中设置第二设备允许播放导航类型的音频数据，第二设备不允许播放通知类型的音频数据；这样，第一设备可将导航类型的音频数据投射至车载设备播放，而不会将通知类型的音频数据投射至车载设备播放，避免用户在使用车载设备播放音频时受到第一设备中通知音的打扰。
示例性的，当第二设备为大屏设备类型的电子设备时，可在设备选择策略中设置第二设备允许播放来自第一应用的音频数据，第二设备不允许播放来自第二应用的音频数据。这样，第一设备可将第一应用的音频数据投射至大屏设备播放，而不会将第二应用的音频数据投射至大屏设备播放，避免用户在使用大屏设备播放音频时受到第一设备中某一应用产生音频的打扰。
示例性的，无论上述第二设备为音箱类型、车载设备类型、大屏设备类型还是其他类型的电子设备，第一设备具体可以为手机、平板电脑或笔记本电脑等运算和处理能力较强的电子设备。
在一种可能的设计方法中，第一设备的应用程序层安装有预设应用，例如DV APP， 第一设备的应用程序框架层包括音频策略模块，例如AudioPolicy；其中，第一设备获取与第二设备对应的设备选择策略，包括：当第一设备与第二设备建立网络连接后，预设应用可确定第二设备的设备类型；进而，预设应用可按照第二设备的设备类型获取对应的设备选择策略；并将设备选择策略下发至音频策略模块。即第一设备中可预先存储多种音频输出设备的设备选择策略，第一设备可根据当前连接的第二设备的设备类型动态的将对应的设备选择策略下发给AudioPolicy，从而按照设备选择策略及时调整音频数据的音频输出设备。
在一种可能的设计方法中，第一设备的应用程序框架层还包括音频处理器，例如AudioFlinger；其中，第一设备根据第一类型以及设备选择策略确定第一音频数据是否允许在第二设备中播放，包括：当音频处理器接收到第一音频数据后，可向音频策略模块发送查询请求，查询请求中包括第一类型的标识；那么，响应于查询请求，音频策略模块可根据设备选择策略确定第一类型的第一音频数据是否允许在第二设备中播放。
在一种可能的设计方法中，在第一设备与第二设备建立网络连接之后，还包括：第一设备在硬件抽象层HAL创建与第二设备对应的第一硬件抽象模块，例如DMSDP Audio HAL；其中，若第一音频数据允许在第二设备中播放，则第一设备将第一音频数据发送至第二设备进行播放，包括：音频处理器接收到音频策略模块发送的第一指示，第一指示用于指示第一音频数据的音频输出设备为第二设备；响应于第一指示，音频处理器可调用第一硬件抽象模块将第一音频数据发送至第二设备。
在一种可能的设计方法中，HAL中还包括与第三设备对应的第二硬件抽象模块，例如Primary HAL、A2dp HAL等；上述方法还包括：音频处理器接收到音频策略模块发送的第二指示，第二指示用于指示第一音频数据的音频输出设备为第三设备，即第一音频数据不允许在第二设备上播放；那么，响应于第二指示，音频处理器可调用第二硬件抽象模块将第二音频数据发送至第三设备。
在一种可能的设计方法中，在第一设备获取与第二设备对应的设备选择策略之后，还包括：第一设备显示音频输出设备的设置界面；第一设备接收用户在设置界面中设置与第二设备对应的设备选择策略；响应于用户的设置，第一设备更新设备选择策略。这样，用户可以按照自身的需要在设置界面中设置或修改在各个音频输出设备上允许播放的音频类型，即对各个音频输出设备设置对应的设备选择策略，使各种类型的音频数据能够按照用户的设置被第一设备分发到相应的音频输出设备上播放。
在一种可能的设计方法中，上述方法还包括：在第二设备播放第一音频数据时，第一设备获取待播放的第二音频数据(第二音频数据的类型为第二类型)，即待播放的音频数据同时包括第一音频数据和第二音频数据；进而，第一设备可根据上述第二类型和设备选择策略确定第二音频数据是否允许在第二设备中播放；若第二音频数据允许在第二设备中播放，则第一设备可将第一音频数据和第二音频数据混音后发送至第二设备进行播放；或者，第一设备可将未经混音的第一音频数据和第二音频数据发送至第二设备进行播放，本申请实施例对此不做任何限制。
在一种可能的设计方法中，上述方法还包括：当第一设备停止向第二设备发送第一音频数据后，第一设备获取待播放的第二音频数据(第二音频数据的类型为第二类 型)，即待播放的音频数据从第一音频数据变为第二音频数据；进而，与上述第一音频数据类似的，第一设备可根据上述第二类型和设备选择策略确定第二音频数据是否允许在第二设备中播放；若第二音频数据允许在第二设备中播放，则第一设备将第二音频数据发送至第二设备进行播放。这样，在播放不同类型的音频数据时，第一设备可根据设备选择策略动态的确定每路音频数据的音频输出设备，使得每路音频数据可以在最合适的音频输出设备上播放。
当然，如果第一设备连接的从设备从第二设备更新为第三设备，则与第一设备将音频数据切换至第二设备播放的过程类似的，第一设备还可以按照第三设备(即新的从设备)的设备选择策略为此时待播放的音频数据选择合适的音频输出设备播放。
第八方面，本申请提供一种音频控制方法，包括：当第一设备与第二设备建立网络连接后，第一设备可将第二设备作为从设备，获取与第二设备对应的混音策略；后续，当第一设备获取到待播放的第一音频数据(第一音频数据的类型为第一类型)和第二音频数据(第二音频数据为第二类型)时，说明当前有多路音频数据需要同时播放，此时第一设备可根据上述第一类型、第二类型以及混音策略确定是否需要对第一音频数据和第二音频数据混音；若不需要对第一音频数据和第二音频数据混音，则第一设备可将未混音的第一音频数据和第二音频数据发送至第二设备进行播放；相应的，若需要对第一音频数据和第二音频数据混音，则第一设备可将第一音频数据和第二音频数据混音为第三音频数据，那么，混音后的第三音频数据中第一音频数据和/或第二音频数据的音频特征(例如响度、频率等)会发生改变；进而，第一设备可将混音后的第三音频数据发送至第二设备进行播放。
可以看出，第一设备(即主设备)在将多路音频数据输出至第二设备(即从设备)进行音频切换时，可按照对应的混音策略对其中的一些音频数据不进行混音便发送给第二设备。这样，第二设备从第一设备获取到的第一音频数据和第二音频数据是没有经过混音处理的，因此第一音频数据和第二音频数据可以较为真实的反映出其音频特征，第二设备得到的待播放的第一音频数据和第二音频数据不存在由于第一设备的混音处理而带来的失真现象，这样，第二设备在播放上述第一音频数据和第二音频数据时产生的失真现象也相应减少，从而降低多路音频数据在跨设备播放时的失真情况，提高音频切换场景的音频输出质量。
在一种可能的实现方式中，上述混音策略具体可以包括：需要混音的音频数据的类型和/或不需要混音的音频数据的类型；
其中，第一设备根据第一类型、第二类型以及混音策略确定是否需要对第一音频数据和第二音频数据混音，包括：第一设备在混音策略中查询第一类型的音频数据是否需要混音，以及第二类型的音频数据是否需要混音；若第一类型的音频数据和第二类型的音频数据中的至少一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音；若第一类型的音频数据和第二类型的音频数据都需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音。
在一种可能的实现方式中，上述混音策略具体可以包括：需要混音的音频数据的类型以及需要混音的音频数据来自的应用，和/或，不需要混音的音频数据的类型以及不需要混音的音频数据来自的应用；
其中，第一设备根据第一类型、第二类型以及混音策略确定是否需要对第一音频数据和第二音频数据混音，包括：第一设备确定第一音频数据来自于第一应用，第二音频数据来自于第二应用；进而，第一设备可在混音策略中查询来自第一应用的第一类型的音频数据是否需要混音，以及来自第二应用的第二类型的音频数据是否需要混音；若来自第一应用的第一类型的音频数据与来自第二应用的第二类型的音频数据中的至少一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音；若来自第一应用的第一类型的音频数据和来自第二应用的第二类型的音频数据都需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音。
在一种可能的实现方式中，上述混音策略具体可以包括：不同类型的音频数据与不允许混音的音频输出设备之间的对应关系；例如，与音乐类型的音频数据对应的不允许混音的音频输出设备包括手机、音箱和电视。
其中，第一设备根据第一类型、第二类型以及混音策略确定是否需要对第一音频数据和第二音频数据混音，包括：第一设备在混音策略中查询与第一类型的音频数据对应的第一音频输出设备是否包含第二设备；并且，第一设备在混音策略中查询与第二类型的音频数据对应的第二音频输出设备是否包含第二设备；若第一音频输出设备包含第二设备和/或第二音频输出设备包含第二设备，即第一音频数据和第二音频数据中至少有一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音；若第一音频输出设备不包含第二设备且第二音频输出设备不包含第二设备，即第一音频数据和第二音频数据均需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音。
也就是说，第一设备可根据当前多路音频数据的类型和当前从设备(即第二设备)的类型在上述混音策略中查询第二设备是否允许对每一路音频数据进行混音。如果有一路音频数据不允许混音，则第一设备可将该路音频数据独立传输给第二设备，降低因混音对音频数据造成的失真。
可以理解的是，也可以在混音策略中设置不同类型的音频数据与允许混音的音频输出设备之间的对应关系；例如，与通知类型的音频数据对应的允许混音的音频输出设备包括耳机和电视。
此时，与上述方法对应的，第一设备可在混音策略中查询与第一类型的音频数据对应的第一音频输出设备是否包含第二设备；并且，第一设备在混音策略中查询与第二类型的音频数据对应的第二音频输出设备是否包含第二设备；若第一音频输出设备包含第二设备且第二音频输出设备包含第二设备，说明第一音频数据和第二音频数据均需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音；若第一音频输出设备不包含第二设备和/或第二音频输出设备不包含第二设备，说明第一音频数据和第二音频数据中至少有一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音。
在一种可能的实现方式中，上述混音策略具体可以包括：不同类型的音频数据、不同应用与不允许混音的音频输出设备之间的对应关系；例如，与来自微信APP的音乐类型的音频数据对应的不允许混音的音频输出设备包括手机、音箱和电视。
其中，第一设备根据第一类型、第二类型以及混音策略确定是否需要对第一音频 数据和第二音频数据混音，包括：第一设备确定第一音频数据来自于第一应用，第二音频数据来自于第二应用；并且，第一设备在混音策略中查询与第一应用、第一类型对应的第一音频输出设备是否包含第二设备；进而，第一设备可在混音策略中查询与第二应用、第二类型对应的第二音频输出设备是否包含第二设备；若第一音频输出设备包含第二设备和/或第二音频输出设备包含第二设备，即第一音频数据和第二音频数据中至少有一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音；若第一音频输出设备不包含第二设备且第二音频输出设备不包含第二设备，即第一音频数据和第二音频数据均需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音。
类似的，也可以在混音策略中设置不同类型的音频数据、不同应用与允许混音的音频输出设备之间的对应关系；例如，与来自视频APP的通知类型的音频数据对应的允许混音的音频输出设备包括耳机和电视。
此时，与上述方法对应的，第一设备可在混音策略中查询与第一类型以及第一应用对应的第一音频输出设备是否包含第二设备；并且，第一设备在混音策略中查询与第二类型以及第二应用对应的第二音频输出设备是否包含第二设备；若第一音频输出设备包含第二设备且第二音频输出设备包含第二设备，说明第一音频数据和第二音频数据均需要混音，则第一设备可确定需要对第一音频数据和第二音频数据混音；若第一音频输出设备不包含第二设备和/或第二音频输出设备不包含第二设备，说明第一音频数据和第二音频数据中至少有一个不需要混音，则第一设备可确定不需要对第一音频数据和第二音频数据混音。
示例性的，当第二设备为音箱类型的电子设备时，可在混音策略中设置向第二设备发送音乐类型的音频数据时不需要混音；这样，第一设备可将音乐类型的音频数据不与其他音频数据混音、独立的投射至第二设备播放，使第二设备在播放音乐类型的音频数据时降低音频的失真现象。
示例性的，当第二设备为车载设备类型的电子设备时，可在混音策略中设置向第二设备发送导航类型的音频数据时不需要混音；这样，第一设备可将导航类型的音频数据不与其他音频数据混音、独立的投射至第二设备播放，使第二设备在播放导航类型的音频数据时降低音频的失真现象。
示例性的，当第二设备为大屏设备类型的电子设备时，可在混音策略中设置向第二设备发送通知类型的音频数据时需要混音。也就是说，当需要向第二设备发送包含通知类型的多路音频数据时，由于用户在大屏设备上对通知音的关注度不高，因此，第一设备可将通知类型的音频数据与其他音频数据混音后发送至第二设备播放。
可以看出，当需要向从设备输出多路音频数据时，主设备可根据当前从设备的混音策略选择对多路音频数据中的某些音频数据不做混音处理，独立传输给从设备进行播放，从而避免因混音处理对某一类型的音频数据造成的失真现象，提高音频切换场景的音频输出质量。
在一种可能的实现方式中，第一设备将第一音频数据和第二音频数据发送至第二设备，包括：第一设备对第一音频数据进行打包，得到至少一个第一数据包；第一设备对第二音频数据进行打包，得到至少一个第二数据包；第一设备将第一数据包和第 二数据包发送至第二设备。
示例性的，上述第一数据包内包括第一标识，第一标识用于指示第一音频数据；第二数据包内包括第二标识，第二标识用于指示第二音频数据。后续，第二设备可根据第一数据包内的第一标识和第二数据包内的第二标识还原出对应的未经混音的第一音频数据和第二音频数据。
示例性的，上述第一数据包内包括第一特征信息，第一特征信息用于指示第一音频数据的音频特征；第二数据包内包括第二特征信息，第二特征信息用于指示第二音频数据的音频特征。
例如，第一特征信息可以包括第一音频数据所属的应用、第一音频数据的类型、第一音频数据的音量等级、第一音频数据的播放格式以及第一音频数据的音轨信息中的至少一个；第二特征信息可以包括第二音频数据所属的应用、第二音频数据的类型、第二音频数据的音量等级、第二音频数据的播放格式以及第二音频数据的音轨信息中的至少一个。
这些特征信息能够反映出音频数据实际的音频特征，使得接收到该数据包的第二设备通过解析数据包中的特征信息能够真实的还原出音频数据以及音频数据的相关特征，从而按照音频数据的特征信息播放对应的音频数据，减少音频数据在音频切换过程中的失真现象。
示例性的，无论上述第二设备为音箱类型、车载设备类型、大屏设备类型还是其他类型的电子设备，第一设备具体可以为手机、平板电脑或笔记本电脑等运算和处理能力较强的电子设备。
在一种可能的实现方式中，当第一设备与第二设备建立网络连接后，还包括：第一设备获取与第二设备对应的设备选择策略；在第一设备获取到待播放的第一音频数据和第二音频数据之后，还包括：第一设备根据第一类型、第二类型以及设备选择策略确定第一音频数据和第二音频数据的音频输出设备为第二设备。也就是说，当第一设备中待播放的音频数据有多路时，第一设备可先确定这多路音频数据中每一路音频数据的音频输出设备。如果有多路音频数据的音频输出设备相同，则第一设备可进一步按照混音策略确定是否对这多路音频数据进行混音。
在一种可能的实现方式中，第一设备的应用程序层安装有预设应用，例如DV APP，第一设备的应用程序框架层包括音频策略模块，例如AudioPolicy；其中，第一设备获取与第二设备对应的混音策略，包括：预设应用确定第二设备的设备类型；预设应用按照第二设备的设备类型获取对应的混音策略；预设应用将混音策略下发至音频策略模块。即第一设备中可预先存储多种音频输出设备的混音策略，第一设备可根据当前连接的第二设备的设备类型动态的将对应的混音策略下发给AudioPolicy，从而按照混音策略及时调整音频数据是否进行混音。
在一种可能的实现方式中，第一设备的应用程序框架层还包括音频处理器，例如AudioFlinger；其中，第一设备获取到待播放的第一音频数据和第二音频数据，包括：当音频处理器获取到来自应用程序层的第一音频数据和第二音频数据后，音频处理器可向音频策略模块发送查询请求，该查询请求中包括第一类型的标识和第二类型的标识；那么，响应于查询请求，音频策略模块可根据混音策略确定是否需要对第一类型 的第一音频数据和第二类型的第二音频数据混音。
在一种可能的实现方式中，在第一设备与第二设备建立网络连接之后，还包括：第一设备在硬件抽象层HAL创建与第二设备对应的硬件抽象模块，例如DMSDP Audio HAL；其中，若不需要对第一音频数据和第二音频数据混音，则方法还包括：音频处理器可接收到音频策略模块发送的第一指示，第一指示用于指示对第一音频数据和第二音频数据不进行混音；那么，响应于第一指示，音频处理器可将第一音频数据封装为至少一个第一数据包，并将第一数据包存储在音频处理器的缓存(buffer)中；并且，响应于第一指示，音频处理器可将第二音频数据封装为至少一个第二数据包，并将第二数据包存储在音频处理器的缓存中；进而，音频处理器将音频处理器的缓存中的第一数据包和第二数据包发送给硬件抽象模块。
此时，第一设备将第一音频数据和第二音频数据发送至第二设备，包括：硬件抽象模块可将音频处理器的缓存中的第一数据包和第二数据包发送给第二设备，使得第二设备通过解析第一数据包和第二数据包还原出第一音频数据和第二音频数据，此时，第一设备无需对第一数据包和第二数据包进行解析；或者；硬件抽象模块可先解析第一数据包和第二数据包，还原出对应的第一音频数据和第二音频数据，再将第一音频数据和第二音频数据发送至第二设备，此时，第二设备无需再解析第一设备发来的音频数据。
在一种可能的实现方式中，在第一设备获取与第二设备对应的混音策略之后，还包括：第一设备显示音频输出设备的设置界面；第一设备接收用户在设置界面中设置与第二设备对应的混音策略；响应于用户的设置，第一设备更新混音策略。这样，用户可以按照自身的需要在设置界面中设置或修改向各个音频输出设备发送音频数据时需要或不需要混音的音频类型，即对各个音频输出设备设置对应的混音策略，使各种类型的音频数据在从设备上进行切换时能够按照用户的设置进行混音或不混音。
在一种可能的实现方式中，上述方法还包括：在第一设备获取到第一音频数据和第二音频数据时，第一设备还可以获取到待播放的第三音频数据(第三音频数据的类型为第三类型)，即待播放的音频数据同时包括三路音频数据；进而，第一设备可根据第一类型、第二类型、第三类型以及混音策略，确定出第一音频数据不需要混音，第二音频数据和第三音频数据需要混音；那么，第一设备可将第一音频数据单独不经过混音发送至第二设备，并且，第一设备将第二音频数据和第三音频数据混音后发送至第二设备。
当然，第一设备根据上述混音策略也可能确定出第一音频数据、第二音频数据和第三音频数据均不需要混音，或者，第一音频数据、第二音频数据和第三音频数据均需要混音，本申请实施例对此不做任何限制。
另外，如果第一设备连接的从设备从第二设备更新为第三设备，则与第一设备将多路音频数据切换至第二设备播放的过程类似的，第一设备还可以按照第三设备(即新的从设备)的混音策略确定此时待播放的多路音频数据是否需要混音。
第九方面，本申请提供一种音频控制方法，包括：第二设备与第一设备建立网络连接；第二设备从第一设备获取未经混音的第一音频数据和第二音频数据，第一音频数据的类型为第一类型，第二音频数据为第二类型；第二设备播放第一音频数据和第 二音频数据。
在一种可能的实现方式中，第二设备从第一设备获取未经混音的第一音频数据和第二音频数据，包括：第二设备从第一设备获取与第一音频数据对应的第一数据包以及与第二音频数据对应的第二数据包；第二设备通过解析第一数据包和第二数据包还原出第一音频数据和第二音频数据。
在一种可能的实现方式中，第一数据包内包括第一标识，第一标识用于指示第一音频数据；第二数据包内包括第二标识，第二标识用于指示第二音频数据；其中，第二设备通过解析第一数据包和第二数据包还原出第一音频数据和第二音频数据，包括：第二设备通过解析第一数据包和第二数据包，将携带有第一标识的数据包中的音频数据还原为第一音频数据，将携带有第二标识的数据包中的音频数据还原为第二音频数据。
在一种可能的实现方式中，第一数据包内包括第一特征信息，第一特征信息用于指示第一音频数据的音频特征；第二数据包内包括第二特征信息，第二特征信息用于指示第二音频数据的音频特征；其中，第二设备播放第一音频数据和第二音频数据，包括：第二设备按照第一特征信息播放第一音频数据，同时，第二设备按照第二特征信息播放第二音频数据。
第十方面，本申请提供一种多音频任务的播放方法，包括：电子设备在显示界面中显示第一窗口和第二窗口，其中，第一窗口中运行有第一应用，第二窗口中运行有第二应用，此时，电子设备进入分屏模式；进而，电子设备可接收用户输入的第一操作；响应于第一操作，电子设备可建立第一窗口与第一音频输出设备的关联关系，即用户可手动设置与第一窗口关联的音频输出设备为第一音频输出设备；同样，如果电子设备接收到用户输入的第二操作，电子设备可建立第二窗口与第二音频输出设备的关联关系，即用户可手动设置与第二窗口关联的音频输出设备为第二音频输出设备；这样，当电子设备获取到来自第一应用的第一音频数据时，电子设备可根据第一窗口与第一音频输出设备的关联关系，将第一音频数据发送至第一音频输出设备播放；类似的，当电子设备获取到来自第二应用的第二音频数据时，电子设备可根据第二窗口与第二音频输出设备的关联关系，将第二音频数据发送至第二音频输出设备播放。
也就是说，当电子设备中运行有多个窗口时，每个窗口中音频任务输出的音频数据可使用与该窗口关联的音频输出设备播放。在多窗口多音频任务并发的场景下，电子设备可将每个窗口中相关音频任务输出的音频数据发送给对应的音频输出设备进行播放。这样，电子设备并发的多路音频数据不会互相干扰，这多路音频数据可以通过不同的音频输出设备播放给不同的用户，每个用户可以可以使用与相关窗口关联的音频输出设备收听对应的音频数据，不会受到来自其他窗口的音频数据的影响，从而提高用户的音频使用体验。
在一种可能的实现方式中，在电子设备在显示界面中显示第一窗口和第二窗口之后，还包括：电子设备可在第一窗口中显示第一对话框，第一对话框中包括具有音频播放功能的至少一个第一候选设备，例如，电子设备可将与电子设备位于同一Wi-Fi网络的音频输出设备显示在第一对话框中；其中，上述第一操作是用户在至少一个第一候选设备中选择第一音频输出设备的操作；同样，电子设备可在第二窗口中显示第 二对话框，第二对话框中包括具有音频播放功能的至少一个第二候选设备，例如，电子设备可将与电子设备连接的具有音频播放功能的音频输出设备显示在第二对话框中；其中，上述第二操作是用户在至少一个第二候选设备中选择第二音频输出设备的操作。
在一种可能的实现方式中，电子设备建立第一窗口与第一音频输出设备的关联关系，具体包括：电子设备可记录第一窗口的第一音频配置信息，第一音频配置信息中包括第一窗口与第一音频输出设备的关联关系；同样，电子设备建立第二窗口与第二音频输出设备的关联关系，具体包括：电子设备可记录第二窗口的第二音频配置信息，第二音频配置信息包括第二窗口与第二音频输出设备的关联关系。
在一种可能的实现方式中，上述方法还包括：当第一应用在第一窗口中运行时，电子设备可记录第一窗口与第一应用之间的第一对应关系，即第一窗口的应用信息，用于指示在第一窗口中运行的应用；同样，当第二应用在第二窗口中运行时，电子设备可记录第二窗口与第二应用之间的第二对应关系，即第二窗口的应用信息，用于指示在第二窗口中运行的应用。
示例性的，电子设备记录第一窗口与第一应用之间的第一对应关系，具体包括：第一应用可申请获取第一窗口的第一音频焦点；当第一应用获取到第一音频焦点时，电子设备可记录第一窗口与第一应用之间的第一对应关系；同样，电子设备记录第二窗口与第二应用之间的第二对应关系，具体包括：第二应用申请获取第二窗口的第二音频焦点；当第二应用获取到第二音频焦点时，电子设备可记录第二窗口与第二应用之间的第二对应关系。
也就是说，电子设备在分屏模式中可为每个窗口设置一个音频焦点(Audio Focus)。每个窗口中的应用需要播放音频任务时需要先获取到该窗口的音频焦点，电子设备可维护每个窗口对应的音频焦点应用，以便获取到待播放的音频数据时确定该音频数据来自哪个窗口中的音频焦点应用。
在一种可能的实现方式中，在电子设备将第一音频数据发送至第一音频输出设备播放之前，还包括：电子设备确定第一音频数据来自于第一应用；进而，电子设备根据上述第一对应关系，可确定与第一音频数据对应的第一窗口；进而，电子设备可根据第一音频配置信息，确定第一音频数据的音频输出设备为与第一窗口关联的第一音频输出设备。
类似的，在电子设备将第二音频数据发送至第二音频输出设备播放之前，还包括：电子设备确定第二音频数据来自于第二应用；进而，电子设备根据上述第二对应关系，确定与第二音频数据对应的第二窗口；进而，电子设备可根据第二音频配置信息，确定第二音频数据的音频输出设备为与第二窗口关联的第二音频输出设备。
在一种可能的实现方式中，第一音频配置信息还可以包括：允许在第一音频输出设备中播放的音频数据的类型，和/或，允许在第一音频输出设备中播放的音频数据的音量大小；第二音频配置信息还可以包括：允许在第二音频输出设备中播放的音频数据的类型，和/或，允许在第二音频输出设备中播放的音频数据的音量大小。这样，电子设备可以根据第一音频配置信息和第二音频配置信息将特定类型的音频数据输出至相应的音频输出设备中播放，并控制相应音频数据的音量大小。
在一种可能的实现方式中，如果上述第一音频配置信息包括允许在第一音频输出 设备中播放的音频数据的音量大小；则在电子设备在显示界面中显示第一窗口和第二窗口之后，还包括：电子设备在第一窗口中显示第一音量调节条；若检测到用户在第一音量调节条上输入第一音量调节操作，则电子设备可修改第一音频配置信息中第一类型的音频数据的音量大小，从而控制在第一音频输出设备中输出的音频的音量，第一类型为第一窗口中正在播放的音频数据的类型或预设的音频数据的类型。
在一种可能的实现方式中，如果上述第二音频配置信息包括允许在第二音频输出设备中播放的音频数据的音量大小；则在电子设备在显示界面中显示第一窗口和第二窗口之后，还包括：电子设备在第二窗口中显示第二音量调节条；若检测到用户在第二音量调节条上输入第二音量调节操作，则电子设备可修改第二音频配置信息中第二类型的音频数据的音量大小，从而控制在第二音频输出设备中输出的音频的音量，第二类型为第二窗口中正在播放的音频数据的类型或预设的音频数据的类型。
在一种可能的实现方式中，在电子设备建立第一窗口与第一音频输出设备的关联关系之后，还包括：响应于用户输入的第三操作，电子设备更新第一音频配置信息，更新后的第一音频配置信息包括第一窗口与第三音频输出设备的关联关系。
在一种可能的实现方式中，在电子设备建立第二窗口与第二音频输出设备的关联关系之后，还包括：响应于用户输入的第四操作，电子设备更新第二音频配置信息，更新后的第二音频配置信息包括第二窗口与第四音频输出设备的关联关系。
也就是说，用户可以手动更新与各个窗口相关联的音频输出设备，从而按照自身的需要以窗口为粒度设置各个窗口的音频输出设备，使各个窗口中的音频数据能够按照用户的设置被分发到相应的音频输出设备上播放。
在一种可能的实现方式中，电子设备的应用程序框架层包括音频策略模块(例如AudioPolicy)和音频处理器(例如AudioFlinger)，方法还包括：当音频处理器接收到第一音频数据时，音频处理器向音频策略模块发送第一查询请求；响应于第一查询请求，音频策略模块可确定第一音频数据的音频输出设备为第一音频输出设备；类似的，当音频处理器接收到第二音频数据时，音频处理器向音频策略模块发送第二查询请求；响应于第二查询请求，音频策略模块可确定第二音频数据的音频输出设备为第二音频输出设备。
在一种可能的实现方式中，电子设备的应用程序框架层包括窗口管理器，窗口管理器可用于将第一窗口与第一应用的第一对应关系、第二窗口与第二应用的第二对应关系、第一窗口的第一音频配置信息以及第二窗口的第二音频配置信息发送至音频策略模块。这样，音频策略模块可根据这些参数确定上述第一音频数据和第二音频数据的音频输出设备。
并且，当窗口与应用的对应关系更新，或者窗口与音频输出设备的对应关系更新时，窗口管理器可将更新后的应用信息和音频配置信息发送给音频策略模块，以便音频策略模块按照最新的应用信息和音频配置信息确定每个窗口对应的音频输出设备。
在一种可能的实现方式中，电子设备的HAL中包括与第一音频输出设备对应的第一音频抽象模块以及与第二音频输出设备对应的第二音频抽象模块；其中，电子设备将第一音频数据发送至第一音频输出设备，包括：音频处理器通过第一音频抽象模块将第一音频数据发送至第一音频输出设备；其中，电子设备将第二音频数据发送至第 二音频输出设备，包括：音频处理器通过第二音频抽象模块将第二音频数据发送至第二音频输出设备。
例如，第一音频输出设备可以为音箱，第一音频抽象模块可以为DMSDP Audio HAL，AudioFlinger可将第一音频数据通过DMSDP Audio HAL发送给音箱播放。又例如，第二音频输出设备可以为蓝牙耳机，第二音频抽象模块可以为A2dp HAL，AudioFlinger可将第二音频数据通过A2dp HAL发送给蓝牙耳机播放。
在一种可能的实现方式中，电子设备的HAL包括显示抽象模块(例如Display HAL)；上述方法还包括：显示抽象模块获取与第一窗口对应的第一显示数据以及与第二窗口对应的第二显示数据；进而，显示抽象模块可将第一显示数据和第二显示数据合成为与显示界面对应的第三显示数据。
示例性的，如果电子设备的显示输出设备为电子设备的显示屏，则在显示抽象模块将第一显示数据和第二显示数据合成为第三显示数据之后，还包括：显示抽象模块将第三显示数据发送至电子设备的显示屏进行显示。
示例性的，如果电子设备的显示输出设备为第一显示设备(例如电视)，则在显示抽象模块将第一显示数据和第二显示数据合成为待显示的第三显示数据之后，还包括：显示抽象模块将第三显示数据发送至第一显示设备进行显示。
也就是说，在分屏模式的投屏场景下，可由主设备分别控制显示数据和音频数据的分发过程，由主设备将不同窗口中的音频数据分发至相应的音频输出设备中播放。
或者，除了将第三显示数据发送至第一显示设备进行显示之外，当电子设备的显示输出设备为第一显示设备时，电子设备根据第一窗口与第一音频输出设备的关联关系，将第一音频数据发送至第一音频输出设备播放，具体包括：电子设备将第一音频数据和第一窗口与第一音频输出设备的关联关系发送给第一显示设备，以使得第一显示设备可按照第一窗口与第一音频输出设备的关联关系，将第一音频数据发送至第一音频输出设备播放；同样，电子设备根据第二窗口与第二音频输出设备的关联关系，将第二音频数据发送至第二音频输出设备播放，具体包括：电子设备将第二音频数据和第二窗口与第二音频输出设备的关联关系发送给第一显示设备，以使得第一显示设备可按照第二窗口与第二音频输出设备的关联关系，将第二音频数据发送至第二音频输出设备播放。
也就是说，在分屏模式的投屏场景下，主设备可将各个窗口中产生的显示数据和音频数据均发送给从设备。并且，主设备可将各个窗口的应用信息和音频配置信息一并发送给从设备，使得从设备可按照该应用信息和音频配置信息将主设备中不同窗口的音频数据分发至相应的音频输出设备中播放，实现多窗口之间音频数据互不干扰的隔离效果。
在一种可能的实现方式中，电子设备的HAL可包括显示抽象模块(例如Display HAL)；如果与第一窗口对应的显示输出设备为第一显示设备，与第二窗口对应的显示输出设备为第二显示设备；则上述方法还包括：显示抽象模块可获取与第一窗口对应的第一显示数据，并将第一显示数据发送至第一显示设备进行显示；并且，显示抽象模块可获取与第二窗口对应的第二显示数据，并将第二显示数据发送至第二显示设备进行显示。也就是说，当在分屏模式下，电子设备可将不同窗口中的显示数据发送 给不同的显示输出设备(包括手机自身)进行显示，实现以窗口为粒度的投屏功能。此时，各个显示输出设备中的显示数据不会互相干扰，各个显示输出设备中的音频数据也不会互相干扰，从而提高用户的音频使用体验。
第十一方面，本申请提供一种录屏方法，包括：响应于用户打开第一设备中录屏功能的操作，第一设备可显示录屏设备列表，该录屏设备列表中包括与第一设备接入同一通信网络(例如同一Wi-Fi网络)的一个或多个电子设备；如果检测到用户在上述录屏设备列表中选择第二设备，一方面，第一设备可向第二设备发送录屏指令，以使得第二设备可响应该录屏指令执行录屏操作；另一方面，第一设备可以执行录屏操作，得到第一设备的第一屏幕数据；并且，第一设备可获取到第二设备执行录屏操作得到的第二屏幕数据；这样，第一设备根据第一屏幕数据和第二屏幕数据生成本次录屏文件。
也就是说，用户在录屏场景下可在第一设备中选择同时录制第一设备和第二设备等多个设备中的屏幕数据。第一设备可根据两个设备录制得到的屏幕数据生成本次录屏文件，该录屏文件既可以还原第一设备的音频和画面，还可以还原第二设备的音频和画面，从而更加全面的记录和还原在第一设备和第二设备上实现的业务场景，提高用户在分布式系统中的使用体验。
在一种可能的实现方式中，上述第一屏幕数据可以包括第一显示数据和第一音频数据；第一显示数据包括：第一设备播放的显示数据(例如第一设备中显示屏幕播放的显示数据)和/或第一设备采集的显示数据(例如第一设备的摄像头采集的显示数据)；第一音频数据包括：第一设备播放的音频数据(例如第一设备的扬声器或听筒播放的音频数据)和/或第一设备采集的音频数据(例如第一设备的麦克风或耳机采集的音频数据)。
也就是说，第一设备进行录屏时，录制的显示数据的来源可以有多种，录制的音频数据的来源也可以有多种，本申请实施例对此不做任何限制。
在一种可能的实现方式中，在第一设备执行录屏操作，得到第一设备的第一屏幕数据之前，还包括：第一设备获取第一设备执行录屏操作使用的第一录屏参数，第一录屏参数包括显示录制参数和音频录制参数；其中，显示录制参数可以包括录屏时使用的分辨率、DPI等录制显示数据时需要使用的参数。又例如，显示录制参数还可以指示本次录制的显示数据的具体来源，例如，录制来源于摄像头采集的显示数据，或录制显示屏中播放的显示数据。类似的，音频录制参数可以包括第一设备对音频数据的采样率、音效设置等录制音频数据时需要使用的参数。又例如，音频录制参数还可以指示本次录制的音频数据的具体来源，例如，录制来源于扬声器播放的音频数据，或录制来源于麦克风采集的音频数据。
此时，第一设备执行录屏操作，得到第一设备的第一屏幕数据，具体包括：第一设备按照上述显示录制参数录制得到第一显示数据；第一设备按照上述音频录制参数录制得到第一音频数据。
当然，上述第一录屏参数中也可以仅包括显示录制参数或音频录制参数。例如，当第一录屏参数中仅包括显示录制参数时，第一设备可按照显示上述录制参数录制得到第一显示数据，此时第一显示数据即为第一设备录制的第一屏幕数据。又例如，当 第一录屏参数中仅包括显示音频参数时，第一设备可按照上述音频录制参数录制得到第一音频数据，此时第一音频数据即为第一设备录制的第一屏幕数据。
在一种可能的实现方式中，在第一设备向第二设备发送录屏指令之前，还包括：第一设备获取第二设备执行录屏操作使用的第二录屏参数，与上述第一录屏参数类似的，第二录屏参数包括显示录制参数(例如分辨率、DPI等)和音频录制参数(例如采样率等)；其中，第一设备向第二设备发送录屏指令，包括：第一设备可将上述第二录屏参数携带在录屏指令中发送给第二设备。这样，第二设备可根据录屏指令中携带的第二录屏参数执行录屏操作，得到第二屏幕数据。
在一种可能的实现方式中，第一设备获取上述第一录屏参数和第二录屏参数，具体包括：第一设备可获取第一设备的第一录屏能力参数，第一录屏能力参数用于反映第一设备的录屏能力；并且，第一设备可获取第二设备的第二录屏能力参数，第二录屏能力参数用于反映第二设备的录屏能力；第一设备根据第一录屏能力参数和第二录屏能力参数，可确定与第一设备对应的第一录屏参数以及与第二设备对应的第二录屏参数。
也就是说，在多设备同步录屏时，第一设备作为主设备可结合自身和第二设备的录屏能力确定本次手机与从设备同步录屏时使用的录屏参数。一般，第一录屏参数和第二录屏参数中对处理显示数据和音频数据的参数一般是相同的，例如，第一录屏参数和第二录屏参数中的分辨率、DPI和采样率等参数相同。这样，第一设备使用第一录屏参数录制的第一屏幕数据和第二设备使用第二录屏参数录制的第二屏幕数据能够被制作为统一的录屏文件。
但是，第一录屏参数和第二录屏参数中设置的屏幕数据的来源可以不同。例如，第一录屏参数中可以设置第一设备从显示屏中录制显示数据，第二录屏参数中可以设置第二设备从摄像头录制采集到的显示数据。
在一种可能的实现方式中，当第一录屏能力参数中第一设备的分辨率大于第二录屏能力参数中第二设备的分辨率时，第一录屏参数和第二录屏参数中的分辨率为第二设备的分辨率，即选择较小的分辨率作为第一录屏参数和第二录屏参数中的分辨率，以保证第一设备和第二设备均有能力按照对应录屏参数中的分辨率进行录屏。
或者，当第一录屏能力参数中第一设备的DPI大于第二录屏能力参数中第二设备的DPI时，第一录屏参数和第二录屏参数中的DPI为第二设备的DPI，即选择较小的DPI作为第一录屏参数和第二录屏参数中的DPI，以保证第一设备和第二设备均有能力按照对应录屏参数中的DPI进行录屏。
或者，当第一录屏能力参数中第一设备的采样率大于第二录屏能力参数中第二设备的采样率时，第一录屏参数和第二录屏参数中的采样率为第二设备的采样率，即选择较小的采样率作为第一录屏参数和第二录屏参数中的采样率，以保证第一设备和第二设备均有能力按照对应录屏参数中的采样率进行录屏。
当然，第一设备还可以结合当前的网络带宽、业务场景或用户习惯等因素确定与第一设备对应的第一录屏参数以及与第二设备对应的第二录屏参数，本申请对此不做任何限制。
在一种可能的实现方式中，与上述第一屏幕数据类似的，第二设备录制得到的第 二屏幕数据可以包括第二显示数据和第二音频数据；第二显示数据包括：第二设备播放的显示数据(例如第二设备中显示屏幕播放的显示数据)和/或第二设备采集的显示数据(例如第二设备的摄像头采集的显示数据)；第二音频数据包括：第二设备播放的音频数据(例如第二设备的扬声器或听筒播放的音频数据)和/或第二设备采集的音频数据(例如第二设备的麦克风或耳机采集的音频数据)。
在一种可能的实现方式中，第一设备根据第一屏幕数据和第二屏幕数据生成录屏文件，包括：第一设备将第一显示数据和第二显示数据合成为第三显示数据；进而，第一设备将第三显示数据、第一音频数据和第二音频数据制作为本次录屏文件。也就是说，第一设备可将第一屏幕数据和第二屏幕数据制作为一个录屏文件，录屏文件中的画面包括第一显示数据和第二显示数据。
或者，第一设备可将第一屏幕数据和第二屏幕数据分别制作为两个录屏文件，例如第一文件和第二文件；其中，第一设备根据第一屏幕数据和第二屏幕数据生成录屏文件，包括：第一设备将第一显示数据和第一音频数据制作为第一文件；第一设备将第二显示数据和第二音频数据制作为第二文件。
在一种可能的实现方式中，在第一设备显示录屏设备列表之前，还包括：第一设备检测与第一设备接入同一通信网络的N个电子设备，N为大于0的整数；进而，第一设备可确定这N个电子设备中具有录屏功能的电子设备；这样，第一设备可将确定出的具有录屏功能的电子设备显示在录屏设备列表中供用户选择。
在一种可能的实现方式中，第一设备的应用程序层包括录屏应用，第一设备的应用程序框架层包括屏幕录制器，第一设备的HAL包括预设的硬件抽象模块；其中，第一设备执行录屏操作，得到第一设备的第一屏幕数据，具体包括：录屏应用调用屏幕录制器执行录屏操作，得到第一设备的第一屏幕数据；其中，第一设备获取第二设备执行录屏操作得到的第二屏幕数据，具体包括：屏幕录制器通过硬件抽象模块获取第二设备执行录屏操作得到的第二屏幕数据。
也就是说，第一设备中的屏幕录制器不仅可以录制第一设备自身的第一屏幕数据，还可以指示第一设备的从设备(即第二设备)录制第二设备的第二屏幕数据。进而，屏幕录制器可根据第一屏幕数据和第二屏幕数据生成对应的录屏文件，实现第一设备与第二设备同步录屏的功能。
第十二方面，本申请提供一种录屏方法，包括：响应于用户打开第一设备中录屏功能的操作，第一设备可显示录屏设备列表，该录屏设备列表中包括与第一设备接入同一通信网络(例如同一Wi-Fi网络)的一个或多个电子设备。如果检测到用户在上述录屏设备列表中选择第二设备，说明用户需要对第一设备和第二设备同步进行录屏，此时，第一设备中的录屏应用可从第二设备中获取第二设备的录屏能力参数，并且，录屏应用可获取第一设备的录屏能力参数。进而，录屏应用根据第一设备和第二设备的录屏能力参数，确定本次第一设备录屏使用的第一录屏参数以及第二设备录屏使用的第二录屏参数；录屏应用可将第二录屏参数携带在录屏指令中发送给第二设备，触发第二设备按照第二录屏参数执行录屏操作；同时，录屏应用可调用应用程序框架层的屏幕录制器按照确定出的第一录屏参数执行录屏操作；例如，屏幕录制器可从display模块实时获取显示屏中播放的显示数据(即第一显示数据)，并且，屏幕录制器可调 用AudioRecord从AudioFlinger中实时获取第一设备的扬声器播放的音频数据(即第一音频数据)；这样，屏幕录制器可以实时获取到第一设备录制的第一屏幕数据(第一屏幕数据包括第一显示数据和第一音频数据)。其中，第一显示数据还可以是屏幕录制器从Camera模块获取的摄像头采集的显示数据，第一音频数据还可以是屏幕录制器从AudioFlinger获取的第一设备的麦克风采集的音频数据，本申请对此不做任何限制。屏幕录制器除了可以获取到第一设备录制的第一屏幕数据外，还可以接收第二设备录制得到的第二屏幕数据。进而，屏幕录制器可将第一屏幕数据和第二屏幕数据上报给录屏应用，由录屏应用根据第一屏幕数据和第二屏幕数据制作对应的录屏文件，该录屏文件既可以通过第一屏幕数据还原第一设备的音频和画面，还可以通过第二屏幕数据还原第二设备的音频和画面，从而更加全面的记录和还原在第一设备和第二设备上实现的业务场景。
第十三方面，本申请提供一种音频时延的更新方法，包括：当第一设备与第二设备建立网络连接后，如果第二设备被设置为第一设备的音频输出设备，则第一设备可以动态的获取第一时延、第二时延和第三时延，其中，第一时延是指音频数据在第一设备中处理时产生的时延，第二时延是指音频数据在第一设备与第二设备之间传输时的产生的时延，第三时延是指音频数据在第二设备中播放时产生的时延；这样，第一设备可基于上述第一时延、第二时延以及第三时延动态的确定当前的音频时延，例如，音频时延＝第一时延+第二时延+第三时延；又例如，音频时延L＝k1*第一时延+k2*第二时延+k3*第三时延，k1+k2+k3＝1。
也就是说，当第一设备需要将音频数据投射至第二设备中播放时，第一设备可以根据上述第一时延、第二时延和第三时延动态的计算当前的音频时延。后续，相关应用或播放器每次获取到的音频时延也是第一设备最新计算出的音频时延，该音频时延可以较为准确的反映出当前的音频数据的时延大小。那么，相关应用或播放器按照上述音频时延进行音画同步等同步处理时能够达到更加准确的同步效果，提高用户的使用体验。
在一种可能的实现方式中，在第一设备与第二设备建立网络连接之后，还包括：第一设备获取第二设备的音频能力参数，音频能力参数用于指示第二设备播放音频的硬件能力以及第二设备播放音频的软件能力；此时，第一设备获取第三时延，包括：第一设备从上述音频能力参数中获取第三时延。也就是说，第二设备可计算自身的音频时延(即第三时延)，并将该第三时延携带在音频能力参数中上报给第一设备，使第一设备从第二设备的音频能力参数中获取到第三时延。
在一种可能的实现方式中，在第一设备获取第二设备的音频能力参数之后，还包括：第一设备按照音频能力参数确定音频策略(例如，是否添加音效、是否重采样等第一设备对音频数据的处理过程)；其中，第一设备获取第一时延，包括：第一设备根据音频策略确定上述第一时延。
例如，上述音频策略包括对音频数据的N个处理过程，N为大于0的整数；其中，第一设备根据音频策略确定第一时延，包括：第一设备确定N个处理过程中每个处理过程的耗时；进而，第一设备可基于每个处理过程的耗时计算得到第一时延。例如，第一设备可将N个处理过程中每个处理过程的耗时相加后得到第一时延，即音频数据 在第一设备中处理所需的耗时。
在一种可能的实现方式中，若第二设备被设置为第一设备的音频输出设备，第二设备的音频能力参数是可以动态更新的，例如，第二设备的音效模式等音频能力可以更新，此时，第一设备还可以获取第二设备更新后的音频能力参数；并且，第一设备可以按照更新后的音频能力参数更新音频策略；当音频能力参数更新时，可触发第一设备根据更新后的音频能力参数更新上述第三时延；当音频策略更新时，可触发第一设备根据更新后的音频策略更新上述第一时延。也就是说。上述第一时延和第三时延是可以动态更新的，从而保证第一设备可以获取到最新的音频时延。
在一种可能的实现方式中，第一设备的HAL中可以包括用于传输音频数据的第一硬件抽象模块，例如Wi-Fi HAL；此时，在第一设备与第二设备建立网络连接之后，还包括：第一设备在HAL中创建与第二设备对应的第二硬件抽象模块，例如DMSDP Audio HAL；其中，第一设备获取第二时延，包括：第二硬件抽象模块可从第一硬件抽象模块中获取第二时延，即音频数据在第一设备和第二设备之间传输过程中所需的耗时。
示例性的，第一硬件抽象模块获取第二时延的具体方法可以包括：第一硬件抽象模块向第二设备发送测试数据包；第一硬件抽象模块接收第二设备响应测试数据包发送的响应数据包；进而，第一硬件抽象模块可根据发送测试数据包以及接收响应数据包之间的时间间隔计算并保存第二时延。
可以理解的，第一硬件抽象模块可以按照上述方法周期性的计算并保存第二时延。当第二时延有更新时，第一硬件抽象模块可通知第二硬件抽象模块获取最新的第二时延。或者，第二硬件抽象模块也可以周期性的从第一硬件抽象模块中获取保存的最新的第二时延。
也就是说，第一时延、第二时延或第三时延都是可以动态更新的。那么，当第一时延、第二时延或第三时延中的至少一个更新时，第一设备可重新计算当前的音频时延。或者，第一设备也可以周期性的获取最新的第一时延、第二时延以及第三时延，从而周期性的计算出当前最新的音频时延。
在一种可能的实现方式中，第一设备输出的显示数据在第一设备的显示屏中显示，在这种场景下，第一设备将音频数据投射至第二设备中播放，将显示数据保留在第一设备中播放；此时，在第一设备确定当前的音频时延之后，还包括：第一设备中运行的第一应用获取音频时延；例如，第一应用可以调用getLatency()接口向AudioService查询当前的音频时延。
当第一应用为视频应用时，第一应用可按照音频时延对第一应用的音频数据和显示数据进行同步，即进行音画同步处理，使用户看到的视频图像与听到的视频声音同步；当第一应用为音乐应用时，第一应用可按照音频时延对第一应用的音频数据和歌词数据进行同步，使用户看到的歌词与听到的歌曲声音同步；当第一应用为K歌应用时，第一应用可按照音频时延对第一应用的音频数据和伴奏音乐进行同步，使用户录制的音频数据与伴奏音乐同步。当然，其他应用也可以获取当前的音频时延进行与音频相关的同步处理，本申请实施例对此不做任何限制。
在一种可能的实现方式中，第一设备输出的显示数据在第三设备的显示屏中显示， 在这种场景下，第一设备将音频数据投射至第二设备中播放，将显示数据投射至第三设备中播放；此时，第一设备除了确定当前的音频时延外，还可以确定当前的显示时延，由于显示数据在第一设备以及第三设备中的处理速度较快，因此显示数据在第一设备以及第三设备中产生的时延可以忽略，那么，上述显示时延可以包括显示数据在第一设备与第三设备之间传输时的产生的时延；进而，第一设备可基于获取到的音频时延和显示时延确定当前的同步时延；后续，第一设备中运行的第二应用可按照当前的同步时延对第二应用的音频数据和显示数据进行同步，提高音画同步的同步效果。
示例性的，上述同步时延可以为音频时延和显示时延之间的差值，从而反映出播放同一时刻的音频数据与显示数据之间的时间差。
在一种可能的实现方式中，若第四设备被设置为第一设备的音频输出设备，且第四设备与第二设备连接，说明当第一设备与第二设备连接时，第二设备连接又将第四设备作为音频输出设备播放音频，即第一设备、第二设备以及第四设备之间为级联关系。此时，第一设备可按照上述方法获取第一时延和第二时延；不同的时，第一设备还需要获取第四时延，第四时延包括：音频数据在第二设备中处理时产生的时延、音频数据在第二设备与第四设备之间传输时产生的时延以及音频数据在第四设备中播放时产生的时延；进而，第一设备可基于第一时延、第二时延以及第四时延计算得到当前的音频时延。例如，该音频时延为第一时延、第二时延以及第四时延之和。
其中，上述第四时延可以被第二设备携带在音频能力参数中上报给第一设备。
第十四方面，本申请提供一种音频时延的更新方法，包括：第一设备与第二设备建立网络连接；若第二设备被设置为第一设备的音频输出设备和显示输出设备，说明第一设备将音频数据和显示数据均投射至第二设备中播放，在这种场景下，音频数据和显示数据在第一设备和第二设备之间传输所导致的时延基本相同，因此，第一设备可获取第一时延和第二时延，第一时延为音频数据在第一设备中处理时产生的时延，第二时延为音频数据在第二设备中播放时产生的时延；进而，第一设备可基于第一时延和第二时延确定当前的同步时延，类似的，当前的同步时延也是随着第一时延和第二时延动态更新的。例如，该同步时延为第一时延和第二时延之和。
后续，在第一设备基于第一时延和第二时延确定当前的同步时延之后，还可以包括：第一设备中运行的第一应用获取同步时延；进而，第一应用可按照获取到的同步时延对第一应用的音频数据和显示数据进行同步。
由于第一设备可以动态的计算出最新的同步时延，因此应用每次获取到的同步时延也是最新计算出的同步时延，该同步时延可以较为准确的反映出当前的音频数据与显示数据之间的时间差。因此，应用按照上述同步时延进行音画同步等同步处理时，能够使第二设备中播放的音频和图像更好的达到音画同步的效果，提高用户的音画同步体验。
第十五方面，本申请提供一种音视频文件的播放方法，包括：第一设备接收用户输入的第一操作，第一操作用于将第一设备中播放的第一文件(第一文件可以为音频文件或视频文件)投射至第二设备中播放；第一设备在播放第一文件时可获取第一文件的数据包(第一文件包括N个数据包，N＞0)，在接收到上述第一操作后，如果接收到第一文件的第一数据包，第一设备可提取第一数据包中的第一音频参数和第一音 频数据，其中，第一音频数据为经过编码后的音频数据，第一音频参数为编码第一音频数据时使用的编码参数；进而，第一设备可将第一音频参数发送至第二设备，以使得第二设备可按照第一音频参数确定自身是否具有解码第一音频数据的能力；若第二设备具有解码第一音频数据的能力，则第一设备无需再对第一音频数据进行解码和重新解码等操作，相应的，第一设备可将第一音频数据直接发送给第二设备，由第二设备解码第一音频数据后播放。
这样一来，第一设备在向第二设备投射音视频文件时，第一设备不需要对数据包中已编码的音频数据进行解码和重新编码等处理，而是直接将音视频文件中经过编码的音频数据发送给第二设备，利用第二设备的解码能力对音频数据解码后播放，使得音视频文件的整个投射过程的时延缩短，从而提高音视频文件跨设备播放场景下用户的使用体验。
并且，由于第一设备向第二设备发送的音频数据是视频文件中没有经过解码的数据，因此，第二设备接收到的音频数据不会出现由于第一设备的解码操作带来的失真，从而实现音视频文件在第一设备和第二设备之间的无损传输，提高音视频文件跨设备播放场景下音视频文件的保真度。
在一种可能的实现方式中，上述第一数据包包括包头(head)和数据(data)部分；其中，第一设备提取第一数据包中的第一音频参数和第一音频数据，具体包括：第一设备从第一数据包的包头提取第一音频参数；第一设备从第一数据包的数据部分提取第一音频数据，即已编码的音频数据。
在一种可能的实现方式中，上述第一音频参数可以包括：编码第一音频数据时使用的编码格式(例如AAC格式)、编码规格(例如AAC-LC)、版本(例如版本1)、采样率或声道数目中的至少一项。当然，上述第一音频参数还可以包括对第一音频数据编码时使用的其他参数，本申请实施例对此不做任何限制。
在一种可能的实现方式中，如果上述第一文件为视频文件，则第一文件的第一数据包中除了包括第一音频数据外还包括第一显示数据，第一显示数据也是经过编码的数据；那么，在第一设备获取第一文件的第一数据包之后，还包括：第一设备提取第一数据包中的第一显示参数和第一显示数据，第一显示参数为编码第一显示数据时使用的编码参数；进而，第一设备可将第一显示参数发送至第二设备，以使得第二设备按照第一显示参数确定是否具有解码第一显示数据的能力；若第二设备具有解码第一显示数据的能力，则第一设备无需再对第一显示数据进行解码和重新解码等操作，相应的，第一设备可将第一显示数据直接发送给第二设备，以使得第二设备解码第一显示数据后播放。
这样一来，第一设备在向第二设备投射视频文件时，第一设备不需要对数据包中已编码的显示数据进行解码和重新编码等处理，而是直接将视频文件中经过编码的显示数据发送给第二设备，利用第二设备的解码能力对显示数据解码后播放，使得视频文件的整个投射过程的时延缩短，从而提高视频文件跨设备播放场景下用户的使用体验。
并且，由于第一设备向第二设备发送的显示数据是视频文件中没有经过解码的数据，因此，第二设备接收到的显示数据不会出现由于第一设备的解码操作带来的失真， 从而实现视频文件在第一设备和第二设备之间的无损传输，提高视频文件跨设备播放场景下视频文件的保真度。
需要说明的是，第一设备可一次性从第一数据包中提取到上述第一音频数据、第一显示数据、第一音频参数以及第一显示参数。并且，第一设备可将提取到的第一音频参数和第一显示参数一起发送给第二设备，或者，第一设备也可以分别将上述第一音频参数和第一显示参数发送给第二设备，本申请实施例对此不做任何限制。
与提取第一音频数据和第一音频参数类似的，第一设备提取第一数据包中的第一显示参数和第一显示数据，具体包括：第一设备可从第一数据包的包头提取第一显示参数；第一设备可从第一数据包的数据部分提取第一显示数据。
示例性的，上述第一显示参数可以包括：编码第一显示数据时使用的编码格式(例如H.264格式)、编码规格、版本或分辨率中的至少一项。当然，上述第一显示参数还可以包括对第一显示数据编码时使用的其他参数，本申请实施例对此不做任何限制。
在一种可能的实现方式中，上述第一设备中设置有第一应用(例如DV APP)、第二应用(例如视频APP)和第一音视频播放器(例如Nuplayer)，第一应用用于与第二设备通信，第二应用用于将待播放的第一文件的数据包发送至第一音视频播放器；在第一设备接收用户输入的第一操作之后，还包括：响应于第一操作，第一设备可通过运行第一应用与第二设备建立网络连接；进而，第一应用可向第二应用发送第一广播消息，以通知第二应用将第一文件投射至第二设备播放；那么，响应于第一广播消息，第二应用可向第一音视频播放器发送第一通知消息，以通知第一音视频播放器开始向第二设备投射音视频文件。否则，第二应用可按照现有的音视频播放方法在第一设备中播放第一文件。
在一种可能的实现方式中，第一设备还包括多媒体提取器(例如MediaExtractor)；其中，当第一音视频播放器接收到上述第一通知消息后，如果获取到第一文件的第一数据包，则第一多媒体提取器可调用多媒体提取器对第一数据包进行解析，得到第一音频参数；并且，第一多媒体提取器可调用多媒体提取器对第一数据包进行解封装，得到第一音频数据。
在一种可能的实现方式中，由于同一音视频文件中各个数据包内音频数据编码时使用的音频参数一般是统一的，因此，如果第二设备具有解码第一音频数据的能力，则说明第二设备具有解码第一文件中其他音频数据的能力。那么，在第一设备将第一音频数据发送给第二设备之后，还包括：第一音视频播放器可从第二应用获取第一文件的第二数据包(即第一数据包后续的数据包)；进而，第一音视频播放器可提取第二数据包中的第二音频数据，并将第二音频数据发送至第二设备，以使得第二设备解码第二音频数据后播放。此时，第一音视频播放器无需再提取第二数据包中的音频参数，也无需将提取到的音频参数发送给第二设备触发第二设备确定是否具有解码第二音频数据的能力，从而降低第一文件投射至第二设备中播放的时延。
当然，如果第二数据包中包括第二显示数据，则第一音视频播放器还可提取第二数据包中的第二显示数据，并将第二显示数据发送至第二设备，以使得第二设备解码第二显示数据后播放。
在一种可能的实现方式中，在第一设备将第一音频数据发送给第二设备之后，还 包括：响应于用户输入的第二操作，第一应用与第三设备建立网络连接；第一应用向第二应用发送第二广播消息，第二广播消息用于通知第二应用将第一文件投射至第三设备播放；也就是说，用户通过第二操作将与第一设备连接的从设备从第二设备切换为第三设备，此时，需要继续在第三设备上播放上述第一文件。那么，第一音视频播放器接收到上述第二广播消息后，可开始向第三设备投射上述第一文件。
示例性的，向第三设备投射上述第一文件的过程与向第二设备投射上述第一文件的过程类似。例如，第一音视频播放器可从第二应用获取第一文件的第三数据包；进而，第一音视频播放器可提取第三数据包中的第二音频参数和第三音频数据，同样，第三音频数据为经过编码后的音频数据，第二音频参数为编码第三音频数据时使用的编码参数；由于第一设备不知道第三设备是否具有解码第一文件中音频数据的能力，因此，第一音视频播放器可将提取到的第二音频参数发送至第三设备，以使得第三设备按照第二音频参数确定是否具有解码第三音频数据的能力；若第三设备具有解码第三音频数据的能力，则第一音视频播放器可直接将第三音频数据发送给第三设备，以使得第三设备解码第三音频数据后播放。
同样，如果第三数据包中包括第三显示数据，则第一音视频播放器还可提取第三数据包中的第三显示数据和显示参数，并将第三数据包中的显示参数发送至第三设备，触发第三设备确定是否具有解码第三显示数据的能力。若第三设备具有解码第三显示数据的能力，则第一音视频播放器可直接将第三显示数据发送至第三设备，以使得第三设备解码第三显示数据后播放。
后续，第一音视频播放器获取到第一文件中的其他数据包后，可提取数据包中的显示数据和/或音频数据，并将提取到的显示数据和/或音频数据发送至第三设备，以使得第三设备利用自身的解码能力解码接收到的显示数据和/或音频数据并播放。
在一种可能的实现方式中，在第一设备将第一音频数据发送给第二设备之后，还包括：响应于用户输入的第三操作，第二应用将当前播放的第一文件切换为第二文件(第二文件为音频文件或视频文件)；第二应用创建第二音视频播放器(例如新的Nuplayer)，第二音视频播放器用于接收来自第二文件的数据包；也就是说，用户通过第三操作将第一设备中正在播放的第一文件切换为第二文件，此时，需要将第二文件投射至第二设备上中播放。那么，第二应用可向第二音视频播放器发送第三通知消息，第二音视频播放器接收到上述第三广播消息后，可开始向第二设备投射上述第二文件。
示例性的，向第二设备投射第二文件的过程与向第二设备投射上述第一文件的过程类似。例如，上述第二音视频播放器可从第二应用获取第二文件的数据包，例如，第四数据包；进而，第二音视频播放器可提取第四数据包中的第三音频参数和第四音频数据，第四音频数据为经过编码后的音频数据，第三音频参数为编码第四音频数据时使用的编码参数；由于第一设备不知道第二设备是否具有解码第二文件中音频数据的能力，因此，第二音视频播放器可将第三音频参数发送至第二设备，以使得第二设备按照第三音频参数确定是否具有解码第四音频数据的能力；若第二设备具有解码第四音频数据的能力，则第二音视频播放器将第四音频数据发送给第二设备，以使得第二设备解码第四音频数据后播放。
同样，如果第四数据包中包括第四显示数据，则第二音视频播放器还可提取第四数据包中的第四显示数据和显示参数，并将第四数据包中的显示参数发送至第二设备，触发第二设备确定是否具有解码第四显示数据的能力。若第四设备具有解码第四显示数据的能力，则第二音视频播放器可直接将第四显示数据发送至第二设备，以使得第二设备解码第四显示数据后播放。
后续，第二音视频播放器获取到第二文件中的其他数据包后，可提取数据包中的显示数据和/或音频数据，并将提取到的显示数据和/或音频数据发送至第二设备，以使得第二设备利用自身的解码能力解码接收到的显示数据和/或音频数据并播放。
在一种可能的实现方式中，在第一设备将第一音频数据发送给第二设备之后，还包括：第一设备运行第三应用；第一设备播放来自第三应用的音频文件或视频文件。也就是说，第一设备在向第二设备投射音视频文件的同时，还可以运行其他的应用(例如第三应用)，播放其他应用中的显示数据和/或音频数据，使得用户可以在跨设备播放音视频文件的同时还能够使用第一设备中其他应用提供的应用功能。
第十六方面，本申请提供一种音视频文件的播放方法，包括：第二设备接收第一设备发送的第一音频参数，第一音频参数为编码第一数据包中第一音频数据时使用的编码参数，第一数据包为第一文件的数据包；进而，第二设备可根据第一音频参数确定是否具有解码第一音频数据的能力；若具有解码第一音频数据的能力，则第二设备可向第一设备发送第一响应消息，以触发第一设备向第二设备发送未解码的第一音频数据；第二设备接收到第一设备发送的第一音频数据后，可对第一音频数据进行解码，得到解码后的第二音频数据；进而，第二设备播放第二音频数据，实现第一文件的跨设备播放功能。
也就是说，如果第二设备具有对第一设备播放的第一文件的音频解码能力，则第一设备可直接将第一文件中未解码的音频数据发送至第二设备，由第二设备对接收到的音频数据进行解码播放，从而简化了音视频文件投射时第一设备与第二设备之间对音频数据的处理过程，缩短了第一设备与第二设备进行音视频文件投射的耗时。
在一种可能的实现方式中，第二设备对第一音频数据进行解码，得到解码后的第二音频数据，具体包括：第二设备可使用第一解码参数对第一音频数据进行解码，得到解码后的第二音频数据，其中，第一解码参数与第一音频参数对应，例如，第一音频参数中编码第一音频数据使用的格式为AAC格式，则对应的第一解码参数中解码第一音频数据使用的格式也为AAC格式。
在一种可能的实现方式中，上述第一数据包还可以包括第一显示数据；此时，第二设备还可以接收第一设备发送的第一显示参数，第一显示参数为编码第一显示数据时使用的编码参数；并且，第二设备可根据第一显示参数确定是否具有解码第一显示数据的能力；若具有解码第一显示数据的能力，则第二设备向第一设备发送的第一响应消息还可用于指示第一设备向第二设备发送第一显示数据；后续，当第二设备接收到第一设备发送的未解码的第一显示数据后，可利用自身的解码能力对第一显示数据进行解码，得到解码后的第二显示数据；进而，第二设备可播放第二显示数据。
也就是说，如果第二设备具有对第一设备播放的第一文件的图像解码能力，则第一设备可直接将第一文件中未解码的显示数据发送至第二设备，由第二设备对接收到 的显示数据进行解码播放，从而简化了视频文件投射时第一设备与第二设备之间对显示数据的处理过程，缩短了第一设备与第二设备进行视频文件投射的耗时。
在一种可能的实现方式中，第二设备对第一显示数据进行解码，得到解码后的第二显示数据，包括：第二设备使用第二解码参数对第一显示数据进行解码，得到解码后的第二显示数据，其中，第二解码参数与第一显示参数对应，例如，第一显示参数中编码第一显示数据使用的格式为H.265格式，则对应的第二解码参数中解码第一显示数据使用的格式也为H.265格式。
在一种可能的实现方式中，由于同一音视频文件中各个数据包内音频数据和显示数据编码时使用的参数一般是统一的，因此，如果第二设备具有解码第一音频数据和第一显示数据的能力，则说明第二设备具有解码第一文件中其他音频数据和显示数据的能力，那么，如果后续第二设备接收到第一文件中的第三音频数据时，第二设备可直接对第三音频数据解码后播放；类似的，如果后续第二设备接收到第一文件中的第三显示数据，第二设备可直接对第三显示数据解码后播放。
在一种可能的实现方式中，在第二设备根据第一音频参数确定是否具有解码第一音频数据的能力之后，还包括：若具有解码第一音频数据的能力，则第二设备按照第一音频参数创建音频解码器(audio decoder)，该音频解码器用于解码第一文件中的音频数据；在第二设备根据第一显示参数确定是否具有解码第一显示数据的能力之后，还包括：若具有解码第一显示数据的能力，则第二设备按照第一显示参数创建图像解码器(video decoder)，图像解码器用于解码第一文件中的显示数据。也就是说，第二设备确定自身具有对第一文件中音视频数据的解码能力后，可预先创建对应的音频解码器和图像解码器，这样，当第二设备接收到第一设备发来的未经解码的音频数据/显示数据时，第二设备可使用已创建的音频解码器/图像解码器进行解码，进一步缩短第一设备与第二设备进行音视频文件投射的耗时。
第十七方面，本申请提供一种设备推荐方法，包括：第一设备可接收用户打开第一业务的第一操作；响应于第一操作，第一设备可从位于同一通信网络中的N(N为大于0的整数)个电子设备中分别获取与第一业务关联的设备参数；进而，第一设备可根据获取到的设备参数预测上述N个电子设备中每个电子设备执行第一业务时的业务质量；后续，第一设备可按照N个电子设备中每个电子设备执行第一业务的业务质量显示设备列表，该设备列表中包括N个电子设备中至少一个电子设备的设备标识，从而向用户推荐适合执行第一业务的具体设备。
示例性的，上述第一业务可以是与音频功能相关的业务，例如音频播放业务、录音业务等。或者，上述第一业务可以是与显示功能相关的业务，例如视频播放业务、视频通话业务、游戏业务等。或者，上述第一业务可以是与相机功能相关的业务，例如视频通话业务、录像业务等。
示例性的，上述设备参数可以包括与音频功能相关的音频参数，与显示功能相关显示参数以及与相机功能相关相机参数等一项或多项。
也就是说，第一设备作为主设备在执行某一业务之前，可获取从设备(例如上述N个电子设备)的相关设备参数，从而预测各个从设备执行该业务时的业务质量。这样，第一设备可基于预测出的各个从设备执行该业务时的业务质量，通过显示设备列 表的方式向用户推荐执行该业务的具体设备，从而提高分布式场景中多设备协同工作时的业务质量，同时提高了用户的使用体验。
在一种可能的实现方式中，上述N个电子设备中可以包括第二设备；第一设备从第二设备获取到的设备参数可以包括M(M为大于0的整数)项参数；此时，第一设备根据设备参数预测第二设备执行第一业务的业务质量，包括：第一设备确定与M项参数一一对应的M项分数；进而，第一设备可根据这M项分数计算第二设备执行第一业务的业务质量分数；当业务质量分数越高时，第一业务的业务质量越高。
示例性的，第一设备可以对第二设备的M项参数一一进行打分，得到对应的M项分数，进而，第一设备可将这M项分数按照预设的权重进行加权平均，得到第二设备执行第一业务的业务质量分数。当然，上述N个电子设备中其他设备执行第一业务的业务质量分数也可按照上述方法计算，本申请对此不做任何限制。
在一种可能的实现方式中，上述N个电子设备中还可以包括第三设备；当第二设备执行第一业务的业务质量分数高于第三设备执行第一业务的业务质量分数时，第二设备在设备列表中的排列顺序位于第三设备之前。也就是说，第一设备可以在显示的设备列表中通过设备之间的先后排列顺序向用户推荐执行相关业务的设备。
在一种可能的实现方式中，当第二设备执行第一业务的业务质量分数高于N个电子设备中其他电子设备执行第一业务的业务质量分数时，说明第二设备为上述N个电子设备中最适合执行第一业务的设备，则第二设备在上述设备列表中可被标记为推荐设备，从而提示用户使用推荐设备执行第一业务。
在一种可能的实现方式中，上述M项参数中可以包括与第一功能对应的第一参数，例如，与显示功能对应的显示参数；那么，当第二设备的第一参数的分数高于N个电子设备中其他电子设备的第一参数的分数时，说明第二设备在执行第一业务的第一功能时业务质量较高，则第一设备可在上述设备列表中显示第一提示信息，第一提示信息用于推荐用户使用第二设备实现第一功能。也就是说，第一设备可以向用户推荐在执行第一业务时某一功能较为突出的设备。
在一种可能的实现方式中，上述M项参数中包括与第一功能对应的第一参数，例如，与显示功能对应的显示参数；那么，当第二设备的第一参数的分数低于N个电子设备中其他电子设备的第一参数的分数时，说明第二设备在执行第一业务的第一功能时业务质量较低，则第一设备可在上述设备列表中显示第二提示信息，第二提示信息包括不推荐用户使用第二设备实现第一功能的原因。也就是说，第一设备可以向用户提示不推荐使用某一设备执行第一业务的具体原因。
在一种可能的实现方式中，上述N个电子设备中包括第二设备；在第一设备按照N个电子设备中每个电子设备执行第一业务的业务质量显示设备列表之后，还包括：第一设备接收用户在设备列表中选择第二设备的第二操作；那么，响应于第二操作，第一设备可将第一业务切换至第二设备中执行。这样，用户可以基于第一设备在设备列表中推荐的设备，将第一业务切换至第二设备中，实现多设备协同工作的分布式业务场景。
在一种可能的实现方式中，在第一设备将第一业务切换至第二设备中执行之后，还包括：第一设备可再次从当前的从设备(例如与手机位于同一通信网络的N个电子 设备)中分别获取与第一业务关联的设备参数；同样，第一设备可根据获取到的设备参数预测当前N个电子设备中每个电子设备执行第一业务的业务质量；当第二设备不是上述N个电子设备中执行第一业务的业务质量最高的电子设备时，说明第一业务目前不适合在第二设备上执行，则第一设备可显示第一提示消息，第一提示消息用于提示用户使用推荐设备执行第一业务，推荐设备为N个电子设备中的一个或多个。
也就是说，第一设备作为主设备可以在与其他设备(例如上述第二设备)协同执行某一业务的过程中，实时的获取各个从设备的相关设备参数，从而预测各个从设备执行该业务时的业务质量。这样，第一设备可基于预测出的各个从设备执行该业务时的业务质量，通过显示提示消息向用户推荐执行该业务的推荐设备，从而提高分布式场景中多设备协同工作时的业务质量，同时提高了用户的使用体验。
在一种可能的实现方式中，第一设备根据设备参数预测N个电子设备中每个电子设备执行第一业务的业务质量，包括：第一设备可以根据从每个电子设备获取的设备参数，计算每个电子设备执行第一业务的业务质量分数。例如，第一设备可以根对每个电子设备对应的设备参数中的每一项参数进行打分，进而对所有的打分进行加权平均后计算出对应电子设备执行第一业务的业务质量分数。
在一种可能的实现方式中，上述N个电子设备中包括第三设备；当第三设备执行第一业务的业务质量分数高于N个电子设备中的其他电子设备时，上述推荐设备为第三设备；或者，当第三设备执行第一业务中第一子任务的业务质量分数高于N个电子设备中的其他电子设备时，上述推荐设备为第三设备。也就是说，当上述N个电子设备中除第二设备的某一设备执行第一业务，或第一业务中某一子任务的业务质量较高时，第一设备可将该设备确定为推荐设备，从而推荐用户使用该推荐设备执行第一业务。
在一种可能的实现方式中，上述第一业务可以包括第一子任务和第二子任务，例如，投屏业务中可以包括音频播放任务和显示任务；上述N个电子设备中可以包括第三设备和第四设备。当第三设备执行第一子任务的业务质量分数高于N个电子设备中的其他电子设备，且第四设备执行第二子任务的业务质量分数高于N个电子设备中的其他电子设备时，上述推荐设备为第三设备和第四设备组成的设备组。也就是说，当多个设备协同执行第一业务时可以获得较高的业务质量时，第一设备可以以设备组的形式向用户推荐使用多个设备共同执行上述第一业务。
在一种可能的实现方式中，上述方法还包括：第一设备预测第一设备执行第一业务的业务质量分数；其中，当第一设备执行第一业务的业务质量分数高于上述N个电子设备时，上述推荐设备可以为第一设备。也就是说，主设备(即第一设备)也可以作为推荐设备的一个候选设备，当第一设备执行目标业务(例如上述第一业务)的业务质量较高时，也可以提示用户使用第一设备执行上述第一业务。
在一种可能的实现方式中，上述第一提示消息中可以包括推荐设备的设备标识；在第一设备显示第一提示消息之后，还包括：第一设备接收用户在第一提示消息中选择推荐设备的第三操作；响应于第三操作，第一设备将第一业务切换至推荐设备中执行。这样，用户通过第一提示消息中推荐设备的设备标识可以快速将第一业务切换至业务质量较高的推荐设备中执行。
在一种可能的实现方式中，当第二设备不是N个电子设备中执行第一业务的业务质量最高的电子设备时，上述方法还包括：第一设备可以向第二设备通知上述推荐设备，以使得第二设备显示第二提示消息，第二提示消息用于提示用户使用推荐设备执行第一业务。同样，用户可以在第二设备中通过第二提示消息快速将第一业务切换至业务质量较高的推荐设备中执行。
在一种可能的实现方式中，上述设备参数可以包括音频参数、显示参数、相机参数或时延中的一个或多个。其中，音频参数可以包括从设备支持的音效算法、声道数目、采样率、混音策略、音频数据的编解码算法、麦克风的数目和型号以及喇叭的数目和型号等一项或多项。上述显示参数可以包括从设备支持的分辨率、帧率以及显示数据的编解码算法等一项或多项。上述相机参数可以包括从设备支持的图像处理算法、摄像头的数目、摄像头的分辨率或者摄像头的FOV等一项或多项。
第十八方面，本申请提供一种超声波定位方法，包括：当第一设备检测到用户打开投屏功能(也可称为内容接续、跨设备续播等功能)的操作时，第一设备可检测与第一设备接入同一通信网络的K(K为大于1的整数)个电子设备，例如，这K个电子设备可以是与第一设备登录同一账号的电子设备；进而，第一设备可对上述K个电子设备中的第二设备进行超声波定位，得到第二设备的定位结果(即第一定位结果)；并且，第一设备可对上述K个电子设备中的第三设备进行超声波定位，得到第三设备的定位结果(即第二定位结果)；这样，第一设备可在交互界面中显示第二设备的标识和第三设备的标识，其中，第二设备的标识在交互界面中的位置与第一定位结果相关，第三设备的标识在交互界面中的位置与第二定位结果相关。
也就是说，当用户触发第一设备的投屏功能时，第一设备可作为主设备对第二设备和第三设备进行超声波定位，得到第二设备和第三设备的定位结果。那么，第一设备可以按照得到的定位结果在交互界面中显示第二设备和第三设备的标识，使得用户可以在交互界面中直观的看到当前检测到的第二设备和第三设备的位置关系。这样，用户可以根据该位置关系在交互界面中方便、准确的选择本次与第一设备进行投屏的设备，提高用户在投屏场景下的使用体验。
其中，上述交互界面可以是第一设备的显示屏显示出的全部界面，也可以是第一设备的显示屏显示出的部分界面。例如，第一设备可以在显示屏的显示区域1中显示等待投射的具体内容(例如视频或图像等)，同时，第一设备可以在显示屏的显示区域2中显示上述第二设备和第三设备的标识。此时，显示区域2即为上述交互界面。
在一种可能的实现方式中，第一设备对第二设备进行超声波定位，包括：第一设备可以向第二设备发送第一定位指令，第一定位指令用于触发第二设备发射第一超声波信号；在第二设备发射第一超声波信号的同时，第一设备可使用自身的N(N为大于1的整数)个超声波接收器采集第一超声波信号；进而，第一设备可以根据第二超声波信号分别到达上述N个超声波接收器的时间对第二设备进行定位。
例如，第一设备可以使用到达时间(Time of Arrival，TOA)或到达时间差(Time Different Of Arrival，TDOA)算法，基于第二超声波信号分别到达上述N个超声波接收器的时间对第二设备进行定位。
其中，第一设备自身的N个超声波接收器具体可以为第一设备中麦克风阵列内的 N个麦克风。此时，第一设备不需要额外新增超声波接收器来适配本申请实施例提供的超声波定位方法，从而降低室内定位的实现成本和难度。
当然，第一设备也可以按照上述方法对第三设备进行超声波定位，本申请对此不做任何限制。
或者，在另一种可能的实现方式中，第一设备对第三设备进行超声波定位，具体包括：第一设备向第三设备发送第二定位指令，第二定位指令用于触发第三设备发射第二超声波信号；在第三设备发射第二超声波信号的同时，第一设备可获取第一超声波数据，第一超声波数据包括第二超声波信号分别到达第一设备中N个超声波接收器的时间；并且，第一设备可以获取第二超声波数据，第二超声波数据包括第二超声波信号分别到达第二设备中M(M为大于1的整数)个超声波接收器的时间；第一设备根据第一超声波数据和第二超声波数据对第三设备进行定位。
也就是说，第一设备作为主设备可以利用第二设备现有的超声波定位能力，通过多设备协同的方式同时开启第一设备和第二设备的超声波接收器接收待定位的第三设备发出的超声波信号，从而根据接收到的更多的超声波信号对的第三设备进行定位，提高对第三设备的定位精度，同时也简化了室内定位的操作过程和实现成本。
在一种可能的实现方式中，在第一设备向第三设备发送第二定位指令之前，还包括：第一设备在上述K个电子设备中将第二设备确定为协同设备，协同设备用于协同第一设备进行超声波定位；第一设备向第二设备发送第一协同定位指令，第一协同定位指令用于触发第二设备使用M个超声波接收器检测第二超声波信号。第二设备可响应第一协同定位指令打开自身的M个超声波接收器，并使用这M个超声波接收器检测第二超声波信号，将检测到的M路第二超声波信号作为上述第二超声波数据发送给第一设备。
这样，在定位场景下，实际采集待定位的第三设备发射的超声波信号的麦克风的数量增加，并且，采集超声波信号的麦克风位于第一设备和第二设备的不同位置，使得第一设备可以根据更多数量和更多方向的超声波信号对第三设备进行定位，从而提高设备的定位精度。
在一种可能的实现方式中，第一设备在K个电子设备中将第二设备确定为协同设备，包括：当第二设备为K个电子设备中定位能力最高的电子设备时，第一设备将第二设备确定为协同设备。例如，当某一电子设备上设置的麦克风的数量越多时，可设置该电子设备的定位能力越高。或者，当某一电子设备上设置的麦克风之间的间距越大时，可设置该电子设备的定位能力越高。或者，当某一电子设备的处理器等硬件参数的性能越高时，可设置该电子设备的定位能力越高。使用定位能力较高的第二设备协同第一设备对第三设备进行定位，可以提高第三设备的定位精度。
在一种可能的实现方式中，第一设备根据第一超声波数据和第二超声波数据对第三设备进行定位，包括：当第一设备已经得到第二设备的定位结果时，第二设备上的M个麦克风可作为第一设备的麦克风使用，相当于第一设备的一部分麦克风(例如上述N个麦克风)设置在本机上，第一设备的另一部分麦克风(例如上述M个麦克风)设置在第二设备上。进而，第一设备可基于获取到的第一超声波数据和第二超声波数据，使用预设的定位算法对第三设备进行定位。
在一种可能的实现方式中，上述N个超声波接收器可以为第一设备的麦克风阵列中的N个麦克风；和/或，上述M个超声波接收器可以为第二设备的麦克风阵列中的M个麦克风；此时，第一设备获取第一超声波数据，包括：第一设备使用上述N个麦克风检测第二超声波信号，得到N路第二超声波信号(即第一超声波数据)；同样，第二设备可使用上述M个麦克风检测第二超声波信号，得到M路第二超声波信号(即第二超声波数据)，并且，第二设备可将第二超声波数据发送给第一设备。
此时，第一设备根据第一超声波数据和第二超声波数据对第三设备进行定位，可以包括：第一设备将上述N路第二超声波信号和M路第二超声波信号合并为多声道超声数据，该多声道超声数据可以包括：上述N路第二超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间，以及上述M路第二超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间；进而，第一设备可根据上述多声道超声数据，使用预设的定位算法对第三设备进行定位。
或者，第一设备对第三设备进行超声波定位，可以包括：第一设备向第三设备发送第二定位指令，第二定位指令用于触发第三设备发射第二超声波信号；在第三设备发射第二超声波信号的同时，第一设备可根据第二超声波信号达到第一设备中N个超声波接收器的时间确定第一超声定位结果，并且，第二设备可根据第二超声波信号达到第二设备中M个超声波接收器的时间确定第二超声定位结果。也就是说，第一设备和第二设备可以同时对第三设备进行超声波定位。进而，第二设备可将得到的第二超声定位结果发送给第一设备，由第一设备根据第二超声定位结果对自身计算出的第一超声定位结果进行校正，输出最终第三设备的定位结果。由于最终输出的第三设备的定位结果是第一设备结合第一超声定位结果和第二超声定位结果得到的，因此，可提高第三设备的定位精度。
示例性的，上述N个超声波接收器可以为第一设备的麦克风阵列中的N个麦克风；此时，第一设备获取第一超声定位结果，包括：第一设备使用N个麦克风检测第二超声波信号；第一设备根据N个麦克风中每个麦克风检测到第二超声波信号的时间对第三设备进行定位，得到第一超声定位结果。
类似的，上述M个超声波接收器可以为第二设备的麦克风阵列中的M个麦克风；此时，第二设备可使用上述M个麦克风检测第二超声波信号；并根据M个麦克风中每个麦克风检测到第二超声波信号的时间对第三设备进行定位，得到第二超声定位结果；进而，第二设备可将第二超声定位结果发送第一设备。
在一种可能的实现方式中，上述K个电子设备中还包括第四设备；那么，第一设备除了按照上述方法对第二设备和第三设备进行超声波定位外，第一设备还可以按照上述方法对第四设备进行超声波定位，得到第四设备的第三定位结果；进而，第一设备可在交互界面中显示第二设备的标识、第三设备的标识以及第四设备的标识，其中，第二设备的标识在交互界面中的位置与第一定位结果相关，第三设备的标识在交互界面中的位置与第二定位结果相关，第四设备的标识在交互界面中的位置与第三定位结果相关。
这样，用户可以在交互界面中直观的看到当前检测到的第二设备、第三设备以及第四设备的位置关系。后续，用户可以根据该位置关系在交互界面中方便、准确的选 择本次与第一设备进行投屏的设备，提高用户在投屏场景下的使用体验。
在一种可能的实现方式中，第一设备对第四设备进行超声波定位的过程与第一设备对第三设备进行超声波定位的过程类似，例如，第一设备可以向第四设备发送第三定位指令，第三定位指令用于触发第四设备发射第三超声波信号；在第四设备发射第三超声波信号的同时，第一设备可以获取第三超声波数据，第三超声波数据包括第三超声波信号分别到达第一设备中N个超声波接收器的时间；同时，第一设备可以获取第四超声波数据，第四超声波数据包括第三超声波信号分别到达第二设备中M个超声波接收器的时间；进而，第一设备可根据第三超声波数据和第四超声波数据对第四设备进行定位。
在一种可能的实现方式中，在第一设备对第四设备进行超声波定位的过程中，第一设备还可以将第二设备和第三设备均作为协同设备，协同第一设备对第四设备进行超声波定位。例如，在第四设备发射第三超声波信号的同时，第三设备也可作为协同设备使用自身的Z个超声波接收器检测上述第三超声波信号，并且，第三设备可将检测到的Z路第三超声波信号作为第五超声波数据发送给第一设备。这样，第一设备可根据获取到的第三超声波数据、第四超声波数据以及第五超声波数据对第四设备进行定位，从而使用更多的超声波信号对第四设备进行定位，提高第四设备的定位精度。
示例性的，当第一设备向第四设备发送第三定位指令时，第一设备还可以向第二设备和第三设备(即两个协同设备)发送第二协同定位指令，第二协同定位指令用于触发第二设备使用M个超声波接收器检测第三超声波信号，并且，第二协同定位指令用于触发第三设备使用Z个超声波接收器检测第三超声波信号。
当然，如果上述K个电子设备中还包括第五设备等其他电子设备，则第一设备仍然可以按照上述方法对其他电子设备进行超声波定位，本申请实施例对此不做任何限制。
在一种可能的实现方式中，在第一设备在交互界面中显示第二设备的标识和第三设备的标识之后，还包括：响应于用户选中第二设备的标识的操作，第一设备可将第一设备播放的内容投射至第二设备播放；或者，响应于用户选中第三设备的标识的操作，第一设备可将第一设备播放的内容投射至第三设备播放。也就是说，用户可以在交互界面中根据展示出的各个电子设备之间的位置关系选择需要与第一设备进行投屏的设备。
其中，用户在交互界面中某一设备的操作具体可以为点击、滑动、隔空手势、或输入对应的语音指令等操作，本申请对此不做任何限制。
第十九方面，本申请提供一种超声波定位方法，包括：第二设备可作为待定位的电子设备接收第一设备发送的定位指令；响应于该定位指令，第二设备可使用自身的超声波发生器(例如扬声器)发射第一超声波信号。后续，第一设备可根据第一超声波信号到达第一设备中各个超声波接收器的时间对第二设备进行超声波定位，得到第二设备的定位结果。
第二十方面，本申请提供一种超声波定位方法，包括：第二设备可作为第一设备的协同设备接收第一设备发送的协同定位指令；响应于该协同定位指令，第二设备可打开自身的M个超声波接收器(例如M个麦克风，M为大于1的整数)检测待定位 的电子设备(例如第三设备)发射的超声波信号。第二设备可将检测到的M路超声波信号作(即第一方面中的第二超声波数据)发送给第一设备，由第一设备结合该第二超声波数据对第三设备进行超声波定位。或者，第二设备可根据上述M路超声波信号到达上述M个麦克风的时间对第三设备进行定位，并将得到的超声定位结果(第一方面中的第二超声定位结果)发送给第一设备，由第一设备结合第二超声定位结果对第三设备进行定位。
第二十一方面，本申请提供一种电子设备(例如上述第一设备)，包括：显示屏、通信模块、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与通信模块、显示屏以及存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当第一设备运行时，该处理器执行该存储器存储的一个或多个计算机程序，以使第一设备执行上述第一方面至第二十方面中任一项所述方法。
第二十二方面，本申请提供一种电子设备(例如上述第二设备)，包括：通信模块、一个或多个处理器、一个或多个存储器、以及一个或多个计算机程序；其中，处理器与通信模块、存储器均耦合，上述一个或多个计算机程序被存储在存储器中，当第二设备运行时，该处理器执行该存储器存储的一个或多个计算机程序，以使第二设备执行上述第一方面至第二十方面中任一项所述方法。
第二十三方面，本申请提供一种音频系统，包括上述第一设备和第二设备，第一设备和第二设备通过交互可执行上述第一方面至第二十方面中任一项所述方法。
第二十四方面，本申请提供一种计算机可读存储介质，包括计算机指令，当计算机指令在上述第一设备或第二设备上运行时，使得第一设备或第二设备执行上述第一方面至第二十方面中任一项所述方法。
第二十五方面，本申请提供一种计算机程序产品，当计算机程序产品在上述第一设备或第二设备上运行时，使得第一设备或第二设备执行上述第一方面至第二十方面中任一项所述方法。
可以理解地，上述各个方面所提供的电子设备、音频系统、计算机可读存储介质以及计算机程序产品均应用于上文所提供的对应方法，因此，其所能达到的有益效果可参考上文所提供的对应方法中的有益效果，此处不再赘述。
附图说明
图1为本申请实施例提供的一种音频系统的架构示意图；
图2为本申请实施例提供的一种音频应用场景示意图1；
图3为本申请实施例提供的一种音频应用场景示意图2；
图4为本申请实施例提供的一种音频控制方法的交互示意图1；
图5为本申请实施例提供的一种电子设备的结构示意图1；
图6为本申请实施例提供的一种音频应用场景示意图3；
图7为本申请实施例提供的一种音频应用场景示意图4；
图8为本申请实施例提供的一种音频应用场景示意图5；
图9为本申请实施例提供的一种音频应用场景示意图6；
图10为本申请实施例提供的一种音频应用场景示意图7；
图11为本申请实施例提供的一种音频应用场景示意图8；
图12为本申请实施例提供的一种音频应用场景示意图9；
图13为本申请实施例提供的一种音频应用场景示意图10；
图14A为本申请实施例提供的一种音频应用场景示意图11；
图14B为本申请实施例提供的一种音频应用场景示意图12；
图15为本申请实施例提供的一种音频应用场景示意图13；
图16A为本申请实施例提供的一种音频应用场景示意图14；
图16B为本申请实施例提供的一种音频应用场景示意图15；
图17为本申请实施例提供的一种音频应用场景示意图16；
图18A为本申请实施例提供的一种音频应用场景示意图17；
图18B为本申请实施例提供的一种音频应用场景示意图18；
图19为本申请实施例提供的一种音频应用场景示意图19；
图20为本申请实施例提供的一种音频应用场景示意图20；
图21为本申请实施例提供的一种音频应用场景示意图21；
图22为本申请实施例提供的一种音频应用场景示意图22；
图23为本申请实施例提供的一种音频应用场景示意图23；
图24为本申请实施例提供的一种音频应用场景示意图24；
图25为本申请实施例提供的一种音频应用场景示意图25；
图26为本申请实施例提供的一种音频应用场景示意图26；
图27为本申请实施例提供的一种音频应用场景示意图27；
图28为本申请实施例提供的一种音频应用场景示意图28；
图29为本申请实施例提供的一种音频应用场景示意图29；
图30为本申请实施例提供的一种音频应用场景示意图30；
图31为本申请实施例提供的一种音频应用场景示意图31；
图32为本申请实施例提供的一种音频应用场景示意图32；
图33为本申请实施例提供的一种音频应用场景示意图33；
图34为本申请实施例提供的一种音频控制方法的交互示意图2；
图35为本申请实施例提供的一种音频应用场景示意图34；
图36为本申请实施例提供的一种音频应用场景示意图35；
图37为本申请实施例提供的一种音频应用场景示意图36；
图38为本申请实施例提供的一种音频应用场景示意图37；
图39为本申请实施例提供的一种音频应用场景示意图38；
图40为本申请实施例提供的一种音频应用场景示意图39；
图41为本申请实施例提供的一种音频控制方法的交互示意图3；
图42为本申请实施例提供的一种音频应用场景示意图40；
图43为本申请实施例提供的一种音频应用场景示意图41；
图44为本申请实施例提供的一种音频应用场景示意图42；
图45为本申请实施例提供的一种音频控制方法的交互示意图4；
图46为本申请实施例提供的一种音频应用场景示意图43；
图47为本申请实施例提供的一种音频应用场景示意图44；
图48为本申请实施例提供的一种音频应用场景示意图45；
图49为本申请实施例提供的一种音频应用场景示意图46；
图50为本申请实施例提供的一种音频应用场景示意图47；
图51为本申请实施例提供的一种音频应用场景示意图48；
图52为本申请实施例提供的一种音频应用场景示意图49；
图53为本申请实施例提供的一种音频应用场景示意图50；
图54为本申请实施例提供的一种音频应用场景示意图51；
图55为本申请实施例提供的一种音频应用场景示意图52；
图56为本申请实施例提供的一种音频应用场景示意图53；
图57为本申请实施例提供的一种音频应用场景示意图54；
图58为本申请实施例提供的一种音频应用场景示意图55；
图59为本申请实施例提供的一种音频应用场景示意图56；
图60为本申请实施例提供的一种音频应用场景示意图57；
图61为本申请实施例提供的一种音频应用场景示意图58；
图62为本申请实施例提供的一种音频应用场景示意图59；
图63为本申请实施例提供的一种音频应用场景示意图60；
图64为本申请实施例提供的一种音频应用场景示意图61；
图65为本申请实施例提供的一种音频应用场景示意图62；
图66为本申请实施例提供的一种音频应用场景示意图63；
图67为本申请实施例提供的一种音频应用场景示意图64；
图68为本申请实施例提供的一种音频应用场景示意图65；
图69为本申请实施例提供的一种音频应用场景示意图66；
图70为本申请实施例提供的一种音频应用场景示意图67；
图71为本申请实施例提供的一种音频应用场景示意图68；
图72为本申请实施例提供的一种音频应用场景示意图69；
图73为本申请实施例提供的一种音频应用场景示意图70；
图74为本申请实施例提供的一种音频应用场景示意图71；
图75为本申请实施例提供的一种音频应用场景示意图72；
图76为本申请实施例提供的一种音频应用场景示意图73；
图77为本申请实施例提供的一种音频应用场景示意图74；
图78为本申请实施例提供的一种音频应用场景示意图75；
图79为本申请实施例提供的一种音频应用场景示意图76；
图80为本申请实施例提供的一种音频应用场景示意图77；
图81为本申请实施例提供的一种音频应用场景示意图78；
图82为本申请实施例提供的一种音频应用场景示意图79；
图83为本申请实施例提供的一种音频应用场景示意图80；
图84为本申请实施例提供的一种音频应用场景示意图81；
图85为本申请实施例提供的一种录屏方法的交互示意图；
图86为本申请实施例提供的一种音频应用场景示意图82；
图87为本申请实施例提供的一种音频应用场景示意图83；
图88为本申请实施例提供的一种音频应用场景示意图84；
图89为本申请实施例提供的一种音频应用场景示意图85；
图90为本申请实施例提供的一种音频应用场景示意图86；
图91为本申请实施例提供的一种音频应用场景示意图87；
图92为本申请实施例提供的一种音频应用场景示意图88；
图93为本申请实施例提供的一种音频应用场景示意图89；
图94为本申请实施例提供的一种音频应用场景示意图90；
图95为本申请实施例提供的一种音频应用场景示意图91；
图96为本申请实施例提供的一种音频应用场景示意图92；
图97为本申请实施例提供的一种音频应用场景示意图93；
图98为本申请实施例提供的一种音频应用场景示意图94；
图99为本申请实施例提供的一种音频应用场景示意图95；
图100为本申请实施例提供的一种音频应用场景示意图96；
图101为本申请实施例提供的一种音频应用场景示意图97；
图102为本申请实施例提供的一种音频应用场景示意图98；
图103为本申请实施例提供的一种音频应用场景示意图99；
图104为本申请实施例提供的一种音频应用场景示意图100；
图105为本申请实施例提供的一种音频更新方法的交互示意图1；
图106为本申请实施例提供的一种音频更新方法的交互示意图2；
图107为本申请实施例提供的一种音频应用场景示意图101；
图108为本申请实施例提供的一种音频应用场景示意图102；
图109为本申请实施例提供的一种音频应用场景示意图103；
图110为本申请实施例提供的一种音频应用场景示意图104；
图111为本申请实施例提供的一种音频应用场景示意图105；
图112为本申请实施例提供的一种音频应用场景示意图106；
图113为本申请实施例提供的一种音频应用场景示意图107；
图114为本申请实施例提供的一种音频应用场景示意图108；
图115为本申请实施例提供的一种音频应用场景示意图109；
图116为本申请实施例提供的一种音频应用场景示意图110；
图117为本申请实施例提供的一种音频应用场景示意图111；
图118为本申请实施例提供的一种音频应用场景示意图112；
图119为本申请实施例提供的一种音频应用场景示意图113；
图120为本申请实施例提供的一种音频应用场景示意图114；
图121为本申请实施例提供的一种音频应用场景示意图115；
图122为本申请实施例提供的一种设备推荐方法的交互示意图；
图123为本申请实施例提供的一种音频应用场景示意图116；
图124为本申请实施例提供的一种音频应用场景示意图117；
图125为本申请实施例提供的一种音频应用场景示意图118；
图126为本申请实施例提供的一种音频应用场景示意图119；
图127为本申请实施例提供的一种音频应用场景示意图120；
图128为本申请实施例提供的一种音频应用场景示意图121；
图129为本申请实施例提供的一种音频应用场景示意图122；
图130为本申请实施例提供的一种音频应用场景示意图123；
图131为本申请实施例提供的一种音频应用场景示意图124；
图132为本申请实施例提供的一种音频应用场景示意图125；
图133为本申请实施例提供的一种音频应用场景示意图126；
图134为本申请实施例提供的一种音频应用场景示意图127；
图135为本申请实施例提供的一种音频应用场景示意图128；
图136为本申请实施例提供的一种音频应用场景示意图129；
图137为本申请实施例提供的一种音频应用场景示意图130；
图138为本申请实施例提供的一种音频应用场景示意图131；
图139为本申请实施例提供的一种音频应用场景示意图132；
图140为本申请实施例提供的一种音频应用场景示意图133；
图141为本申请实施例提供的一种音频应用场景示意图134；
图142为本申请实施例提供的一种音频应用场景示意图135；
图143为本申请实施例提供的一种音频应用场景示意图136；
图144为本申请实施例提供的一种音频应用场景示意图137；
图145为本申请实施例提供的一种音频应用场景示意图138；
图146为本申请实施例提供的一种音频应用场景示意图139；
图147为本申请实施例提供的一种音频应用场景示意图140；
图148为本申请实施例提供的一种音频应用场景示意图141；
图149为本申请实施例提供的一种音频应用场景示意图142；
图150为本申请实施例提供的一种音频应用场景示意图143；
图151为本申请实施例提供的一种音频应用场景示意图144；
图152为本申请实施例提供的一种音频应用场景示意图145；
图153为本申请实施例提供的一种音频应用场景示意图146；
图154为本申请实施例提供的一种音频应用场景示意图147；
图155为本申请实施例提供的一种音频应用场景示意图148；
图156为本申请实施例提供的一种音频应用场景示意图149；
图157为本申请实施例提供的一种电子设备的结构示意图2；
图158为本申请实施例提供的一种电子设备的结构示意图3。
具体实施方式
下面将结合附图对本实施例的实施方式进行详细描述。
本申请实施例提供的一种音频控制方法，可应用于图1所示的音频系统200中。如图1所示，该音频系统200中可包括主设备(master)101和N个从设备(slave)102，N为大于0的整数。主设备101与任意一个从设备102之间可通过有线的方式通信，也可以通过无线的方式通信。
示例性的，主设备101与从设备102之间可以使用通用串行总线(universal serial bus，USB)建立有线连接。又例如，主设备101与从设备102之间可以通过全球移动通讯系统(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)、蓝牙、无线保真(wireless fidelity，Wi-Fi)、NFC、基于互联网协议的语音通话(voice over Internet protocol，VoIP)、支持网络切片架构的通信协议建立无线连接。
其中，主设备101用于提供需要播放的音频数据，并向从设备102输出该音频数据。从设备102用于接收主设备101发送的音频数据并播放。或者，从设备102也可用于采集音频数据，并将采集到的音频数据发送给主设备101进行存储等处理。也就是说，主设备101可将自身的音频输入输出功能分布至一个或多个从设备102中实现，从而实现跨设备的分布式音频能力。
示例性的，主设备101具体可以为手机、音箱、平板电脑、电视(也可称为智能电视、智慧屏或大屏设备)、笔记本电脑、超级移动个人计算机(Ultra-mobile Personal Computer，UMPC)、手持计算机、上网本、个人数字助理(Personal Digital Assistant，PDA)、可穿戴电子设备、车载设备、虚拟现实设备等具有音频输入输出功能的设备，本申请实施例对此不做任何限制。例如，从设备102除了可以是蓝牙耳机、有线耳机等传统的音频输出设备外，还可以是手机、电视、音箱或车载设备等安装有操作系统(例如安卓系统)的智能的电子设备。从设备102接收到主设备101发来的音频数据后可通过其操作系统对音频数据进行采样、混音或添加音效等处理。
以手机为主设备101举例，用户可以通过手机的控制中心选择一个或多个从设备102作为手机的音频输出设备。例如，如图2所示，手机可响应用户在当前显示界面中输入的预设操作(例如上拉操作或下拉操作)显示出控制中心201(也可称打开控制中心)，控制中心201也可称为上拉菜单或下拉菜单。在控制中心201中用户可设置手机内一些快捷功能的开关，例如，蓝牙功能的开关、无线局域网(WLAN)功能的开关、手电筒的开关以及亮度和音量的调节开关等，本申请实施例对此不做任何限制。
在本申请实施例中，仍如图2所示，手机还可以在控制中心201中显示音频切换功能的切换按钮202。当用户希望修改当前手机的音频输出设备时，可点击切换按钮202查询当前可以作为音频输出设备的一个或多个电子设备。
示例性的，手机检测到用户点击切换按钮202后，如图3所示，手机可在控制中心201中显示音频切换功能的详情菜单301。详情菜单301中包括当前手机搜索到的可与手机进行音频切换的一个或多个候选设备302。例如，手机可以搜索与手机位于同一Wi-Fi网络中的电子设备，并将搜索到的电子设备作为候选设备显示在详情菜单301中。又例如，手机可以在服务器中查询与手机登录同一账号(例如华为账号)的电子设备，并将查询到的电子设备作为候选设备显示在详情菜单301中。这样，用户在控制中心201中可直观的看到当前可用于与手机进行音频切换的一个或多个电子设备，方便用户进行选择。
仍如图3所示，详情菜单301中显示的候选设备可以包括手机自身(即本机)、耳机、音箱、电视或其他手机等具有音频输入输出能力的电子设备。如果用户选择本机，则说明用户希望使用手机自身的扬声器(speaker)输出手机的音频；如果用户选择其他候选设备，则说明用户希望将手机的音频通过用户选择的候选设备输出，此时用户选择的候选设备可作为手机的从设备102播放手机输出的音频。
在本申请实施例中，如图4所示，当手机检测到用户选中与手机进行音频切换的从设备102后，手机可与该从设备102建立网络连接。以电视为用户选中的从设备102举例，手机检测到用户选中电视后可与电视建立网络连接。例如，手机可通过路由器与电视建立Wi-Fi连接，或者，手机可直接与电视建立Wi-Fi P2P连接。进而，手机可从电视获取电视的音频能力参数，该音频能力参数用于反映电视所支持的具体的音频输入或输出能力。以电视所支持的音频输出能力举例，该音频能力参数可以包括电视的播放时延、音效参数、音频采样率或声音通道数目等一项或多项参数。这样，手机可基于电视的音频能力参数确定进行音频切换时的音频播放策略，进而根据该音频播放策略向电视输出对应的音频数据，从而将手机上的音频的切换至电视上播放。
例如，手机获取到电视的音频能力参数中指示电视支持播放双声道的音频数据。那么，如果手机中正在运行的音乐APP输出的音频数据为4声道的音频数据，则手机可在音频播放策略中要求将这4声道的音频数据合并为双声道的音频数据。然后，手机可将合并后的双声道的音频数据发送给电视播放，使得手机可以根据当前从设备的音频能力灵活的将音频切换至从设备上播放，为用户提供较好的音频使用体验。
又例如，用户还可以在上述详情菜单301中选择多个电子设备作为手机的从设备102进行音频切换。例如，如果检测到用户在上述详情菜单301中选择了耳机和电视，则手机可分别获取耳机和电视的音频能力参数。由于耳机的便携性较好，而电视具有较好的显示体验，那么，手机可在进行音频切换时将与视频画面对应的音频数据发送给电视播放，而将手机的铃声、通知音等系统音频数据发送给耳机播放。这样，手机可以根据多个从设备不同的音频能力将音频数据分布在多个从设备上播放，为用户提供较好的音频使用体验。
可以看出，在本申请实施例中，主设备101(例如上述手机)可响应用户的选择将音频数据输出至一个或多个从设备102中进行音频切换，实现跨设备的分布式音频能力。并且，在进行音频切换时，由于从设备102也可以具有一定的音频处理能力，因此，主设备101可以获取从设备102的音频能力参数，根据从设备102的音频能力参数动态的确定进行音频切换时的音频播放策略。这样，主设备101可以按照从设备102的实际音频能力向从设备102输出定制化的音频数据，使得从设备102也可以按照自身的音频能力对主设备发来的音频数据进行处理，从而灵活的将主设备101的音频功能分布在从设备102上实现，为用户提供较好的音频使用体验。
其中，主设备与从设备进行音频切换的具体细节将在后续实施例中详细阐述，故此处不予赘述。
示例性的，以手机作为上述音频200中的主设备201举例，图5示出了手机的结构示意图。
手机可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线 (universal serial bus，USB)接口130，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180等。
可以理解的是，本发明实施例示意的结构并不构成对手机的具体限定。在本申请另一些实施例中，手机可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
手机的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。
移动通信模块150可以提供应用在手机上的包括2G/3G/4G/5G等无线通信的解决方案。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。
无线通信模块160可以提供应用在手机上的包括无线局域网(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)等无线通信的解决方案。
在一些实施例中，手机的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得手机可以通过无线通信技术与网络以及其他设备通信。
手机通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
显示屏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)等。在一些实施例中，手机可以包括1个或N个显示屏194，N为大于1的正整数。
手机可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。
摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，手机可以包括1个或N个摄像头193，N为大于1的正整数。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行手机的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。
手机可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。
音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。
扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。手机可以通过扬声器170A收听音乐，或收听免提通话。
受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。当手机接听电话或语音信息时，可以通过将受话器170B靠近人耳接听语音。
麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。当拨打电话或发送语音信息时，用户可以通过人嘴靠近麦克风170C发声，将声音信号输入到麦克风170C。手机可以设置至少一个麦克风170C。在另一些实施例中，手机可以设置两个麦克风170C，除了采集声音信号，还可以实现降噪功能。在另一些实施例中，手机还可以设置三个，四个或更多麦克风170C，实现采集声音信号，降噪，还可以识别声音来源，实现定向录音功能等。
耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以 是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。
传感器模块180中可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等。
当然，手机还可以包括充电管理模块、电源管理模块、电池、按键、指示器以及1个或多个SIM卡接口等，本申请实施例对此不做任何限制。
上述手机的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明手机的软件结构。当然，在其他操作系统中，只要各个功能模块实现的功能和本申请的实施例类似。
图6是本申请实施例的手机的软件结构框图。
分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为五层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，HAL(hardware abstraction layer，硬件抽象层)层以及内核层。
应用程序层可以包括一系列应用程序包。
如图6所示，应用程序层中可以安装通话，备忘录，浏览器，联系人，相机，图库，日历，地图，蓝牙，音乐，视频，短信息等APP(应用，application)。
需要说明的是，应用程序层中安装的这些应用可以具有音频功能。例如，音乐APP可以播放音频，相机APP拍照时可以输出系统预设的快门声音。又例如，视频APP播放视频的同时可输出与视频画面对应的音频。又例如，地图APP开启导航功能后可输出导航语音。在本申请实施例中，可将具有音频功能的应用称为音频APP。
应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图6所示，以音乐APP为音频APP举例，Android系统中设置有为音频APP实现音频功能的音频架构601。在应用程序框架层中，上述音频架构601可包括音频管理器(AudioManager)、音频播放器和音频处理器。
示例性的，音频播放器可以为AudioTrack或MediaPlayer等播放器。音频处理器可以为AudioFlinger等处理器。当音频APP需要播放音频时可调用音频播放器，向音频播放器输入相应的音频数据。例如，音频APP可以向音频播放器输入原始的音频数据，由音频播放器对原始的的音频数据进行解析、解封装或解码等处理后，得到一帧帧的PCM(pulse code modulation，脉冲编码调制)数据。或者，音频APP也可以直接输出PCM数据至音频播放器。进而，音频播放器可将音频数据发送给音频处理器进行音频处理。
具体的，音频处理器可按照音频管理器输出的音频播放策略对音频数据进行音频处理。示例性的，音频管理器可以包括音频服务(AudioService)和音频策略模块(AudioPolicy)。音频APP在运行时可调用音频服务通知音频策略模块设置音频数据输入输出时的具体音频播放策略。例如，音量大小、音频数据的采样率、音效设置、 混音设置等。音频策略模块可在音频播放的过程中实时的向音频处理器输出对应的音频播放策略，使得音频处理器可按照最新的音频播放策略对音频播放器输出的音频数据进行混音、重采样、音效设置等处理，处理后的音频数据为待播放的音频数据。
仍如图6所示，在Android系统的应用程序框架层和内核层之间还可以包括HAL(hardware abstraction layer，硬件抽象层)。HAL负责与手机的各个硬件设备进行交互，HAL一方面隐藏了各个硬件设备的实现细节，另一方面可向Android系统提供调用各个硬件设备的接口。HAL中提供了与不同手机硬件设备对应的HAL，例如，Audio HAL、Camera HAL、Wi-Fi HAL等。
其中，Audio HAL也可以作为上述音频架构601中的一部分。音频处理器(例如AudioFlinger)可直接调用Audio HAL，将处理后的音频数据发送给Audio HAL，由Audio HAL将该音频数据发送给对应的音频输出设备(例如扬声器、耳机等)进行播放。
示例性的，根据音频输出设备的不同，Audio HAL又可以进一步划分为Primary HAL、A2dp HAL等。AudioFlinger可调用Primary HAL将音频数据输出至手机的扬声器(speaker)，或者，AudioFlinger可调用A2dp HAL将音频数据输出至与手机相连的蓝牙耳机。以A2dp HAL举例，当手机开机时，应用程序层中的蓝牙APP(也可称为蓝牙服务)可在HAL创建A2dp HAL，此时A2dp HAL可以一个空进程的形式运行，A2dp HAL尚未与具体的蓝牙设备连接。
后续，当手机与某一蓝牙设备(例如第一蓝牙耳机)连接后，蓝牙APP可在音频管理器中注册第一蓝牙耳机的标识、蓝牙地址等信息，并将第一蓝牙耳机的相关硬件参数(例如第一蓝牙耳机的采样率等)发送至A2dp HAL，使得A2dp HAL可支持与第一蓝牙耳机进行数据收发。此时A2dp HAL在手机与第一蓝牙耳机保持连接的过程中是固定不变的。当手机与第一蓝牙耳机断开连接后，蓝牙APP可在音频管理器中清空第一蓝牙耳机的相关信息，并将A2dp HAL恢复为一个空进程运行在HAL中。
当手机又与其他的蓝牙设备(例如第二蓝牙设备，第二蓝牙设备与第一蓝牙设备可以相同或不同)连接时，与上述过程类似的，蓝牙APP可在音频管理器中注册第二蓝牙耳机的标识、蓝牙地址等信息，并将第二蓝牙耳机的相关硬件参数发送至A2dp HAL，使得A2dp HAL可支持与第二蓝牙耳机进行数据收发。当手机与第二蓝牙耳机断开连接后，蓝牙APP可在音频管理器中清空第二蓝牙耳机的相关信息，并将A2dp HAL恢复为一个空进程运行在HAL。
另外，应用程序框架层还可以包括窗口管理器，内容提供器，视图系统，资源管理器，通知管理器等，本申请实施例对此不做任何限制。
例如，上述窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。上述内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。上述视图系统可用于构建应用程序的显示界面。每个显示界面可以由一个或多个控件组成。一般而言，控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、微件(Widget)等界面元素。上述资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件， 视频文件等等。上述通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，振动，指示灯闪烁等。
如图6所示，Android runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。
其中，表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。
内核层位于HAL之下，是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动等，本申请实施例对此不做任何限制。
基于图6所示的音频架构601，在本申请实施例中，如图7所示，可在手机的应用程序层中安装用于实现音频切换功能的设备虚拟化(DeviceVirtualization)APP，后续可称为DV APP。DV APP可作为系统应用常驻在手机中运行。或者，也可将DV APP实现的音频切换功能以系统服务的形式常驻在手机中运行。当手机需要将音频APP产生的音频数据切换至某一从设备上播放，或者需要使用某一从设备的录音功能录制音频时，DV APP可触发手机获取该从设备的音频能力，从而按照该从设备的音频能力在手机中创建一个对应的虚拟设备，这样，手机通过控制该虚拟设备可将自身的音频功能切换至从设备上实现。
示例性的，以音乐APP为音频APP举例，如图8中的(a)所示，手机在运行音乐APP时可显示用于音频切换的切换按钮801。当前手机使用自身的扬声器输出音频数据，如果用户希望使用其他音频输出设备继续播放该音频数据，则可点击上述切换按钮801触发音频切换功能。手机检测到用户点击切换按钮801后，DV APP可触发手机开始检测附近可进行音频切换的一个或多个候选设备。例如，如图8中的(b)所示，手机可检测与手机位于同一Wi-Fi网络且具有音频输出功能的候选设备，并将检测到的候选设备显示在菜单802中。以菜单802中包括电视803、音箱804以及耳机805这三个候选设备举例，用户可从这三个候选设备中选择一个作为继续播放音乐APP中音频数据的从设备。
以用户在菜单802中选择电视803举例，检测到用户点击电视803这一候选设备后，手机可向电视803发送访问请求。此时，如图9中的(a)所示，电视803可显示对话框901请求用户允许手机访问电视803。如果用户允许手机访问电视803，可选择对话框901中“本次允许”或“始终允许”的按钮，此时，电视803可向手机发送允许访问的响应。进而，DV APP可触发手机与电视803建立网络连接，例如Wi-Fi P2P连接等。
需要说明的是，手机与从设备(例如电视803)建立的网络连接具体可以是指业务通道的网络连接(即业务连接)。例如，在用户选择电视803作为手机的从设备之前，手机可能与电视803已经通过Wi-Fi网络建立了连接，此时的连接是指数据通道的连接(即数据连接)。当用户选择电视803作为手机的从设备后，手机与电视803在已经建立的数据连接的基础上建立业务连接。例如，该网络连接可以是基于TCP(transmission control protocol，传输控制协议)或UDP(user datagram protocol，用户数据报协议)的P2P连接，本申请实施例对此不做任何限制。
如果手机当前是第一次与电视803建立网络连接，则如图9中的(b)所示，电视803可显示一串随机生成的连接码902作为鉴权信息与手机进行身份鉴权，同时，电视803可将连接码902发送给手机。DV APP在手机的显示屏中要求用户输入电视803上显示的连接码902。如果DV APP检测到用户在手机上输入的连接码与电视803发给手机的连接码902相同，说明手机与电视803之间的身份鉴权通过，则DV APP可触发手机与电视803建立网络连接。当然，如果手机与电视803之间曾经完成过身份鉴权，则DV APP在检测到用户选择电视803后可直接与电视803建立网络连接，无需再次进行身份鉴权。
在本申请实施例中，手机与电视803建立了网络连接后，手机与电视803可通过该网络连接进行通信。例如，手机中的DV APP可将电视803作为手机的从设备，基于已建立的网络连接从电视803中获取电视803的音频能力参数。例如，该音频能力参数可以包括电视803的音频播放时延、音效参数、音频采样率或声音通道数目等一项或多项，这些参数可反映出电视803所支持的具体的输出能力。进而，仍如图7所示，DV APP可调用HAL的预设接口，向预设接口中输入获取到的音频能力参数，从而创建与电视803对应的HAL。本申请实施例中可将DV APP为了将音频数据切换至从设备而创建的HAL称为DMSDP(Distributed Mobile Sensing Development Platform，分布式移动传感开发平台)Audio HAL。与传统Audio HAL不同的是，DMSDP Audio HAL并不与手机实际的硬件设备相对应，DMSDP Audio HAL可将接收到的音频数据通过已建立的建立网络连接传输给手机的从设备，实现音频切换功能。
在一些实施例中，电视803也可以将用于指示自身显示能力的显示能力参数(例如屏幕分辨率、显示数据的编解码算法等)通过已建立的网络连接发送给手机的DV APP；或者，电视803(即从设备)也可以将用于指示自身相机能力的相机能力参数(例如摄像头数目、图像处理算法等)通过已建立的网络连接发送给手机的DV APP。当然，如果从设备(例如上述电视803)还具有其他能力(例如打印能力等)，则从设备也可将相关的能力参数发送给手机的DV APP。那么，手机的DV APP还可以将这些能力参数同上述音频能力参数一同输入至预设接口中创建对应的HAL，此时创建的 HAL不仅集成有从设备的音频能力，还集成有从设备的其他各项能力。后续实施例中可以将DV APP按照从设备的各项能力参数创建的HAL称为DMSDP HAL，也就是说，上述DMSDP Audio HAL可以是DMSDP HAL中用于实现音频功能的一个功能模块，在一些实施例中，也可以将DMSDP Audio HAL称为DMSDP Audio HAL。手机可通过DMSDP HAL与从设备实现音频、显示或相机等各项分布式场景中的业务功能，本申请实施例对此不做任何限制。
并且，在本申请实施例中，DV APP除了在HAL为手机的从设备创建对应的DMSDP Audio HAL之外，还可以调用AudioManager在AudioPolicy中注册该从设备的音频能力。示例性的，DV APP可将电视803的标识和电视803的音频能力参数发送给AudioPolicy进行保存。AudioPolicy可根据电视803的音频能力参数确定对应的音频策略，并将确定出的音频策略输出给音频处理器(例如AudioFlinger)。这样，AudioFlinger可根据AudioPolicy确定出的音频策略对音频播放器(例如AudioTrack)输出的音乐APP的音频数据进行对应的处理，并将处理后的音频数据通过DMSDP Audio HAL发送给电视803进行播放，从而将手机上的音频定制化的切换至从设备(即电视803)上播放，实现跨设备的分布式音频能力。
其中，电视803的音频能力参数可以包括电视803的播放参数和录制参数，播放参数用于反映电视803的音频播放能力，录制参数用于反映电视803的音频录制能力。例如，电视803可将播放参数封装在第一字段中，将录制参数封装在第二字段中发送给手机。手机的AudioPolicy从第一字段中提取到上述播放参数后可确定对应的音频播放策略，AudioPolicy从第二字段中提取到上述录制参数后可确定对应的音频录制策略。当然，第一字段或第二字段也可以为空，说明电视803不具有音频播放能力或音频录制能力。
另外，DV APP在HAL创建的DMSDP Audio HAL是可以动态更新的。当电视803的音频能力发生变化时，例如，如果电视803的音频播放时延发生变化，或者，用户手动更改了电视803的音效参数，则电视803可动态的向手机发送最新的音频能力参数。进而，手机的DV APP可根据电视803最新的音频能力参数更新DMSDP Audio HAL，使得DMSDP Audio HAL与电视803的音频能力相匹配。同时，手机的DV APP可将电视803最新的音频能力参数注册至AudioPolicy中，使得AudioPolicy可以按照最新的音频能力参数更新当前的音频策略。
上述实施例是以音频切换时手机的从设备数量为1个举例说明的，在本申请实施例中，手机还可以将自身的音频数据切换至多个从设备上播放。例如，用户可以在手机搜索到的候选设备中选择多个设备作为手机的从设备。以手机的从设备包括音箱804和电视803举例，与上述手机和电视803的交互过程类似的，手机可以分别与多个从设备建立网络连接，并获取每个从设备的音频能力参数，从而创建与每个从设备对应的DMSDP Audio HAL。例如，如图10所示，DV APP可按照音箱804的音频能力参数1在HAL创建DMSDP Audio HAL1，并且，DV APP可按照电视803的音频能力参数2在HAL创建DMSDP Audio HAL2。进而，手机将音箱804和电视803的音频能力注册至AudioPolicy后，AudioPolicy可根据每个从设备的音频能力参数定制对应的音频策略，使得AudioFlinger可根据AudioPolicy确定出的音频策略处理音频数据。 后续，AudioFlinger可通过DMSDP Audio HAL1将需要音箱804播放的第一音频数据发送给音箱804，并通过DMSDP Audio HAL2将需要电视803播放的第二音频数据发送给电视803，从而实现跨设备的分布式音频能力。其中，第一音频数据与第二音频数据可以相同或不同。
可以看出，在本申请实施例提供的音频架构中，DV APP可响应用户的音频切换需求与对应的从设备建立网络连接，从而获取从设备的音频能力参数。进而，DV APP可按照该音频能力参数在HAL创建对应的DMSDP Audio HAL，并在AudioPolicy中注册从设备的音频能力，使得AudioPolicy能够根据从设备的音频能力定制化的向AudioFlinger输出与从设备的音频能力匹配的音频策略。后续，AudioFlinger按照该音频策略处理手机提供的音频数据后，可调用已创建的DMSDP Audio HAL将处理后的音频数据发送给从设备，使得从设备可播放与自身音频能力相匹配的来自手机(即主设备)的音频数据。这样，主设备能够根据从设备的音频能力将自身的音频功能切换至其他一个或多个从设备上，充分利用从设备的音频处理能力，与从设备更加高效、灵活的协同完成音频切换过程，从而为用户提供较好的音频使用体验。
仍以手机为主设备举例，以下将结合具体的音频能力参数阐述本申请实施例提供的一种音频控制方法。
仍以音乐APP为音频APP举例，手机在运行音乐APP使用自身的扬声器播放歌曲A时，如图11所示，音乐APP可调用音频播放器(例如AudioTrack)将歌曲A的音频数据1发送给音频处理器(例如AudioFlinger)。由AudioFlinger对音频数据1进行采样、混音、设置音效或声道转换等处理。由于此时手机没有连接其他音频输出设备，因此，如图11中的虚线箭头所示，AudioFlinger可调用HAL中的Primary HAL，将处理后的音频数据1输出至手机的扬声器进行播放，实现手机本地的音频播放功能。
另外，音乐APP在运行时可调用AudioManager将正在播放的音频数据1的相关信息注册在AudioPolicy中。例如，音乐APP可将音频数据1当前的音效模式、声道数目、采样率、音量大小等信息缓存在AudioPolicy中。
在本申请实施例中，仍如图8中的(a)所示，手机在运行音乐APP时可显示用于音频切换的切换按钮801。同时，手机可在后台运行用于实现音频切换功能的DV APP。音乐APP检测到用户点击上述切换按钮801后可与DV APP通信，触发DV APP搜索附近可进行音频切换的一个或多个候选设备。如图8中的(b)所示，DV APP可将与手机位于同一Wi-Fi网络的电视803、音箱804以及耳机805这三个候选设备显示在菜单802中。
以用户选择音箱804为手机的从设备举例，检测到用户选择音箱804这一候选设备后，DV APP可将音箱804作为手机的从设备与音箱804建立网络连接。或者，音乐APP检测到用户点击上述切换按钮801后可触发预设的通信APP(例如hilink APP)通信搜索附近可进行音频切换的一个或多个候选设备。当检测到用户选中某一候选设备(例如音箱804)后，可触发DV APP可将音箱804作为手机的从设备与音箱804建立网络连接。例如，该网络连接可以是基于TCP(transmission control protocol，传输控制协议)或UDP(user datagram protocol，用户数据报协议)的P2P连接。
需要说明的是，如果本次为手机首次与音箱804建立网络连接，则手机与音箱804还需要进行身份鉴权。其中，身份鉴权的具体过程可参见图9中的(a)和(b)中手机与电视803之间进行身份鉴权的相关描述，此处不再赘述。
手机与音箱804建立了网络连接后，DV APP可将音箱804作为手机的从设备，从音箱804中获取音箱804的音频能力参数。如图12所示，音箱804中的音频架构与手机中的音频架构类似，音箱804中可安装用于实现音频切换功能的代理APP。手机与音箱804建立了网络连接后可向音箱804的代理APP发送音频能力参数的获取请求，进而，响应该获取请求，音箱804的代理APP可调用其AudioManager从音箱804的AudioPolicy或AudioFlinger中获取音箱804自身的音频能力参数。这样，音箱804的代理APP可将音箱804的音频能力参数发送给手机的DV APP。或者，也可以在手机中设置代理APP，音箱804的代理APP可将音箱804的音频能力参数发送给手机的代理APP，进而由手机的代理APP将音箱804的音频能力参数发送给DV APP，以减轻DV APP的运行负荷。
仍如图11所示，手机中的DV APP获取到音箱804的音频能力参数后，可按照该音频能力参数创建与音箱804对应的DMSDP Audio HAL 1101。并且，DV APP可调用AudioManager在AudioPolicy中注册音箱804的音频能力。例如，DV APP可将音箱804的标识以及音箱804的音频能力参数发送给AudioPolicy。这样，AudioPolicy可以根据音箱804的音频能力参数设置将音频切换至音箱804时的音频播放策略。
其中，音箱804的音频能力参数可用于反映音箱804所支持的具体的音频输入或输出能力。在本申请实施例中，从设备(例如音箱804)的音频能力参数可以包括两类参数，一类是主要与音箱804的硬件能力相关的音频能力参数(可称为硬件能力参数)，例如音箱804支持的采样率、声道数目等，这类参数可反映出音箱804输入或输出音频时的硬件能力；另一类是主要与音箱804的软件能力相关的音频能力参数(可称为软件能力参数)，例如音箱804支持的音效模式、编解码能力等，这类参数可反映出音箱804输入或输出音频时的软件能力。这样一来，AudioPolicy可以结合音箱804播放音频时的硬件能力和软件能力设置对应的音频播放策略。
示例性的，与音箱804的硬件能力相关的音频能力参数(即硬件能力参数)主要是由音箱804的硬件特性决定的，例如，音箱804中处理器、扬声器或麦克风的硬件类型、型号接口类型等。当手机的从设备不发生变化时，例如，当手机的从设备为音箱804时，音箱804在音频能力参数中上报的硬件能力参数一般是固定不变的。当然，在一些极端情况下，例如音箱804中的一些硬件发生故障或损坏时，音箱804向手机上报的音频能力参数中的硬件能力参数也是可以改变的。
相应的，与音箱804的软件能力相关的音频能力参数(即软件能力参数)主要是由音箱804的软件特性决定的，例如，音箱804使用的音效算法、回声消除算法、编码或解码算法等。当手机的从设备不发生变化时，例如，当手机的从设备为音箱804时，音箱804在音频能力参数中上报的软件能力参数是可以动态更新的。例如，用户打开音箱804的音效开关后，音箱804可在音频能力参数中上报音箱804的音效模式为开启状态。当用户关闭音箱804的音效开关后，音箱804可更新其音频能力参数，在音频能力参数中上报音箱804的音效模式为关闭状态。
需要说明的是，任意一个设备在实现音频输入或输出功能时都需要设备的硬件和软件相互支持，因此在划分上述软件能力参数和硬件能力参数时无法单纯定义软件能力参数完全是由设备的软件特性决定的，而硬件能力参数完全是由设备的硬件特性决定的。例如，音箱804上报的音频能力参数中可以包括音频播放时延这一参数，音频播放时延既与音箱804对音频数据的处理算法、网络环境等软件因素相关，也与音箱804的硬件处理能力相关。在本申请实施例中，由于音箱804上报的音频播放时延是可以动态更新的，因此可将音频播放时延作为一个软件能力参数。当然，本领域技术人员也可以实际应用场景或实际经验划分上述软件能力参数和硬件能力参数，本申请实施例对此不做任何限制。
在一些实施例中，音箱804的音频能力参数中可以包括音箱804所支持的音效能力(可称为音效参数)。例如，音箱804支持重低音音效、3D环绕音效、杜比音效、histen音效等。
一般，音箱804在某一时刻开启的音效模式是固定的。例如，音箱804开机后可默认开启杜比音效。如果用户希望修改音箱804播放音频时的音效，则用户可以手动在音箱804上设置当前的音效模式。例如，可将音箱804从杜比音效的音效模式设置为重低音音效。那么，音箱804在向手机的DV APP上报音频能力参数时，可将音箱804所支持的音效模式以及当前开启的音效模式作为音效参数添加在音频能力参数中。当然，如果音箱804没有开启音效模式，音箱804也可以在音频能力参数中说明音箱804没有开启音效模式。
示例性的，手机运行音乐APP时，音乐APP可调用AudioTrack将音频数据1发送给AudioFlinger。AudioFlinger在处理音频数据1之前可与AudioPolicy通信，向AudioPolicy请求本次处理音频数据1的音频播放策略。AudioPolicy响应于AudioFlinger的请求，可在音箱804的音频能力参数中查询当前音箱804是否开启了音效模式。如果开启了音效模式，则AudioPolicy可在音频播放策略中设置对音频数据1不做音效处理。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger不需要对音频数据1做音效处理。AudioFlinger调用DMSDP Audio HAL1101将音频数据1发送给音箱804后，可由音箱804对音频数据1做相应的音效处理后播放。
如果音箱804没有开启音效模式，则AudioPolicy可在音频播放策略中设置对音频数据1不做音效处理。或者，如果音箱804没有开启音效模式，为了提高音频在音箱804上的播放效果，AudioPolicy可在音频播放策略中设置对音频数据1做音效处理。例如，对音频数据1进行重低音处理。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger可响应该音频播放策略对音频数据1进行重低音处理，并将处理后的音频数据1通过DMSDP Audio HAL 1101发送给音箱804。此时，音箱804虽然没有开启任何音效，但音箱804在播放来自手机的音频时也可为用户呈现重低音的音效。
这样一来，AudioPolicy根据音箱804的音效参数设置的音频播放策略可以避免手机(即主设备)与音箱804(即从设备)均对音频数据进行音效处理而导致的音效叠加现象，也可以避免手机(即主设备)与音箱804(即从设备)均对音频数据未进行 音效处理而导致的音效缺失现象，从而提高用户的音频使用体验。
在一些实施例中，AudioPolicy还可以结合从设备的设备类型确定与音效相关的音频播放策略。例如，手机当前的从设备为可穿戴手表，手机与可穿戴手表建立网络连接后可以获取到可穿戴手表的标识以及可穿戴手表的音频能力参数。手机通过可穿戴手表的标识可以确定当前从设备的设备类型为可穿戴设备。如果可穿戴手表的音频能力参数中指示可穿戴手表开启了杜比音效，则手机的AudioPolicy可在音频播放策略中设置使用杜比音效处理需要播放的音频数据。后续，AudioFlinger可响应该音频播放策略向音频数据中添加杜比音效，并将处理后的音频数据通过相应的DMSDP Audio HAL发送给可穿戴手表。这样，可穿戴手表在播放该音频数据时无需再进行音效处理，不仅可以降低可穿戴手表这一类音频处理能力较低的设备的运行负荷，同时可以保证可穿戴手表在播放音频数据时可呈现出较好的杜比音效，从而提高用户的音频使用体验。
在另一些实施例中，音乐APP在手机中运行时，手机还可以调用AudioManager将手机支持的音效模式以及从设备(例如音箱804)支持的音效模式提供给音乐APP，由音乐APP选择具体使用哪种音效模式播放当前的音频数据。例如，音乐APP可通过列表的形式向用户展示手机以及音箱804支持的音效模式，由用户手动选择需要的音效模式。那么，如果用户选择的音效模式为手机和音箱804均支持的音效模式，则AudioPolicy可在音频播放策略中设置手机对音频数据不做音效处理，从而由音箱804对手机发来的音频数据进行相应的音效处理后播放。如果用户选择的音效模式为只有手机支持的音效模式，则AudioPolicy可在音频播放策略中设置手机对音频数据进行相应的音效处理，这样音箱804播放该音频数据后仍然可呈现出用户所需的音效。相应的，如果用户选择的音效模式为只有音箱804支持的音效模式，则AudioPolicy可在音频播放策略中设置手机对音频数据不做音效处理，从而由音箱804对手机发来的音频数据进行相应的音效处理后播放。
在另一些实施例中，音箱804的音频能力参数中可以包括音箱804所支持的发声能力(可称为音频质量参数)，例如，音箱804所支持的采样率(即音箱804每秒从连续的音频信号中提取并组成离散信号的采样个数)、声音通道数目(即声道数目)等。
示例性的，AudioPolicy获取到上述音频能力参数中音箱804所支持的最大采样率为96KHz，进而，AudioPolicy可查询当前AudioFlinger接收到的音频数据1的采样率。如果当前AudioFlinger接收到的音频数据1的采样率大于96KHz，则AudioPolicy可在音频播放策略中设置对音频数据1进行重采样，重采样的采样率为96KHz。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger可按照96KHz的采样率对音频数据1进行重采样，使得重采样后的音频数据1与音箱804的声音播放能力相匹配。
又例如，AudioPolicy获取到上述音频能力参数中的声音通道数目为2通道，进而，AudioPolicy可查询当前AudioFlinger接收到的音频数据1的声音通道数目是否为2通道。如果不是，则AudioPolicy可在音频播放策略中设置声音通道数目为2通道。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger可按照2通道的声 音通道数目对音频数据1进行混音，使得混音后的音频数据1与音箱804的声音播放能力相匹配。
在另一些实施例中，一些音频APP在播放音频时具有低时延的播放要求。例如，K歌应用在录制用户歌声时需要及时输出伴奏音频保证用户的录制体验。又例如，视频应用在输出显示画面时需要及时输出对应的音频保证用户的观看体验。这些要求低时延的音频APP需要音频输出设备在输出音频时的处理速度尽可能的快。
示例性的，手机从音箱804获取到的音频能力参数中也可以包括音箱804的音频播放时延(latency)。该音频播放时延具体可以是指音箱804处理一帧音频数据所需的时间。一般，音频数据是以音频流的形式产生的，为了音频算法处理或传输的方便，可按照某一时间单位(又称为某一时长)将连续的音频数据划分为一帧一帧的音频数据。示例性的，可取2.5ms～60ms为单位的音频数据为一帧音频数据，一帧音频数据为设备进行音频处理时的最小粒度。
AudioPolicy根据上述音频能力参数中的音频播放时延可判断音箱804是否支持低时延的音频处理能力。例如，当音箱804的音频播放时延小于或等于5ms(即音箱804处理一帧音频数据所需的时间小于或等于5ms)时可确定音箱804支持低时延的音频处理能力。那么，AudioPolicy可在音频播放策略中设置低时延模式，使得AudioFlinger可按照低时延模式处理音频数据1。或者，音箱804可在音频能力参数中指示自身是否支持低时延的音频处理能力，例如，如果音箱804的音频能力参数中预设的时延参数的字段为0，则说明音箱804支持低时延的音频处理能力。此时，AudioPolicy可在音频播放策略中设置低时延模式。相应的，如果其音频能力参数中预设的时延参数的字段为1，则说明音箱804不支持低时延的音频处理能力。此时，AudioPolicy可在音频播放策略中设置非低时延模式。
低时延的音频处理能力一般要求设备对音频数据具有较高的处理能力。例如，在非低时延模式中，AudioFlinger可设置一帧音频数据的时长为10ms，AudioFlinger每次需要缓存10帧音频数据保证音频输出的连续一致性。也就是说，手机处理每一帧音频数据的时间粒度为10ms，手机每次处理音频数据的一个周期为100ms(10ms*10)。而在低时延模式中，AudioFlinger可将一帧音频数据的时长降低为5ms，手机的缓存中仍然需要存储10帧音频数据，那么，在低时延模式中，手机处理每一帧音频数据的时间粒度为5ms，手机每次处理音频数据的一个周期为50ms(5ms*10)。
如果AudioPolicy输出的音频播放策略中设置了低时延模式，则AudioFlinger可以5ms为一帧音频数据的时长向音箱804发送音频数据1。也就是说，相比于非低时延模式，在低时延模式中手机可将每一帧音频数据的时长设置的较小，例如，一帧音频数据的时长为5ms。后续，音箱804可按照低时延模式以5ms的时间粒度处理每一帧音频数据，以降低每一帧音频数据的处理时间，提高用户的音频使用体验。
示例性的，AudioPolicy还可以查询当前运行的音乐APP是否有低时延的播放要求。如果过音乐APP有低时延的播放要求，且音箱804支持低时延播放能力，则AudioPolicy可在音频播放策略中设置低时延模式。如果音乐APP有低时延的播放要求，但音箱804不支持低时延播放能力，则AudioPolicy可在音频播放策略中尽量减少对音频数据1的处理流程。例如，AudioPolicy可以设置对音频数据1不做音效处理。 这样可减少手机向音箱804发送音频数据的时延，尽量满足音频APP的低时延播放要求。相应的，如果音乐APP没有低时延的播放要求，则AudioPolicy可以在音频播放策略中设置低时延模式，也可以在音频播放策略中设置非低时延模式，本申请实施例对此不做任何限制。
在另一些实施例中，音箱804的音频能力参数中可以包括音箱804的EQ(Equalizer，均衡器)参数。EQ参数一般包括频率(frequency)、增益(gain)和量化值(quantize)三个参数，频率用于设定音频数据中需要进行调整的频率点的参数；增益用于调整某一频率的音频数据进行增益或衰减的参数；quantize用于设定进行增益或衰减的频段“宽度”的参数。通过EQ参数可以对音频数据中的一个或多个频段进行增益或衰减，从而达到调整音色的目的。
示例性的，AudioPolicy获取到上述音频能力参数中的EQ参数后，AudioPolicy可在音频播放策略中将音频数据1的EQ参数设置为从音箱804的获取到的EQ参数。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger可按照音箱804的EQ参数调整音频数据1的音色，使得后续手机发送给音箱的音频数据1与音箱804的音频播放能力相匹配。
在一些实施例中，AudioPolicy获取到的音箱804的音频能力参数后，可将音箱804的音频能力参数保存在手机中。如表1所示，AudioPolicy可将每次DV APP获取到的从设备的设备名称、标识以及对应的音频能力参数保存在手机中。其中，标识具体可以为从设备的IMEI(international mobile equipment identity，国际移动设备识别码)或MAC(Media Access Control)地址等能够唯一标识该设备的标识。音频能力参数可以包括音效参数、音频质量参数、音频播放时延以及EQ参数等。这样，AudioPolicy不仅可以根据表1中音箱804的音频能力参数定制与音箱804的音频能力相匹配的音频播放策略，后续，当手机再次将音箱804作为手机的从设备与手机建立网络连接后，手机通过获取音箱804的标识可在表1中查找是否存储有音箱804的音频能力参数。如果存储有音箱804的音频能力参数，则手机无需再额外获取音箱804的音频能力参数便可确定对应的音频播放策略，从而提升后续音频切换过程的切换速度。
表1
Figure PCTCN2021104105-appb-000001
Figure PCTCN2021104105-appb-000002
上述实施例是以手机获取到的音箱804的音频能力参数中包括音效参数、音频质量参数、音频播放时延以及EQ参数为例说明的，可以理解的是，上述音频能力参数中还可以包括其他与音箱804的音频能力相关的参数，例如信噪比、失真率等参数，本申请实施例对此不做任何限制。手机中的AudioPolicy可根据音箱804的音频能力参数定制与音箱804的音频能力相匹配的音频播放策略，使得音箱804(即从设备)可播放与自身音频能力相匹配的来自手机(即主设备)的音频数据。
与上述实施例中手机保存音箱804的音频能力参数类似的，在另一些实施例中，AudioPolicy根据音箱804的音频能力参数确定出对应的音频播放策略后，还可以将音箱804的音频播放策略保存在手机中。如表2所示，AudioPolicy可将每次为不同从设备确定出的音频播放策略保存在手机中。这样，当手机再次将音箱804作为手机的从设备进行音频切换时，DV APP通过获取音箱804的标识可在表2中查找是否存储有音箱804的音频播放策略。如果存储有音箱804的音频播放策略，则DV APP可直接将音箱804的音频播放策略下发给AudioPolicy，手机无需再额外获取音箱804的音频能力参数，也无需再次确定对应的音频播放策略，从而提升后续音频切换过程的切换速度。
表2
Figure PCTCN2021104105-appb-000003
当然，如果后续音箱804的音频能力参数发生变化，则手机的AudioPolicy可根据音箱804最新的音频能力参数重新确定音箱804的音频播放策略。此时，AudioPolicy可更新表2中音箱804的音频播放策略保存在手机中。
需要说明的是，音箱804的音频播放策略也可以为空，即手机不需要对需要发送给音箱804的音频数据做与上述音频能力参数相关的处理。此时，第一设备可直接将来自音频APP的音频数据发送给音箱804。当然，手机在向音箱804发送音频数据前，仍然可以对待发送的音频数据进行解析、编码、解码、封装或解封装等常规处理操作，本申请实施例对此不做任何限制。
示例性的，仍如图11所示，手机中的AudioFlinger按照AudioPolicy输出的音频播放策略对音频数据1进行处理后，可调用DMSDP Audio HAL 1101将处理后的音频数据1发送给音箱804的代理APP。在一些实施例中，AudioFlinger通过DMSDP Audio HAL 1101向音箱804发送音频数据1时，还可以按照一定的规则或协议对音频数据1进行解析、封装或编码等处理，这些处理一般是与音箱804的音频能力参数没有直接关联的。例如，DMSDP Audio HAL 1101可将AudioFlinger输出的音频数据1打包为一帧一帧的数据包，并将音频数据1的相关信息(例如音频数据1的类型、音频格式 等)添加包头文件中与音频数据1的数据包一起发送给音箱804的代理APP。
当然，音箱804的应用程序层中可以安装除代理APP之外的其他应用，例如音乐APP等，本申请实施例对此不做任何限制。仍如图11所示，音箱804的代理APP接收到手机发来的音频数据1后，可调用其音频播放器(例如AudioTrack)将音频数据1发送给音箱804的音频处理器(例如AudioFlinger)。由AudioFlinger对接收到的音频数据1进行处理，并调用HAL中的Audio HAL，将处理后的音频数据1输出至音箱804的扬声器进行播放，完成手机将音频切换至音箱804继续播放的过程。
可以看出，对于手机的从设备(例如上述音箱804)而言，从设备只需要安装上述代理APP后，便可以通过代理APP向手机上报从设备的音频能力参数，并从手机获取到与自身音频能力匹配的音频数据进行播放，从而灵活的将主设备101的音频功能分布在从设备102上实现，为用户提供较好的音频使用体验。
进一步地，当手机将正在播放的歌曲A的音频数据1成功切换至音箱804上播放后，如果检测到当前播放的音频数据发生变化，或者检测到从设备的音频能力发生了变化，或者检测到用户切换了新的从设备，则手机还可以动态调整当前的音频播放策略，使从设备能够播放与自身音频能力相匹配的来自手机(即主设备)的音频数据。
示例性的，手机将正在播放的歌曲A的音频数据1切换至音箱804后，手机仍在运行音乐APP。此时，用户可以通过手机的音量按钮修改音频数据1在音箱804上的播放音量。其中，在Android系统的音频架构中预先定义了多种类型的音频流。例如，音频流的类型包括STREAM_ALARM(警报)、STREAM_MUSIC(音乐)、STREAM_RING(铃声)、STREAM_SYSTEM(系统)以及STREAM_VOICE_CALL(通话)等。
如图13所示，当手机检测到用户按压音量按钮1301时可显示音量调节控件1302。同时，由于音乐APP输出的音频数据1的音频流类型为STREAM_MUSIC，因此，手机可调用AudioManager在AudioPolicy中按照STREAM_MUSIC这种音频流类型重新设置音量大小。
例如，手机检测到用户按压音量按钮1301按钮后，可调用AudioManager在AudioPolicy中将音频数据1当前的音量乘以一个预设的音量系数，得到调整后的音量大小。例如，当用户按压“音量+”按钮时，AudioPolicy可将当前的音量(例如100)乘以音量系数120％，得到调整后的音量大小为120。又例如，当用户按压“音量－”按钮时，AudioPolicy可将当前的音量(例如100)乘以音量系数80％，得到调整后的音量大小为80。进而，AudioPolicy可将调整后的音量大小输出至AudioFlinger，由AudioFlinger根据调整后的音量大小处理音频数据1。例如，AudioFlinger可以调用stream volume()函数修改音频数据1的增益，从而修改音频数据1的音量大小。进而，AudioFlinger可以调用DMSDP Audio HAL 1101将处理后的音频数据1发送给音箱804，音箱804播放的音频数据1为音量调节后的音频数据。这样，用户将手机中的音频切换至音箱804后，还可以通过手机方便的控制音频在音箱804上播放的音量大小。
在另一些实施例中，手机将正在播放的歌曲A的音频数据1切换至音箱804后，手机仍在运行音乐APP。如图14A所示，音乐APP还可以修改正在播放的歌曲A的 音效模式。例如，用户可以在音乐APP的设置菜单1401中将歌曲A的音效模式从重低音音效1402修改为民谣音效1403。音乐APP检测到用户点击设置菜单1401中的民谣音效1403后，可调用AudioManager在AudioPolicy中修改正在手机上播放的音频数据1的音效模式。
进而，AudioPolicy可根据从音箱804获取到的音频能力参数查找音箱804当前是否支持民谣音效的播放模式。如果音箱804不支持民谣音效的播放模式，则AudioPolicy可更新当前的音频播放策略，在音频播放策略中设置使用民谣音效处理音频数据1。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger可以对音频数据1做民谣音效的处理。后续，AudioFlinger调用DMSDP Audio HAL 1101将处理后的音频数据1发送给音箱804后，音箱804播放的音频数据1可为用户呈现出民谣音效。
或者，如果音箱804支持民谣音效的播放模式，则AudioPolicy也可更新当前的音频播放策略，在音频播放策略中设置不使用民谣音效处理音频数据1。这样，AudioPolicy将音频播放策略输出给AudioFlinger后，AudioFlinger不需要对音频数据1做民谣音效的处理。后续，AudioFlinger调用DMSDP Audio HAL 1101将处理后的音频数据1发送给音箱804后，可由音箱804对音频数据1做民谣音效处理后播放，这样也可为用户呈现出民谣音效。
在一些实施例中，如图14B所示，手机还可以在音乐APP的设置菜单1401中标识各种音效模式所对应的设备。例如，手机和音箱804均支持重低音音箱和杜比音效。民谣音效只有手机支持，Histen音效只有音箱804支持。这样，用户可以直观的了解当前主设备和从设备所支持的音效模式，从而对音频数据1选择相应的音效模式。例如，如果用户选择的音效模式只有音箱804支持(例如Histen音效)，则手机的AudioPolicy可更新当前的音频播放策略，在音频播放策略中设置手机对音频数据1不进行音频处理，后续可由音箱804对音频数据1做Histen音效处理后播放。如果用户选择的音效模式只有手机支持(例如民谣音效)，则手机的AudioPolicy可更新当前的音频播放策略，在音频播放策略中设置手机使用民谣音效处理音频数据1，后续，手机将处理后的音频数据1发送给音箱804后，音箱804播放的音频数据1可为用户呈现出民谣音效。如果用户选择了手机和音箱均支持的音效模式(例如杜比音效)，则手机可在音频播放策略中默认由手机(或音箱804)使用杜比音效处理音频数据1。或者，手机也可以通过显示对话框提示用户选择使用手机提供的杜比音效或者使用音箱804提供的杜比音效处理音频数据。进而，手机可根据用户的选择在音频播放策略中设置由手机或音箱804对音频数据1进行音效处理。
又或者，手机除了将当前主设备(即手机)和从设备(即音箱804)支持的音效模式展示给用户外，还可以将其他音频输出设备支持的音效模式展示给用户。例如，如果手机之前将电视作为从设备进行音频切换，则手机可获取到电视支持的一种或多种音效模式。手机可将电视支持的一种或多种音效模式进行保存。当手机将音箱804作为从设备进行音频切换时，还可以在上述设置菜单1401中显示电视支持的一种或多种音效模式。那么，如果用户选中电视支持的音效模式，说明用户希望使用电视支持的音效模式处理手机当前输出的音频数据，则手机可断开与音箱804之间的网络连接， 重新将电视作为从设备与电视建立网络连接。进而，手机可将音频数据输出至电视，由电视按照用户选中的音效模式对音频数据进行音效处理并播放。当然，在手机更换从设备之前还可以通过对话框询问用户是否将从设备由音箱804更新为电视。如果用户确认将手机的从设备更新为电视，则手机可断开与音箱804之间的网络连接，并与电视建立网络连接。
在另一些实施例中，手机将正在运行的音乐APP的音频数据1切换至音箱804后，如果手机退出音乐APP，则手机可以结束本次音频切换。此时，手机中的AudioFlinger可停止调用DMSDP Audio HAL 1101将后续手机产生的音频数据发送给音箱804，而是调用HAL中的Primary HAL将后续手机产生的音频数据输出至手机的扬声器进行播放。
又或者，手机退出音乐APP后，手机可继续将手机产生的音频数据发送给音箱804播放，即本次音频切换没有结束。例如，用户通过点击home键等方式触发手机退出音乐APP后，如果用户此时打开通信APP与联系人Mike进行音频通话(例如VoIP通话)，则如图15所示，手机可显示与联系人Mike的通话界面1501。此时，与上述音乐APP将音频数据1切换至音箱804的过程类似的，如图16A所示，通信APP可调用AudioTrack将来自联系人Mike的音频数据2发送给AudioFlinger。AudioFlinger可按照AudioPolicy输出的音频播放策略对音频数据2进行处理，并调用DMSDP Audio HAL 1101将处理后的音频数据2发送给音箱804播放。
并且，手机运行通信APP时还需要录制用户的声音，将用户的声音发送给联系人Mike。那么，手机开始运行通信APP后还可以向音箱804(即从设备)发送录音指令，使得音箱804可响应该录音指令开启自身的音频录制功能采集用户输入的音频数据，并将采集到的音频数据发送给手机。这样，手机在将音频输出功能切换至其他从设备上实现的同时，还可以将音频输入功能切换至其他从设备上实现。其中，手机通过音箱804采集用户输入的音频数据，从而实现音频输入功能的具体过程可参见图26的相关描述，故此处不予赘述。
不同的是，通信APP接收来自联系人Mike的音频数据2后，音频数据2的音频流类型变为STREAM_VOICE_CALL。此时，通信APP可调用AudioManager将音频数据2的相关信息注册在AudioPolicy中。例如，通信APP可将音频数据2当前的音效模式、声道数目、采样率、音量大小等信息缓存在AudioPolicy中。
此时，手机的从设备没有改变，仍然为音箱804，但手机播放的音频数据(即音源)发生了改变。那么，仍如图16A所示，AudioPolicy可根据音频数据2的相关信息以及音箱804的音频能力参数更新对应的音频播放策略。
例如，如果通信APP输出的音频数据2为8声道的音频数据，而音箱804仅支持2声道和4声道的音频数据，则AudioPolicy可在更新的音频播放策略中指示将8声道的音频数据转换为4声道的音频数据，使得转换后的音频数据2与音箱804的声音播放能力相匹配。又例如，通信APP输出的音频数据2的类型为STREAM_VOICE_CALL，而音箱804仅支持STREAM_MUSIC类型的音频流。那么，AudioPolicy可在更新的音频播放策略中指示由手机播放上述音频数据2。此时，AudioFlinger可按照更新后的音频播放策略调用Primary HAL，使用Primary HAL将音频数据2输出至手机的扬声器 播放。也就是说，在音频切换的过程中，如果手机输出的音频数据发生变化，也可触发手机重新定制与从设备的音频能力相匹配的音频播放策略。
在一些实施例中，如图16B所示，手机运行通话APP时可通过基站等网络设备接收对端设备(例如另一手机)发来的音频数据3，与一般音频APP不同的是，手机可直接通过HAL的modem HAL接收音频数据3，而不需要通过AudioTrack和AudioFlinger对音频数据3进行处理。在本申请实施例中，如图16B所示，DV APP按照音箱804的音频能力参数创建了DMSDP Audio HAL 1101，并在AudioPolicy中注册了音箱804的音频能力参数后，AudioPolicy可向modem HAL指示当前音频数据的输出设备为与DMSDP Audio HAL 1101对应的音箱804。进而，modem HAL接收到音频数据3后，可将音频数据3发送给DMSDP Audio HAL 1101，由DMSDP Audio HAL1101将音频数据3发送给音箱804播放，实现通话场景下的音频切换功能。
在另一些实施例中，手机将正在运行的音乐APP的音频数据1切换至音箱804后，如果音箱804的音频能力发生变化，音箱804可动态的向手机的DV APP上报最新的音频能力参数。进而，DV APP可按照音箱804最新的音频能力参数更新DMSDP Audio HAL 1101，并在AudioPolicy中更新已注册的音箱804的音频能力参数。
例如，当手机和音箱804所在的Wi-Fi网络的网速降低时，音箱804的音频播放时延会随之增加。此时，音箱804可向手机的DV APP上报最新的音频播放时延。DV APP可按照最新的音频播放时延更新HAL中的DMSDP Audio HAL 1101。并且，DV APP可在AudioPolicy中更新音箱804的音频播放时延。如果更新后的音频播放时延大与预设时间(例如20ms)，则AudioPolicy可确定此时音箱804不支持低时延播放能力。进而，AudioPolicy可更新音频播放策略，在更新后的音频播放策略中设置非低时延模式，使得AudioFlinger按照非低时延模式处理音频数据1。也就是说，当从设备的音频能力发生变化时也可触发手机重新定制与从设备的音频能力相匹配的音频播放策略。
在另一些实施例中，手机将正在运行的音乐APP的音频数据1切换至音箱804后，用户还可以在手机上手动修改当前与手机进行音频切换的从设备。
例如，如图17中的(a)所示，手机将音频数据1切换至音箱804后继续显示音乐APP的应用界面1701，如果用户需要切换当前与手机进行音频切换的从设备，可打开手机的控制中心。例如，用户可在应用界面1701中输入上拉操作，响应于用户的上拉操作，手机可显示控制中心1702。控制中心1702中包括音频切换功能的切换按钮1703。当用户希望修改当前手机的从设备时，可点击切换按钮1703查询当前可以作为手机的从设备的一个或多个候选设备。
如图17中的(b)所示，手机检测到用户点击切换按钮1703后，手机可检测与手机位于同一Wi-Fi网络且具有音频输出功能的候选设备，并将检测到的候选设备显示在控制中心1702中。例如，控制中心1702中可以包括当前与手机建立网络连接的音箱804，还可以包括手机本机1704，还可以包括手机检测到的未与手机建立网络连接的电视803和耳机805。其中，音箱804已被显示为选中状态，提示用户当前手机输出的音频已切换至音箱804中播放。
如果用户希望将手机输出的音频从音箱804切换至电视803中播放，可点击控制 中心1702中的电视803。响应于用户点击电视803的操作，DV APP可断开与音箱804之间的网络连接，并且，手机可将电视803作为手机当前的从设备与电视803建立网络连接。进而，如图18A所示，与上述实施例中手机将音频数据切换至音箱804的过程类似的，DV APP可将电视803作为手机最新的从设备，从电视803中获取电视803的音频能力参数’。进而，如图18A所示，DV APP可按照该音频能力参数’调用相关的接口创建与电视803对应的DMSDP Audio HAL 1801，并关闭为音箱803创建的DMSDP Audio HAL 1101的进程。或者，DV APP可按照电视803的音频能力参数更新DMSDP Audio HAL 1101，使得更新后的DMSDP Audio HAL 1101与电视803的音频能力相匹配。
并且，如图18A所示，DV APP可调用AudioManager在AudioPolicy中注册电视803的音频能力。例如，DV APP可将电视803的标识以及电视803的音频能力参数’发送给AudioPolicy。这样，AudioPolicy可以根据电视803的音频能力参数’设置新的音频播放策略，并将设置的新的音频播放策略输出至AudioFlinger。AudioFlinger可按照AudioPolicy输出的新的音频播放策略对音乐APP输出的音频数据1进行处理。后续，AudioFlinger可调用新创建的DMSDP Audio HAL 1801，将处理后的音频数据1发送给电视803，从而将手机的音频功能从音箱804切换至电视803。
在另一些实施例中，如果用户希望将手机输出的音频切换至耳机805中播放，可点击上述控制中心1702中的耳机805。由于现有的Android系统中已经设置了与耳机805对应的Audio HAL，例如A2dp HAL。因此，手机检测到用户点击控制中心1702中的耳机805后，手机可断开与音箱804之间的网络连接，由AudioFlinger按照现有的音频架构调用A2dp HAL将音乐APP的音频数据1输出至耳机805，从而将手机的音频功能从音箱804切换至耳机805。
在一些实施例中，手机在进行音频切换时DV APP也可以不在HAL创建相应的DMSDP Audio HAL。仍以手机的从设备为电视803举例，如图18B所示，手机的DV APP获取到电视2003的音频能力参数后，可在AudioPolicy中注册电视2003的音频能力参数，而无需在HAL创建相应的DMSDP Audio HAL。那么，AudioPolicy按照电视2003的音频能力参数向AudioFlinger输出对应的音频播放策略后，AudioFlinger可根据该音频播放策略处理来自音乐APP的音频数据1。与上述实施例不同的是，AudioFlinger可将处理后的音频数据1发送给手机中应用程序层内的代理APP，由该代理APP将处理后的音频数据1发送给电视2003播放。或者，手机中的代理APP也可以系统服务的形式运行在手机中，本申请实施例对此不做任何限制。
与图18A类似的，手机中的代理APP可将处理后的音频数据1发送给电视2003中的代理APP，电视2003的代理APP可调用其音频播放器(例如AudioTrack)将来自手机的音频数据1发送给音频处理器(例如AudioFlinger)。由AudioFlinger对接收到的音频数据1进行处理，并调用HAL中的Audio HAL，将处理后的音频数据1输出至电视2003的扬声器进行播放，完成手机将音频切换至电视2003继续播放的过程。
另外，上述实施例是以用户从手机的控制中心或手机正在运行的音频应用中切换手机的音频输出设备举例说明的，可以理解的是，本领域技术人员还可以将进行音频切换的入口设置在手机的其他位置。例如，如图19中的(a)所示，手机可以在下拉 菜单1901中显示上述切换按钮1703。其中，手机还可以在下拉菜单1901的通知中心1902中以通知的形式提示用户当前手机的音频被切换至某一设备中播放。又例如，如图19中的(b)所示，手机还可以在负一屏菜单1903中显示上述切换按钮1703，本申请实施例对此不做任何限制。
上述实施例是以音乐APP为音频APP举例，具体阐述了将音乐APP中的音频数据1切换至从设备上进行音频切换，并在音频切换过程中动态修改音频播放策略的过程。在另一些实施例中，用户可能需要将手机上的音频和图像同时切换至其他设备上播放。例如，手机在运行视频APP播放视频时，用户可能需要将视频中的每一帧图像以及与图像对应的音频同时切换至电视中播放。
目前，已经有一些投屏技术用于将手机上的图像和音频同时投射至大屏设备(例如电视)上播放。例如，手机可通过Miracast的投屏方式，将显示屏实时输出的显示数据发送给电视，同时，手机可将AudioFlinger实时输出的音频数据发送给电视，从而将手机上的图像和音频投射至电视播放。又例如，手机可通过DLNA(digital living network alliance，数字生活网络联盟)的投屏方式，将视频的URL(Uniform Resource Locator，统一资源定位符)发送给电视，由电视根据该URL获取相应的图像和音频进行播放。
在本申请实施例中，如图20所示，手机在运行视频APP时如果用户需要使用投屏功能，可打开手机的控制中心2001。控制中心2001中可设置卡片2002，卡片2002用于展示手机检测到的附近的一个或多个设备。例如，手机可将检测到的与手机位于同一Wi-Fi网络内的电子设备显示在卡片2002中供用户选择。又例如，手机可在卡片2002显示与手机绑定在同一账号(例如华为账号)下的多个电子设备，如果手机检测到某一电子设备接入手机所在的Wi-Fi网络，则手机可在卡片2002中点亮该电子设备，从而提示用户该电子设备可作为手机的从设备实现投屏功能。
如果检测到用户在卡片2002中选中某一电子设备(例如电视2003)，由于电视2003同时具有显示功能和音频播放功能，说明用户希望将手机上运行的视频APP的图像和音频投射至电视2003。此时，手机可与电视2003建立网络连接，并且，如图21所示，手机可按照现有的投屏方式将手机中视频APP输出的显示数据发送给电视2003进行显示。
不同的是，手机可按照上述实施例中音频切换的过程将手机中的音频数据切换至电视2003中，而不是按照DLNA或Miracast的投屏方式将音频数据切换至电视2003中。
示例性的，手机检测到用户点击卡片2002中的电视2003后，仍如图21所示，一方面，手机可以将视频APP输出的显示数据发送给电视2003。另一方面，手机的DV APP可从电视2003中获取电视2003的音频能力参数。进而，DV APP可按照电视2003的音频能力参数在HAL创建与电视2003对应的DMSDP Audio HAL2101，并且在AudioPolicy中注册电视2003的音频能力参数。这样，AudioPolicy根据电视2003的音频能力参数可设置投屏过程中与电视2003的音频能力匹配的音频播放策略，并将音频播放策略输出至AudioFlinger。AudioFlinger可按照该音频播放策略对视频APP产生的音频数据进行处理，并调用DMSDP Audio HAL2101将处理后的音频数据发送给 电视2003播放。或者，AudioFlinger也可以将处理后的音频数据发送给视频APP，由视频APP将音频数据发送至电视2003播放，本申请实施例对此不做任何限制。
另外，手机通过DMSDP Audio HAL2101向电视2003发送上述音频数据时还可以在音频数据中添加时间戳。同时，手机在向电视2003发送来自视频APP的显示数据时也可以在显示数据中添加时间戳。这样，电视2003可按照显示数据中的时间戳以及音频数据的时间戳播放画面与音频同步的视频，使投屏过程中电视2003播放的音频与画面保持同步。
可以看出，相比于传统投屏方式中直接将AudioFlinger实时输出的音频数据发送给从设备(例如电视2003)，在本申请实施例提供的投屏方法中，手机通过获取从设备的音频能力参数可定制出与从设备的音频能力相匹配的音频播放策略，使得AudioFlinger可按照该音频播放策略输出对应的音频数据发送给从设备，这样，从设备可播放与自身音频能力相匹配的来自手机(即主设备)的音频数据，提升了投屏场景下音频的播放效果。
上述实施例中是以手机将音频数据切换至某一个从设备上实现音频切换功能举例说明的，在本申请的另一些实施例中，手机还可以将音频数据切换至多个从设备上进行音频切换。
示例性的，仍以手机运行音乐APP举例，如图8中的(a)所示，如果检测到用户点击音乐APP中的切换按钮801，可触发手机搜索附近可进行音频切换的一个或多个候选设备。与上述实施例中不同的是，如图22所示，手机在菜单2201中显示出手机搜索到的多个候选设备后，用户可在这些候选设备中选择多个同时作为手机的从设备进行音频切换。
以用户在菜单2201中选择第一音箱2202和第二音箱2203作为手机的从设备举例，手机可分别与第一音箱2202和第二音箱2203建立网络连接。进而，如图23所示，手机可通过DV APP分别获取第一音箱2202和第二音箱2203的音频能力参数。例如，第一音箱2202的音频能力参数为音频能力参数1，第二音箱2203的音频能力参数为音频能力参数2。那么，DV APP可在AudioPolicy中注册第一音箱2202的音频能力参数1和第二音箱2203的音频能力参数2。并且，DV APP可在HAL按照音频能力参数1创建与第一音箱2202对应的DMSDP Audio HAL 2301，并按照音频能力参数2创建与第二音箱2203对应的DMSDP Audio HAL 2302。进而，AudioPolicy可根据第一音箱2202的音频能力参数1和第二音箱2203的音频能力参数2设置音频播放策略，使得AudioFlinger可根据AudioPolicy确定出的音频播放策略处理来自音乐APP的音频数据。
示例性的，AudioPolicy确定的音频播放策略可以包括与第一音箱2202对应的音频播放策略1，以及与第二音箱2203对应的音频播放策略2。其中，AudioPolicy根据第一音箱2202的音频能力参数1确定音频播放策略1的过程，与上述实施例中AudioPolicy根据音箱803的音频能力参数确定音频播放策略的过程类似，同样，AudioPolicy根据第二音箱2203的音频能力参数2确定音频播放策略2的过程，也与上述实施例中AudioPolicy根据音箱803的音频能力参数确定音频播放策略的过程类似，故此处不再赘述。
不同的是，AudioPolicy可指示AudioFlinger将来自音乐APP的音频数据1复制为2份，例如，音频数据11和音频数据12。这样，仍如图23所示，AudioPolicy将音频播放策略1输出给AudioFlinger后，AudioFlinger可按照音频播放策略1处理音频数据11，得到与第一音箱2202的音频能力相匹配的音频数据。同样，AudioPolicy将音频播放策略2输出给AudioFlinger后，AudioFlinger可按照音频播放策略2处理音频数据12，得到与第二音箱2203的音频能力相匹配的音频数据。后续，仍如图23所示，AudioFlinger可调用DMSDP Audio HAL 2301将处理后的音频数据11发送给第一音箱2202播放，同时，AudioFlinger可调用DMSDP Audio HAL 2302将处理后的音频数据12发送给第二音箱2203播放。这样，手机可将自身的音频播放功能同时切换至多个从设备上，实现跨设备的分布式音频能力。
在一些实施例中，AudioPolicy还可以结合每个从设备的音频能力或设备位置等信息定制相应的音频播放策略。例如，第一音箱2202和第二音箱2203在各自上报的音频能力参数中还可以携带自身的位置信息。例如，第一音箱2202的摆放位置相对于用户位于用户的左边，第二音箱2203的摆放位置相对于用户位于用户的右边。那么，AudioPolicy根据该位置信息可在音频播放策略1中设置按照左声道音效处理音频数据11，并在音频播放策略2中设置按照右声道音效处理音频数据12。这样，AudioFlinger调用相应的DMSDP Audio HAL将处理后的音频数据11和音频数据12分别发送给第一音箱2202和第二音箱2203播放时，可为用户呈现出立体声的播放效果。
又例如，以手机进行音频切换的从设备为电视和音箱举例，AudioPolicy可结合电视和音箱分别上报的音频能力参数，确定出音箱的音效处理能力比电视的音效处理能力更强。那么，AudioPolicy可在音频播放策略中设置将需要进行音效处理的音频数据输出给音箱播放，将不需要进行音效处理的音频数据输出给电视播放。进而，AudioFlinger可根据AudioPolicy输出的音频播放策略对来自音频APP的音频数据进行分流，得到需要进行音效处理的音频数据A以及不需要进行音效处理的音频数据B。后续，AudioFlinger可调用与音箱对应的DMSDP Audio HAL将处理后的音频数据A发送给音箱播放，并调用与电视对应的DMSDP Audio HAL将处理后的音频数据B发送给电视播放。
在另一些实施例中，如果第一音箱2202的音频能力参数1和第二音箱2203的音频能力参数2相同，例如第一音箱2202和第二音箱2203是两个型号相同的音箱，则如图24所示，DV APP可在HAL创建一个与音频能力参数1(也即音频能力参数2)对应的DMSDP Audio HAL 2401。也就是说，DV APP在HAL创建的DMSDP Audio HAL是与音频能力参数对应的。由于第一音箱2202的音频能力参数1和第二音箱2203的音频能力参数2相同，因此AudioPolicy根据该音频能力参数确定出的音频播放策略也相同。如图24所示，AudioPolicy可将确定出的音频播放策略输出至AudioFlinger，由AudioFlinger按照该音频播放策略对来自音频APP的音频数据进行处理。不同的是，AudioFlinger可将处理后的音频数据分成2份，例如，AudioFlinger可对处理后的音频数据1进行复制，得到音频数据11’和音频数据12’(此时音频数据11’和音频数据12’相同)。又或者，AudioFlinger可从处理后的音频数据1中提取与左声道对应的音频数据11’以及与右声道对应的音频数据12’(此时音频数据11’和音频数据12’不同)。 进而，AudioFlinger可调用DMSDP Audio HAL 2401将音频数据11’和音频数据12’分别发送至第一音箱2202和第二音箱2203，实现跨设备的分布式音频能力。
上述实施例中是以手机将自身的音频数据切换至一个或多个从设备上播放举例说明的，例如，手机通过获取电视的音频能力创建DMSDP Audio HAL，将来自音频APP的音频数据通过DMSDP Audio HAL切换至电视上播放。此时，电视为手机的一个从设备。
在另一些实施例中，手机的从设备(例如电视)在播放音频时也可以将对应的音频数据切换至其他设备中进行音频切换。此时，手机的从设备可作为主设备，按照上述实施例中的音频切换方法将手机发来的音频数据再次切换至其他从设备上播放，实现多级设备之间的连续音频切换功能。
示例性的，如图25所示，电视2501与音箱2502建立蓝牙连接后，电视2501可获取音箱2502的音频能力参数，从而创建对应的DMSDP Audio HAL。此时，音箱2502可作为电视2501的从设备播放来自电视2501的音频数据。那么，当手机将音频数据发送至电视2501后，电视2501可作为主设备根据音箱2502的音频能力参数设置对应的音频播放策略，并按照该音频播放策略处理手机发来的音频数据。后续，电视2501可调用与音箱2502对应的DMSDP Audio HAL将音频数据发送给音箱2502播放。这样，手机最终将音频数据切换至了音箱2502中播放，音箱2502可播放与自身音频能力相匹配的音频数据，音箱2502的主设备(即电视2501)也可以根据音箱2502的音频能力对音箱2502的音频播放过程进行管控，从而为用户提供较好的音频使用体验。
或者，手机在获取电视2501的音频能力参数时，如果电视2501已经与音箱2502建立蓝牙连接，即此时电视2501的音频输出设备为音箱2502，那么，电视2501可直接将音箱2502的音频能力参数上报给手机。这样，手机可以直接按照音箱2502的音频能力参数定制对应的音频播放策略，并按照该音频播放策略处理音频数据后发送给电视2501，再由电视2501将手机发来的音频数据透传至音箱2502播放。
又或者，如果手机从电视2501中获取到电视2501当前的从设备为音箱2502，则手机可以直接与音箱2502建立网络连接，并从音箱2502中获取音箱2502的音频能力参数。这样，手机也可以直接按照音箱2502的音频能力参数定制对应的音频播放策略，并按照该音频播放策略处理音频数据后发送给音箱2502播放，无需再由电视2501将手机发来的音频数据透传至音箱2502。
可以理解的是，电视2501作为主设备将音频数据切换至蓝牙音箱2502的具体过程，与电视2501作为从设备时，手机将音频数据切换至电视2501的具体过程类似，故此处不再赘述。
另外，上述实施例中是以手机将音频数据切换至一个或多个从设备上播放举例说明的，即将手机的音频输出功能分布至一个或多个从设备中实现，可以理解的是，手机也可以将音频输入功能(也可称为音频录制或录音功能)分布至一个或多个从设备中实现。也就是说，手机可以使用一个或多个从设备的录音功能输入音频数据，并将输入的音频数据发送至手机。
示例性的，与上述实施例中的音频播放过程类似的，手机从从设备中获取到的音频能力参数中除了包括从设备的音频播放能力(例如音效参数、音频质量参数或音频 播放时延等)，还可以包括从设备的音频录制能力。
以音箱为手机的从设备举例，如表3所示，音箱的音频能力参数可以包括播放参数和录制参数。其中，播放参数具体可包括上述实施例中所述的音效参数、音频质量参数或音频播放时延等，播放参数用于反映音箱的音频输出能力；录制参数具体可包括采样率以及设备所支持的语音算法等，录制参数用于反映音箱的音频输入能力。其中，语音算法中的3A算法具体可包括AEC(acoustic echo cancelling，回声消除)算法、AGC(automatic gain control，自动增益控制)算法以及ANC(active noise control，主动降噪)算法，用于提高录制音频的音频质量。
表3
Figure PCTCN2021104105-appb-000004
如图26所示，以手机运行通信APP进行音频通话举例，在运行通信APP时既需要播放将来自联系人的音频数据，还需要录制用户输入的音频数据发送给联系人。那么，在运行通信APP的过程中，如果用户选择将手机的音频功能切换至音箱，则如图27所示，手机可在运行通信APP时可显示提示2602，用于提示用户使用音箱的扬声器和麦克风播放、录制声音。并且，仍如图26所示，手机可与音箱建立网络连接并获取音箱的音频能力参数，该音频能力参数中可以包括如表2所示的播放参数和录制参数。进而，DV APP可按照该音频能力参数在HAL创建DMSDP Audio HAL 2601。创建出的DMSDP Audio HAL 2601既可以支持向音箱发送音频数据，还可以支持接收音箱录制的音频数据。并且，DV APP将音箱的音频能力参数注册至AudioPolicy之后，AudioPolicy可根据音频能力参数中的播放参数定制对应的音频播放策略，同时，AudioPolicy可根据音频能力参数中的录制参数定制对应的音频录制策略。
当然，如果从设备(例如音箱)上报的音频能力参数中不包括录制参数，说明从设备不具备音频录制能力，则手机可选择使用自身的麦克风或其他具有音频录制能力的设备录制音频数据，本申请实施例对此不做任何限制。
示例性的，如果手机获取到的音箱的音频能力参数中既包括播放参数也包括录制参数，说明音箱同时具有音频输出和输入能力。那么，手机按照音箱的音频能力参数将音频功能切换至音箱后，如图28中的(a)所示，手机可在控制中心中显示与音频输出能力对应的第一按钮2801以及与音频输入能力对应的第二按钮2802。用户可通过第一按钮2801和第二按钮2802分别控制手机的音频输出和输入功能在从设备上的切换。例如，如果检测到用户点击第一按钮2801，则图28中的(b)所示，手机可显示具有音频输出功能的候选设备的设备列表2803，其中，手机当前的音频输出设备为 音箱。用户可在设备列表2803中切换手机的音频输出设备。类似的，如果检测到用户点击第二按钮2802，则图28中的(c)所示，手机可显示具有音频输入功能的候选设备的设备列表2804，其中，手机当前的音频输入设备也为音箱。用户可在设备列表2804中切换手机的音频输入设备。这样，用户可以按照自身的需求将手机的音频输出和输入能力分别切换至对应的设备中，分开控制手机的音频输出和输入功能，提高用户的音频使用体验。
与上述实施例中手机的AudioPolicy定制音频播放策略类似的，AudioPolicy可根据上述录制参数中的采样率和语音算法设置音频录制策略。例如，如果音箱录制音频数据1时支持16KHz的采样率，则AudioPolicy可在音频录制策略中设置以16KHz的采样率对音频数据1进行采样。又例如，如果音箱录制音频数据1时支持3A算法，则AudioPolicy可在音频录制策略中设置不使用3A算法处理音频数据1，避免手机与音箱重复使用3A算法处理录制的音频数据1。
手机的AudioPolicy确定出当前的音频录制策略后，仍如图26所示，可将该音频录制策略输出给AudioFlinger，AudioFlinger通过调用DMSDP Audio HAL 2601可接收来自音箱录制的音频数据。示例性的，仍如图26所示，音箱可通过硬件层中的麦克风等硬件设备录制音频数据4，并将录制得到的音频数据4通过AudioHAL输出至音箱的AudioFlinger进行处理，例如使用3A算法处理音频数据4。进而，AudioFlinger可将处理后的音频数据4输出至音箱的音频录制器(AudioRecord)，由AudioRecord将录制的音频数据4上报给音箱中安装的代理APP，最终由代理APP将录制的音频数据4发送给手机。手机接收到音箱发来的音频数据4后，可通过DMSDP Audio HAL 2601将音频数据4输出至手机的AudioFlinger。此时，AudioFlinger可按照AudioPolicy输出的音频录制策略处理音频数据4，使得处理后的音频数据4与音箱的音频录制能力相匹配。后续，AudioFlinger可将处理后的音频数据4通过音频录制器(AudioRecord)输出给通信APP。同时，通信APP运行时产生的音频数据也可按照上述实施例中的音频切换方法切换至音箱上播放。这样，手机可结合从设备的音频能力，将自身的音频输入输出功能灵活的切换至其他从设备上，实现跨设备的分布式音频架构。
与上述实施例中手机将音频数据切换至多个从设备中播放类似的，手机也可以通过多个从设备录制音频数据。示例性的，如图29所示，手机的从设备可以包括音箱2701和音箱2702，音箱2701和音箱2702均具有录音功能。那么，手机的DV APP获取到音箱2701和音箱2702的音频能力参数后，可在HAL创建对应的DMSDP Audio HAL 2703和DMSDP Audio HAL 2704。并且，DV APP可在AudioPolicy中注册音箱2701和音箱2702的音频能力参数，使得AudioPolicy可以根据音箱2701和音箱2702的音频能力参数确定音频录制策略。例如，该音频录制策略可指示AudioFlinger将音箱2701和音箱2702分别采集到的音频数据进行混音，实现立体声的混音效果。
那么，AudioFlinger通过DMSDP Audio HAL 2703接收到音箱2701录制的音频数据5以及通过DMSDP Audio HAL 2704接收到音箱2702录制的音频数据6后，AudioFlinger可按照AudioPolicy输出的音频录制策略对音频数据5和音频数据6进行混音处理。例如，AudioFlinger滤除音频数据5中的杂音和回声后可将音频数据5作为左声道数据，并且，AudioFlinger滤除音频数据6中的杂音和回声后可将音频数据6 作为右声道数据，进而，AudioFlinger可将左声道数据和右声道数据合并为一个音频文件。后续，AudioFlinger可将合并后的音频文件通过音频录制器(AudioRecord)输出给通信APP，使得通信APP最终获取到的音频能够尽可能真实的还原用户的真实发声情况。
与上述实施例中手机按照音频播放策略将音频数据切换至从设备上播放的过程类似的，手机将音频录制功能切换至从设备上实现后，如果检测到当前录制的音频数据发生变化，或者检测到从设备的音频录制能力发生了变化，或者检测到用户切换了新的从设备，则手机还可以动态调整当前的音频录制策略。这样，手机可以动态调整音频录制策略对从设备的音频录制过程进行管控，从而为用户提供较好的音频使用体验。
在分布式音频场景中，主设备可与从设备交互不同类型的音频数据。仍以手机为主设备举例，手机在运行音乐APP时播放的歌曲为MUSIC(音乐)类型的音频数据，手机接收到短信时播放的短信提示音为NOTIFICATION(通知)类型的音频数据。当手机与从设备(例如音箱)连接时，手机可将正在播放的MUSIC类型的音频数据发送至音箱播放。此时，如果手机接收到新的短信，则手机可将NOTIFICATION类型的音频数据也发送至音箱播放。这样一来，用户在使用音箱听音乐时会被短信提示音所打扰，使用户的音频使用体验降低。
在本申请实施例中，可按照音频数据具体实现的业务功能定义音频数据的不同类型。例如，可将通话业务中手机为实现通话功能接收到的对端发送的音频数据定义为通话音；例如，可将音频或视频业务中手机为实现音视频播放功能而产生的音频数据定义为媒体音；例如，可将导航业务中手机为实现导航功能而产生的音频数据定义为导航音；例如，可将手机在实现按键功能时用户点击按键时产生的音频数据定义为按键音等。一个应用中可以产生或接收到一种或多种类型的音频数据。例如，微信APP在播放歌曲时可产生媒体音类型的音频数据，微信APP在进行音频通话业务时接收到的音频数据为通话音类型的音频数据。
示例性的，在安卓系统中，可按照具体的业务功能将音频数据的类型划分为：ALARM(警报)、MUSIC(音乐)、RING(铃声)、SYSTEM(系统)、NOTIFICATION(通知)、DTMF(双音多频)、COMMUNICATION(通信)以及VOICE_CALL(通话)等类型。手机对不同类型的音频数据可以分别进行控制。例如，如图30所示，手机的设置应用可以在声音的设置界面3001中向用户提供设置各个类型的音频数据的音量大小的选项。例如，设置界面3001中可以包括与MUSIC(音乐)类型对应的音量调整滑块3002。用户可以通过滑动音量调整滑块3002设置MUSIC(音乐)类型的音频数据的音量大小。类似的，用户还可以在设置界面3001中设置NOTIFICATION(通知)、ALARM(警报)以及VOICE_CALL(通话)等类型的音频数据的音量大小。这样，手机在播放不同类型的音频数据时，可按照用户设置的音量大小播放对应的音频数据。
由于音频数据通常是以数据流的形式存在的，因此可将音频数据的类型称为音频流的类型。在安卓系统中，以RING(铃声)这种类型的音频数据举例，也可以将RING(铃声)这种类型的音频数据表示为STREAM_RING(铃声流)。当然，在不同版本的安卓系统中，对音频数据的类型的具体划分可能不一致，本申请实施例对此不做任 何限制。另外，在其他操作系统中，也可以按照业务场景的不同将音频数据划分为多种类型。
对于不用类型的音频数据，手机可按照设定的设备选择策略对不同的音频数据进行分流。例如，可在设备选择策略中预先设置RING类型的音频数据可以由已连接的耳机和本机的扬声器同时播放，MUSIC类型的音频数据优先使用耳机播放。
那么，手机与耳机连接后，当手机播放MUSIC类型的音频数据时，例如，在手机运行音乐APP播放歌曲时，手机按照上述设备选择策略可将MUSIC类型的音频数据发送给耳机播放。如果手机接收到联系人打来的电话，则手机需要播放RING类型的铃声。此时，手机可按照上述设备选择策略将RING类型的铃声同时发送给耳机和本机的扬声器，由耳机和本机的扬声器同时播放RING类型的铃声。
在本申请实施例中，手机作为主设备可以将产生的音频数据切换至一个或多个从设备上播放。手机可以结合当前从设备的设备特点为不同类型的音频数据设置相应的设备选择策略，以便在进行音频切换时根据设备选择策略进行分流。
例如，当手机的从设备为音箱时，由于音箱播放音频数据时的音效较好但便携性较差，用户使用音箱一般是收听音乐或音频节目。因此，可预先在设备选择策略中设置音箱作为手机的从设备时用于接收MUSIC类型的音频数据，而不接收NOTIFICATION类型的音频数据。后续，如图31所示当用户选择音箱为手机本次音频切换的从设备时，手机可按照上述设备选择策略将MUSIC类型的音频数据(例如歌曲)发送至音箱播放。如果手机产生了NOTIFICATION类型的音频数据，则手机不会将NOTIFICATION类型的音频数据(例如短信提示音)发送至音箱播放。这样，手机将音箱作为从设备进行音频切换时，用户可在音箱上收听来自手机的MUSIC类型的音频数据，而不会受到其他手机中其他音频数据(例如短信提示音)的打扰。
又例如，当手机的从设备为车载设备(也可称为车机)时，由于车载设备播放音频数据时大多在驾驶的场景下，用户需要保持较为集中的注意力。因此，可预先在设备选择策略中设置车载设备作为手机的从设备时可以接收MUSIC类型和导航语音类型的音频数据，而不接收其他类型(例如NOTIFICATION类型以及SYSTEM)的音频数据。后续，如图32所示，当用户选择车载设备为手机本次音频切换的从设备时，手机可按照上述设备选择策略将MUSIC类型(例如歌曲)或导航语音类型的音频数据发送至车载设备播放。如果手机接收或者产生了其他类型的音频数据，则手机不会将该音频数据发送至车载设备播放。这样，手机将车载设备作为从设备进行音频切换时，用户可在车载设备上收听来自手机的MUSIC类型或VOICE_CALL类型的音频数据，而不会受到其他手机中其他音频数据(例如短信提示音)的打扰。
另外，当手机在上述设备选择策略中禁止从设备接收某一类型的音频数据时，例如，禁止车载设备接收NOTIFICATION类型的音频数据时，手机还可以在设备选择策略中进一步设置该NOTIFICATION类型的音频数据的音频输出设备，即允许播放该NOTIFICATION类型的音频数据的具体设备。例如，手机可将自身设置为NOTIFICATION类型的音频数据的音频输出设备。那么，手机将车载设备作为从设备进行音频切换时，如果产生NOTIFICATION类型的音频数据，则手机不会将该音频数据发送给车载设备，而是使用自身的扬声器播放该音频数据，防止手机产生的音频数 据被漏掉。当然，手机也可以选择其他设备作为音频切换时NOTIFICATION类型音频数据的音频输出设备，本申请实施例对此不做任何限制。
可以看出，在本申请实施例中，主设备(例如上述手机)在将音频数据输出至一个或多个从设备中进行音频切换时，可将与从设备的设备特点相匹配的音频数据发送给从设备播放，从而为用户过滤掉一些不适合在从设备上播放的音频数据，使得音频数据与音频输出设备的适配性更高，为用户提供较好的音频使用体验。
在一些实施例中，如图33所示，在手机的DV APP为从设备创建了DMSDP Audio HAL之后，DV APP还可以向AudioPolicy下发与当前从设备对应的设备选择策略。该设备选择策略中记录了从设备对不同类型的音频数据的播放能力。以手机的从设备为音箱举例，音箱的设备选择策略可以如表4所示，该设备选择策略中记录了音箱对每一种类型的音频数据的播放能力。例如，允许在音箱上播放MUSIC类型和RING类型的音频数据，不允许在音箱上播放SYSTEM类型和NOTIFICATION类型的音频数据。
表4
Figure PCTCN2021104105-appb-000005
一般，如图33所示，音频APP产生了某一类型的音频数据后，可调用音频播放器进行播放。并且，音频APP可在音频播放器中通过设置预设的参数(例如mode参数)标识上述音频数据的具体类型。例如，当音频APP将mode参数设置为01时，表示音频APP向音频播放器输入的音频数据的类型为MUSIC类型；当音频APP将mode参数设置为11时，表示音频APP向音频播放器输入的音频数据的类型为RING类型等。
那么，仍如图33所示，当AudioFlinger通过音频播放器接收到来自音频APP产生的音频数据后，AudioFlinger可通过读取音频播放器中的mode参数确定此时接收到的音频数据的类型。进而，仍如图33所示，AudioFlinger可请求AudioPolicy查询该类型的音频数据是否允许在当前的从设备(即音箱)上播放。AudioPolicy可响应该请求，根据DV APP下发的如表4所示的设备选择策略确定当前音频数据的音频输出设备是否为音箱，即为当前的音频数据选择一个合适的音频输出设备。
如果音箱允许播放当前类型的音频数据，则AudioPolicy可向AudioFlinger指示当前音频数据的音频输出设备为音箱。进而，如图33中的实线箭头所示，AudioFlinger对音频数据进行处理后，可将处理后的音频数据通过上述DMSDP Audio HAL发送给音箱，由音箱播放该音频数据。
相应的，如果音箱不允许播放当前类型的音频数据，则AudioPolicy可以重新为当前的音频数据选择一个音频输出设备，例如，AudioPolicy可将本机的扬声器设置为当 前音频数据的音频输出设备。进而，AudioPolicy可向AudioFlinger指示当前音频数据的音频输出设备为本机的扬声器。那么，如图33中的虚线箭头所示，AudioFlinger对音频数据进行处理后，可将处理后的音频数据通过Primary HAL发送给手机的扬声器，由手机的扬声器播放该音频数据。
可以理解的是，可以在上述设备选择策略(例如表4所示的音箱的设备选择策略)中仅设置音箱允许播放的音频数据的类型。此时，其他类型的音频数据可默认为音箱不允许播放的音频数据。或者，可以在表4所示的设备选择策略中仅设置音箱不允许播放的音频数据的类型。此时，其他类型的音频数据可默认为音箱允许播放的音频数据，本申请实施例对此不做任何限制。
在另一些实施例中，如表5所示，也可以在设备选择策略中设置每一种类型的音频数据对应的音频输出设备。例如，对于MUSIC类型的音频数据，允许该音频数据在手机、音箱以及电视上播放。对于NOTIFICATION类型的音频数据，允许该音频数据在手机和手表上播放。
表5
类型 音频输出设备
MUSIC(音乐) 手机、音箱、电视
NOTIFICATION(通知) 手机、手表
…… ……
那么，当AudioFlinger接收到某一类型的音频数据后，仍然可以请求AudioPolicy确定该类型的音频数据的具体音频输出设备。以MUSIC类型的音频数据举例，AudioPolicy可按照表5所示的设备选择策略确定能够播放该音频数据的音频输出设备包括手机、音箱以及电视。如果当前手机连接的从设备为音箱，则AudioPolicy可确定MUSIC类型的音频数据的音频输出设备为音箱，进而指示AudioFlinger将MUSIC类型的音频数据发送至音箱播放。以NOTIFICATION类型的音频数据举例，AudioPolicy可按照表5所示的设备选择策略确定能够播放该音频数据的音频输出设备包括手机和手表，即当前手机连接的音箱不允许播放该音频数据，那么，AudioPolicy可将手机确定为NOTIFICATION类型的音频数据的音频输出设备，进而指示AudioFlinger将NOTIFICATION类型的音频数据发送手机的扬声器播放。
当音频APP输出的音频数据的类型发生变化时，音频APP可在音频播放器中修改上述mode参数。进而，当AudioFlinger读取到上述mode参数发生变化时，可根据最新的mode参数确定出当前音频数据的类型。这样，AudioFlinger可重新请求AudioPolicy查询新类型的音频数据是否允许在当前的从设备(即音箱)上播放，从而动态的将不同类型的音频数据切换至相应的音频输出设备上播放。
或者，当手机的从设备发生变化(例如从设备从音箱更新为电视)时，可触发DV APP向AudioPolicy下发与电视对应的设备选择策略。进而，AudioPolicy可根据电视的设备选择策略实时的为当前类型的音频数据选择一个合适的音频输出设备，从而动态的将不同类型的音频数据切换至相应的音频输出设备上播放。
可以看出，基于图33所示的音频架构，主设备可根据各个从设备的设备特点预先为从设备设置对应的设备选择策略。这样，在进行音频切换的过程中，主设备可根据 当前从设备的设备选择策略，将与从设备的设备特点相匹配的音频数据发送给从设备播放，从而为用户过滤掉一些不适合在从设备上播放的音频数据，使得主设备可以有选择性的将各类音频数据切换至相应的音频输出设备中播放，为用户提供较好的音频使用体验。
仍以手机为主设备举例，以下将结合附图阐述本申请实施例提供的一种音频控制方法。
如图34所示，本申请实施例提供的一种音频控制方法包括以下步骤：
S3401、手机通过运行DV APP与第一从设备建立网络连接。
示例性的，用户可以在手机中切换手机输出音频时的音频输出设备。例如，如图35中的(a)所示，手机在运行音乐APP时可显示用于音频切换的切换按钮3501。如果检测到用户点击上述切换按钮3501，则手机通过运行DV APP可搜索附近用于进行音频切换的一个或多个候选设备。如图35中的(b)所示，DV APP可将与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在菜单3502中。用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
又例如，用户还可以打开手机的控制中心，在控制中心中切换手机输出音频时的音频输出设备。响应于用户向手机输入的打开控制中心的操作，如图36中的(a)所示，手机可显示控制中心3601。控制中心3601中设置有用于音频切换的切换按钮3602。如果检测到用户点击上述切换按钮3602，手机也可通过运行DV APP搜索附近可用于进行音频切换的一个或多个候选设备。如图36中的(b)所示，DV APP可将搜索到的与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在控制中心3601中。同样，用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
以用户选中音箱为从设备举例，检测到用户在上述候选设备中选择音箱这一候选设备后，DV APP可将音箱作为手机的从设备与音箱建立网络连接。例如，该网络连接可以是基于TCP(transmission control protocol，传输控制协议)或UDP(user datagram protocol，用户数据报协议)的P2P连接，本申请实施例对此不做任何限制。
需要说明的是，在步骤S3401中手机与从设备建立的网络连接具体可以是指业务通道的网络连接(即业务连接)。例如，在用户选择音箱作为手机的从设备之前，手机可能与音箱已经通过Wi-Fi网络建立了连接，此时的连接是指数据通道的连接(即数据连接)。当用户选择音箱作为手机的从设备后，手机与音箱可在已经建立的数据连接的基础上建立业务连接。
手机与音箱建立了网络连接后，如图37所示，DV APP可基于该网络连接获取音箱的音频能力参数，该音频能力参数可反映出音箱具体支持的音频输出功能。进而，DV APP可按照音箱的音频能力参数在HAL创建与对应的DMSDP Audio HAL 3701。后续，手机可通过DMSDP Audio HAL 3701向音箱传输音频数据。
在一些实施例中，用户还可以选择多个从设备用于输出手机的音频。例如，用户可以在在上述候选设备中选择音箱和电视同时作为手机的从设备，此时，DV APP可分别与音箱和电视箱建立网络连接并获取对应的音频能力参数。进而，DV APP可按照音箱的音频能力参数在HAL创建与音箱对应的第一DMSDP Audio HAL，并且，DV  APP可按照电视的音频能力参数在HAL创建与电视对应的第二DMSDP Audio HAL。后续，手机可通过第一DMSDP Audio HAL向音箱发送对应的第一音频数据，并通过第二DMSDP Audio HAL向电视发送对应的第二音频数据(第二音频数据与第一音频数据可以相同或不同)。
S3402、手机中的DV APP将第一从设备的设备选择策略下发给AudioPolicy。
在本申请的一些实施例中，手机中可预先存储多种音频输出设备的设备选择策略。每种音频输出设备的设备选择策略用于指示这一类设备对不同类型的音频数据的播放能力。例如，手机可预先存储音箱类设备、大屏类设备、车载类设备以及可穿戴设备这四种类型的音频输出设备的设备选择策略。
那么，当手机与第一从设备(例如音箱1)建立网络连接后，DV APP可以获取音箱1的标识。进而DV APP可根据音箱1的标识识别出音箱1为音箱类设备。进而，仍如图37所示，DV APP可将预先存储的音箱类设备的设备选择策略(即设备选择策略1)发送给AudioPolicy。AudioPolicy可将DV APP下发的设备选择策略1与音箱1关联，此时，该设备选择策略1可作为音箱1的设备选择策略与音箱1绑定。
例如，音箱1的设备选择策略1(也即音箱类设备的设备选择策略)可以如表6所示，该设备选择策略1中记录了音箱1对每一种类型的音频数据的播放能力。例如，设备选择策略1中允许在音箱1上播放MUSIC类型和RING类型的音频数据，此时，MUSIC类型和RING类型的音频数据的音频输出设备为音箱1。又例如，设备选择策略1中不允许在音箱1上播放SYSTEM类型和NOTIFICATION类型的音频数据。对于不允许播放的某一类音频数据，设备选择策略1中还可以进一步设置该类音频数据的音频输出设备，即允许播放该类音频数据的具体音频输出设备。例如，SYSTEM类型的音频数据不允许在音箱1上播放，该类音频数据的音频输出设备为手机，即允许使用手机自身的扬声器播放SYSTEM类型的音频数据。
表6
Figure PCTCN2021104105-appb-000006
另外，用户还可以通过DV APP手动修改上述音箱1的设备选择策略1。例如，如图38所示，DV APP可向用户显示音频切换功能的设置界面3801。设置界面3801中设置有音频切换功能的开关按钮3802。如果检测到用户打开开关按钮3802，则说明用户希望开启音频切换功能，手机可允许将手机中的音频切换至其他音频输出设备上播放。并且，用户可在设置界面3801中进一步设置当前音频输出设备的设备选择策略。例如，用户可以在设置界面3801中选择允许在音箱1上播放的具体类型的音频数据，以及不允许在音箱1上播放的具体类型的音频数据。对于不允许在音箱1上播放的音频数据，用户还可以点击按钮3803进一步设置该类型的音频数据的音频输出设备。
DV APP可根据用户在设置界面3801中的选择更新表6所示的音箱1的设备选择策略1，并将更新后设备选择策略1下发给AudioPolicy。由AudioPolicy按照更新后的设备选择策略1确定当前的音频数据的是否允许在音箱1上播放。
这样，用户可以按照自身的需要在设置界面3801中设置或修改在各个音频输出设备上允许播放的音频类型，即对各个音频输出设备设置对应的设备选择策略，使各种类型的音频数据能够按照用户的设置被手机分发到相应的音频输出设备上播放。
当然，手机还可以保存用户为音箱1设置的设备选择策略。后续，当手机再次与音箱1建立网络连接时，手机可以根据音箱1的标识查找到已保存的音箱1的设备选择策略，并使用该设备选择策略确定是否将当前的音频数据输出至音箱1上播放。
在一些应用场景中，手机可以同时具有多个音频输出设备，即手机当前的从设备可以有多个。例如，手机可以同时与音箱1和音箱2建立网络连接。此时，手机中的DV APP可按照上述方法将音箱1的设备选择策略以及音箱2的设备选择策略均下发给AudioPolicy。示例性的，由于音箱1和音箱2均为音箱类设备，那么，音箱1的设备选择策略与音箱2的设备选择策略可以相同。后续，用户可以在图38所示的设置界面3801中进一步设置音箱1和/或音箱2的设备选择策略。在一些实施例中，当音箱1和音箱2同时支持播放某一类型的音频数据时，AudioPolicy可以将当前的音频数据既发送给音箱1也发送给音箱2，或者，AudioPolicy也可以将当前的音频数据发送给音箱1和音箱2中的一个。例如，AudioPolicy可以将当前的音频数据发送给音箱1和音箱2中距离用户较近的一个音箱播放，本申请实施例对此不做任何限制。
在本申请的另一些实施例中，手机可默认设置每个音频输出设备允许播放任意类型的音频数据。那么，当手机与第一从设备(例如音箱1)建立网络连接后，DV APP可将表7所示的设备选择策略发送给AudioPolicy。在表7所示的设备选择策略中，音箱1允许播放任意类型的音频数据。后续，手机可根据用户在上述设置界面1201中的选择更新表7所示的音箱1的设备选择策略，并将更新后的音箱1的设备选择策略下发给AudioPolicy。由AudioPolicy按照更新后的音箱1的设备选择策略确定当前音频数据的具体音频输出设备。
表7
Figure PCTCN2021104105-appb-000007
当然，上述音频输出设备的设备选择策略也可以是手机从服务器获取的，又或者，上述音频输出设备的设备选择策略也可以是开发人员预先在手机中设置的，本申请实施例对此不做任何限制。
S3403、手机在运行音频APP时，AudioPolicy根据第一从设备的设备选择策略确定第一从设备是否允许播放来自音频APP的第一音频数据。
需要说明的是，手机可以在与第一从设备建立网络连接之前开始运行音频APP，也可以在与第一从设备建立网络连接之后开始运行音频APP，即手机运行音频APP的过程与步骤S3401-S3402之间没有先后顺序关系。如果在与第一从设备建立网络连接之前手机已经运行音频APP产生了音频数据，由于手机没有与其他音频输出设备相连，则手机可使用自身的扬声器播放该音频数据。
在步骤S3403中，仍如图37所示，手机运行音频APP时可调用音频播放器(例如AudioTrack)，向音频处理器(例如AudioFlinger)中输入当前产生的音频数据(例如音频数据1)。并且，音频APP可在AudioTrack中设置音频数据1的类型。例如，音频APP可在AudioTrack中将mode参数设置为01，以指示当前输入至AudioTrack的音频数据1的类型为MUSIC类型的音频数据。
AudioFlinger接收到来自音频APP的音频数据后，通过在AudioTrack中读取上述mode参数可识别出音频数据1的具体类型。进而，AudioFlinger可向AudioPolicy发送查询请求，该查询请求中可以包括音频数据1的类型标识(例如01)，以请求AudioPolicy查询当前与手机相连的从设备(即第一从设备)是否允许播放标识为01类型的音频数据1。
AudioPolicy接收到AudioFlinger发送的查询请求后，可根据查询请求中音频数据的类型标识，在DV APP下发的第一从设备的设备选择策略中查询第一从设备是否允许播放音频数据1。如果第一从设备允许播放音频数据1，则手机可继续执行下述步骤S3404，如果第一从设备不允许播放音频数据1，则手机可继续执行下述步骤S3405-S3406。
在另一些实施例中，手机的DV APP也可以预先将各类音频输出设备的设备选择策略均下发给AudioPolicy。当DV APP与第一从设备建立网络连接后，DV APP可向AudioPolicy指示第一从设备的标识。这样，AudioPolicy可根据第一从设备的标识确定第一从设备的设备类型。进而，AudioPolicy可在各类音频输出设备的设备选择策略中查找到与第一从设备的设备类型对应的设备选择策略，并将查找到的设备选择策略确定为第一从设备的设备选择策略。或者，也可以预先在AudioPolicy中存储各个音频输出设备的设备选择策略，无需DV APP向AudioPolicy下发音频输出设备的设备选择策略，本申请实施例对此不做任何限制。
S3404、若第一从设备允许播放第一音频数据，则AudioPolicy指示AudioFlinger将第一音频数据发送至第一从设备。
仍以第一从设备为音箱1举例，参见表6所示的设备选择策略1，如果当前音频APP产生的音频数据1的类型为MUSIC或RING，则AudioPolicy可确定音箱1允许播放音频数据1。例如，当音频APP为音乐APP时，手机运行音乐APP播放歌曲时产生的音频数据1的类型为MUSIC。AudioFlinger接收到音频数据1后可请求AudioPolicy查询是否在音箱1上播放MUSIC类型的音频数据1。此时，AudioPolicy根据表6所示的设备选择策略可确定音频数据1可由手机的从设备(即音箱1)播放。进而，AudioPolicy可向AudioFlinger发送第一指示消息，指示AudioFlinger将当前产生的音频数据1发送至音箱。
那么，仍如图37所示，AudioFlinger接收到AudioPolicy发送的第一指示消息后， 可调用HAL中与音箱1对应的DMSDP Audio HAL 3701，通过DMSDP Audio HAL3701将音频数据1发送给音箱1，由音箱1播放MUSIC类型的音频数据1。
当然，AudioFlinger在通过DMSDP Audio HAL 3701向音箱1发送音频数据1之前，还可以对音频数据1进行解析、采样、编码、解码、封装或解封装等处理操作，并将处理后的音频数据1发送至音箱1。类似的，音箱1接收到手机发送的音频数据1后，也可以对音频数据1进行解析、采样、编码、解码、封装或解封装等处理操作后再播放，本申请实施例对此不做任何限制。
S3405、若第一从设备不允许播放第一音频数据，则AudioPolicy按照第一从设备的设备选择策略确定由第一设备播放第一音频数据。
S3406、AudioPolicy指示AudioFlinger将第一音频数据发送至上述第一设备。
与步骤S3404对应的，在步骤S3405-S3406中，仍以第一从设备为音箱1举例，参见表6所示的音箱1的设备选择策略1，如果当前音频APP产生的音频数据1的类型为SYSTEM或NOTIFICATION，则AudioPolicy可确定音箱1不允许播放该音频数据1。
例如，如图39所示，手机在运行短信APP时，如果短信APP接收到新的短信，则短信APP可作为音频APP将产生的短信提示音(即音频数据2)通过AudioTrack输入至AudioFlinger，并且，短信APP可在AudioTrack中设置音频数据2的类型为NOTIFICATION。AudioFlinger接收到音频数据2后，可向AudioPolicy请求查询音箱1是否允许播放NOTIFICATION类型的音频数据2。进而，AudioPolicy可根据表6所示的设备选择策略1确定音箱1不允许播放NOTIFICATION类型的音频数据2。并且，AudioPolicy可在表6所示的设备选择策略1中进一步确定音频数据2的音频输出设备，即允许播放NOTIFICATION类型的第一设备。
例如，表6所示的设备选择策略1中设置了NOTIFICATION类型的音频数据的音频输出设备为手机。那么，AudioPolicy可向AudioFlinger发送第二指示消息，指示AudioFlinger将来自短信APP的音频数据2发送至手机，即播放音频数据2的第一设备为手机。仍如图39所示，AudioFlinger接收到AudioPolicy发送的第二指示消息后，可调用HAL中与手机的扬声器对应的Primary HAL，通过Primary HAL将音频数据2发送给手机的扬声器播放。
可以看出，当手机将音频功能切换至音箱后，手机并不是将自身产生或者接收到的所有音频数据毫无区分的发送给音箱1(即从设备)播放，手机可以根据音箱1的设备选择策略将适合在音箱1上播放的一种或多种类型的音频数据发送至音箱1播放，并将其他音频数据发送至其他音频输出设备上播放。这样，手机在进行音频切换时可以结合从设备的设备特点精确控制每种音频数据的输出流向，有选择性的将音频数据切换至对应的音频输出设备中播放，从而为用户过滤掉一些不适合在当前手机的从设备上播放的音频数据。
在一些实施例中，如果音箱1(即从设备)的设备选择策略1中设置了不允许播放NOTIFICATION类型的音频数据2，则AudioPolicy在确定播放音频数据2的第一设备时，还可以按照一定的选择策略动态的确定此时音频数据2的音频输出设备。例如，AudioPolicy可按照后接入后优先的原则，将除音箱之外最近与手机接入的音频输 出设备确定为音频数据2的音频输出设备，即播放音频数据2的第一设备。
例如，如图40所示，手机的音频输出设备从T0时刻开始是手机本机，即使用手机自身的扬声器播放音频。在T1(T1＞T0)时刻，如果手机与蓝牙耳机连接，则手机此时的音频输出设备更新为蓝牙耳机。在T2(T2＞T1)时刻，如果用户又将有线耳机插入手机的耳机接口，则手机此时的音频输出设备更新为有线耳机。在T3(T3＞T2)时刻，如果用户选择音箱1为手机进行音频切换的从设备，触发手机与音箱1建立网络连接，则手机此时的音频输出设备更新为音箱1。
可以看出，时间上越晚接入手机的音频输出设备(即最近接入手机的音频输出设备)的优先级越高。那么，当上述音频数据2不允许在音箱1上播放时，AudioPolicy可选择此时除音箱1外优先级最高的音频输出设备为播放音频数据2的音频输出设备，即选择有线耳机播放音频数据2。进而，AudioPolicy可指示AudioFlinger将音频数据2发送至有线耳机播放。当然，本领域技术人员也可以根据实际经验或实际应用场景设置音频输出设备的设备选择策略，本申请实施例对此不做任何限制。
通过执行步骤S3401-S3406，手机作为主设备与第一从设备建立网络连接后，可以按照第一从设备的设备选择策略，动态的将手机中音频APP产生的不同类型的音频数据有选择性的切换至第一从设备中播放，从而为用户过滤掉一些不适合在第一从设备上播放的音频数据，为用户提供较好的音频使用体验。
后续，如果用户将手机连接的第一从设备修改为第二从设备，则与手机将音频数据切换至第一从设备播放类似的，手机还可以按照第二从设备的设备选择策略将此时音频APP产生的音频数据切换至第二从设备播放。
示例性的，如图41所示，手机可通过执行下述步骤S4101-S4106将音频数据切换至第二从设备播放。
S4101、手机断开与第一从设备之间的网络连接，并通过运行DV APP与第二从设备建立网络连接。
仍以第一从设备为音箱1举例，手机将音频功能切换至音箱1后，用户还可以在手机上手动修改当前与手机进行音频切换的从设备。例如，如图42中的(a)所示，手机可响应用户打开控制中心的操作显示控制中心4201。控制中心4201中包括音频切换功能的切换按钮4202。当用户希望修改当前手机的从设备时，可点击切换按钮4202查询当前可以作为手机的从设备的一个或多个候选设备。如图42中的(b)所示，手机检测到用户点击切换按钮4202后，手机可将检测到的一个或多个候选设备显示在控制中心4201中。此时，用户可在控制中心4201中选择与手机进行音频切换的从设备(即第二从设备)。
或者，如果手机检测到用户开启了手机的投屏功能，由于投屏场景下需要手机将音频和图像同时切换至其他设备上播放，即投屏场景下也需要进行音频切换，因此，手机也可响应用户开启投屏功能的操作修改与手机进行音频切换的从设备。
例如，如图43所示，手机在运行微信APP时可显示微信APP的应用界面4300。在应用界面4300中用户可以打开与某一联系人(例如Sara或Mike)的对话界面，收听用户或联系人发送的语音。如果用户需要使用投屏功能，仍如图43所示，用户可在应用界面4300中打开手机的控制中心4301。控制中心4301中可设置卡片4302，卡片 4302用于展示手机检测到的附近的一个或多个可进行投屏的候选设备。如果手机已经开启了投屏功能，则手机还可以在卡片4302中通过高亮等方式标识当前正在与手机进行投屏的设备。如果检测到用户在卡片4302中选中某一电子设备(例如电视)，说明用户希望开启投屏功能，将手机此时产生的图像和音频投射至电视。此时，手机可断开已经与音箱1(即第一从设备)建立的网络连接，并将电视作为第二从设备与电视建立网络连接。
并且，与步骤S3401类似的，如图44所示，手机中的DV APP可获取电视的音频能力参数，并按照电视的音频能力参数在HAL创建与对应的DMSDP Audio HAL。或者，手机可按照电视的音频能力参数更新步骤S3401中为音箱创建的DMSDP Audio HAL，使得更新后的DMSDP Audio HAL与电视的音频能力匹配。后续，在投屏场景下，手机可通过更新后的DMSDP Audio HAL向电视传输音频数据。并且，在投屏场景下，手机可按照现有的投屏方式将手机中的显示数据(例如微信APP的应用界面4300)发送给电视进行显示，本申请实施例对此不做任何限制。
S4102、手机中的DV APP将第二从设备的设备选择策略下发给AudioPolicy。
与步骤S3402类似的，手机将电视确定为当前的从设备(即第二从设备)并建立网络连接后，仍如图44所示，DV APP可向AudioPolicy下发电视的设备选择策略(即设备选择策略2)。例如，DV APP可获取电视的标识，从而确定当前连接的第二从设备为大屏类设备。进而，DV APP可将预先为大屏类设备存储的设备选择策略作为电视的设备选择策略2下发给AudioPolicy。后续，AudioPolicy可按照电视的设备选择策略2确定当前手机中音频数据的具体音频输出设备。
示例性的，电视的设备选择策略2可以如表8所示，与表6所示的设备选择策略1不同的是，电视的设备选择策略2中还可以设置一个或多个应用的标识，例如应用的包名(Package Name)。也就是说，手机在设备选择策略2中还可以设置不同应用分别对不同类型的音频数据的播放能力。例如，对于微信APP，电视允许微信APP播放MUSIC类型和COMMUNICATION类型的音频数据，不允许微信APP播放NOTIFICATION类型和DTMF类型的音频数据。对于视频APP，电视允许微信APP播放MUSIC类型的音频数据等。其中，设备选择策略2中包含的具体应用可以是开发人员预先设置的。或者，每当用户在手机中安装新的应用时，手机可从服务器获取该应用在不同音频输出设备中的设备选择策略，这样，手机可以根据手机中安装的应用动态更新每个音频输出设备的设备选择策略，本申请实施例对此不做任何限制。
表8
Figure PCTCN2021104105-appb-000008
这样一来，手机在运行微信APP时，微信APP产生的语音或者媒体音可切换至电视中播放，而微信APP产生的消息提示音和按键音可被分流至手机中播放，避免微信APP产生的消息提示音和按键音打扰手机在电视中的投屏过程。可以看出，手机可以以应用为粒度，将一个应用产生的不同类型的音频数据按照设备选择策略输出至相应的音频输出设备中播放，使得不同的音频输出设备可有针对性的播放特定应用中特定类型的音频数据，提高用户的音频使用体验。
在另一些实施例中，还可以在AudioPolicy中设置如表9所示的设备选择策略。该设备选择策略中针对不同的应用，为每个应用设置了不同类型的音频数据的音频输出设备。例如，当微信APP产生MUSIC类型的音频数据时，该音频数据的音频输出设备可以为手机、音箱、电视或耳机。又例如，当音乐APP产生COMMUNICATION类型的音频数据时，该音频数据的音频输出设备可以为手机、音箱或电视。后续，AudioPolicy可按照表9所示的设备选择策略，确定正在运行的音频APP产生的各类音频数据的音频输出设备。
表9
Figure PCTCN2021104105-appb-000009
在另一些实施例中，用户还可以在手机中手动修改当前从设备的设备选择策略。如图45中的(a)所示，手机将电视作为从设备切换音频数据时，可在控制中心4501中显示音频切换的卡片4502，并在卡片4502中设置音频切换的设置按钮4503。如果检测到用户点击设置按钮4503，则如图45中的(b)所示，DV APP可显示电视作为从设备时的设置界面4504。与图38类似的，设置界面4504中可以设置音频切换功能的开关按钮4505。当用户打开开关按钮4505后，用户可在设置界面4504中设置电视可接收哪些类型的音频数据，或者设置手机在运行不同应用时电视可接收哪些类型的音频数据。进而，DV APP可根据用户在设置界面4504中的选择更新表8所示的电视的设备选择策略2，使得用户可以动态的指定在各个音频输出设备中输出的音频数据的类型。
S4103、手机在运行音频APP时，AudioPolicy根据第二从设备的设备选择策略确定第二从设备是否允许播放来自音频APP的第二音频数据。
与步骤S3403类似的，仍如图44所示，AudioFlinger可接收来自不同音频APP产生的音频数据。当手机的从设备从音箱1切换为电视后，AudioFlinger可以向AudioPolicy请求查询当前接收到的音频数据是否允许在电视中播放。进而，AudioPolicy可根据电视的设备选择策略2确定当前的音频数据是否允许在电视中播放。
在一些场景下，AudioFlinger可能会同时接收到同一或不同音频APP产生的多路音频数据。例如，如图46所示，在T1时刻用户在手机中打开了音乐APP开始播放歌曲，在T2(T2＞T1)时刻用户在手机的微信APP中打开联系人发送的语音消息开始播放语音，在T3-T4(T4＞T3＞T2)这一时间段内用户在微信APP中使用键盘点击按键时开始播放按键音。那么，在T3-T4这一时间段内手机的AudioFlinger可同时接收到来自微信APP的COMMUNICATION类型的音频数据A和DTMF类型的音频数据B，以及来自音乐APP的MUSIC类型的音频数据C。仍如图44所示，AudioFlinger可向AudioPolicy请求查询音频数据A、音频数据B以及音频数据C是否允许在电视中播放。进而，AudioPolicy可根据表8所示的设备选择策略2确定当前的音频数据A、音频数据B以及音频数据C是否允许在电视中播放。
S4104、若第二从设备允许播放第二音频数据，则AudioPolicy指示AudioFlinger将第二音频数据发送至第二从设备。
与步骤S3404类似的，仍如图44所示，AudioPolicy根据表8所示的设备选择策略2可确定电视允许播放COMMUNICATION类型的音频数据A和MUSIC类型的音频数据C，但不允许播放DTMF类型的音频数据B。那么，AudioPolicy可向AudioFlinger发送第一指示消息，指示AudioFlinger将音频数据A和音频数据C发送至音箱。进而，AudioFlinger可响应该第一指示消息，将音频数据A和音频数据C这两路音频数据混音为音频数据A+C，并通过DMSDP Audio HAL将混音后的音频数据A+C发送给电视。或者，AudioFlinger也可以不对音频数据A和音频数据C进行混音处理，将未混音的音频数据A和音频数据C通过DMSDP Audio HAL发送给电视，由电视在投屏场景下播放来自微信APP的音频数据A和来自音乐APP的音频数据C。
S4105、若第二从设备不允许播放第二音频数据，则AudioPolicy按照第二从设备的设备选择策略确定由第二设备播放第二音频数据。
S4106、AudioPolicy指示AudioFlinger将第二音频数据发送至上述第二设备。
在步骤S4105-S4106中，仍如图44所示，AudioPolicy根据表8所示的设备选择策略2可确定电视不允许播放DTMF类型的音频数据B。那么，AudioPolicy可在表8所示的设备选择策略中进一步确定允许播放DTMF类型的具体音频输出设备，即播放音频数据B的第二设备。
例如，表8所示的设备选择策略中设置了微信APP中DTMF类型的音频数据的音频输出设备为手机。那么，AudioPolicy可向AudioFlinger发送第二指示消息，指示AudioFlinger将当前产生的音频数据B发送至手机。那么，仍如图44所示，AudioFlinger响应于第二指示消息后，可调用HAL中与手机的扬声器对应的Primary HAL，通过Primary HAL将音频数据B发送给手机的扬声器播放。
通过执行步骤S4101-S4106，手机作为主设备与第二从设备建立网络连接后，可以按照第二从设备的设备选择策略，动态的将手机中音频APP产生的不同类型的音频数据有选择性的切换至第二从设备中播放，从而为用户过滤掉一些不适合在第二从设备上播放的音频数据，为用户提供较好的音频使用体验。
在分布式音频场景中，主设备(例如上述手机)中可能会同时产生多路音频数据。例如，手机在运行地图APP时，地图APP在导航模式下可以产生导航语音；同时， 手机还可以运行音乐APP播放歌曲。此时，手机可以同时播放来自地图APP的导航语音(即音频数据1)以及来自音乐APP播放歌曲(即音频数据2)。后续，如果手机的短信APP接收到新的短消息，则手机还需要播放短消息的提示音(即音频数据3)。此时，手机除了播放音频数据1和音频数据2之外，还可以同时播放音频数据3。
在本申请实施例中，手机作为主设备可以将产生的音频数据发送至一个或多个从设备上播放，实现多设备之间的音频切换功能。那么，当手机需要输出多路音频数据时，手机可将这多路音频数据进行混音后输出至从设备播放，但经过混音后的多路音频数据会出现失真的现象，导致在从设备上播放该混音后的音频数据时也出现失真现象。
示例性的，手机的音频输出设备(即从设备)可以为音箱。手机在运行时可以同时产生音频数据1和音频数据2。在现有技术中，如图47所示，手机在向音箱投射音频数据1和音频数据2时，需要先对音频数据1和音频数据2进行混音，使得音频数据1和音频数据2中的音频信号被叠加，得到混音后的音频数据3。后续，手机可将音频数据3打包为一个个的数据包发送给音箱，音箱解析出每个数据包中的音频数据3后可以播放对应的音频。
经过混音，可以将多路音频数据转换为一路音频数据。但是，在混音过程中由于采样等处理会使得混音后的音频数据3中不能完整保留混音前音频数据1和音频数据2的音频特征，例如，音频数据1或音频数据2的响度、频率等音频特征在混音后的音频数据3中出现了变化，使音频数据3出现失真现象。也就是说，音频数据3中音频数据1的分量与混音前的音频数据1可能会出现偏差，导致混音前音频数据1的音频特征与混音后音频数据3中包含的音频数据1的音频特征不同；类似的，音频数据3中音频数据2的分量与混音前的音频数据2可能会出现偏差，导致混音前音频数据2的音频特征与混音后音频数据2中包含的音频数据2的音频特征不同，使得音箱在播放音频数据3时出现失真现象，影响用户的音频使用感受。
对此，在本申请实施例中，可以在主设备(例如手机)中预先设置混音策略，该混音策略可用于指示不同类型的音频数据是否允许混音。示例性的，如表1所示的混音策略，用户对音乐类型的音频质量一般要求较高，因此可预先在混音策略中设置对于MUSIC类型的音乐不允许与其他音频数据混音，而对于NOTIFICATION类型的通知音以及DTMF类型的按键音允许与其他音频数据混音。后续，当手机产生了多路音频数据，且这多路音频数据需要在同一音频输出设备上播放时，手机可根据每一路音频数据的类型，按照表1所示的混音策略确定哪些音频数据不需要混音，哪些音频数据需要混音。
表10
类型 是否允许混音
NOTIFICATION(通知) 允许
DTMF(双音多频) 允许
MUSIC(音乐) 不允许
…… ……
可以理解的是，可以在上述混音策略(例如表10所示的混音策略)中仅设置允许 混音的音频数据的类型。此时，其他类型的音频数据可默认为不允许混音的音频数据。或者，可以在上述混音策略中仅设置不允许混音的音频数据的类型。此时，其他类型的音频数据可默认为允许混音的音频数据，本申请实施例对此不做任何限制。
仍以手机为主设备举例，手机与音箱建立网络连接后，可将音箱作为从设备进行音频切换。例如，手机在运行音乐APP时产生了MUSIC类型的音频数据1，如果此时只有音频数据1这一路音频数据，则手机可将音频数据1发送给音箱播放。当然，在发送音频数据1之前手机还可以对音频数据1进行解析、采样、编码、解码、封装或解封装等处理，本申请实施例对此不做任何限制。后续，在音箱播放音频数据1的过程中，如果手机的微信APP接收到新的短消息，则微信APP可产生NOTIFICATION类型的音频数据2。此时，手机需要向音箱发送来自微信APP和来自音乐APP的两路音频数据。
那么，手机通过查询表10所示的混音策略，可以确定MUSIC类型的音频数据1不允许与其他音频数据进行混音，因此不需要对音频数据1和音频数据2进行混音，即这两路音频数据需要独立传输至音箱。进而，如图48所示，手机可对来自音乐APP的音频数据1进行打包(也可称为封包)，得到与音频数据1对应的第一数据包4801(第一数据包4801可以有多个)，同时，手机可对来自微信APP的音频数据2进行打包，得到与音频数据2对应的第二数据包4802(第二数据包4802可以有多个)。后续，手机可将第一数据包4801和第二数据包4802发送给音箱，音箱通过解析接收到的第一数据包4801和第二数据包4802可以获得未经过混音的音频数据1和音频数据2。也就是说，手机可将音频数据1以及音频数据2相对独立的发送至音箱，无需对这两路音频数据进行混音。
这样一来，音箱从手机获取到的音频数据1和音频数据2是没有经过混音处理的，因此音频数据1可以较为真实的反映出音乐APP中歌曲的音频特征，音频数据2也可以较为真实的反映出短信APP的通知音的音频特征。也就是说，音箱获取到的音频数据1和音频数据2中不存在由于手机的混音处理而带来的失真现象。这样，音箱在播放上述音频数据1和音频数据2时产生的失真现象也相应减少，从而降低多路音频数据在跨设备播放时的失真情况，提高音频切换场景的音频输出质量。
在一些实施例中，手机在打包上述音频数据1的过程中，还可以在第一数据包4801中添加音频数据1的特征信息，例如，音频数据1的标识为01，音频数据1的类型为MUSIC类型，音频数据1的音量等级为5及等。上述特征信息能够反映出音频数据1实际的音频特征。这样一来，音箱解析出第一数据包4801后，不仅可以获得未经混音的音频数据1，还可以根据第一数据包4801中的特征信息获得音频数据1的音频特征。后续，音箱在播放音频数据1时可按照音频数据1的特征信息更加真实的还原音频数据1的音频特征，减少音频切换过程中的失真现象。
类似的，手机在打包上述音频数据1的过程中，也可以在第二数据包4802中添加音频数据2的特征信息，使得音箱不仅可以获得未经混音的音频数据2，还可以根据第二数据包4802中的特征信息获得音频数据2的音频特征，以减少音频切换过程中的失真现象。其中，手机对多路音频数据进行打包的具体过程将在后续实施例中详细阐述，故此处不与赘述。
当然，音箱在播放上述音频数据1和音频数据2时，也可以对音频数据1和音频数据2进行解析、采样、编码、解码、封装或解封装等处理操作，本申请实施例对此不做任何限制。
在本申请实施例中，如图49所示，手机的DV APP为手机的从设备创建了DMSDP Audio HAL之后，DV APP还可以向AudioPolicy下发不同类型的音频数据的混音策略。例如，DV APP可以向AudioPolicy下发上述表10所示的混音策略，该混音策略中记录了每一种类型的音频数据的是否允许进行混音。
那么，当AudioFlinger接收到至少两路不同类型的音频数据时，如图49所示，AudioFlinger请求AudioPolicy查询当前的多路音频数据中哪些音频数据需要独立传输，哪些音频数据需要混音后再传输。响应于AudioFlinger的请求，AudioPolicy根据表10所示的混音策略可查询当前的哪些音频数据需要独立传输，哪些音频数据需要混音后再传输。
例如，如果AudioFlinger同时接收到NOTIFICATION类型的音频数据A、DTMF类型的音频数据B以及MUSIC类型的音频数据C，则AudioFlinger可向AudioPolicy发送第一请求，请求AudioPolicy确定这三路音频数据是否需要混音。进而，AudioPolicy可响应第一请求查询表10所示的混音策略，从而确定MUSIC类型的音频数据C不需要混音，而NOTIFICATION类型的音频数据A和DTMF类型的音频数据B需要混音。那么，AudioPolicy可向AudioFlinger输出混音指示，该混音指示中指示了将音频数据A和音频数据B混音为一路音频数据，而音频数据C不与音频数据A和音频数据B混音。AudioFlinger可响应上述混音指示，对音频数据A和音频数据B进行混音处理，对音频数据C不进行混音，这样，AudioFlinger最终可输出两路音频数据，一路是混音后的音频数据A+B，另一路是未经过混音的音频数据C。
后续，AudioFlinger可调用DMSDP Audio HAL分别将音频数据A+B以及音频数据C输出至从设备进行播放。这样，对于音频要求较高的MUSIC类型的音乐(即音频数据C)，主设备可以将音频数据C独立传输至从设备，不与其他音频数据进行混音，使得从设备接收到的音频数据C不会因为混音丢失掉音频数据C中的一些音频特征，避免因混音处理而带来的音频失真现象，从而降低多路音频数据在跨设备播放时的失真情况，提高音频切换场景的音频输出质量。
可以看出，基于图49所示的音频架构，主设备可预先设置各种类型的音频数据对应的混音策略。这样，当需要向从设备输出多路音频数据时，主设备可根据混音策略选择对多路音频数据中的某些音频数据不做混音处理，独立传输给从设备进行播放，从而避免因混音处理对某一类型的音频数据造成的失真现象，提高音频切换场景的音频输出质量。
仍以手机为主设备举例，以下将结合附图阐述本申请实施例提供的一种音频控制方法。
如图50所示，本申请实施例提供的一种音频控制方法包括以下步骤：
S5001、手机通过运行DV APP与第一从设备建立网络连接。
示例性的，用户可以在手机中切换手机输出音频时的音频输出设备。例如，如图51中的(a)所示，手机在运行音乐APP时可显示用于音频切换的切换按钮5101。如 果检测到用户点击上述切换按钮5101，则手机通过运行DV APP可搜索附近可用于进行音频切换的一个或多个候选设备。如图51中的(b)所示，DV APP可将与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在菜单5102中。用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
又例如，用户还可以打开手机的控制中心，在控制中心中切换手机输出音频时的音频输出设备。响应于用户打开控制中心的操作，如图52中的(a)所示，手机可显示控制中心5201。控制中心5201中设置有用于音频切换的切换按钮5202。如果检测到用户点击上述切换按钮5202，手机也可通过运行DV APP搜索附近可用于进行音频切换的一个或多个候选设备。如图52中的(b)所示，DV APP可将搜索到的与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在控制中心5201中。同样，用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
以用户选中音箱为手机的从设备(即步骤S5001中的第一从设备)举例，检测到用户在上述候选设备中选择音箱这一候选设备后，DV APP可将音箱作为手机的从设备与音箱建立网络连接。例如，该网络连接可以是基于TCP(transmission control protocol，传输控制协议)或UDP(user datagram protocol，用户数据报协议)的P2P连接，本申请实施例对此不做任何限制。
需要说明的是，在步骤S5001中手机与从设备建立的网络连接具体可以是指业务通道的网络连接(即业务连接)。例如，在用户选择音箱作为手机的从设备之前，手机可能与音箱已经通过Wi-Fi网络建立了连接，此时的连接是指数据通道的连接(即数据连接)。当用户选择音箱作为手机的从设备后，手机与音箱可在已经建立的数据连接的基础上建立业务连接。
手机与音箱建立了网络连接后，如图53所示，DV APP可基于该网络连接获取音箱的音频能力参数，该音频能力参数可反映出音箱具体支持的音频输出功能。例如，该音频能力参数可以包括音箱支持的采样率、声道数目、音效模式、播放时延等。进而，DV APP可按照音箱的音频能力参数在HAL创建对应的DMSDP Audio HAL。后续，手机可通过DMSDP Audio HAL向音箱传输音频数据，从而将手机中的音频功能切换至音箱中实现。
在一些实施例中，用户还可以选择多个从设备用于输出手机的音频。例如，用户可以在在上述候选设备中选择音箱和电视同时作为手机的从设备，此时，DV APP可分别与音箱和电视建立网络连接并获取对应的音频能力参数。进而，DV APP可按照音箱的音频能力参数在HAL创建与音箱对应的第一DMSDP Audio HAL，并且，DV APP可按照电视的音频能力参数在HAL创建与电视对应的第二DMSDP Audio HAL。后续，手机可通过第一DMSDP Audio HAL向音箱发送对应的第一音频数据，并通过第二DMSDP Audio HAL向电视发送对应的第二音频数据(第二音频数据与第一音频数据可以相同或不同)。
S5002、手机中的DV APP将第一从设备的混音策略下发给AudioPolicy。
在本申请的一些实施例中，手机中可预先存储多种音频输出设备的混音策略。每种音频输出设备的混音策略用于指示这一类设备对不同类型的音频数据的混音需求。 例如，手机可预先存储音箱类设备、大屏类设备、车载类设备以及可穿戴设备这四种类型的音频输出设备的混音策略。
示例性的，如表11所示，手机中预先存储有音箱类设备以及大屏类设备的混音策略。在混音策略中，设置了向不同类型的音频输出设备输出每一种音频数据时是否允许混音的混音策略。可以看出，与表10所示的混音策略不同的是，手机可针对不同类型的音频输出设备设置对应的混音策略。
例如，在音箱类设备的混音策略中，不允许对MUSIC类型的音频数据混音。也就是说，MUSIC类型的音频数据需要单独传输给音箱，不与其他音频数据进行混音。并且，在音箱类设备的混音策略中，允许将NOTIFICATION类型和DTMF类型的音频数据与其他音频数据进行混音。又例如，在大屏类设备的混音策略中，不允许对MUSIC类型和NOTIFICATION类型的音频数据混音。也就是说，MUSIC类型的音频数据和NOTIFICATION类型的音频数据需要单独传输给电视，不与其他音频数据进行混音。
表11
Figure PCTCN2021104105-appb-000010
那么，当手机与第一从设备(例如音箱1)建立网络连接后，DV APP可以获取音箱1的标识。进而DV APP可根据音箱1的标识识别出音箱1为音箱类设备。进而，仍如图53所示，DV APP可将预先存储的音箱类设备的混音策略(即混音策略1)发送给AudioPolicy。AudioPolicy可将DV APP下发的混音策略1与音箱1关联，此时，该混音策略1可作为音箱1的混音策略与音箱1绑定。
另外，用户还可以通过DV APP手动修改上述音箱1的混音策略1。例如，如图54所示，DV APP可向用户显示音频切换功能的设置界面5401。设置界面5401中设置有音频切换功能的开关按钮5402。如果检测到用户打开开关按钮5402，则说明用户希望开启音频切换功能，手机可允许将手机中的音频切换至其他音频输出设备上播放。并且，用户可在设置界面5401中进一步设置当前音频输出设备的混音策略。例如，用户可以在设置界面5401中选择不需要混音的具体类型的音频数据，以及需要混音的具体类型的音频数据。又例如，如果用户需要对更多类型的音频数据设置混音策略，用户可点击设置界面5401中“添加其他”的选项5403。手机可响应用户点击选项5403的操作显示出更多类型的音频数据，用户可设置对这些音频数据是否进行混音。
DV APP可根据用户在设置界面5401中的选择更新音箱1的混音策略1，并将更新后混音策略1下发给AudioPolicy。由AudioPolicy按照更新后的混音策略1确定是否对音频APP产生的不同音频数据进行混音。
这样，用户可以按照自身的需要在设置界面5401中设置或修改向各个音频输出设备需要独立传输的音频数据音频类型，即对各个音频输出设备设置对应的混音策略，使各种类型的音频数据能够按照用户的设置独立传输或经过混音后传输至相应的音频输出设备上播放。
当然，手机还可以保存用户为音箱1设置的混音策略。后续，当手机再次与音箱1建立网络连接时，手机可以根据音箱1的标识查找到已保存的音箱1的混音策略，并使用该混音策略确定是否对音频APP产生的不同音频数据进行混音。
在本申请的另一些实施例中，手机可默认设置除手机自身外的每一类音频输出设备允许对任意类型的音频数据进行混音。那么，当手机与第一从设备(例如音箱1)建立网络连接后，DV APP可将表12所示的混音策略发送给AudioPolicy。在表13所示的混音策略中，手机向音箱1发送的任意类型的音频数据均允许进行混音。后续，手机可根据用户在上述设置界面1101中的选择更新表12所示的音箱1的混音策略，并将更新后的音箱1的混音策略下发给AudioPolicy。由AudioPolicy按照更新后的音箱1的混音策略确定是否对音频APP产生的不同音频数据进行混音。或者，手机也可以默认设置除手机自身外的每一类音频输出设备均不允许对任意类型的音频数据进行混音，后续用户也可按照自身的需要在手机中设置当前从设备的混音策略。
表12
Figure PCTCN2021104105-appb-000011
当然，上述混音策略也可以是手机从服务器获取的，又或者，上述混音策略也可以是开发人员预先在手机中设置的，本申请实施例对此不做任何限制。
在另一些实施例中，手机的DV APP也可以预先将各类音频输出设备的混音策略下发给AudioPolicy。当DV APP与第一从设备(例如音箱1)建立网络连接后，DV APP可向AudioPolicy指示音箱1的标识。这样，AudioPolicy可根据音箱1的标识，在各类音频输出设备的混音策略中查找到与音箱1的设备类型对应的混音策略，并将查找到的混音策略确定为音箱1的混音策略。或者，也可以预先在AudioPolicy中存储各个音频输出设备的混音策略，无需DV APP向AudioPolicy下发音频输出设备的混音策略，本申请实施例对此不做任何限制。
S5003、手机中的第一音频应用产生第一音频数据后，AudioFlinger将第一音频数据发送至第一从设备进行播放。
在步骤S5003中，仍如图53所示，手机在运行第一音频APP(例如音乐APP)时如果产生了音频数据(可称为第一音频数据)，则第一音频APP可调用音频播放器(例如AudioTrack)，向音频处理器(例如AudioFlinger)中输入当前产生的第一音频数据。并且，音乐APP可在AudioTrack中设置音频数据1的类型。例如，音频APP可在AudioTrack中将与音频数据1对应的mode参数设置为01，以指示当前输入至AudioTrack的音频数据1的类型为MUSIC类型的音频数据。
AudioFlinger接收到来自第一音频APP的音频数据(例如音频数据1)后，通过在AudioTrack中读取上述mode参数可识别出音频数据1的具体类型。并且，AudioFlinger接收到音频数据1后，可确定此时接收到了几路音频数据，即同一时刻需要在从设备上播放的音频数据的数目。如果此时AudioFlinger只接收到这一路音频数据，则无论音频数据1是什么类型的音频数据，均不需要进行混音处理。因此，仍如图53所示，AudioFlinger可调用HAL中与音箱对应的DMSDP Audio HAL，通过DMSDP Audio HAL将音频数据1发送给音箱，由音箱播放音频数据1。
需要说明的是，在向音箱发送音频数据1之前，AudioPolicy还可以根据音箱的音频能力参数设置对应的音频策略，并将该音频策略输出至AudioFlinger。例如，AudioPolicy可以根据音箱的音频能力参数设置是否对音频数据1进行采样、是否添加音效等。进而，AudioFlinger可按照AudioPolicy输出的音频策略对音频数据1进行相应的处理。那么，AudioFlinger调用DMSDP Audio HAL向音箱发送音频数据1为AudioFlinger按照上述音频策略处理之后的音频数据。
S5004、手机中的第二音频应用产生第二音频数据后，AudioPolicy根据第一从设备的混音策略确定是否对第一音频数据和第二音频数据混音。
如图55所示，以第二音频应用为短信APP举例，在音乐APP(即第一音频应用)播放歌曲的过程中，如果短信APP接收到新的短消息，则短信APP可产生NOTIFICATION类型的音频数据2(即第二音频数据)。与第一音频数据类似的，第二音频APP也可调用AudioTrack向AudioFlinger中输入当前产生的第二音频数据。
AudioFlinger接收到来自短信APP的音频数据2后，可查询此时是否还有其他音频数据需要在从设备上播放。例如，如果AudioFlinger不仅接收到来自音乐APP的音频数据1，还同时接收到来自短信APP的音频数据2，则AudioFlinger可确定音频数据1和音频数据2需要同时在当前的从设备(即音箱)上播放。
并且，AudioFlinger可通过在AudioTrack中读取与音频数据1和音频数据2分别对应的mode参数可以识别出音频数据1与音频数据2的类型不同。例如，AudioFlinger可确定音频数据1为MUSIC类型的音频数据，音频数据2为NOTIFICATION类型的音频数据。由于当前需要在音箱上播放的音频数据为多路不同类型的音频数据，因此，AudioFlinger可向AudioPolicy发送查询请求，该查询请求中可以包括音频数据1和音频数据2的具体类型，以请求AudioPolicy确定是否对音频数据1和音频数据2进行混音。
若不需要对音频数据1和音频数据2进行混音，则手机可继续执行下述步骤S5005-S5006；若需要对音频数据1和音频数据2进行混音，则手机可继续执行下述步骤S5007-S5009。
需要说明的是，上述第一音频应用和第二音频应用可以是相同的应用，也可以是不同的应用。例如，微信APP作为音频APP时，既可以播放NOTIFICATION类型的提示音，也可以播放MUSIC类型的音乐，本申请实施例对此不做任何限制。另外，如果上述第一音频数据与第二音频数据的类型相同，说明第一音频数据与第二音频数据的音频特征相同，混音对第一音频数据与第二音频数据造成的失真影响较小，则AudioPolicy可默认允许否对第一音频数据与第二音频数据进行混音。
S5005、若不需要对第一音频数据和第二音频数据混音，则AudioPolicy向AudioFlinger发送第一混音指示，第一混音指示用于指示独立传输第一音频数据和第二音频数据。
仍以第一从设备为音箱1举例，AudioPolicy接收到AudioFlinger发送的查询请求后，参见表11所示的混音策略，AudioPolicy根据音频数据1和音频数据2的类型可确定出MUSIC类型的音频数据1不允许进行混音，即音频数据1需要独立传输。虽然NOTIFICATION类型的音频数据2允许与其他音频数据混音，但由于此时除了音频数据1和音频数据2之外没有其他支持混音的音频数据，因此，AudioPolicy可确定不需要对音频数据1和音频数据2进行混音。也就是说，当音频数据1和音频数据2中有一个不允许混音时，AudioPolicy可确定不需要对音频数据1和音频数据2进行混音。
此时，AudioPolicy可向AudioFlinger发送第一混音指示，第一混音指示用于指示不需要对音频数据1和音频数据2进行混音，即音频数据1和音频数据2需要独立传输给音箱1，以保证音箱1根据接收到的音频数据1和音频数据2能够尽量还原音频数据1和音频数据2的音频特征进行播放。
S5006、响应于第一混音指示，手机中的AudioFlinger分别将第一音频数据和第二音频数据发送给第一从设备。
AudioFlinger接收到AudioPolicy发送的第一混音指示后，可确定当前接收到的音频数据1和音频数据2需要独立传输给音箱1，那么，AudioFlinger无需按现有技术中的方法对音频数据1和音频数据2进行混音处理。相应的，仍如图55所示，AudioFlinger可调用HAL中的DMSDP Audio HAL，向DMSDP Audio HAL发送两路音频数据(即音频数据1和音频数据2)，进而通过DMSDP Audio HAL将音频数据1和音频数据2发送给音箱1。这样，音箱1接收到的音频数据1和音频数据2是相对独立的两路音频数据，音箱1在播放音频数据1和音频数据2时能够尽可能的还原音频数据1和音频数据2各自的音频特征。
示例性的，AudioFlinger接收到上述第一混音指示后，可分别对音频数据1和音频数据2进行打包(也可称为封包)，例如，手机可将音频数据1中的每3帧音频数据封装为一个数据包，手机可将音频数据2中的每2帧音频数据封装为一个数据包。如图56所示，在对音频数据1进行打包的过程中，可在每个数据包中添加音频数据1的标识，例如01。相应的，在对音频数据2进行打包的过程中，可在每个数据包中添加音频数据2的标识，例如02。仍如图56所示，AudioFlinger可实时的将打包后得到的数据包存储在AudioFlinger的缓存(buffer)5601中，并实时的将buffer 5601中的数据包发送给DMSDP Audio HAL。这样，DMSDP Audio HAL虽然是从同一buffer 5601中获取到的音频数据1和音频数据2的数据包，但DMSDP Audio HAL根据数据包中的标识可以还原出哪些数据包为音频数据1的数据包，哪些数据包为音频数据2的数据包。
或者，也可以在AudioFlinger中设置多个buffer，每一路需要传输给从设备(例如音箱1)的音频数据与一个buffer对应。例如，AudioFlinger可将上述音频数据1打包为若干个数据包存储在第一buffer中，将上述音频数据2打包为若干个数据包存储在第二buffer中。此时，AudioFlinger可以在数据包中添加用于指示具体音频数据的 标识，也可以不在数据包添加用于指示具体音频数据的标识。这样，DMSDP Audio HAL从第一buffer获取的数据包为音频数据1的数据包，DMSDP Audio HAL从第二buffer获取的数据包为音频数据2的数据包。
DMSDP Audio HAL从上述buffer 5601中获取到携带有标识的各个数据包后，可以对每个数据包进行解包，即解封装每个数据包。这样，DMSDP Audio HAL可以根据每个数据包中携带的标识还原出两路未经混音的音频数据(即音频数据1和音频数据2)。进而，DMSDP Audio HAL可通过步骤S5001中建立的网络连接将音频数据1和音频数据2相对独立的发送至音箱1，使音箱1可以获得未经混音的音频数据1和音频数据2。
或者，DMSDP Audio HAL从上述buffer 5601中获取到携带有标识的各个数据包后，可直接将获取到的数据包发送至音箱1，由音箱1对接收到的每个数据包进行解包，从而根据每个数据包中携带的标识还原出两路未经混音的音频数据(即音频数据1和音频数据2)。这样可以减少手机中DMSDP Audio HAL的处理复杂度，降低手机与音箱1进行音频切换时产生的时延。
在一些实施例中，如果上述音频数据1和音频数据2需要发送至两个不相同的音频输出设备，例如，将音频数据1发送至音箱1播放，将音频数据2发送至电视2播放。那么，DMSDP Audio HAL从上述buffer 5601中获取到携带有标识的各个数据包后，需要先对各个数据包进行解包，以还原出音频数据1和音频数据2这两路音频数据，再分别将音频数据1发送至音箱1，将音频数据2发送至电视2。
当音频数据1和音频数据2被发送至音箱1后，由于音频数据1和音频数据2没有经过混音处理，因此音频数据1和音频数据2的音频特征最大程度的得到了保留，使得音箱1在播放音频数据1和音频数据2时也能够最大程度的还原出音频数据1和音频数据2的音频特征，从而降低音频切换场景下播放失真的现象。
示例性的，用户在手机中已经设置了MUSIC类型的音频数据1的音量为7级，且设置了NOTIFICATION类型的音频数据2的音量为4级。当音量等级越大时，AudioFlinger会将对应的音频数据的增益设置的越大，使得音频数据在播放时的响度越大。那么，如图57所示，由于手机中的DMSDP Audio HAL向音箱1发送的音频数据1和音频数据2是相对独立的两路音频数据，因此，音箱1接收到的音频数据1的增益大小还是与手机中的7级音量对应的，音频数据2的增益大小也是与手机中的4级音量对应的。那么，音箱1可以直接按照音频数据1和音频数据2的增益大小同时播放音频数据1和音频数据2。或者，音箱1也可以在音频数据1和音频数据2的基础上成比例的对音频数据1和音频数据2的增益大小进行放大或缩小后再播放。无论是哪种方式，由于音箱1接收到的音频数据1的音量大于音频数据2的音量，因此音箱1最终播放出的音频数据1的音量仍然大于音频数据2的音量，从而还原出音频数据1和音频数据2原本在手机上的音量特征，避免用户感受到多路音频数据中某一路音频数据音量过大或音量过小的问题。
需要说明的是，音箱1在播放音频数据1和音频数据2之前，还可以对播放音频数据1和音频数据2进行解析、采样、编码、解码、封装或解封装等处理操作，进而播放处理后的音频数据1和音频数据2，本申请实施例对此不做任何限制。
S5007、若需要对第一音频数据和第二音频数据混音，则AudioPolicy向AudioFlinger发送第二混音指示，第二混音指示用于指示对第一音频数据和第二音频数据进行混音。
与步骤S5005对应的，在步骤S5007中，AudioPolicy可以根据音频数据1和音频数据2的类型，按照表11所示的混音策略确定音频数据1是否允许混音，并确定音频数据2是否允许混音。如果音频数据1和音频数据2均允许进行混音，则AudioPolicy可确定需要对音频数据1和音频数据2进行混音。
此时，AudioPolicy可向AudioFlinger发送第二混音指示，第二混音指示用于指示需要对音频数据1和音频数据2进行混音，即音频数据1和音频数据2不需要独立传输给音箱1。
S5008、响应于第二混音指示，手机中的AudioFlinger将第一音频数据和第二音频数据混音为第三音频数据。
AudioFlinger接收到AudioPolicy发送的第二混音指示后，如图58所示，可对音频数据1和音频数据2进行混音处理。例如，当音频数据1的采样率大于音频数据2的采样率时，AudioFlinger可使用音频数据2的采样率(即较小的采样率)统一对音频数据1和音频数据2进行采样。又例如，当音频数据1的音量与音频数据2的音量不一致时，AudioFlinger可将音频数据1和音频数据2的增加大小调整为同样的取值。那么，经过混音后的音频数据1和音频数据2被合为一路音频数据(即第三音频数据)。
S5009、手机中的AudioFlinger将第三音频数据发送给第一从设备。
在步骤S5009中，仍如图58所示，AudioFlinger可将混音后的第三音频数据通过DMSDP Audio HAL发送给音箱1，由音箱1播放混音后的第三音频数据。由于第三音频数据中音频数据1和音频数据2的部分音频特征在混音时被修改，因此音箱1播放第三音频数据时可能会出现一定的失真现象。但由于用户已经在音箱1对应的混音策略中设置了允许与音频数据1和音频数据2的类型对应的音频数据进行混音，因此播放第三音频数据时出现的失真现象一般是在用户的接收范围内的。
上述实施例中是以音频数据1和音频数据2这两路音频数据是否进行混音举例说明的，可以理解的是，当手机中的AudioFlinger同时接收到三路或更多路音频数据时，仍可按照上述实施例中所述的方法确定哪些音频数据需要独立传输给从设备，哪些音频数据需要混音后再传输给从设备，本申请实施例对此不做任何限制。
示例性的，仍以第一从设备为音箱1举例，手机将音频功能切换至音箱1后，用户还可以在手机上手动修改当前与手机进行音频切换的从设备。例如，手机在运行音乐APP时，如果接收到用户打开控制中心的操作，则如图59中的(a)所示，手机可在音乐APP的应用界面中显示控制中心5901。控制中心5901中包括音频切换功能的切换按钮5902。当用户希望修改当前手机的从设备时，可点击切换按钮5902查询当前可以作为手机的从设备的一个或多个候选设备。如图59中的(b)所示，手机检测到用户点击切换按钮5902后，手机可将检测到的一个或多个候选设备显示在控制中心5902中。控制中心5902中的音箱已经被标记为选中状态，即此时音箱作为手机的从设备(即第一从设备)正在播放来自手机的音频。如果用户需要将更换手机的从设备，则用户可在控制中心5902中重新选择进行音频切换的从设备(即第二从设备)。
以用户选择车机为手机的第二从设备举例，手机可响应用户在控制中心5902中选择车机的操作，断开已经与音箱1建立的网络连接，并与车机建立网络连接。与步骤S5001类似的，手机与车机建立网络连接后，可通过DV APP可获取车机的音频能力参数，并按照车机的音频能力参数在HAL创建与对应的DMSDP Audio HAL。或者，手机可按照车机的音频能力参数更新步骤S5001中为音箱1创建的DMSDP Audio HAL，使得更新后的DMSDP Audio HAL与车机的音频能力匹配。
进而，与步骤S5002类似的，如图60所示，手机将车机确定为当前的从设备(即第二从设备)并建立网络连接后，DV APP可获取车机的标识，从而确定当前连接的第二从设备为车载类设备。进而，DV APP可将预先为车载类设备存储的混音策略作为车机的混音策略2下发给AudioPolicy。后续，AudioPolicy可按照车机的混音策略2确定是否对当前接收到的音频数据进行混音。
示例性的，车机的混音策略2可以如表13所示，与表11所示的混音策略不同的是，混音策略2中还可以设置一个或多个包括应用的标识，例如应用的包名(Package Name)。也就是说，手机在混音策略2中还可以设置不同应用分别对不同类型的音频数据的混音能力。例如，对于微信APP，车机不允许对MUSIC类型和COMMUNICATION类型的音频数据进行混音，允许对NOTIFICATION类型和DTMF类型的音频数据进行混音。对于音乐APP，车机不允许对MUSIC类型的音频数据进行混音等。其中，混音策略2中包含的具体应用可以是开发人员预先设置的。或者，每当用户在手机中安装新的应用时，手机可从服务器获取该应用在不同音频输出设备中的混音策略，这样，手机可以根据手机中安装的应用动态更新每个音频输出设备的混音策略，本申请实施例对此不做任何限制。
表13
Figure PCTCN2021104105-appb-000012
这样一来，手机在运行微信APP时，微信APP产生的MUSIC类型和COMMUNICATION类型的音频数据可独立传输至车机中播放，不与其他同时接收到的音频数据进行混音，从而降低这两种类型的音频数据在车机上播放时的失真率。并且，手机可以以应用为粒度，将一个应用产生的不同类型的音频进行混音或不混音，从而将某一应用中用户对音质要求较高的音频数据独立传输给从设备，使从设备在播放音频数据时能够尽可能真实的还原音频数据在主设备(即手机)中原有的音频特征。
在另一些实施例中，还可以在AudioPolicy中设置如表14所示的混音策略。该混音策略中针对不同的应用，为每个应用中不同类型的音频数据设置了不允许进行混音的设备类型，即向哪些类型的音频输出设备发送音频数据时需要独立传输。例如，当 微信APP产生MUSIC类型的音频数据时，当该音频数据需要在手机、音箱、电视或车机这几类音频输出设备上播放时，不允许将该音频数据与其他音频数据进行混音。又例如，当音乐APP产生NOTIFICATION的音频数据时，该音频数据在任意类型的音频输出设备上播放时均可进行混音，即不允许混音的设备类型为空。后续，AudioPolicy可按照表14所示的混音策略，结合当前从设备的设备类型确定对正在运行的音频APP产生的各类音频数据是否进行混音。当然，也可以在表14所示的混音策略中为每个应用中不同类型的音频数据设置允许进行混音的音频输出设备，本申请实施例对此不做任何限制。
表14
Figure PCTCN2021104105-appb-000013
在另一些实施例中，用户还可以在手机中手动修改当前从设备的混音策略。如图61中的(a)所示，手机将音乐APP切换至后台运行后，可打开微信APP显示微信APP的应用界面6100。如果检测到用户在应用界面6100中输入打开控制中心的操作，则手机可在应用界面6100中显示控制中心6101。控制中心6101中设置有音频切换的卡片6102，卡片6102中包括音频切换的设置按钮6103。如果检测到用户点击设置按钮6103，则如图61中的(b)所示，DV APP可显示车机作为从设备时的设置界面6104。与图54类似的，设置界面6104中可以设置音频切换功能的开关按钮6105。当用户打开开关按钮6105后，用户可在设置界面6104中设置当车机为从设备时手机允许对哪些类型的音频数据进行混音，或者进一步设置当车机为从设备时手机允许对某些应用中某些类型的音频数据进行混音。进而，DV APP可根据用户在设置界面6104中的选择更新表13所示的车机的混音策略2，使得用户可以动态的指定在各个类型的音频数据在向从设备输出时是否进行混音。
当手机的从设备从音箱切换为车机后，AudioFlinger可以向AudioPolicy请求查询当前接收到的音频数据是否需要进行混音。进而，AudioPolicy可根据DV APP下发的混音策略2确定是否对当前的音频数据进行混音。
示例性的，以AudioFlinger同时接收到三路音频数据举例，如图62所示，在T1时刻用户在手机中打开了音乐APP开始播放歌曲，在T2(T2＞T1)时刻微信APP接收到联系人发送的新消息后开始播放提示音，在T3-T4(T4＞T3＞T2)这一时间段内用户在微信APP中使用键盘点击按键时开始播放按键音。那么，如图60所示，在T3-T4 这一时间段内手机的AudioFlinger可同时接收到来自微信APP的NOTIFICATION类型的音频数据A和DTMF类型的音频数据B，以及来自音乐APP的MUSIC类型的音频数据C。
仍如图60所示，AudioFlinger可向AudioPolicy请求查询音频数据A、音频数据B以及音频数据C是否需要混音。进而，AudioPolicy可根据表13所示的混音策略2，确定NOTIFICATION类型的音频数据A和DTMF类型的音频数据B可以混音，而MUSIC类型的音频数据C不允许与其他音频数据混音，需要独立传输至车机，以保证车机在播放MUSIC类型的音频数据C时的音质。
那么，AudioPolicy可向AudioFlinger发送指示消息，指示AudioFlinger对音频数据A和音频数据B进行混音，而音频数据C不需要进行混音。仍如图60所示，AudioFlinger可响应该指示消息，将音频数据A和音频数据B混音为一路音频数据(即音频数据A+B)后，输出两路音频数据，即经过混音的音频数据A+B以及未经过混音的音频数据C。进而，AudioFlinger可调用DMSDP Audio HAL将混音后的音频数据A+B以及未经过混音的音频数据C发送给车机，由车机播放上述音频数据A+B以及音频数据C。这样，MUSIC类型的音频数据C可以不经过混音处理相对独立的传输给从设备(即车机)，使得从设备接收到的音频数据C能够较为真实的反映出原有的音频特征，避免因混音处理而带来的音频失真现象，从而降低多路音频数据在跨设备播放时的失真情况，提高音频切换场景的音频输出质量。
在一些实施例中，仍以车机为手机的从设备举例，手机在向车机发送每一路音频数据(例如音频数据C)时，可以将音频数据C打包为一个一个的数据包，以数据包的形式发送给车机。例如，手机中的AudioFlinger可以按照JSON(JavaScript Object Notation，对象简谱)协议对音频数据C进行打包，并在数据包中添加音频数据C的特征信息。例如，该特征信息可以包括音频数据C所属的应用包名、播放类型(例如游戏、电影等)、播放格式(例如MP3等)、音量等级、是否混音、音频类型(例如MUSIC类型等)、音轨信息(例如音轨数量、音轨的序号等)。这些特征信息能够反映出音频数据C实际的音频特征，使得接收到该数据包的从设备(例如车机)通过解析数据包中的特征信息能够真实的还原出音频数据C以及音频数据C的相关特征，从而按照音频数据C的特征信息播放音频数据C，减少音频数据C在音频切换过程中的失真现象。
例如，AudioFlinger可在每个数据包的头文件(head)中调添加对应音频数据的特征信息。以PCM格式的音频数据举例，AudioFlinger按照JSON协议封装的数据包1和数据包2可以如下所示：
Figure PCTCN2021104105-appb-000014
Figure PCTCN2021104105-appb-000015
在一些实施例中，AudioFlinger可将封装好的数据包(例如上述数据包1和数据包2)先发送给DMSDP Audio HAL，由DMSDP Audio HAL对上述数据包1和数据包2进行解包。DMSDP Audio HAL通过读取数据包1和数据包2中的特征信息(例如应用的包名)可以识别出数据包1来自微信APP，而数据包2来自音乐APP，即数据包1和数据包2分别属于两路音频数据。这样，DMSDP Audio HAL对AudioFlinger发来的每个数据包进行解包后，可原出对应的未经混音的两路音频数据。进而，DMSDP Audio HAL可接将这两路音频数据相对独立的发送至车机播放。
在另一些实施例中，DMSDP Audio HAL获取到AudioFlinger已经封装好的数据包后，可直接将取到的数据包发送给车机。由车机对接收到的每个数据包进行解包，从而根据每个数据包中携带的特征信息还原出对应的未经混音的两路音频数据。并且，车机还可以根据对应的特征信息选择相应的播放方式准确还原这两路音频数据的播放过程。例如，车机可以使用MP3格式播放与上述数据包1对应的音频数据，并使用flac格式播放与上述数据包2对应的音频数据，从而尽可能的还原出这两路音频数据在手机中播放时的音频特征，降低音频切换场景下播放失真的现象。
在上述实施例中，是以手机将手机中的所有音频数据均切换至从设备(例如音箱)中播放举例说明的。可以理解的是，在一些实施例中，当手机的AudioFlinger接收到来自不同应用或同一应用的多路音频数据时，AudioFlinger还可通过与AudioPolicy交互确定这多路音频数据中每一路音频数据的音频输出设备。
仍以手机的从设备为音箱举例，手机与音箱建立连接后，如图63所示，手机中的DV APP除了向AudioPolicy下发上述混音策略外，还可以向AudioPolicy下发音箱的设备选择策略，该设备选择策略中设置了音箱允许播放的音频数据的类型和音箱不允许播放的音频数据的类型。例如，音箱允许播放MUSIC类型、NOTIFICATION类型和RING类型的音频数据，但音箱不允许播放SYSTEM类型和DTMF类型的音频数据。
仍如图62所示，在T3-T4这一时间段内手机的AudioFlinger可同时接收到来自微 信APP的NOTIFICATION类型的音频数据A和DTMF类型的音频数据B，以及来自音乐APP的MUSIC类型的音频数据C。进而，仍如图63所示，AudioFlinger可向AudioPolicy请求查询音频数据A、音频数据B以及音频数据C是否允许在音箱中播放，即与AudioPolicy协商音频数据的音频输出设备。进而，AudioPolicy可根据上述设备选择策略确定可以在音箱上播放NOTIFICATION类型的音频数据A和MUSIC类型的音频数据C，但不允许在音箱上播放DTMF类型的音频数据B。并且，AudioPolicy还可以为音频数据B设置一个音频输出设备，例如，将音频数据B的音频输出设备设置为手机自身。进而，AudioPolicy可向AudioFlinger指示将音频数据A和音频数据C输出至音箱播放，将音频数据B输出至手机的扬声器播放。
进一步的，AudioFlinger根据AudioPolicy的指示可确定音频数据A和音频数据C需要发送至音箱播放。此时，为了保证音频数据A和音频数据C在音箱上播放的音频质量，AudioFlinger可请求AudioPolicy查询是否需要对音频数据A和音频数据C进行混音，即与AudioPolicy协商是否对音频数据进行混音。进而，AudioPolicy可按照上述实施例中的方法根据DV APP下发的混音策略确定是否需要对音频数据A和音频数据C进行混音。如果不需要对音频数据A和音频数据C进行混音，手机可执行如步骤S5005-5006所述的方法，将音频数据A和音频数据C这两路音频数据相对独立的发送给音箱进行播放(图63中未示出)；如果需要对音频数据A和音频数据C进行混音，如图63所示，则手机可执行如步骤S5007-5009所述的方法，将音频数据A和音频数据C混音后得到的一路音频数据A+C发送给音箱进行播放。
或者，当AudioPolicy根据上述设备选择策略确定出音频数据A和音频数据C的音频输出设备为音箱，音频数据B的音频输出设备为手机后，由于此时音箱需要同时播放多路音频数据，因此AudioPolicy可进一步根据DV APP下发的混音策略确定是否需要对音频数据A和音频数据C进行混音。进而，AudioPolicy可向AudioFlinger指示音频数据A和音频数据C的音频输出设备为音箱，且音频数据A和音频数据C是否需要混音，并且，向AudioFlinger指示音频数据B的音频输出设备为手机。
后续，AudioFlinger可通过Primary HAL将音频数据B输出至手机的扬声器播放，并且，AudioFlinger可通过DMSDP Audio HAL将未经混音的音频数据A和音频数据C(或者混音后的音频数据A+C)发送至音箱播放。
这样一来，在手机需要将同时产生的多路音频数据切换至从设备播放时，手机不仅可以根据当前从设备的设备选择策略为不同的音频数据选择相应的音频输出设备，还可以根据当前从设备的混音策略确定需要在同一音频输出设备上播放的多路音频数据中独立传输的音频数据，从而避免因混音处理对某一类型的音频数据造成的失真现象，提高音频切换场景的音频输出质量。
在分布式音频场景中，主设备可以是具有分屏显示功能(也可称为分屏功能)的电子设备。示例性的，分屏功能是指主设备在自身的显示屏中显示时可创建多个窗口，并在每个窗口中运行和显示相应的应用、软件或程序。
仍以手机为主设备举例，用户通过预设的操作(例如长按屏幕等操作)可触发手机进入分屏模式。如图64所示，在分屏模式中，手机可将显示屏中的显示区域划分为窗口6401和窗口6402。其中，手机的状态栏可显示在窗口6401或窗口6402中，或 者，也可以在分屏模式中隐藏手机的状态栏，本申请实施例对此不作任何限制。窗口6401和窗口6402可分别用于运行并显示对应的应用，或者，窗口6401和窗口6402也可分别运行并显示同一应用的不同任务，例如，窗口6401可显示微信APP中与联系人Amy的聊天界面，同时，窗口6402可显示微信APP中与联系人Mike的聊天界面。当然，手机还可以将显示区域划分为3个或更多个窗口，本申请实施例对此不做任何限制。
示例性的，窗口6401中可运行第一视频APP，窗口6402中可运行第二视频APP。第一视频APP在运行时可创建一个或多个音频任务，例如，播放视频A的音频任务1，播放通知消息提示音的音频任务2。类似的，第二视频APP在运行时也可创建一个或多个音频任务。
在本申请实施例中，主设备(例如手机)显示的每一个窗口可与一个音频输出设备关联。也就是说，每个窗口中音频任务输出的音频数据可使用与该窗口关联的音频输出设备播放。示例性的，窗口与音频输出设备之间的关联关系可以是用户设置的。例如，如果用户设置窗口A与有线耳机关联。那么，当窗口A中应用创建的音频任务输出对应的音频数据时，手机可将该音频数据发送至与手机相连的有线耳机中播放。在一些实施例中，手机也可修改窗口与音频输出设备之间的关联关系。仍以用户将与窗口A关联的音频输出设备设置为有线耳机举例，如果手机没有与有线耳机连接，则手机可重新确定与窗口A关联的音频输出设备，例如，手机可将手机本机确定为与窗口A关联的音频输出设备，进而，手机可将将窗口A中输出的音频数据发送至手机的扬声器播放。又或者，如果有线耳机不支持播放当前窗口A中的音频数据，例如，一些配置较低的有线耳机可能不支持播放高清格式的音频数据，则手机可重新确定与窗口A关联的音频输出设备，并将该音频数据发送至关联的音频输出设备中播放。当然，手机也可以响应用户的设置修改窗口与音频输出设备之间的关联关系，本申请实施例对此不做任何限制。
示例性的，当手机进入分屏模式后，如图65所示，手机可在窗口6401中显示第一对话框6501，在第一对话框6501中提示用户选择与窗口6401关联的音频输出设备。例如，手机可将与手机位于同一Wi-Fi网络内或与手机已经建立连接的具有音频播放功能的电子设备显示在第一对话框6501中。这样，用户可在第一对话框6501中选择与窗口6401关联的音频输出设备(即手机的一个从设备)。以用户在第一对话框6501中选择蓝牙耳机举例，如果检测到用户在第一对话框6501中选择蓝牙耳机，则手机可建立窗口6401与蓝牙耳机之间的关联关系。后续，手机可将窗口6401中音频任务输出的音频数据发送给蓝牙耳机播放。上述第一对话框6501可以是手机进入分屏模式后在窗口6401中自动显示的，也可以是手机进入分屏模式后用户通过某一按键或手势触发手机在窗口6401中显示的。
类似的，仍如图65所示，手机进入分屏模式后，手机还可在窗口6402中显示第二对话框6502，在第二对话框6502中提示用户选择与窗口6402关联的音频输出设备。例如，手机可将与手机位于同一Wi-Fi网络内或与手机已经建立连接的具有音频播放功能的电子设备显示在第二对话框6502中。这样，用户可在第二对话框6502中选择与窗口6402关联的音频输出设备(即手机的另一个从设备)。以用户在第二对话框 6502中选择音箱举例，如果检测到用户在第二对话框6502中选择音箱，则手机可建立窗口6402与音箱之间的关联关系。后续，手机可将窗口6402中音频任务输出的音频数据发送给音箱播放。类似的，上述第二对话框6502可以是手机进入分屏模式后在窗口6402中自动显示的，也可以是手机进入分屏模式后用户通过某一按键或手势触发手机在窗口6402中显示的。
在一些实施例中，用户为窗口6401设置的相关联的音频输出设备与用户为窗口6402设置的相关联的音频输出设备可以相同，例如，用户在第一对话框6501中选择了本机，并且，用户在第二对话框6502中也选择了本机。此时，如图66所示，手机可显示提示消息6601，提示消息6601用于提示用户将窗口6401和窗口6402关联至了同一音频输出设备(即手机本机)上。后续，手机可将与窗口6401对应的音频数据和与窗口6402对应的音频数据进行混音后输出至本机的扬声器播放。
在一些实施例中，手机还可以向用户提供修改不同窗口与不同音频输出设备之间关联关系的入口。例如，如图67中的(a)所示，手机可在窗口6401中显示音频输出设备的第一切换按钮6701，并且，手机可在窗口6402中显示音频输出设备的第二切换按钮6702。如果检测到用户点击第一切换按钮6701，则与图65类似的，手机可将此时检测到的具有音频播放功能的一个或多个电子设备显示在对话框6703中供用户选择。如果用户选中了蓝牙耳机之外的电子设备，例如，用户在对话框6703中选中了手机本机，说明用户希望由手机本机播放窗口6401中音频任务输出的音频数据，则手机可响应用户的操作，将窗口6401与蓝牙耳机之间的关联关系修改为窗口6401与手机本机之间的关联关系。
类似的，如图67中的(b)所示，如果检测到用户点击第二切换按钮6702，手机可将此时检测到的具有音频播放功能的一个或多个电子设备显示在对话框6704中供用户选择。如果用户选中了音箱之外的电子设备，例如，用户在对话框6704中选中了电视，说明用户希望由电视播放窗口6402中音频任务输出的音频数据，则手机可响应用户的操作，将窗口6402与音箱之间的关联关系修改为窗口6402与电视之间的关联关系。
当然，除了在窗口中设置切换按钮(例如上述第一切换按钮6701和第二切换按钮6702)之外，本领域技术人员还可以设置其他方式修改窗口与音频输出设备之间的关联关系。例如，如果检测到用户在窗口6402中输入长按操作，则手机可显示上述对话框6704以便用户修改与窗口6402对应的音频输出设备，本申请实施例对此不做任何限制。
另外，手机可保存用户为每个窗口设置的音频输出设备，即保存不同窗口与不同音频输出设备之间的关联关系。当手机再次进入分屏模式后，手机可按照已保存的窗口与音频输出设备之间的关联关系，将与窗口对应的音频数据分别发送至对应的音频输出设备中播放。
当然，除了由用户手动设置分屏模式下与每个窗口关联的音频输出设备外，手机还可以从服务器中获取不同窗口与不同音频输出设备之间的关联关系。或者，手机也可以根据不同窗口中应用的类型或音频数据的类型自动设置与该窗口关联的音频输出设备。例如，如果窗口6402中音乐APP创建的音频任务输出MUSIC类型的音频数据， 则手机可自动将该MUSIC类型的音频数据发送至音箱播放，本申请实施例对此不做任何限制。
可以看出，在本申请实施例中，主设备(例如手机)可以以窗口为粒度设置不同窗口与不同音频输出设备之间的关联关系。在多窗口多音频任务并发的场景下，手机可将每个窗口中相关音频任务输出的音频数据发送给对应的音频输出设备进行播放。这样，主设备并发的多路音频数据不会互相干扰，这多路音频数据可以通过不同的音频输出设备播放给不同的用户，每个用户可以可以使用与相关窗口关联的音频输出设备收听对应的音频数据，不会受到来自其他窗口的音频数据的影响，从而提高用户的音频使用体验。
仍以手机为主设备举例，上述图6示出了手机中Android系统的架构示意图，其中，Android系统中设置有实现音频功能的音频架构601。在图6所示的Android系统的基础上，如图68所示，Android系统中还设置有实现显示功能的显示架构6801。在应用程序框架层中，该显示架构6801可包括窗口管理器(WindowManager)和display模块。
仍以视频APP举例，视频APP可将待显示的显示数据的一系列绘制指令输出至窗口管理器中。例如，该绘制指令可以OpenGL指令等。窗口管理器可创建相应的display模块，并在display模块按照视频APP下发的绘制指令绘制出对应的显示数据。例如，窗口管理器可查询当前手机是否为分屏模式。如果不是分屏模式，则窗口管理器可创建一个display模块，该display模块用于向显示屏提供显示数据。进而，窗口管理器可按照接收到的绘图指令在上述display模块中绘制视频APP待显示的显示数据。后续，窗口管理器可将上述display模块中的显示数据通过Display HAL发送至显示屏中进行显示。也就是说，在非分屏模式下手机可将显示屏中的整个显示区域作为一个窗口显示视频APP的显示数据。
如果手机处于分屏模式，则窗口管理器可创建多个display模块，每个display模块与显示屏中的一个窗口对应。例如，仍如图68所示，在分屏模式下手机可默认将显示屏中的显示区域划分为两个窗口，那么，如果检测到用户输入开启分屏模式的操作，则窗口管理器可创建与窗口1对应的display模块1以及与窗口2对应的display模块2。display模块1可理解为一块虚拟的存储空间，用于存储窗口1中需要显示的显示数据；类似的，display模块2也可理解为一块虚拟的存储空间，用于存储窗口2中需要显示的显示数据。如果视频APP在窗口1中运行，则窗口管理器接收到来自视频APP的绘制指令后，可在display模块1中按照该绘制指令绘制对应的显示数据1。后续，窗口管理器可将上述display模块1中的显示数据1通过Display HAL发送至显示屏中的窗口1中进行显示。类似的，在窗口2中运行的应用(例如音乐APP)也可以将对应的绘制指令传输至窗口管理器。窗口管理器可按照该绘制指令在display模块2中绘制对应的显示数据2，并通过Display HAL将display模块2中的显示数据2发送至显示屏中的窗口2中进行显示。这样，在分屏模式下手机可以窗口为粒度在每个窗口中显示相关应用的显示数据。
一般，在分屏模式下，display模块1和display模块2中的显示数据共同组成了显示屏中的显示数据。那么，Display HAL可以周期性的从display模块1和display模块 2中获取对应的2路显示数据，并将这2路显示数据组合为与整个显示屏对应的一路显示数据，并将该路显示数据发送至显示屏进行显示。
以下将结合具体示例详细阐述分屏场景下的音频控制方法。
示例性的，用户可向手机(即主设备)输入预设的分屏操作触发手机进入分屏模式。例如，如图69中的(a)所示，手机在运行微信APP时，如果检测到用户使用指关节在显示屏上画直线，则手机可响应该操作进入分屏模式。如图69中的(b)所示，进入分屏模式后，手机可自动将显示屏划分为两个窗口，即第一窗口6901和第二窗口6902。其中，第一窗口6901可用于继续运行微信APP，第二窗口6902可用于显示手机的桌面。用户可在第一窗口6901中使用手机提供的各项功能，也可以在第二窗口6902中使用手机提供的各项功能。
示例性的，在进入分屏模式前，如果微信APP检测到用户使用指关节在显示屏上画直线的操作，则微信APP可向窗口管理器发送指示消息，以指示窗口管理器进入分屏模式。进而，如图70所示，窗口管理器可响应该指示消息创建与第一窗口6901对应的display模块1以及与第二窗口6902对应的display模块2，display模块1和display模块2可通过不同的display ID区分。display模块1用于向第一窗口6901提供对应的显示数据，display模块2用于向第二窗口6902提供对应的显示数据。
在窗口管理器创建了display模块1和display模块2后，如图70所示，窗口管理器可接收来自微信APP的绘制指令，并按照该绘制指令在display模块1中绘制与微信APP对应的显示数据。并且，窗口管理器可默认将桌面的显示数据2绘制在display模块2中。后续，HAL中的Display HAL可将display模块1中的显示数据1和display模块2中的显示数据2合成整个显示屏的显示数据3，并将显示数据3发送至手机的显示屏，使显示屏显示出如图69中的(b)所示的显示界面。当然，手机也可以在第二窗口6902中运行微信APP，在第一窗口6901中运行桌面。或者，除了桌面之外，手机也可以在除了运行微信APP的窗口中默认运行其他的应用，本申请实施例对此不做任何限制。
以安卓系统举例，目前安卓系统中设置有音频焦点(Audio Focus)抢占机制，一次只能有一个应用持有音频焦点。一般，获取到音频焦点的应用具有播放音频的权限。示例性的，当应用1创建了音频任务后，可调用requestAudioFocus()接口获取音频焦点，获取到音频焦点的应用1(可称为音频焦点应用)可以开始执行音频任务播放相应的音频数据。当音频任务执行结束时，应用1可调用abandonAudioFocus()释放上述音频焦点(也可称为失焦)，并停止播放相应的音频数据。或者，在应用1持有音频焦点时，如果应用2调用requestAudioFocus()接口申请获取上述音频焦点，则应用1也可以释放上述音频焦点，使得应用2获取到该应用2，成为当前的音频焦点应用。
在本申请实施例中，手机在分屏模式中可为每个窗口设置一个音频焦点(Audio Focus)。例如，上述第一窗口6901可以与音频焦点1对应，上述第二窗口6902可以与音频焦点2对应。这样，第一窗口6901中获取到音频焦点1的音频焦点应用可开始执行相关的音频任务，同样，第二窗口6902中获取到音频焦点2的音频焦点应用可开始执行相关的音频任务，使得各个窗口之间的音频任务不会互相干扰，后续，不同窗口中音频任务输出的音频数据也可以被分发至不同的音频输出设备中播放，使得各个 窗口之间的音频数据不会互相干扰。
示例性的，窗口管理器可用于管理第一窗口6901中音频焦点1的获取和释放过程，以及第二窗口902中音频焦点62的获取和释放过程。例如，手机进入分屏模式后，窗口管理器可创建并维护每个窗口与音频焦点应用之间的对应关系。例如，如表15所示，display模块1的ID与微信APP的包名对应，即第一窗口6901中的音频焦点应用为微信APP，微信APP当前持有第一窗口6901的音频焦点1；display模块2的ID与桌面的包名对应，即第二窗口6902中的音频焦点应用为桌面，桌面当前持有第二窗口6902中的音频焦点2。后续，如果用户在第二窗6902显示的桌面中打开其他应用，例如，如果检测到用户打开视频APP的操作，则视频APP可调用requestAudioFocus()接口向窗口管理器申请获取第二窗口6902的音频焦点2。窗口管理器响应视频APP的申请可将表15中与display模块2的ID对应的应用包名修改为视频APP包名，使得第二窗口6902中的桌面释放音频焦点2，同时使得第二窗口6902中的视频APP获得音频焦点2。
表15
Display ID 音频焦点应用的包名
display模块1的ID 微信APP的包名
display模块2的ID 桌面的包名
这样，窗口管理器通过记录与每个display模块对应的音频焦点应用，可以确定出与当前每个窗口对应的具体应用。在一些实施例中，一个窗口中也可以运行多个应用。例如，可以以窗口为粒度在每个窗口中设置前台应用和后台应用。例如，可在第一窗口6901的前台运行微信APP，在第一窗口6901的后台运行音乐APP。又例如，可在第二窗口6902的前台运行视频APP，在第二窗口6902的后台运行运动APP。此时，如表16所示，与display模块1对应的应用包括微信APP和音乐APP；与display模块2对应的应用包括视频APP和运动APP。
表16
Display ID 前台应用和/或后台应用的包名
display模块1的ID 微信APP的包名、音乐APP的包名
display模块2的ID 视频APP的包名、运动APP的包名
在本申请实施例中，可以将表15或表16所示的display模块与应用之间的对应关系称为各个窗口的应用信息，窗口管理器可用于记录并维护各个窗口的应用信息，使得手机可以根据该应用信息确定各个窗口中运行的具体应用有哪些。
手机进入分屏模式后，窗口管理器还可以以窗口为粒度为每个窗口设置对应的音频输出设备。示例性的，手机可以与一个或多个音频输出设备相连，即手机的从设备可以有一个或多个。例如，手机可以与蓝牙耳机建立蓝牙连接，并且，手机还可以通过Wi-Fi网络与音箱和电视建立网络连接，同时，手机自身的扬声器也可作为音频输出设备播放音频。
仍如图68所示的音频架构，手机中的DV APP与每个从设备建立网络连接后，可在音频策略模块中注册该从设备，例如，注册从设备的标识、设备名称、设备型号或设备类型等。那么，手机的音频管理器在音频策略模块中可以查询到当前手机可用的 音频输出设备具体有哪些。
以第一窗口6901中的音频焦点应用为微信APP，第二窗口6902中的音频焦点应用为视频APP举例，手机进入分屏模式后，音频管理器可在音频策略模块中查询当前手机可用的一个或多个音频输出设备，并将查询到的音频输出设备通知给窗口管理器。进而，如图71所示，窗口管理器可在运行微信APP的第一窗口6901中显示第一对话框7101，第一对话框7101中包括当前手机可用的一个或多个音频输出设备；并且，窗口管理器可在运行视频APP的第二窗口6902中显示第二对话框7102，第二对话框7102中也包括当前手机可用的一个或多个音频输出设备。这样，用户可以在第一对话框7101中选择与第一窗口6901关联的音频输出设备，并且，用户可以在第二对话框7102中选择与第二窗口6902关联的音频输出设备。
示例性的，如果检测到用户在第一对话框7101中选择蓝牙耳机，说明用户希望第一窗口6901中音频任务输出的音频数据由蓝牙耳机播放，则如表17所示，窗口管理器可建立display模块1与蓝牙耳机之间的关联关系，即第一窗口6901与蓝牙耳机关联；如果检测到用户在第二对话框7102中选择音箱，说明用户希望第二窗口6902中音频任务输出的音频数据由音箱播放，则如表17所示，窗口管理器可建立display模块2与音箱之间的关联关系，即第二窗口6902与音箱关联。这样，如表17所示，窗口管理器可以建立并维护分屏模式下不同窗口与不同音频输出设备之间的对应关系。
表17
Display ID 音频输出设备
display模块1的ID 蓝牙耳机
display模块2的ID 音箱
在一些实施例中，窗口管理器除了可以为每个窗口设置对应的音频输出设备外，还可以进一步设置对应的音频输出设备允许播放的音频数据的类型。示例性的，在安卓系统中，可按照具体的业务功能将音频数据的类型划分为：ALARM(警报)、MUSIC(音乐)、RING(铃声)、SYSTEM(系统)、NOTIFICATION(通知)、DTMF(双音多频)、COMMUNICATION(通信)以及VOICE_CALL(通话)等类型。
例如，如表18所示，窗口管理器可设置与第一窗口6901关联的音频输出设备为蓝牙耳机，并且，窗口管理器可设置该蓝牙耳机允许播放MUSIC(音乐)类型和NOTIFICATION(通知)类型的音频数据，不允许播放RING(铃声)类型的音频数据。这样，当第一窗口6901中产生MUSIC(音乐)类型或NOTIFICATION(通知)类型类型的音频数据时，该音频数据可被输出至蓝牙耳机播放。而当第一窗口6901中产生RING(铃声)类型类型的音频数据时，该音频数据不会被输出至蓝牙耳机中播放，从而在用户使用蓝牙耳机时为用户过滤掉RING(铃声)类型类型的音频数据。当然，窗口管理器也可以默认设置与第一窗口6901关联的音频输出设备允许播放所有类型的音频数据，本申请实施例对此不做任何限制。
表18
Figure PCTCN2021104105-appb-000016
Figure PCTCN2021104105-appb-000017
或者，窗口管理器也可以在表18中仅设置音频输出设备允许播放的音频数据的类型，此时其他类型的音频数据为音频输出设备不允许播放的音频数据；或者，窗口管理器也可以在表18中仅设置音频输出设备不允许播放的音频数据的类型，此时其他类型的音频数据为音频输出设备允许播放的音频数据。
在一些实施例中，用户也可以手动修改与各个窗口关联的音频输出设备，以及该音频输出设备允许或不允许播放的音频数据的类型。示例性的，如图72中的(a)所示，手机可以在第一窗口6901中显示第一设置按钮7201。例如，第一设置按钮7201可以为悬浮按钮。如果检测到用户点击第一设置按钮7201，则如图72中的(b)所示，手机可显示第一设置菜单7202。在第一设置菜单7202中，用户可以重新设置与第一窗口6901关联的音频输出设备。并且，在第一设置菜单7202中，用户还可以设置与当前窗口关联的音频输出设备允许或不允许播放的音频数据的类型。
类似的，如图73中的(a)所示，手机也可以在第二窗口6902中显示第二设置按钮7301。如果检测到用户点击第二设置按钮7301，则如图73中的(b)所示，手机可显示第二设置菜单7302。在第二设置菜单7302中，用户可以重新设置与第二窗口6902关联的音频输出设备。并且，在第二设置菜单7302中，用户还可以设置与当前窗口关联的音频输出设备允许或不允许播放的音频数据的类型。
进而，窗口管理器可根据用户在第一设置菜单7202或第二设置菜单7302中的选择更新表18中不同窗口、音频输出设备以及允许或不允许播放的音频数据类型之间的对应关系。这样，用户可以按照自身的需要以窗口为粒度设置各个窗口的音频输出设备，以及在音频输出设备上输出的具体音频数据，使各个窗口中的音频数据能够按照用户的设置被手机分发到相应的音频输出设备上播放。
在一些实施例中，窗口管理器还可以进一步对设置每个窗口中对应的各类音频数据播放时的音量大小。示例性的，如表19所示，与display模块1(即第一窗口6901)对应的音频输出设备为蓝牙耳机，蓝牙耳机允许播放MUSIC(音乐)类型和NOTIFICATION(通知)类型的音频数据。其中，播放MUSIC(音乐)类型的音频数据时的音量等级为15级，播放NOTIFICATION(通知)类型的音频数据时的音量等级为10级。与display模块2(即第二窗口6902)对应的音频输出设备为音箱，音箱允许播放MUSIC(音乐)类型、RING(铃声)类型以及NOTIFICATION(通知)类型的音频数据。其中，播放MUSIC(音乐)类型的音频数据时的音量等级为12级，播放RING(铃声)类型的音频数据时的音量等级为8级，播放NOTIFICATION(通 知)类型的音频数据时的音量等级为6级。
表19
Figure PCTCN2021104105-appb-000018
示例性的，用户可以手动修改每个窗口中对应的各类音频数据播放时的音量大小。如图74所示，手机在第一窗口6901中运行微信APP时，如果接收到联系人Sara发送的新消息，则微信APP可产生NOTIFICATION(通知)类型的通知提示音。如果此时用户希望调节第一窗口6901中通知提示音的音量大小，用户可通过预设的手势触发手机在第一窗口6901中显示音量调节条7401。这样，用户可以通过调节音量调节条7401上滑块的位置调整第一窗口6901中通知提示音的音量大小。此时，窗口管理器可以根据音量调节条7401上滑块的位置修改表19中与display模块1对应的NOTIFICATION(通知)类型的音频数据的音量等级。
类似的，当第一窗口6901中播放MUSIC(音乐)类型的音频数据时，用户也可以通过第一窗口6901中的音量调节条7401，触发窗口管理器修改与display模块1对应的MUSIC(音乐)类型的音频数据的音量等级。另外，当第一窗口6901中没有任何音频任务正在播放时，如果检测到用户调节音量调节条7401中滑块的位置，则窗口管理器可默认修改与display模块1对应的某一类型(例如MUSIC类型)的音频数据的音量等级。或者，第一窗口6901中有多种类型的音频数据同时播放时，窗口管理器也可默认修改与display模块1对应的某一类型的音频数据的音量等级。
类似的，仍如图74所示，手机在第二窗口6902中运行视频APP时，也可以在第二窗口6902中显示音量调节条7402。由于视频APP运行时产生的音频数据为MUSIC(音乐)类型的音频数据，那么，如果手机检测到用户调节音量调节条7402上的滑块，则窗口管理器可以根据音量调节条7402上滑块的位置修改表19中与display模块2对应的MUSIC(音乐)类型的音频数据的音量等级。
同样，如果第二窗口6902中正在播放RING(铃声)类型的音频数据，则用户也可以通过第二窗口6902中的音量调节条7402，触发窗口管理器修改与display模块2对应的RING(铃声)类型的音频数据的音量等级。如果第二窗口6902中正在播放NOTIFICATION(通知)类型的音频数据，则用户也可以通过第二窗口6902中的音量调节条7402，触发窗口管理器修改与display模块2对应的NOTIFICATION(通知)类型的音频数据的音量等级。如果第二窗口6902中没有任何音频任务正在播放，此时如果检测到用户调节音量调节条7402中滑块的位置，则窗口管理器可默认修改与 display模块2对应的某一类型(例如MUSIC类型)的音频数据的音量等级。或者，第二窗口6902中有多种类型的音频数据同时播放时，窗口管理器也可默认修改与display模块2对应的某一类型的音频数据的音量等级。
当然，手机也可以在上述第一设置菜单7202或第二设置菜单7302中设置修改各类音频数据的音量大小的选项，使用户可以手动设置各类音频数据在不同窗口和不同音频输出设备上播放时的音量大小，本申请实施例对此不做任何限制。
在本申请实施例中，可以将上述表17至表19所示的包含不同窗口与不同音频输出设备之间关联关系的具体音频配置内容称为各个窗口的音频配置信息。例如，第一窗口6901(即display模块1)的音频配置信息包括关联的音频输出设备，还可以进一步包括该音频输出设备允许和/或不允许播放的音频数据的类型，以及允许播放的音频数据的音量等级等。
也就是说，在分屏模式下，窗口管理器可以建立并维护各个窗口的应用信息(例如表15或表16所示的不同display模块与对应应用之间的对应关系)，并且，窗口管理器可以建立并维护各个窗口的音频配置信息(例如表17至表19中任一项所示的音频配置信息)。这样，当手机中不同窗口内的应用创建了相应的音频任务后，手机可以按照上述各个窗口的应用信息和音频配置信息，以窗口为粒度管理与各个窗口对应的音频数据，使各个窗口中音频任务输出的音频数据之间不会互相干扰。
示例性的，如图75所示，在分屏模式下，窗口管理器可将上述各个窗口的应用信息和音频配置信息发送至音频管理器，例如，发送至音频管理器的音频策略模块(例如AudioPolicy)。并且，当窗口管理器检测到某个窗口的应用信息或者音频配置信息发生变化后，窗口管理器可动态更新该窗口的应用信息或者音频配置信息，并将最新的各个窗口的应用信息和音频配置信息发送至AudioPolicy。
仍以第一窗口6901中的音频焦点应用为微信APP，第二窗口6902中的音频焦点应用为视频APP举例，如果检测到用户点击第二窗口6902中视频APP的播放按钮，则视频APP一方面可创建播放视频中音频数据的音频任务1，另一方面可创建播放视频中显示数据的显示任务1。
仍如图75所示，对于显示任务1，视频APP可将相关的绘图指令(图75中来自视频APP的虚线箭头)下发至窗口管理器，由于窗口管理器在创建display模块2的时候已经建立了display模块2与第二窗口6902之间的对应关系，因此，窗口管理器接收到第二窗口6902中来自视频APP下发的绘图指令后，可在对应的display模块2中按照视频APP下发的绘制指令绘制视频APP的显示数据1。
对于音频任务1，视频APP可创建对应的音频播放器1(例如AudioTrack 1)，并将视频APP待播放的音频数据1发送至AudioTrack 1中。AudioTrack 1可将来自视频APP的音频数据1发送至音频处理器(例如AudioFlinger)，由AudioFlinger对音频数据1进行采样、添加音效等处理。
在本申请实施例中，如图75所示，AudioFlinger接收到音频数据1后，可向AudioPolicy发送查询请求，请求AudioPolicy查询音频数据1具体的音频输出设备。例如，视频APP在创建AudioTrack 1时可将AudioTrack 1与视频APP关联，例如，建立AudioTrack 1与视频APP的包名之间的对应关系。AudioFlinger接收到音频数据 1时可根据上述对应关系确定接收到的音频数据1是来自视频APP的视频数据。进而，AudioFlinger可将视频APP的包名携带在上述查询请求中发送至AudioPolicy。
AudioPolicy接收到AudioFlinger发送的查询请求后，可根据查询请求中视频APP的包名查询视频APP具体在哪个窗口中运行。例如，如表15所示，如果视频APP的包名与display模块2的ID对应，说明视频APP为当前运行在第二窗口6902中的音频焦点应用，即视频APP持有第二窗口6902中的音频焦点2，具有播放音频数据的播放权限。进而，AudioPolicy可根据窗口管理器下发的各个窗口的音频配置信息，确定与display模块2对应的音频输出设备。
在一些实施例中，视频APP在创建的AudioTrack 1也可以与视频APP的进程ID关联。视频APP运行时可能会创建多个进程，即视频APP可与多个进程ID对应，每个进程中创建的音频任务可与对应的AudioTrack对应。那么，窗口管理器可将窗口、音频焦点应用以及音频焦点应用中不同进程ID之间的对应关系的发送给AudioPolicy。这样，AudioPolicy根据与AudioTrack 1关联的进程ID也可以确定出音频数据1为来自视频APP的音频数据。进而，AudioPolicy可按照上述方法查询视频APP具体在哪个窗口中运行，即与视频APP对应的display模块。
以表17所示的各个窗口的音频配置信息举例，AudioPolicy确定出来自视频APP的音频数据1与display模块2对应后，AudioPolicy根据表17所示的音频配置信息可确定与display模块2对应的音频输出设备为音箱。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息用于指示AudioFlinger将处理后的音频数据1通过DMSDP Audio HAL发送给音箱播放。
再以表18所示的各个窗口的音频配置信息举例，AudioFlinger向AudioPolicy发送的查询请求中还可以携带音频数据1的类型标识，例如，音频数据1为MUSIC(音乐)类型的音频数据。进而，AudioPolicy确定出音频数据1与display模块2对应后，AudioPolicy根据表18所示的音频配置信息可确定与display模块2对应的音频输出设备为音箱。并且，AudioPolicy根据表18所示的音频配置信息可确定音箱允许播放MUSIC(音乐)类型的音频数据，即音箱允许播放上述音频数据1。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息用于指示AudioFlinger将处理后的音频数据1通过DMSDP Audio HAL发送给音箱播放。
在一些实施例中，如果音频数据1的音频输出设备为音箱，但音箱不允许播放音频数据1这一类型的音频数据，则AudioPolicy可重新确定音频数据1的音频输出设备。例如，AudioPolicy可默认使用本机的扬声器作为音频输出设备播放音频数据1。或者，AudioPolicy可将除音箱之外最近接入手机的音频输出设备作为音频数据1的音频输出设备。当然，AudioPolicy也可以确定音频数据1的音频输出设备为空，即不使用任何音频输出设备播放音频数据1，本申请实施例对此不做任何限制。
再以表19所示的各个窗口的音频配置信息举例，AudioPolicy确定出来自视频APP的音频数据1与display模块2对应后，AudioPolicy根据表19所示的音频配置信息可确定与display模块2对应的音频输出设备为音箱。并且，AudioPolicy根据表19所示的音频配置信息可确定音箱允许播放MUSIC(音乐)类型的音频数据，且播放时的音量等级为12级。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息中 不仅可向AudioFlinger指示将处理后的音频数据1通过DMSDP Audio HAL发送给音箱播放，还用于指示音频数据1的音量等级为12级。这样，AudioFlinger响应于该指示消息，可按照12级的音量等级放大或缩小音频数据1中音频信号的增益，并将输出的音频数据1通过DMSDP Audio HAL发送给音箱播放。
在一些实施例中，在分屏模式下可能会出现多窗口中的多音频任务并发播放的场景。例如，如图76所示，在第二窗口6902中的视频APP创建了上述音频任务1播放视频的同时，如果用户在第一窗口6901中点击微信APP中的语音消息7601，则微信APP一方面可创建播放语音消息7601的音频任务2，另一方面可创建显示微信APP中应用界面的显示任务2。
与上述显示任务1类似的，仍如图75所示，对于显示任务2，微信APP可将相关的绘图指令(如图75中来自微信APP的虚线箭头)下发至窗口管理器。由于窗口管理器在创建display模块1的时候已经建立了display模块1与第一窗口6901之间的对应关系，因此，窗口管理器接收到第一窗口6901中微信APP下发的绘图指令后，窗口管理器可在对应的display模块1中按照微信APP下发的绘制指令绘制与微信APP的应用界面对应的显示数据2。
示例性的，仍能够如图75所示，HAL中的Display HAL可按照一定的帧率周期性的从display模块1和display模块2中获取对应的显示数据。以Display HAL从display模块1中获取到上述显示数据2，在display模块2中获取到上述显示数据1举例，
Display HAL可将显示数据1和显示数据2合成为与手机显示屏对应的显示数据3。进而，Display HAL可将显示数据3发送至手机的显示屏进行显示，使得显示屏可显示出如图76所示的第一窗口6901和第二窗口6902。
对于上述音频任务2，仍如图75所示，与上述音频任务1类似的，微信APP可创建对应的音频播放器2(例如AudioTrack 2)，并将微信APP中待播放的语音消息7601的音频数据(即音频数据2)发送至AudioTrack 2中。AudioTrack 2可将来自微信APP的音频数据2发送至音频处理器(例如AudioFlinger)，由AudioFlinger对音频数据2进行采样、添加音效等处理。
同样，AudioFlinger接收到音频数据2后，可将微信APP的包名携带在查询请求中向AudioPolicy发送该查询请求，请求AudioPolicy查询音频数据2具体的音频输出设备。AudioPolicy接收到AudioFlinger发送的查询请求后，可根据查询请求中微信APP的包名，查询微信APP具体在哪个窗口中运行。例如，如表16所示，如果微信APP的包名与display模块1的ID对应，说明微信APP为当前运行在第一窗口6901中。进而，AudioPolicy可根据窗口管理器下发的各个窗口的音频配置信息，确定与display模块1对应的音频输出设备。
以表17所示的各个窗口的音频配置信息举例，AudioPolicy根据表17所示的音频配置信息可确定与display模块1对应的音频输出设备为蓝牙耳机。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息用于指示AudioFlinger将处理后的音频数据2通过DMSDP Audio HAL发送给蓝牙耳机播放。
再以表18所示的各个窗口的音频配置信息举例，AudioFlinger向AudioPolicy发送的查询请求中还可以携带音频数据2的类型标识，例如，音频数据2为MUSIC(音 乐)类型的音频数据。进而，AudioPolicy根据表18所示的音频配置信息可确定与display模块1对应的音频输出设备为蓝牙耳机。并且，AudioPolicy根据表18所示的音频配置信息可确定蓝牙耳机允许播放MUSIC(音乐)类型的音频数据，即蓝牙耳机允许播放上述音频数据2。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息用于指示AudioFlinger将处理后的音频数据2通过A2dp HAL发送给蓝牙耳机播放。
再以表19所示的各个窗口的音频配置信息举例，AudioPolicy根据表19所示的音频配置信息可确定与display模块1对应的音频输出设备为蓝牙耳机。并且，AudioPolicy根据表19所示的音频配置信息可确定蓝牙耳机允许播放MUSIC(音乐)类型的音频数据，且播放时的音量等级为15级。进而，AudioPolicy可向AudioFlinger发送指示消息，该指示消息中不仅可向AudioFlinger指示将处理后的音频数据2通过A2dp HAL发送给蓝牙耳机播放，还用于指示音频数据2的音量等级为15级。这样，AudioFlinger响应于该指示消息，可按照15级的音量等级放大或缩小音频数据2中音频信号的增益，并将输出的音频数据2通过A2dp HAL发送给蓝牙耳机播放。
也就是说，当第一窗口6901中的音频任务与第二窗口6902中的音频任务并发播放时，AudioPolicy可根据窗口管理器下发的各个窗口的应用信息和音频配置信息，以窗口为粒度将第一窗口6901中音频任务输出的音频数据发送至第一音频输出设备(例如上述蓝牙耳机)中播放，并将第二窗口6902中音频任务输出的音频数据发送至第二音频输出设备(例如上述音箱)中播放。这样，用户A可使用第一音频输出设备收听来自第一窗口6901的音频数据，用户B可使用第二音频输出设备收听来自第二窗口6902的音频数据，使各个窗口之间输出的音频数据不会互相干扰，从而提高用户的音频使用体验。
另外，在上述音频任务1和音频任务2并发播放的场景下，如果AudioPolicy接收到窗口管理器最新下发的各个窗口的音频配置信息，则AudioPolicy可按照上述方法根据最新的各个窗口的音频配置信息重新确定不同窗口中音频数据的音频输出设备、音量大小等信息，从而指示AudioFlinger将与每个窗口对应的音频数据输出至最新的音频输出设备中播放，本申请实施例对此不再赘述。
在另一些实施例中，仍以上述音频任务1和音频任务2举例，如图77所示，第二窗口6902中的视频APP创建了音频任务1后，可在应用程序框架层中创建与音频任务1对应的AudioTrack 1。并且，第一窗口6901中的微信APP创建了音频任务2后，可在应用程序框架层中创建与音频任务2对应的AudioTrack 2。与上述实施例不同的是，窗口管理器可将上述各个窗口的应用信息和音频配置信息发送至AudioTrack 1和AudioTrack 2，无需将各个窗口的应用信息和音频配置信息发送至AudioPolicy。
这样，如图77所示，AudioTrack 1根据上述应用信息可确定自身接收到的音频数据与display模块1对应。进而，AudioTrack 1根据上述音频配置信息可确定与display模块1关联的音频输出设备为音箱，即自身接收到的音频数据需要输出至音箱中播放。那么，后续AudioTrack 1接收到来自视频APP的音频数据1后，可将音频数据1发送给AudioFlinger进行采样等处理，同时，AudioTrack 1可指示AudioFlinger将处理后的音频数据1通过DMSDP Audio HAL发送给音箱播放。
类似的，如图77所示，AudioTrack 2根据上述应用信息可确定自身接收到的音频 数据与display模块2对应。进而，AudioTrack 2根据上述音频配置信息可确定与display模块2关联的音频输出设备为蓝牙耳机，即自身接收到的音频数据需要输出至蓝牙耳机中播放。那么，后续AudioTrack 2接收到来自微信APP的音频数据2后，可将音频数据2发送给AudioFlinger进行采样等处理，同时，AudioTrack 1可指示AudioFlinger将处理后的音频数据2通过A2dp HAL发送给蓝牙耳机播放。
与上述实施例类似的，如果用户修改了某个窗口中的音频焦点应用，则窗口管理器可响应用户的修改将最新的应用信息发送给当前的多个AudioTrack。或者，如果用户修改了某个窗口关联的音频输出设备、音频数据的音量大小等，则窗口管理器可响应用户的修改将最新的音频配置信息发送给当前的多个AudioTrack。这样，每个AudioTrack可按照上述方法根据最新的应用信息和音频配置信息重新确定不同窗口中音频数据的音频输出设备、音量大小等信息，从而指示AudioFlinger将与每个窗口对应的音频数据输出至最新的音频输出设备中播放，本申请实施例对此不再赘述。
在另一些实施例中，手机进入分屏模式后，还可以通过投屏功能将手机显示屏中的各个窗口投射至其他电子设备中显示。
示例性的，如图78所示，手机进入分屏模式后，在第一窗口6901中运行微信APP，并且，在第二窗口6902中运行视频APP。如果用户需要使用投屏功能，用户可在打开手机的控制中心7801。控制中心7801中可设置卡片7802，卡片7802用于展示手机检测到的附近的一个或多个可进行投屏的候选设备。如果检测到用户在卡片7802中选中某一电子设备(例如电视)，说明用户希望开启投屏功能，将手机中的显示数据投射至电视显示，即手机此时的显示输出设备为电视。
在一种可能的实现方式中，如图79所示，响应于用户在卡片7802中选中电视的操作，窗口管理器可指示Display HAL实时的将display模块1中的显示数据1和display模块2中的显示数据2合成对应的显示数据3。进而，Display HAL可实时的将显示数据3发送至电视进行显示，使得电视可显示出手机在分屏模式下的第一窗口6901和第二窗口6902。当然，Display HAL也可以实时的将显示数据3发送至手机的显示屏中显示，此时，手机与电视可同步显示上述第一窗口6901和第二窗口6902。
另外，如果用户在卡片1702中选中电视时手机与电视还未建立网络连接，则手机可先与电视建立网络连接，再通过Display HAL向电视实时的发送上述显示数据3。
此时，第一窗口6901中微信APP产生的音频数据以及第二窗口6902中视频APP产生的音频数据仍然可以由AudioFlinger按照AudioPolicy的指示发送至不同的音频输出设备中播放。例如，可将视频APP产生的音频数据1通过DMSDP Audio HAL发送至音箱播放，将微信APP产生的音频数据2通过A2dp HAL发送给蓝牙耳机播放。也就是说，在分屏模式的投屏场景下，可由主设备分别控制显示数据和音频数据的分发过程，由主设备将不同窗口中的音频数据分发至相应的音频输出设备中播放。
在另一种可能的实现方式中，如图80所示，响应于用户在卡片7802中选中电视的操作，手机不仅可以通过Display HAL实时的将包含第一窗口6901和第二窗口6902的显示数据3发送至电视进行显示，手机还可以通过DMSDP Audio HAL将来自第一窗口6901的音频数据1以及来自第二窗口6902的音频数据2实时的发送给电视。并且，仍如图80所示，手机中的AudioPolicy还可以将窗口管理器下发的各个窗口的应 用信息和音频配置信息发送至电视。
示例性的，如图80所示，电视的应用程序层中可以安装代理APP，代理APP用于接收手机发来的显示数据和音频数据，例如，显示数据可以为上述显示数据3，音频数据可以为上述音频数据1和音频数据2。并且，与手机的显示架构和音频架构类似的，电视的应用程序框架层也可以包括窗口管理器、音频策略模块(例如AudioPolicy)以及音频处理器(例如AudioFlinger)等。代理APP接收到上述显示数据3后，可调用窗口管理器将显示数据3通过电视的Display HAL发送给电视的显示屏进行显示。
如图80所示，电视的代理APP还用于接收手机发送的各个窗口的应用信息和音频配置信息后，进而，代理APP可将该应用信息和音频配置信息发送至电视的
AudioPolicy。并且，电视的代理APP接收到手机发送的音频数据1和音频数据2后，可创建AudioTrack 1用于播放音频数据1，并创建AudioTrack 2用于播放音频数据2。进而，AudioTrack 1可将接收到的音频数据1发送至电视的AudioFlinger进行采样等处理，同样，AudioTrack 2可将接收到的音频数据2发送至电视的AudioFlinger进行采样等处理。
与手机中AudioFlinger与AudioPolicy的交互过程类似的，电视的AudioFlinger接收到上述音频数据1和音频数据2后，也可以向电视的AudioPolicy发送查询请求，请求AudioPolicy查询音频数据1和音频数据2具体的音频输出设备。AudioPolicy可响应该查询请求，按照各个窗口的应用信息和音频配置信息确定音频数据1的音频输出设备为音箱、音频数据2的音频输出设备为蓝牙耳机。进而，电视的AudioPolicy可指示其AudioFlinger将音频数据1通过DMSDP Audio HAL发送给音箱播放，并指示AudioFlinger将音频数据2通过A2dp HAL发送给蓝牙耳机播放。其中，电视中AudioPolicy与AudioFlinger的交互过程与手机中AudioPolicy与AudioFlinger的交互过程类似，故此处不再赘述。
可以看出，在分屏模式的投屏场景下，手机(即主设备)可将各个窗口中产生的显示数据和音频数据均发送给电视(即从设备)。并且，手机可将各个窗口的应用信息和音频配置信息一并发送给电视，使得电视可按照该应用信息和音频配置信息将手机中不同窗口的音频数据分发至相应的音频输出设备中播放，实现多窗口之间音频数据互不干扰的隔离效果。
在一些实施例中，当手机在分屏模式下向电视投屏时，用户也可以更改与每个窗口关联的音频输出设备。示例性的，如图81所示，在手机将第一窗口6901和第二窗口6902投射至电视中显示的过程中，如果检测到用户对第一窗口6901执行预设的手势(例如长按第一窗口6901)，则手机可显示第一设备列表8101，用户可以在第一设备列表8101中选择与第一窗口6901关联的音频输出设备。类似的，如果检测到用户对第二窗口6902执行预设的手势(例如长按第二窗口6902)，则手机可显示第二设备列表8102，用户可以在第二设备列表8102中选择与第二窗口6902关联的音频输出设备。
例如，第一设备列表8101(或第二设备列表8102)中的电视设备可以是与手机相连的具有音频输出功能的一个或多个电视设备。或者，第一设备列表8101(或第二设备列表8102)中的电视设备可以是与电视相连的具有音频输出功能的一个或多个电视 设备，本申请实施例对此不做任何限制。
手机中的窗口管理器可根据用户在上述第一设备列表8101(或第二设备列表8102)中的选择更新各个窗口的音频配置信息，并将更新后的音频配置信息发送给手机的AudioPolicy。进而，手机的AudioPolicy可将更新后的音频配置信息发送给电视，由电视的代理APP将接收到的更新后的音频配置信息发送给电视的AudioPolicy，使电视的AudioPolicy能够实时获取到最新的音频配置信息。这样，电视可根据最新的音频配置信息将来自不同窗口的音频数据分发给对应的音频输出设备播放。
另外，如果电视检测到音频配置信息中与某一窗口关联的音频输出设备没有与电视建立网络连接，则电视可先与该音频输出设备建立网络连接，再将来自该窗口的音频数据通过已建立的网络连接发送给该音频输出设备。
上述实施例中是以手机中显示多个窗口进行多音频任务并发播放的应用场景举例说明的，在一些实施例中，手机也可以隐藏显示屏中显示的一个或多个窗口。例如，手机可以应用为粒度进行投屏，如图82所示，手机在向电视投屏某一应用(例如视频APP)时，窗口管理器可创建display模块1，并将视频APP产生的显示数据1绘制在display模块1中，即display模块1与电视对应。手机的Display HAL可实时的从display模块1中获取显示数据1，并将显示数据1发送至电视进行显示。不同的是，Display HAL不需要将显示数据1发送至手机的显示屏显示，即手机可在显示屏中隐藏与display模块1对应的窗口。
与此同时，用户可在手机中运行其他的应用，并显示该应用的应用界面。例如，用户在手机中打开微信APP后，微信APP可通过窗口管理器可创建display模块2。窗口管理器可将微信APP产生的显示数据2绘制在display模块2中，即display模块2与收手机自身的显示屏对应。进而，手机的Display HAL可实时的从display模块2中获取显示数据2，并将显示数据2发送至手机的显示屏进行显示。此时，手机将运行的视频APP投射至电视中显示，并且手机将运行的微信APP保留在自身的显示屏中显示。也就是说，手机在向电视投射某一应用时手机还可以正常工作，用户还可以在手机上运行其他的应用。
在这种场景下，与display模块1关联的音频输出设备为从设备(即电视)的音频输出设备，与display模块2关联的音频输出设备为主设备(即手机)的音频输出设备。与上述实施例类似的，仍如图82所示，视频APP通过创建AudioTrack 1可将产生的音频数据1发送至AudioFlinger，同时，微信APP通过创建AudioTrack 2可将产生的音频数据2发送至AudioFlinger。AudioPolicy中存储有最新的各个窗口的应用信息和音频配置信息。AudioFlinger通过与AudioPolicy交互可确定出音频数据1的音频输出设备为音箱，音频数据2的音频输出设备为蓝牙耳机。进而，AudioFlinger通过DMSDP Audio HAL可将音频数据1发送至音箱播放，并且，AudioFlinger通过A2dp HAL可将音频数据2发送至蓝牙耳机播放。
也就是说，当手机进行分屏模式后，可通过不同display模块向不同的显示输出设备(包括手机自身)提供显示数据，并且，不同的显示输出设备可与不同的音频输出设备关联，手机可将与对应显示输出设备匹配的音频数据发送至关联的音频输出设备中播放。这样，各个显示输出设备中的显示数据不会互相干扰，各个显示输出设备中 的音频数据也不会互相干扰，从而提高用户的音频使用体验。
在分布式音频场景中，主设备可以具有录屏功能；主设备的从设备也可以具有录屏功能。主设备(例如上述手机)可以录制自身的第一屏幕数据，第一屏幕数据可以包括主设备播放的显示数据以及音频数据。并且，主设备可以从具有录屏功能的从设备(例如电视)中获取从设备录制的第二屏幕数据，第二屏幕数据可以包括从设备播放的显示数据以及音频数据。
当用户在主设备中开启录屏功能后，主设备不仅可以通过自身的录屏功能获取到第一屏幕数据，同时，主设备还可以向从设备发送录屏指令。从设备接收到该录屏指令后，如果从设备具有录屏功能，则从设备可响应该录屏指令录制从设备的第二屏幕数据。并且，从设备可将录制的第二屏幕数据实时发送给主设备。这样，主设备根据主设备的第一屏幕数据以及从设备的第二屏幕数据可以生成本次屏幕录制的录屏文件，该录屏文件既可以还原主设备录屏时播放的内容，还可以还原从设备录屏时播放的内容，从而更加全面的还原在主设备和从设备上实现的业务场景，提高用户在分布式系统中的使用体验。
以手机为主设备举例，手机可以在控制中心、负一屏菜单或下拉菜单等位置显示用于开启录屏功能的录屏按钮。例如，如图83所示，检测到用户打开手机中下拉菜单的操作后，手机可显示下拉菜单8301，下拉菜单8301中设置有录屏按钮8302。如果检测到用户点击录屏按钮8302，说明用户当前有使用录屏功能的需求，此时，手机可搜索当前与手机接入同一通信网络的一个或多个电子设备。例如，手机可以搜索与手机位于同一Wi-Fi网络中的一个或多个电子设备。又例如，手机可以在服务器中查询与手机登录同一账号(例如华为账号)的一个或多个电子设备。
进而，如图84所示，手机可将搜索到的一个或多个电子设备显示在设备列表8401中。或者，手机可在搜索到的一个或多个电子设备中选择具有显示功能的电子设备，并将具有显示功能的电子设备显示在设备列表8401中。又或者，手机在搜索当前与手机接入同一通信网络的一个或多个电子设备时，可查询搜索到的电子设备是否具有录屏功能。如果具有录屏功能，则手机可将该电子设备显示在设备列表8401中。当然，设备列表8401中也可以包括手机自身(即主设备)。用户可以在设备列表8401中选择本次录屏操作需要录制哪个或哪些设备的屏幕数据。示例性的，手机可默认用户需要录制手机自身的屏幕数据，此时，用户只需要在设备列表8401中选择希望与手机同时进行录屏的一个或多个电子设备。
示例性的，如果检测到用户在设备列表8401中选择电视8402，说明用户此时需要同时录制手机以及电视8402中播放的屏幕数据。那么，如图85所示，一方面，手机可以执行录屏操作，开始录制手机中播放的显示数据和音频数据，得到第一屏幕数据。另一方面，手机可将电视8402作为从设备，向电视8402发送录屏指令。电视8402响应于手机发来的录屏指令，也可以执行录屏操作，开始录制电视8402中播放的显示数据和音频数据，得到第二屏幕数据。并且，电视8402可将实时录制得到的第二屏幕数据发送给手机。手机可根据第一屏幕数据和第二屏幕数据生成本次录屏文件。
其中，主设备(例如上述手机)通过与从设备(例如上述电视8402)交互完成录屏操作的具体过程将在后续实施例中详细阐述，故此处不予赘述。
可以看出，在本申请实施例中，用户在录屏场景下可在主设备中选择同时录制主设备和从设备中的屏幕数据。主设备作为主控设备可向用户选择的从设备发送录屏指令，触发从设备录制从设备的屏幕数据，并且，主设备可同时录制主设备的屏幕数据。后续，主设备可根据两个设备录制得到的屏幕数据生成本次录屏文件，该录屏文件既可以还原主设备播放的内容，还可以还原从设备播放的内容，从而更加全面的记录和还原在主设备和从设备上实现的业务场景，提高用户在分布式系统中的使用体验。
基于图6所示的Android系统架构，如图86所示，应用程序层中可以包括具有录屏功能的录屏应用。应用程序框架层中可以包括MediaRecord、display模块、AudioRecord以及AudioFlinger。其中，display模块用于存储待播放的显示数据，并将待播放的显示数据实时输出至显示屏播放。AudioFlinger用于对来自应用的音频数据进行混音、重采样、音效设置等处理，并将处理后的音频数据通过HAL输出给相应的音频输出设备(例如扬声器、耳机等)。AudioRecord用于从AudioFlinger中获取相应的音频数据进行音频录制。录屏应用检测到用户打开录屏功能后，录屏应用可以调用MediaRecord开始本次屏幕录制过程。
示例性的，仍如图86所示，录屏应用可向MediaRecord发送录屏请求，例如，该录屏请求可以指示本次录制需要录制显示屏播放的显示数据以及扬声器播放的音频数据。进而，MediaRecord可响应上述录屏请求，从display模块实时获取显示屏播放的显示数据。并且，MediaRecord可调用AudioRecord，由AudioRecord从AudioFlinger实时获取当前扬声器播放的音频数据，并将获取到的音频数据发送给MediaRecord。后续，MediaRecord可将实时获取到的显示数据和音频数据合成为第一屏幕数据，第一屏幕数据可以还原出屏幕录制时手机正在播放的画面和音频。进而，MediaRecord可将第一屏幕数据发送给录屏应用。录屏应用可将得到的第一屏幕数据以录屏文件的形式保存在手机本地。或者，录屏应用也可将得到的第一屏幕数据实时发送给服务器或其他电子设备。
仍如图86所示，HAL中提供了与手机的不同硬件模块对应的HAL，例如，Audio HAL、Camera HAL、Wi-Fi HAL等。以Audio HAL举例，根据手机的音频输出设备的不同，Audio HAL又可以进一步划分为Primary HAL、Remote Submix HAL、A2dp HAL等。Primary HAL可与手机的麦克风对应，A2dp HAL可与手机连接的蓝牙耳机对应，Remote Submix HAL可与手机内播放的系统音对应。例如，AudioFlinger可调用Primary HAL获取手机的麦克风采集到的音频数据。又例如，AudioFlinger可调用A2dp HAL将音频数据输出至与手机相连的蓝牙耳机播放。又例如，AudioFlinger可调用Remote Submix HAL获取扬声器播放的系统音频。
在录屏场景下，如果录屏应用向MediaRecord发送的录屏请求指示录制手机的系统音频(即内录场景)，则AudioFlinger可实时从Remote Submix HAL中获取手机正在播放的音频数据，并将获取到的音频数据通过AudioRecord发送给MediaRecord。或者，如果录屏应用向MediaRecord发送的录屏请求指示录制手机麦克风采集的声音(即外录场景)，则AudioFlinger可实时从Primary HAL中获取手机的麦克风录制的音频数据，并将获取到的音频数据通过AudioRecord发送给MediaRecord。当然，录屏应用也可以指示MediaRecord同时录制手机自身正在播放的音频数据以及手机麦克风采集 的音频数据。AudioFlinger可将从Primary HAL获取的音频数据和从Remote Submix HAL获取的音频数据进行混音后通过AudioRecord发送给MediaRecord。
在一些实施例中，仍如图86所示，应用程序框架层还设置有Camera模块，Camera模块通过Camera HAL可获取到当前摄像头采集到的显示数据。示例性的，录屏应用向MediaRecord发送录屏请求还可以指示本次需要录制的显示数据为摄像头采集的显示数据。进而，MediaRecord可响应该录屏请求，从Camera模块实时获取对应的显示数据，并将该显示数据上报给MediaRecord，由MediaRecord将实时获取到的显示数据和音频数据合成为第一屏幕数据。
也就是说，手机在录屏时录制的第一屏幕数据可以包括手机显示屏中播放的显示数据、手机摄像头采集的显示数据、手机自身播放的音频数据或手机麦克风采集的音频数据中的至少一项，本申请实施例对此不做任何限制。
在本申请实施例中，手机与从设备建立网络连接后，手机可在HAL中创建与从设备对应的DMSDP HAL，DMSDP HAL与手机当前连接的从设备对应。手机可作为主控设备通过DMSDP HAL与从设备进行数据收发，将从设备作为手机的一个虚拟设备，与从设备协同完成分布式场景中的音频或显示等业务。
示例性的，用户开启手机中录屏应用提供的录屏功能时，录屏应用可向用户显示当前搜索到的可与手机同步进行录屏的电子设备。例如，录屏应用可将当前与手机登录同一账号的电子设备呈现给用户。以用户选中电子设备1举例，手机可将用户选中的电子设备1作为从设备与手机建立连接。例如，手机可与电子设备1建立WiFi P2P(peer-to-peer)连接或蓝牙连接。并且，如图87所示，手机可在HAL中创建与从设备对应的DMSDP HAL，即此时的DMSDP HAL与电子设备1对应。
在本申请实施例中，仍如图87所示，应用程序框架层内可以设置屏幕录制器，该屏幕录制器不仅可以兼容MediaRecord的功能录制手机自身的第一屏幕数据，还可以指示手机的从设备录制从设备的第二屏幕数据。进而，屏幕录制器可根据第一屏幕数据和第二屏幕数据生成对应的录屏文件，实现手机与从设备同步录屏的功能。
示例性的，屏幕录制器可以通过上述DMSDP HAL获取电子设备1的录屏能力参数。其中，该录屏能力参数可以包括从设备录屏时支持的显示能力参数和音频能力参数。例如，显示能力参数具体可以包括从设备的分辨率、DPI(Dots Per Inch，每英寸点数)等用于录制显示数据的能力参数；音频能力参数具体可以包括从设备对音频数据的采样率、是否具有录制系统音的能力或是否具有使用麦克风采集音频的能力等用于录制音频数据的能力参数。
并且，屏幕录制器可以获取到手机自身的录屏能力参数，即手机的显示能力参数和音频能力参数。进而，屏幕录制器可根据电子设备1的录屏能力参数和手机的录屏能力参数确定本次录屏时手机和电子设备1使用的录屏参数。与上述录屏能力参数对应的，该录屏参数中可以包括分辨率、DPI等显示录制参数，以及对音频数据的采样率、是否具有录制系统音的能力或是否具有使用麦克风采集音频的能力等音频录制参数。也就是说，主设备可根据从设备的录屏能力确定本次手机与从设备同步录屏时使用的录屏参数。
进而，仍如图87所示，屏幕录制器可将为电子设备1确定出的录屏参数发送给电 子设备1(即从设备)。例如，屏幕录制器可将电子设备1的标识以及录屏参数发送给DMSDP HAL，DMSDP HAL可根据电子设备1的标识向电子设备1发送录屏指令，录屏指令中包括上述录屏参数。这样，电子设备1接收到手机发来的录屏指令后，可根据录屏指令中的录屏参数开始录制电子设备1的屏幕数据。例如，电子设备1的屏幕数据可以包括电子设备1的显示屏正在播放的显示数据，电子设备1的摄像头正在采集的显示数据，电子设备1的扬声器正在播放的音频数据或电子设备1的麦克风正在采集的音频数据中的一项或多项。并且，在本次录屏结束前，电子设备1可将录制得到的屏幕数据(后续可称为第二屏幕数据)实时发送给屏幕录制器。
仍如图87所示，对于手机而言，屏幕录制器为手机确定出对应的录屏参数后，可按照该录屏参数开始录制手机的屏幕数据(后续可称为第一屏幕数据)。例如，第一屏幕数据可以包括手机的显示屏正在播放的显示数据，手机的摄像头正在采集的显示数据，手机的扬声器正在播放的音频数据或手机的麦克风正在采集的音频数据中的一项或多项。
这样，手机中的屏幕录制器在本次录屏过程中可以实时获取到手机录制的第一屏幕数据以及电子设备1录制的第二屏幕数据。后续，屏幕录制器可将第一屏幕数据和第二屏幕数据上报给录屏应用。录屏应用可以将接收到的第一屏幕数据和第二屏幕数据封装为一个录屏文件，或者，录屏应用也可以将接收到的第一屏幕数据和第二屏幕数据分别封装为两个录屏文件。当然，也可以由屏幕录制器将第一屏幕数据和第二屏幕数据封装为一个或多个录屏文件后上报给录屏应用。
另外，上述屏幕录制器或手机中的其他功能模块还可以对第一屏幕数据和/或第二屏幕数据进行解析、编解码、混音或添加音效等操作，本申请实施例对此不做任何限制。
可以看出，在上述录屏场景下，手机(即主设备)可以同步获取主设备录制的第一屏幕数据以及电子设备1(即从设备)录制的第二屏幕数据。那么，手机根据第一屏幕数据和第二屏幕数据生成的录屏文件既可以还原主设备播放的内容，还可以还原从设备播放的内容，从而更加全面的记录和还原在主设备和从设备上实现的业务场景，使得用户可以同时录制多个电子设备中的屏幕数据，从而提升用户在分布式系统中的录屏使用体验。
仍以手机为主设备举例，以下将结合附图具体阐述本申请实施例提供的一种录屏方法。
如图88中的(a)所示，以手机在下拉菜单8801中设置有录屏按钮8802举例。如果检测到用户点击录屏按钮8802，可触发手机获取当前与手机位于同一通信网络的一个或多个电子设备。例如，手机可搜索与手机接入同一Wi-Fi网络或登录同一账号的电子设备。进而，手机可在搜索到的电子设备中查询具有录屏功能的电子设备。例如，手机可向搜索到的电子设备发送请求消息，请求接收到该请求消息的电子设备上报自身是否具有录屏功能。
以电视1和平板电脑1具有录屏功能举例，如图88中的(b)所示，手机可将电视1和平板电脑1显示在对话框8803中。用户可以在对话框8803中选择本次与手机同步录屏的一个或多个从设备。也就是说，用户在手机(即主设备)中打开录屏功能 后，可选择一个或多个从设备与手机进行同步录屏。
在一些实施例中，手机也可以将手机本身作为一个选项显示在对话框8803中。此时，用户可以选择录制手机中的屏幕数据，也可以选择不录制手机中的屏幕数据。例如，用户可以选择同步录制电视1和平板电脑1中的屏幕数据，而不录制手机中的屏幕数据。当然，除了点击上述录屏按钮8802外，用户也可以通过向手机输入预设的手势或语音指令等方式打开手机与其他设备同步录屏的功能，本申请实施例对此不做任何限制。
以用户在对话框8803中选择电视1举例，检测到用户选择电视1后，如图89所示，手机可将电视1作为手机的从设备，触发录屏应用获取电视1的录屏能力参数(可称为第二录屏能力参数)。其中，第二录屏能力参数可包括电视1录屏时支持的显示能力参数和音频能力参数。例如，该显示能力参数可以包括电视1的分辨率或DPI等参数；该音频能力参数可以包括电视1的采样率、录制系统音的能力或使用麦克风采集音频的能力等参数。可以理解的是，电视1录屏时可能使用的参数均可作为上述第二录屏能力参数。例如，第二录屏能力参数还可以包括电视1支持的音频或图像编解码格式，电视1中摄像头的焦距、分辨率等参数，本申请实施例对此不做任何限制。
示例性的，电视1的第二录屏能力参数用于指示电视1的分辨率为1080*720，电视1的DPI为200，电视1的采样率为36KHz，电视1支持录制系统音频，不支持使用麦克风录制音频。电视1可将上述第二录屏能力参数发送至手机的DMSDP HAL，由DMSDP HAL将第二录屏能力参数发送给录屏应用。
仍如图89所示，录屏应用除了可以获取到电视1的第二录屏能力参数外，还可以获取手机自身的录屏能力参数(可称为第一录屏能力参数)。与第二录屏能力参数类似的，第一录屏能力参数可包括手机录屏时支持的显示能力参数和音频能力参数。例如，手机的第一录屏能力参数用于指示手机的分辨率为1920*1080，手机的DPI为300，手机的采样率为48KHz，手机支持录制系统音频，也支持使用麦克风录制音频。
进而，仍如图89所示，录屏应用可向应用程序框架层中的屏幕录制器1发送录屏请求1，该录屏请求1中可以包括上述第一录屏能力参数和第二录屏能力参数。响应于上述录屏请求1，屏幕录制器1可以根据第一录屏能力参数和第二录屏能力参数确定本次录屏使用的录屏参数。该录屏参数中可以包括与上述显示能力参数对应的显示录制参数，以及与上述音频能力参数对应的音频录制参数。其中，屏幕录制器1可向应用程序框架层中的应用(例如录屏应用)提供录屏接口，例如，名称为HwMediaProject的录屏接口。录屏应用通过调用HwMediaProject这一录屏接口可与屏幕录制器1交互。
例如，当手机的分辨率1920*1080大于电视1的分辨率1080*720时，屏幕录制器1可将本次录屏时的分辨率设置为1080*720(即电视1的分辨率)，以保证手机和电视1均能够完成本次录屏操作。
又例如，当手机的DPI 300大于电视1的DPI 200时，屏幕录制器1可将本次录屏时的DPI设置为200(即电视1的DPI)，以保证电视1和手机均能够完成本次录屏操作。
又例如，当手机对音频数据的采样率1大于电视1对音频数据的采样率2时，屏幕录制器1可将本次录屏时对音频数据的采样率设置为采样率2(即电视1的采样率)， 以保证电视1和手机均能够完成本次录屏操作。
又例如，电视1支持录制系统音频，不支持使用麦克风录制音频，而手机支持录制系统音频，也支持使用麦克风录制音频，那么，屏幕录制器1可设置电视1在本次录屏操作中录制系统音频，而手机在本次录屏操作中同时录制系统音频和麦克风音频。
这样，如表20所示，屏幕录制器1可根据上述第一录屏能力参数和第二录屏能力参数，确定出本次录屏操作中手机和电视1使用的录屏参数，该录屏参数包括显示录制参数和音频录制参数。该录屏参数同时满足手机(即主设备)和电视1(即从设备)的录屏能力，使得手机和电视1可按照确定出的录屏参数完成本次录屏操作。
表20
Figure PCTCN2021104105-appb-000019
在一些实施例中，屏幕录制器1还可以结合当前的网络状态确定上述录屏参数。例如，当手机与电视1之间的网络带宽小于预设值时，说明手机与电视1之间的网络状态不佳，此时，屏幕录制器1可将录屏参数中手机和电视1使用的分辨率设置为默认值，该默认值可以小于当前手机和电视1的分辨率。这样，电视1后续按照该分辨率在录屏时采集到的屏幕数据的数据量较小，可避免后续电视1与手机同步录屏时，由于带宽不足而导致电视1不能及时将录制的屏幕数据发送给手机的情况。
在一些实施例中，屏幕录制器1还可以结合当前的业务场景确定上述录屏参数。例如，当录屏应用为直播类型的应用时，由于直播业务对音频和画面的时延要求较高，因此，屏幕录制器1也可将录屏参数中手机和电视1使用的分辨率设置为上述默认值。这样，电视1后续按照该分辨率在录屏时采集到的屏幕数据的数据量较小，可避免后续电视1与手机同步录屏时由于数据量过高而导致手机与电视1录制的屏幕数据不同步的情况。
在一些实施例中，上述屏幕参数中的显示录制参数还可以包括显示数据的来源。显示数据的来源可以包括显示屏和/或摄像头。例如，当录屏应用为直播类型的应用时，屏幕录制器1可以设置手机录制的显示数据的来源为摄像头，而电视录制的显示数据的来源为显示屏。也就是说，在本次录屏操作中录屏应用可以同时录制手机上摄像头采集的显示数据以及电视1中显示屏播放的显示数据。
在另一些实施例中，用户也可以在本次录屏过程中手动设置或修改上述屏幕参数。例如，屏幕录制器1可以根据第一录屏能力参数和第二录屏能力参数确定出一项或多项可选的屏幕参数。屏幕录制器1通过录屏应用可向用户显示可选的屏幕参数，例如，是否开启麦克风录制、是否开启摄像头录制等，由用户手动设置上述屏幕参数。
如图90所示，录屏应用在录制过程中可以显示手机的录制控制栏9001以及电视1的录制控制栏9002。录制控制栏9001和录制控制栏9002中可以显示当前的录制时长等信息。
并且，当手机的第一录屏能力参数中指示手机支持麦克风录制音频数据，并支持 摄像头采集显示数据时，录屏应用可在录制控制栏9001中显示麦克风按钮9003和相机按钮9004。例如，用户通过点击麦克风按钮9003可以打开或关闭手机的麦克风，并且，屏幕录制器1可以根据用户对麦克风按钮9003的操作修改屏幕参数中手机使用的音频录制参数。又例如，用户通过点击相机按钮9004可以打开或关闭手机的摄像头，并且，屏幕录制器1可以根据用户对相机按钮9004的操作修改屏幕参数中手机使用的显示录制参数。
类似的，当电视1的第二录屏能力参数中指示电视1不支持麦克风录制音频数据，支持摄像头采集显示数据时，录屏应用可在录制控制栏9001中显示相机按钮9005。用户通过点击相机按钮9005可以打开或关闭电视1的摄像头，并且，屏幕录制器1可以根据用户对相机按钮9005的操作修改屏幕参数中电视1使用的显示录制参数。当然，在录制过程中，手机也可以指示电视1显示上述录制控制栏9001和/或录制控制栏9002，本申请实施例对此不做任何限制。
录屏应用检测到用户修改了手机或电视1使用的录屏参数后，可将最新的录屏参数发送给屏幕录制器1。后续，屏幕录制器1可按照最新的录屏参数控制手机和电视1进行同步录屏操作。
另外，上述实施例中是以屏幕录制器1根据第一录屏能力参数和第二录屏能力参数确定本次录屏操作中手机和电视1使用的录屏参数举例说明的，可以理解的是，录屏应用也可以按照上述实施例中的方法确定手机和电视1使用的录屏参数，进而，录屏应用可将确定出的录屏参数携带在录屏请求1中发送给屏幕录制器1，本申请实施例对此不做任何限制。
仍如图89所示，屏幕录制器1确定出手机和电视1使用的录屏参数后，一方面，屏幕录制器1可触发手机自身按照与手机对应的录屏参数执行录屏操作。另一方面，屏幕录制器1可将电视1使用的录屏参数发送至电视1，由电视1按照与电视1对应的录屏参数执行录屏操作。例如，屏幕录制器1可将电视1的标识，以及表20中与电视1对应的录屏参数通过AudioFlinger传递给DMSDP HAL，由DMSDP HAL根据电视1的标识向电视1发送录屏指令，该录屏指令中可以包括电视1使用的录屏参数。
并且，对于手机自身，屏幕录制器1可调用display模块，按照录屏参数中与手机对应的显示录制参数，从display模块中实时获取手机显示屏中正在播放的显示数据1。或者，如果显示录制参数中指示需要录制手机摄像头采集的显示数据，则屏幕录制器1可调用Camera模块，按照对应的显示录制参数从Camera模块中实时获取手机摄像头采集的显示数据。当然，屏幕录制器1也可以一边从display模块获取手机显示屏中正在播放的显示数据，一边从Camera模块中获取手机摄像头采集的显示数据，本申请实施例对此不做任何限制。
同时，屏幕录制器1可调用AudioRecord，按照录屏参数中与手机对应的音频录制参数，从AudioFlinger中实时获取手机的音频数据1。例如，如果音频录制参数中指示手机录制系统音频，则AudioFlinger可从Remote Submix HAL中获取手机正在播放的音频数据。这样，屏幕录制器1从AudioFlinger中获取到的音频数据1为手机的系统音频。又例如，如果音频录制参数中指示手机录制麦克风音频，则AudioFlinger可从Primary HAL中获取手机的麦克风录制的音频数据。这样，屏幕录制器1从 AudioFlinger中获取到的音频数据1为手机麦克风采集的音频。又或者，如果音频录制参数中指示手机录制系统音频以及麦克风音频，则AudioFlinger可将从Remote Submix HAL中获取的音频数据以及从Primary HAL中获取的音频数据进行混音。这样，屏幕录制器1从AudioFlinger中获取到的音频数据1为手机麦克风采集的音频以及手机的系统音频。
仍如图89所示，屏幕录制器1可以实时的获取到手机的显示数据1和音频数据1，即手机录制的第一屏幕数据，第一屏幕数据可以记录和还原手机中正在播放(或采集)的音频和画面。同时，对于电视1，电视1接收到手机发来的录屏指令后，可利用自身的录屏能力，按照录屏指令中与电视1对应的录屏参数执行录屏操作。
如图91所示，与手机中操作系统的软件架构类似的，电视1的应用程序层中可以设置代理应用，电视1的应用程序框架层中设置有屏幕录制器2、display模块、Camera模块、AudioRecord以及AudioFlinger等功能模块，电视1的HAL中设置有Camera HAL、Remote Submix HAL以及Primary HAL等。
其中，电视1的代理应用可用于与手机进行交互。例如，电视1与手机建立连接后，电视1的代理应用可调用屏幕录制器2获取电视1的录屏能力参数(即上述第二录屏能力参数)，并将第二录屏能力参数发送给手机(例如，手机的录屏应用或手机的录屏录制器1)。又例如，代理应用可接收手机(例如，手机的录屏应用或手机的录屏录制器1)发来的录屏指令，该录屏指令中包括与电视1对应的录屏参数。响应于该录屏指令，代理应用可按照上述录屏参数调用屏幕录制器2执行本次录屏操作。
与手机执行录屏操作的过程类似的，屏幕录制器2可调用电视1的display模块，按照录屏参数中与电视1对应的显示录制参数，从display模块中实时获取电视1显示屏中正在播放的显示数据2。或者，如果显示录制参数中指示需要录制电视1的摄像头采集的显示数据，则屏幕录制器2可调用电视1的Camera模块，按照对应的显示录制参数从Camera模块中实时获取电视1的摄像头采集的显示数据。当然，屏幕录制器2也可以一边从display模块获取电视1的显示屏中正在播放的显示数据，一边从Camera模块中获取电视1的摄像头采集的显示数据，本申请实施例对此不做任何限制。
同时，屏幕录制器2可调用电视1的AudioRecord，按照录屏参数中与电视1对应的音频录制参数，从AudioFlinger中实时获取电视1的音频数据2。例如，AudioFlinger可从Remote Submix HAL中获取电视1正在播放的音频数据。又例如，AudioFlinger可从Primary HAL中获取电视1的麦克风采集的音频数据。
这样，电视1中的屏幕录制器2可以实时的获取到电视1的显示数据2和音频数据2，即电视1录制的第二屏幕数据，第二屏幕数据可以记录和还原电视1中正在播放(或采集)的音频和画面。进而，屏幕录制器2可将获取到的第二屏幕数据发送给手机。或者，屏幕录制器2可将获取到的第二屏幕数据上报给代理应用，由代理应用将第二屏幕数据发送给手机。其中，电视1与手机之间的数据交互均可通过手机中的DMSDP HAL实现。
仍如图89所示，手机中的屏幕录制器1可通过DMSDP HAL接收电视1中屏幕录制器2(或电视1的代理应用)发来的第二屏幕数据。这样，屏幕录制器1可实时获取到手机录制的第一屏幕数据以及电视1录制的第二屏幕数据。第一屏幕数据中包 括手机录制的显示数据1和音频数据1，第二屏幕数据中包括电视1录制的显示数据2和音频数据2。后续，屏幕录制器1可将第一屏幕数据和第二屏幕数据上报给录屏应用，录屏应用可调用相应的接口将第一屏幕数据和第二屏幕数据制作为本次录屏文件。当然，也可以由屏幕录制器1根据第一屏幕数据和第二屏幕数据制作本次录屏文件，并将该录屏文件上报给录屏应用，本申请实施例对此不做任何限制。
在一些实施例中，以录屏应用根据第一屏幕数据和第二屏幕数据制作本次录屏文件举例，录屏应用可将第一屏幕数据和第二屏幕数据制作为一个录屏文件。例如，如图92所示，由于第一屏幕数据和第二屏幕数据是按照表20所示的统一的录屏参数录制的，因此，第一屏幕数据中的显示数据1和第二屏幕数据中的显示数据2的分辨率等显示录制参数是统一的，那么，录屏应用可以对显示数据1和显示数据2重新编码，将显示数据1和显示数据2合并为一个显示画面对应的显示数据3。录屏应用可以在录屏文件中设置一个显示轨道，显示轨道与显示数据3对应。其中，本申请实施例对显示数据1和显示数据2在合并后的显示画面中的位置、形状和占比不做任何限制。
仍如图92所示，录屏应用可以在录屏文件中设置两个音频轨道，其中，音频轨道1对应第一屏幕数据中的音频数据1，音频轨道2对应第二屏幕数据中的音频数据2。当然，录屏应用也可以对音频数据1和音频数据2进行编码等操作，本申请实施例对此不做任何限制。最终，录屏应用制作得到的录屏文件包括显示数据3以及音频轨道1和音频轨道2上的音频数据。
或者，录屏应用也可以通过混音将音频数据1和音频数据2合成为音频数据3。此时，录屏应用可以在录屏文件中设置一个音频轨道与音频数据3，并设置一个显示轨道与显示数据3对应，本申请实施例对此不做任何限制。
在手机和电视1同步录屏的过程中，电视1将录制的第二屏幕数据通过通信网络传输给手机需要一定的耗时，可能会导致手机录制的第一屏幕数据与电视1录制的第二屏幕数据在时间上不同步的现象。在一些实施例中，录屏应用还可以获取录屏过程中的传输时延T。例如，录屏应用可以通过DMSDP HAL周期性的查询Wi-Fi模块当前的传输时延T。当传输时延T大于阈值时，录屏应用可以先按照当前的传输时延T对第一屏幕数据和第二屏幕数据进行同步，进而，录屏应用可按照上述方法将同步后的第一屏幕数据和第二屏幕数据制作为一个录屏文件，从而避免多设备同步录屏时出现的屏幕数据不同步的现象。
在一些实施例中，录屏应用可以将第一屏幕数据和第二屏幕数据分别制作为对应的两个录屏文件。例如，如图93中的(a)所示，录屏应用可以对第一屏幕数据中的显示数据1和音频数据1进行编解码或封装等操作，得到录屏文件1。录屏文件1中的显示轨道与显示数据1对应，录屏文件1中的音频轨道与音频数据1对应。并且，如图93中的(b)所示，录屏应用可以对第二屏幕数据中的显示数据2和音频数据2进行编解码或封装等操作，得到录屏文件2。录屏文件2中的显示轨道与显示数据2对应，录屏文件2中的音频轨道与音频数据2对应。
需要说明的是，录屏应用可以将制作得到的一个或多个录屏文件保存在手机本地，也可以将制作得到的一个或多个录屏文件发送给电视1，由电视1将该录屏文件保存在电视1本地。或者，录屏应用也可以实时的将生成的录屏文件发送给服务器或其他 电子设备，本申请实施例对此不做任何限制。
另外，如果用户在打开录屏功能时还选择了使用其他从设备与手机和电视1同步录屏，则与上述实施例中手机与电视1同步录屏的过程类似的，手机还可以指示其他从设备按照手机确定出的录屏参数录制自身的屏幕数据。此时，录屏应用还可以接收到其他从设备发来的屏幕数据，录屏应用仍然可以按照上述方法将获取到的多个设备录制的屏幕数据制作为对应的录屏文件。
在一些实施例中，手机除了可以通过创建DMSDP HAL，使用DMSDP HAL与从设备(例如电视1)交互外，手机也可以通过在应用程序层设置代理应用，由手机的代理应用与从设备进行交互。示例性的，如图94所示，手机和电视1中均设备有代理应用。手机的代理应用可与电视1的代理应用进行交互，实现手机与电视1之间的数据收发。例如，在手机与电视1同步录屏的过程中，手机可通过其代理应用将电视1的录屏参数发送给电视1的代理应用，由电视1的代理应用按照图91所述的方法调用屏幕录制器2录制第二屏幕数据。并且，电视1的代理应用可将第二屏幕数据发送给手机的代理应用，由手机的代理应用将第二屏幕数据发送给录屏应用。同样，录屏应用不仅可以获取到屏幕录制器1上报的第一屏幕数据，还可以获取到代理应用发来的第二屏幕数据。后续，录屏应用可按照上述方法根据第一屏幕数据和第二屏幕数据制作对应的录屏文件。在这种实现方式中，手机不需要在HAL中创建与从设备对应的DMSDP HAL，也可以实现手机与其他设备的同步录屏操作。
可以看出，在本申请实施例中，手机(即主设备)在录屏场景下可以同步获取主设备录制的第一屏幕数据以及从设备录制的第二屏幕数据。进而，手机可根据第一屏幕数据和第二屏幕数据生成录屏文件，从而同步还原主设备和从设备中播放(或采集)的音频和画面，更加全面的记录和还原在主设备和从设备上实现的业务场景，使得用户可以同时录制多个电子设备中的屏幕数据，从而提升用户在分布式系统中的录屏使用体验。
在分布式音频场景中，以手机为主设备举例，主设备向从设备投射显示数据和/或音频数据时具体可以包括以下多种场景。
场景一
如图95所示，手机运行视频APP时播放的视频一般包括音频数据和显示数据。手机可使用自身的显示屏显示视频APP产生的显示数据，同时，手机可将视频APP产生的音频数据发送至从设备(例如音箱)中播放。也就是说，在场景一中，手机可将音频数据投射至从设备中播放，而手机自身可播放对应的显示数据。
在这种场景下，由于手机处理显示数据的速度较快，且人眼对图像具有视觉暂留现象，因此，手机处理并显示显示数据所花费的显示时延S可以忽略不计。其中，显示时延S具体可以是指显示数据的一个数据包从产生到最终被显示所花费的时间。其中，显示数据的数据包可以是响应于用户输入的播放指令产生的，例如，响应于用户点击视频APP中的播放按钮这一播放指令，视频APP可以开始产生待播放的显示数据的数据包。或者，显示数据的数据包也可以是视频APP自动产生的，例如，视频APP在显示广告时可自动产生待播放的显示数据的数据包，本申请实施例对此不做任何限制。
而手机从开始处理视频APP产生的音频数据，到手机将音频数据发送至音箱，最终由音箱播放该音频数据所花费的音频时延L一般较长。仍如图95所示，音频数据的一个数据包的音频时延L可以包括：该数据包在手机(即主设备)中处理所花费的时间L1(后续称为主设备音频时延)，该数据包在手机和音箱(即从设备)之间传输时所花费的时间L2(后续称为音频传输时延)，以及音箱接收到该数据包后，音箱开始处理该数据包到最终播放该数据包中音频数据所花费的时间L3(后续称为从设备音频时延)。可以理解，前述的处理过程和传输过程的起始时刻和结束时刻可以有多种实现方式，产品实现时本领域技术人员可根据需要进行选择。
示例性的，主设备音频时延L1的起始时刻可以是视频APP产生待播放音频数据中一个数据包的时刻，主设备音频时延L1的结束时刻可以是该数据包从手机中发送出去的时刻。其中，视频APP可以响应用户输入的播放指令产生待播放音频数据的数据包，或者，视频APP可自动产生待播放音频数据的数据包，本申请实施例对此不做任何限制。
示例性的，音频传输时延L2的起始时刻可以是上述数据包从手机中发送出去的时刻(即主设备音频时延L1的结束时刻)，音频传输时延L2的结束时刻可以是该数据包传输至音箱的时刻，即音箱接收到该数据包的时刻。
示例性的，从设备音频时延L3的起始时刻可以是音箱接收到上述数据包的时刻(即音频传输时延L2的结束时刻)，从设备音频时延L3的结束时刻可以是音箱播放该数据包中音频数据的时刻。
示例性的，主设备音频时延L1的起始时刻具体可以是主设备中视频APP接收到用户点击视频APP中播放按钮的时刻，或者，主设备音频时延L1的起始时刻可以是视频APP响应于用户点击上述播放按钮生成播放指令的时刻，或者，主设备音频时延L1的起始时刻可以是主设备中音频播放器接收到上述播放指令的时刻等。
类似的，主设备音频时延L1的结束时刻(即音频传输时延L2的起始时刻)可以是主设备的HAL将音频数据的数据包发送出去的时刻，也可以是主设备的Wi-Fi等硬件模块将音频数据的数据包发送出去的时刻等。
类似的，音频传输时延L2的结束时刻(即从设备音频时延L3的起始时刻)可以是从设备中相关应用接收到上述数据包的时刻，也可以是从设备中相关硬件模块接收到上述数据包的时刻等。
可以理解的是，本领域技术人员可以根据检测精度的需求、实际的应用场景或实际经验调整上述起始时刻和结束时刻的具体时间节点，此时上述主设备音频时延L1、音频传输时延L2或从设备音频时延L3的具体取值虽然会有微小的浮动，但如果该浮动所带来的误差在预设的取值范围内，则不会对音频时延L的计算和更新过程产生明显影响。
也就是说，音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。当然，在计算音频时延L时，主设备也可以将主设备音频时延L1、音频传输时延L2以及从设备音频时延L3乘以一定的比例系数后再相加得到音频时延L，即音频时延L＝k1*主设备音频时延L1+k2*音频传输时延L2+k3*从设备音频时延L3，k1+k2+k3＝1。
另外，上述主设备音频时延L1也可以称为第一时延、音频传输时延L2也可以称 为第二时延、从设备音频时延L3也可以称为第三时延等名称，本申请实施例对此不做任何限制。
那么，音频数据与显示数据之间的同步时延T＝音频时延L-显示时延S。当同步时延T大于0时，说明音频数据的发声晚于显示数据的显示；当同步时延T小于0时，说明音频数据的发声早于显示数据的显示；当同步时延T等于0时，说明音频数据的发声与显示数据的显示是对应的。由于场景一中显示数据的显示时延S可以忽略不计，因此，同步时延T≈音频时延L。即音频时延L可以反映出播放同一时刻的音频数据和显示数据之间的时间差。
以音频时延L为500ms举例，由于显示时延S可以忽略不计，说明播放同一时刻的音频数据要比播放该时刻对应的显示数据慢500ms。那么，手机获取到音频时延L后，可以将音频时延L作为同步时延T，并按照音频时延L设置当前进行音画同步处理的同步策略。例如，视频APP接收到用户点击视频中播放按钮的操作后，可获取当前最新的音频时延L(音频时延L＝500ms)。进而，视频APP可在同步策略中设置当视频APP产生第1秒的显示数据后，手机等待500ms后使用显示屏显示该显示数据，此时经过500ms的音频时延L，与第1秒的显示数据对应的第1秒的音频数据已经被处理并发送至音箱中播放，从而使音箱中播放的音频和手机中播放的图像能够达到音画同步的效果，提高用户的使用体验。
场景二
如图96所示，仍以手机运行视频APP播放视频举例，在场景二中，手机可将视频APP产生的音频数据和显示数据均发送至从设备(例如电视)中播放。也就是说，在场景二中，手机可将视频中的音频和图像全部投射至同一从设备中播放。
在这种场景下，手机从开始处理视频APP产生的显示数据，到手机将显示数据发送至电视，最终由电视播放该显示数据所花费时间为显示时延S。仍如图96所示，显示数据的一个数据包的显示时延S可以包括：该数据包在手机(即主设备)中处理所花费的时间S1(后续称为主设备显示时延)，该数据包在手机和电视(即从设备)之间传输时所花费的时间S2(后续称为显示传输时延)，以及电视接收到该数据包后，电视开始处理该数据包到最终播放该数据包中显示数据所花费的时间S3(后续称为从设备显示时延)。
与主设备音频时延L1类似的，主设备显示时延S1的起始时刻可以是视频APP产生待播放显示数据中一个数据包的时刻，主设备显示时延S1的结束时刻可以是该数据包从手机中输出的时刻。显示传输时延S2的起始时刻可以是上述数据包从手机中输出的时刻(即主设备显示时延S1的结束时刻)，显示传输时延S2的结束时刻可以是该数据包传输至电视的时刻，即电视接收到该数据包的时刻。从设备显示时延S3的起始时刻可以是电视接收到上述数据包的时刻(即显示传输时延S2的结束时刻)，从设备显示时延S3的结束时刻可以是电视显示该数据包中显示数据的时刻。
也就是说，显示时延S＝主设备显示时延S1+显示传输时延S2+从设备显示时延S3。与音频时延L类似的，在计算显示时延S时，主设备也可以将主设备显示时延S1、显示传输时延S2以及从设备显示时延S3乘以一定的比例系数后再相加得到显示时延S。
其中，无论是主设备还是从设备，由于显示数据在电子设备中的处理过程一般较 为简单，即处理速度较快，因此，显示数据的主设备显示时延S1与从设备显示时延S3可以忽略不计。此时，上述显示时延S≈显示传输时延S2。
对于手机运行视频APP时产生的音频数据，与上述场景一类似的，音频数据的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。
那么，音频数据与显示数据之间的同步时延T＝音频时延L-显示时延S≈音频时延L-显示传输时延S2。同步时延T可以反映出播放同一时刻的音频数据和显示数据之间的时间差。
以音频时延L为500ms，显示传输时延S2为200ms举例，此时音频数据与显示数据之间的同步时延T＝500ms-200ms＝300ms，即电视播放同一时刻的音频数据要比播放该时刻对应的显示数据慢300ms。那么，手机获取到同步时延T后，可以按照同步时延T设置当前进行音画同步处理的同步策略。例如，视频APP在播放第N帧显示数据时可获取当前最新的同步时延T(同步时延T＝300ms)，进而，视频APP可在同步策略中设置当电视接收到第N+1帧显示数据后等待300ms再播放该显示数据。由于第N+1帧显示数据从手机传输至电视还需要耗时200ms(即显示传输时延S2＝200ms)，因此，与第N+1帧显示数据对应的音频数据经过500ms的处理和传输后也可以同步在电视中播放，从而使电视中播放的音频和图像能够达到音画同步的效果，提高用户的使用体验。
在一些实施例中，手机向电视发送音频数据和显示数据时手机与电视之间的网络连接一般是固定的，例如，手机可基于与电视之间的Wi-Fi P2P连接传输音频数据和显示数据，那么，在Wi-Fi P2P连接上传输音频数据和显示数据的传输速率一般是相同的，并且，音频数据中数据包的大小与显示数据中数据包的大小大多是同一数量级别的，因此，手机在该Wi-Fi P2P连接上传输音频数据中一个数据包的耗时与传输显示数据中一个数据包的耗时基本是相同的，即显示数据的显示传输时延S2≈音频数据的音频传输时延L2，此时，同步时延T≈(主设备音频时延L1+音频传输时延L2+从设备音频时延L3)-显示传输时延S2≈主设备音频时延L1+从设备音频时延L3。这样，手机通过获取主设备音频时延L1和从设备音频时延L3可以计算出当前的同步时延T。
场景三
如图97所示，仍以手机运行视频APP播放视频举例，在场景三中，手机可将视频APP产生的显示数据发送至第一从设备(例如电视)中播放，并且，手机可将视频APP产生的音频数据发送至第二从设备(例如音箱)中播放。也就是说，在场景三中，手机可将视频中的音频和图像投射至不同的从设备中播放。
在这种场景下，显示数据的显示时延S＝主设备显示时延S1+显示传输时延S2+从设备显示时延S3。与场景二类似的，显示数据的主设备显示时延S1和从设备显示时延S3可以忽略不计。即：显示时延S≈显示传输时延S2。与场景二不同的是，显示传输时延S2是指手机与电视(即第一从设备)之间传输显示数据的时延。
类似的，音频数据的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。与场景二不同的是，音频传输时延L2是指手机与音箱(即第二从设备)之间传输音频数据的时延。
由于手机与电视之间的第一网络连接和手机与音箱之间的第二网络连接可能不同， 例如，手机与电视之间建立的是Wi-Fi连接，而手机与音箱之间建立的是蓝牙连接，因此，在场景三中，上述显示传输时延S2与音频传输时延L2可能不同。
那么，音频数据与显示数据之间的同步时延T＝音频时延L-显示时延S＝(主设备音频时延L1+音频传输时延L2+从设备音频时延L3)-显示传输时延S2。
同样，手机通过获取上述同步时延T，可以按照同步时延T设置当前进行音画同步处理的同步策略，从而按照该同步策略向音箱和电视分别投射音频数据和视频数据，使音箱中播放的音频和电视中播放的图像能够达到音画同步的效果。
可以看出，无论在哪一种场景下，手机在向从设备投射显示数据和/或音频数据时，为了达到音画同步的效果，手机均需要获取音频时延L与显示时延S之间的同步时延T，进而根据同步时延T设置进行音画同步处理的同步策略。
在本申请实施例中，手机可以动态的检测并更新上述音频时延L，这样，手机按照最新的音频时延L可以更加准确的计算出音频时延L与显示时延S之间的同步时延T，即同步时延T也是随着音频时延L动态更新的。后续，手机可按照最新的同步时延T设置进行音画同步处理的同步策略，从而使手机投射的音频和图像能够较更加准确的达到音画同步的效果，提高用户的使用体验。
基于图6所示的Android系统架构，如图98所示，在一次音频播放过程中音频数据需要经过音频播放器、音频处理器、音频管理器以及HAL的层层处理最终输出至扬声器等硬件模块进行播放。也就是说，音频数据的音频时延L从视频APP产生音频数据开始，该音频数据经过音频播放器、音频处理器、音频管理器以及HAL的层层处理，直至该音频数据从扬声器播放结束。显然，音频数据的音频时延L一般比较长。
而手机在显示图像时，仍以视频APP举例，仍如图98所示，视频APP产生的显示数据可直接通过surface模块进行解析，由surface模块将解析后的显示数据通过显示驱动发送至显示屏进行显示。可以看出，当图像在手机上显示时，一次图像显示过程中显示数据的处理过程较为简单，此时显示数据的显示时延S可以忽略不计。在这种场景下，音频数据的音频时延L可反映出手机播放同一时刻的音频数据和显示数据之间的时间差，即音频时延L≈同步时延T。
为了保证视频APP中播放的图像和音频同步(即音画同步)，手机在运行视频APP时，视频APP可定期调用getLatency()接口获取音频数据的音频时延L。进而，视频APP可按照获取到的音频时延L设置进行音画同步处理的同步策略。例如，视频APP可以周期性的获取最新的音频时延L。以周期为3秒举例，当视频APP产生第3秒的待播放的音频数据和显示数据时如果获取到当前的音频时延L为500ms，进而，视频APP可在同步策略中设置将第3秒的音频数据相对于显示数据提前500ms输入至音频播放器中，这样，第3秒的音频数据经过500ms的处理过程后可与第3秒的显示数据同步进行播放，达到音画同步的效果。
示例性的，当手机运行的APP(例如视频APP)需要进行音画同步处理时，视频APP可调用getLatency()接口向音频服务(AudioService)查询最近一次计算出的音频数据与显示数据之间的同步时延T(同步时延T＝音频时延L-显示时延S)。或者，视频APP可调用播放器(例如Nuplayer、Mediaplayer)，由播放器调用getLatency()接口向音频服务(AudioService)查询最近一次计算出的音频数据与显示数据之间的同 步时延T。后续，当视频APP或播放器获取到同步时延T后，可按照该同步时延T设置进行音画同步处理的同步策略，从而按照该同步策略向从设备输出视频APP后续产生的音频数据和/或显示数据。
在本申请实施例中，为了提高音画同步时音频和图像同步的准确率，AudioService中存储的同步时延T是可以动态更新的，使得视频APP或播放器获取到的同步时延T可以更加准确的指示当前播放同一时刻的音频数据和显示数据之间的时间差。以下，将结合具体实施例详细阐述动态更新同步时延T的具体方法。
场景一
在场景一中，手机在运行视频APP时，可以将视频APP产生的音频数据投射至从设备中播放，而APP产生的显示数据仍然在手机中播放。
示例性的，如图99中的(a)所示，手机在运行视频APP时可显示用于音频切换的切换按钮9901。如果检测到用户点击上述切换按钮9901，说明用户希望将视频APP产生的音频数据切换至其他音频输出设备上播放，则手机通过运行DV APP搜索附近可用于进行音频切换的一个或多个候选设备。例如，如图99中的(b)所示，DV APP可将与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在菜单9902中。用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
又例如，用户还可以打开手机的控制中心，在控制中心中切换手机输出音频时的音频输出设备。响应于用户打开控制中心的操作，如图100中的(a)所示，手机可显示控制中心10001。控制中心10001中设置有用于音频切换的切换按钮10002。如果检测到用户点击上述切换按钮10002，手机也可运行DV APP搜索附近可用于进行音频切换的一个或多个候选设备。如图100中的(b)所示，DV APP可将搜索到的与手机位于同一Wi-Fi网络的电视、音箱以及耳机等候选设备显示在控制中心10001中。同样，用户可在这些候选设备中选择一个作为手机后续输出音频时的音频输出设备，也即手机的从设备。
以用户选中音箱为手机的从设备举例，检测到用户在上述候选设备中选择音箱这一候选设备后，DV APP可将音箱作为手机的从设备与音箱建立网络连接。例如，该网络连接可以是基于TCP(transmission control protocol，传输控制协议)或UDP(user datagram protocol，用户数据报协议)的P2P连接，本申请实施例对此不做任何限制。
手机与音箱建立了网络连接后，DV APP可基于该网络连接获取音箱的音频能力参数，该音频能力参数可反映出音箱具体支持的音频输出功能。例如，该音频能力参数可以包括音箱支持的采样率、声道数目、音效模式等。进而，DV APP可按照音箱的音频能力参数在HAL创建对应的DMSDP Audio HAL。后续，手机可通过DMSDP Audio HAL向音箱传输音频数据，从而将手机中的音频功能切换至音箱中实现。
在一些实施例中，手机与音箱建立网络连接后，手机还可以查询当前的从设备(例如音箱)是否具有显示功能。例如，手机可向音箱发送查询请求，请求音箱上报自身是否具有显示能力。又例如，手机可获取音箱的设备型号等信息，进而根据音箱的设备型号等信息确定音箱是否具有显示功能。如果音箱具有显示功能，则如图101所示，手机可提示用户是否需要将手机中的显示数据也投射至音箱中显示，即向从设备同时 投射显示数据和音频数据。
如果用户选择将显示数据也投射至音箱中显示，则手机可按照下述场景二中的具体方法将手机中的显示数据和音频数据一起投射至从设备中播放。
如果用户选择将显示数据保留在手机中显示，或者，如果手机确定音箱不具有显示功能，则手机可确定只需要将手机中的音频数据投射至音箱中播放，而手机中的显示数据仍由手机自身的显示屏进行显示。
在手机将音频数据投射至音箱进行播放的过程中，仍如图95所示，音频数据的每个数据包产生的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。而手机使用自身显示屏播放显示数据的显示时延S≈0。那么，音频数据与显示数据之间的同步时延T＝音频时延L-显示时延S≈音频时延L。
示例性的，DV APP在HAL中为音箱创建了对应的DMSDP Audio HAL后，DMSDP Audio HAL可周期性的获取音频数据与显示数据之间的同步时延T，在场景一中，同步时延T为手机向音箱投射音频数据时的音频时延L。例如，DMSDP Audio HAL可以以1秒(s)为周期，周期性的获取当前的主设备音频时延L1、音频传输时延L2以及从设备音频时延L3，进而计算获取到的主设备音频时延L1、音频传输时延L2以及从设备音频时延L3之和，得到最新的音频时延L。当然，本领域技术人员可以根据实际经验或实际应用场景设置DMSDP Audio HAL获取主设备音频时延L1、音频传输时延L2以及从设备音频时延L3的具体周期。
其中，上述主设备音频时延L1的大小主要取决于手机(即主设备)对音频数据的具体处理过程。例如，当手机需要对音频数据进行音效处理时，对应的主设备音频时延L1会增加。又例如，当手机使用不同的编码算法对音频数据进行编码时，所对应的主设备音频时延L1也会不同。又例如，当手机需要对音频数据进行重采样时，对应的主设备音频时延L1会增长。
在本申请实施例中，当手机与音箱建立网络连接后，手机中的AudioPolicy可以根据当前从设备(例如音箱)的音频能力参数确定对应的音频策略，该音频策略中具体包括了是否添加音效，是否进行重采样以及如何进行编码等音频处理指示。那么，DMSDP Audio HAL可以向AudioPolicy请求查询当前的音频策略，进而根据当前的音频策略确定此时的主设备音频时延L1。
例如，如图102所示，如果音频策略中设置需要对音频数据添加音效(即进行音效处理)，则DMSDP Audio HAL可确定音效处理过程耗时20ms。相应的，如果音频策略中设置对音频数据不进行音效处理，则DMSDP Audio HAL可确定音效处理过程耗时0ms。
又例如，如图102所示，如果音频策略中设置使用AAC(Advanced Audio Coding，高级音频编码)格式对音频数据编码，则DMSDP Audio HAL可确定编码过程耗时15ms；如果音频策略中设置使用H.264格式对音频数据编码，则DMSDP Audio HAL可确定编码过程耗时10ms。
又例如，如图102所示，如果音频策略中设置对音频数据进行重采样，则DMSDP Audio HAL可确定重采样过程耗时5ms；如果音频策略中设置对音频数据不进行重采样，则DMSDP Audio HAL可确定重采样过程耗时0ms。
进而，仍如图102所示，DMSDP Audio HAL可将上述音效处理过程的耗时、编码过程的耗时以及重采样过程的耗时相加后得到当前的主设备音频时延L1。需要说明的是，上述音效处理过程的具体耗时、编码过程的具体耗时以及重采样过程的具体耗时可以是开发人员预先设置的经验值，也可以是手机从服务器中获取的。手机可以更新这些音频处理过程的具体耗时。例如，当新版本的操作系统中将音效处理过程的耗时由20ms更新为15ms时，手机更新了新版本的操作系统后也随之将音效处理过程的耗时由20ms更新为15ms。
当然，如果音频策略中还设置了其他音频处理过程，则DMSDP Audio HAL还可以确定其他音频处理过程的耗时，并将该耗时作为主设备音频时延L1中的一部分，本申请实施例对此不做任何限制。
在本申请实施例中，由于DV APP从音箱获取的音频能力参数是动态更新的，因此AudioPolicy根据音频能力参数确定的音频策略也是动态更新的。那么，DMSDP Audio HAL根据上述音频策略确定出的主设备音频时延L1也是动态更新的。
例如，DMSDP Audio HAL中可以设置用于存储主设备音频时延L1的第一标志位。DMSDP Audio HAL可按照上述方法周期性(例如以1秒为周期)的计算最新的主设备音频时延L1，并将每次计算出的主设备音频时延L1更新在第一标志位中进行保存。
又例如，当AudioPolicy每次按照最新的音频能力参数更新了音频策略后，可向DMSDP Audio HAL发送更新消息，即向DMSDP Audio HAL通知音频策略已经更新。DMSDP Audio HAL可响应该更新消息从AudioPolicy中获取最新的音频策略，并按照最新的音频策略计算最新的主设备音频时延L1，进而，DMSDP Audio HAL可将计算出的主设备音频时延L1更新在第一标志位中进行保存。
在一些实施例中，上述音频传输时延L2的大小主要取决于手机(即主设备)与音箱(即从设备)之间网络连接的网络状况。例如，当手机与音箱之间网络连接的网络质量较好时，对应的音频传输时延L2会降低；当手机与音箱之间网络连接的网络质量较差时，对应的音频传输时延L2会增加。又例如，当手机与音箱之间的距离较近时，对应的音频传输时延L2会降低；当手机与音箱之间的距离较远时，对应的音频传输时延L2会增加。
以手机与音箱之间的网络连接为Wi-Fi P2P连接举例，手机HAL中的Wi-Fi HAL可以定期检测手机与音箱之间的音频传输时延L2。例如，如图103所示，Wi-Fi HAL可以以500ms为周期，通过手机与音箱之间的Wi-Fi P2P连接向音箱发送测试数据包，音箱接收到该测试数据包后可以向手机的Wi-Fi HAL发送响应数据包。那么，Wi-Fi HAL通过检测发送上述测试数据包与接收上述响应数据包之间的时间间隔，可以计算出当前手机与音箱之间的音频传输时延L2。
又例如，手机与音箱建立Wi-Fi P2P连接后，手机可通过心跳机制周期性的接收音箱发来的心跳包或心跳应答。当手机在预设时间内没有接收到音箱发来的心跳包或心跳应答，说明此时手机与音箱之间的网络状况可能出现变化，则可触发手机的Wi-Fi HAL向音箱发送测试数据包，并接收音箱响应该测试数据包发来的响应数据包。这样，Wi-Fi HAL通过检测发送上述测试数据包与接收上述响应数据包之间的时间间隔，可以计算出当前手机与音箱之间的音频传输时延L2。
示例性的，如果手机向音箱发送测试数据包至手机接收到音箱发来的响应数据包之间的时间间隔为N，则Wi-Fi HAL可计算当前手机与音箱之间的音频传输时延L2＝N/2，即手机向音箱传输音频数据中一个数据包的耗时。
在本申请实施例中，DMSDP Audio HAL中可以设置用于存储音频传输时延L2的第二标志位。仍如图103所示，DMSDP Audio HAL可周期性的读取Wi-Fi HAL中存储的音频传输时延L2，并将每次读取到的音频传输时延L2更新在第二标志位中进行保存。其中，DMSDP Audio HAL获取音频传输时延L2的周期，与上述实施例中DMSDP Audio HAL获取主设备音频时延L1的周期可以相同或不同。
又例如，当Wi-Fi HAL每次计算出了最新的音频传输时延L2后，可向DMSDP Audio HAL发送更新消息，即向DMSDP Audio HAL通知音频传输时延L2已经更新。DMSDP Audio HAL可响应该更新消息读取Wi-Fi HAL中存储的音频传输时延L2，并将读取到的音频传输时延L2更新在第二标志位中进行保存。
在一些实施例中，上述从设备音频时延L3的大小主要取决于音箱(即从设备)对音频数据的具体处理和播放过程。例如，当音箱需要对音频数据进行音效处理时，对应的从设备音频时延L3会增加。又例如，当音箱需要使用DSP处理音频数据时，对应的从设备音频时延L3也会增加。又例如，当音箱使用不同型号或不同厂商的扬声器播放音频数据时，对应的从设备音频时延L3也会不同。
在本申请实施例中，手机的DV APP从音箱中获取的音频能力参数中可以包括音箱作为从设备时的从设备音频时延L3。也就是说，音箱可计算自身的音频时延，并将该音频时延作为从设备音频时延L3携带在音频能力参数中上报给手机(即主设备)。
示例性的，音箱作为从设备获取从设备音频时延L3的过程与手机作为主设备获取上述主设备音频时延L1的过程类似。例如，如果音箱需要对音频数据进行音效处理，则音箱可确定音效处理过程耗时15ms。相应的，如果音箱不需要对音频数据进行音效处理，则音箱可确定音效处理过程耗时0ms。又例如，如果音箱需要使用DSP处理音频数据，则音箱可确定DSP的处理过程耗时10ms。相应的，如果音箱不需要使用DSP处理音频数据，则音箱可确定DSP的处理过程耗时0ms。
音箱可将对音频数据的各个处理过程的耗时相加后得到从设备音频时延L3。进而，音箱可将当前的从设备音频时延L3携带在音频能力参数中上报给手机的DV APP，由手机的DV APP将该音频能力参数注册在AudioPolicy中。如图104所示，DMSDP Audio HAL中可以设置用于存储从设备音频时延L3的第三标志位。DMSDP Audio HAL通过读取AudioPolicy中音频能力参数中的从设备音频时延L3，可以将读取到的从设备音频时延L3保存在第三标志位中。
在本申请实施例中，DV APP从音箱获取的音频能力参数是动态更新的。例如，当用户将音箱的音效模式从杜比音效模式设置为重低音音效模式后，音箱可响应用户的设置将音效处理过程耗时由15ms更新为20ms。此时，音箱可重新计算并更新从设备音频时延L3，并将更新后的从设备音频时延L3携带在音频能力参数中上报给手机的DV APP。DV APP可将最新的音频能力参数下发给AudioPolicy。AudioPolicy获取到最新的音频能力参数后可通知DMSDP Audio HAL，DMSDP Audio HAL此时可从AudioPolicy中获取到最新的从设备音频时延L3，并将最新的从设备音频时延L3更新 在第三标志位中。
这样一来，DMSDP Audio HAL的第一标志位中存储有最新的主设备音频时延L1，第二标志位中存储有最新的音频传输时延L2，第三标志位中存储有最新的从设备音频时延L3。那么，DMSDP Audio HAL可以从第一标志位、第二标志位以及第三标志位中周期性的获取最新的主设备音频时延L1、音频传输时延L2以及从设备音频时延L3。进而，DMSDP Audio HAL可计算出对应的音频时延L，音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。这样，DMSDP Audio HAL可以动态的更新当前音频数据的音频时延L。
或者，DMSDP Audio HAL可以设置当第一标志位、第二标志位或第三标志位中的一个标志位的内容更新时，可触发DMSDP Audio HAL获取第一标志位中的主设备音频时延L1，第二标志中的音频传输时延L2以及第三标志位中的从设备音频时延L3，并计算最新的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。这样，DMSDP Audio HAL也可以动态的更新当前音频数据的音频时延L。
示例性的，手机中的DMSDP Audio HAL可按照上述方法动态的计算当前音频数据的音频时延L。并且，DMSDP Audio HAL可在预设标志位中保存最近一次计算出的音频时延L。如果DMSDP Audio HAL本次计算出的音频时延L与最近一次计算出的音频时延L之间的差值小于阈值，说明当前的音频时延L没有出现较大的波动，则DMSDP Audio HAL无需修改预设标志位中保存的音频时延L。
如图105所示，手机中的DMSDP Audio HAL可按照上述方法计算出当前音频数据的音频时延L后，如果本次计算出的音频时延L与最近一次计算出的音频时延L之间的差值大于阈值，说明当前的音频时延L出现了较大的波动，则DMSDP Audio HAL可将预设标志位中的内容更新为本次计算出的音频时延L。进而，DMSDP Audio HAL可向AudioFlinger发送通知消息，在通知消息中携带预设标志位中的音频时延L，即告知AudioFlinger最新的音频时延L。进而，AudioFlinger可将通知消息中最新的音频时延L发送给AudioService，由AudioService保存该最新的音频时延L。
后续，视频APP或播放器在运行过程中可以调用getLatency()接口向AudioService查询当前音频数据与显示数据之间的同步时延T。由于在场景一中同步时延T≈音频时延L，那么，AudioService可将保存的最新的音频时延L作为同步时延T反馈给视频APP或播放器。这样，视频APP或播放器可根据最新的音频时延L设置进行的音画同步处理的同步策略。
在另一些实施例中，如图106所示，手机中的DMSDP Audio HAL可按照上述方法计算出当前音频数据的音频时延L，并在预设标志位中更新音频时延L。进而，DMSDP Audio HAL可向AudioFlinger发送通知消息，指示当前的音频时延L已经更新，此时，该通知消息中不包含更新后的音频时延L。那么，AudioFlinger接收到该通知消息后，可从DMSDP Audio HAL的预设标志位中读取更新后的音频时延L(即最新的音频时延L)。进而，AudioFlinger可将最新的音频时延L发送给AudioService，由AudioService保存该最新的音频时延L。
后续，与图105类似的，视频APP或播放器在运行过程中可以调用getLatency()接口向AudioService查询当前音频数据与显示数据之间的同步时延T。AudioService 可将保存的最新的音频时延L作为同步时延T反馈给视频APP或播放器，使得视频APP或播放器可根据最新的音频时延L设置进行的音画同步处理的同步策略。
由于AudioService可以动态的获取到DMSDP Audio HAL最新计算出的音频时延L，因此视频APP或播放器每次从AudioService中获取到的音频时延L也是最新计算出的音频时延L，该音频时延L可以较为准确的反映出当前的音频数据与显示数据之间的时间差。因此，视频APP或播放器按照上述音频时延L进行音画同步处理时，能够使音箱中播放的音频和手机中播放的图像更好的达到音画同步的效果，提高用户的音画同步体验。
示例性的，视频APP或播放器在运行过程中可以周期性的调用getLatency()接口获取最新的音频时延L。每次获取到最新的音频时延L后，视频APP或播放器可按照最新的音频时延L为后续输出的音频数据和显示数据设置相应的同步策略进行音画同步。例如，视频APP可以以5帧音频数据为一个周期获取最新的音频时延L。视频APP在输出第N帧音频数据后可以调用getLatency()接口获取最新的音频时延L，以此时的音频时延L＝400ms举例，视频APP可在同步策略中设置显示数据晚于音频数据400ms播放。这样，视频APP在播放第N+1帧音频数据至第N+5帧音频数据的过程中可按照上述同步策略播放对应的音频数据和视频数据，以实现音画同步的效果。
进而，当视频APP在输出第N+5帧音频数据后，视频APP可以再次调用getLatency()接口获取最新的音频时延L，以此时的音频时延L＝500ms举例，视频APP可根据最新的音频时延L更新上述同步策略。例如，视频APP可在同步策略中设置显示数据晚于音频数据500ms播放。那么，视频APP在播放第N+6帧音频数据至第N+10帧音频数据的过程中可按照上述同步策略播放对应的音频数据和视频数据。这样，视频APP在运行过程中可以不断的根据最新的音频时延L更新对应的同步策略，使音频播放时用户获得更好的音画同步效果。
或者，AudioService可以在视频APP运行的过程中主动向视频APP上报最新的音频时延L。例如，AudioService每次获取到AudioFlinger上报的最新的音频时延L后，可主动将最新的音频时延L发送给视频APP，触发视频APP按照最新的音频时延L设置对应的同步策略。也就是说，一旦手机检测到当前的音频时延L发生变化，手机便可将最新的音频时延L通知给视频APP，使得视频APP可以根据最新的音频时延L更新对应的同步策略，使音频播放时用户获得更好的音画同步效果。
在一些实施例中，在手机将音频数据投射至音箱播放的过程中，用户还可以在手机上修改当前与手机进行音频切换的从设备。例如，手机在运行视频APP时，如果接收到用户打开控制中心的操作，则如图107中的(a)所示，手机可在视频APP的应用界面中显示控制中心10701。控制中心10701中包括音频切换功能的切换按钮10702。当用户希望修改当前手机的从设备时，可点击切换按钮10702查询当前可以作为手机的从设备的一个或多个候选设备。如图107中的(b)所示，手机检测到用户点击切换按钮10702后，手机可将检测到的一个或多个候选设备显示在控制中心10703中。此时，控制中心10703中的音箱已经被标记为选中状态，即此时音箱作为手机的从设备正在播放来自手机的音频。如果用户需要将更换手机的从设备，则用户可在控制中心10703中重新选择进行音频切换的从设备。
以用户选择车机为手机新的从设备举例，手机可响应用户在控制中心10703中选择车机的操作，断开已经与音箱建立的网络连接，并与车机建立网络连接。进而，手机可通过DV APP可获取车机的音频能力参数，并按照车机的音频能力参数更新HAL中的DMSDP Audio HAL，使得更新后的DMSDP Audio HAL与车机的音频能力匹配。
进而，更新后的DMSDP Audio HAL可将车机作为从设备，继续按照上述方法周期性的获取主设备音频时延L1、音频传输时延L2以及从设备音频时延L3，从而周期性的计算最新的音频时延L。后续，与图105或图106中的过程类似的，DMSDP Audio HAL每次可将最新的音频时延L作为同步时延T，通过AudioFlinger存储在AudioService中，使得视频APP或播放器可在AudioService中获取到最新的音频时延L，从而按照最新的音频时延L设置进行的音画同步处理的同步策略。
场景二
在场景二中，手机在运行视频APP时，可以将视频APP产生的音频数据和显示数据投射至同一从设备中播放，即在手机中使用投屏功能将手机的音频和图像同时切换至从设备播放。
示例性的，如图108所示，手机在运行视频APP时，如果用户需要使用投屏功能，用户可在视频APP的应用界面中打开手机的控制中心10801。控制中心10801中可设置卡片10802，卡片10802用于展示手机检测到的附近一个或多个可进行投屏的候选设备。如果检测到用户在卡片10802中选中某一电子设备(例如电视)，说明用户希望通过手机的投屏功能，将视频APP产生的音频数据和显示数据投射至电视播放。
与场景一类似的，手机检测到用户选择电视作为手机的从设备进行投屏时，DV APP可与电视建立网络连接，进而通过该网络连接获取电视的音频能力参数，并按照电视的音频能力参数在HAL创建与对应的DMSDP Audio HAL。后续，手机可通过DMSDP Audio HAL向电视传输视频APP产生的音频数据。并且，在投屏场景下，手机可按照现有的投屏方式将视频APP产生的显示数据发送给电视进行显示。或者，手机也可以在HAL中创建与显示功能对应的DMSDP Display HAL，进而通过DMSDP Display HAL向电视传输视频APP产生的显示数据，本申请实施例对此不做任何限制。
在场景二中，如图96所示，对于手机运行视频APP时产生的音频数据，与上述场景一类似的，音频数据的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。
在场景二中，如图96所示，对于手机运行视频APP时产生的显示数据，显示数据的显示时延S＝主设备显示时延S1+显示传输时延S2+从设备显示时延S3。由于显示数据在电子设备中的处理过程一般较为简单，即处理速度较快，因此，显示数据的主设备显示时延S1与从设备显示时延S3可以忽略不计。此时，上述显示时延S≈显示传输时延S2。
并且，在场景二中，视频APP产生的显示数据和音频数据都是通过手机与电视之间的网络连接传输的，此时，显示数据中一个数据包从手机传输至电视的时间与视频数据中一个数据包从手机传输至电视的时间基本相同，即显示传输时延S2≈音频传输时延L2。
那么，音频数据与显示数据之间的同步时延T＝音频时延L-显示时延S≈(主设备 音频时延L1+音频传输时延L2+从设备音频时延L3)-显示传输时延S2≈主设备音频时延L1+从设备音频时延L3。
在本申请实施例中，DMSDP Audio HAL可以动态的获取当前的主设备音频时延L1和从设备音频时延L3，从而动态的得到最新的同步时延T(同步时延T＝主设备音频时延L1+从设备音频时延L3)。其中，DMSDP Audio HAL动态获取主设备音频时延L1和从设备音频时延L3的具体方法可参见场景一中的相关描述，故此处不再赘述。由于手机与电视投屏过程中的同步时延T是动态更新的，因此该同步时延T能够较为准确的指示电视播放同一时刻的音频数据和显示数据之间的时间差。
与图105或图106中的过程类似的，手机中的DMSDP Audio HAL每次可将更新后的同步时延T(即最新的同步时延T)通过AudioFlinger存储在AudioService中，使得视频APP或播放器可在AudioService中获取到最新的同步时延T，从而按照最新的同步时延T设置进行的音画同步处理的同步策略。由于APP或播放器获取到最新的同步时延T能够较为准确的指示电视播放同一时刻的音频数据和显示数据之间的时间差，因此，视频APP或播放器按照上述同步时延T进行音画同步处理时，能够使电视中播放的音频和图像更好的达到音画同步的效果，提高用户的音画同步体验。
场景三
在场景三中，手机在运行视频APP时，手机可将视频APP产生的显示数据发送至第一从设备中播放，并且，手机可将视频APP产生的音频数据发送至第二从设备中播放。也就是说，在场景三中，手机可将视频中的音频和图像投射至不同的从设备中播放。
示例性的，如图109中的(a)所示，手机在运行视频APP时，用户可在视频APP的应用界面中打开手机的控制中心10901。控制中心10901中可设置用于音频切换的第一按钮10902以及用于显示切换的第二按钮10903。
如果检测到用户点击第一按钮10902，说明用户希望将视频APP产生的音频数据切换至其他音频输出设备上播放，则手机通过运行DV APP搜索附近可用于进行音频切换的一个或多个候选设备。如图109中的(b)所示，DV APP可将与手机进行音频切换的候选设备显示在菜单10904中。用户可在这些候选设备中选择一个作为手机后续输出音频数据时的音频输出设备。
如果检测到用户点击第二按钮10903，说明用户希望将视频APP产生的显示数据切换至其他显示设备上播放，此时，如图109中的(c)所示，手机可将当前检测到的可用于接收手机的显示数据并显示的候选设备显示在菜单10905中。用户可在这些候选设备中选择一个作为手机后续输出显示数据时的显示输出设备。
以用户在菜单10904中选择音箱作为音频数据的音频输出设备，并在菜单10905中选择电视作为显示数据的显示输出设备举例，手机可以与音箱建立第一网络连接，并且与电视建立第二网络连接。手机可通过第一网络连接将视频APP产生的音频数据发送给音箱播放，并且，手机可通过第二网络连接将视频APP产生的显示数据发送给电视进行显示。
在本申请实施例中，手机与音箱建立第一网络连接后，手机中的DV APP可通过第一网络连接获取音箱的音频能力参数，并按照音箱的音频能力参数在HAL创建与对 应的DMSDP Audio HAL。DMSDP Audio HAL可以动态的获取当前音频数据和显示数据之间的同步时延T。
在场景三中，如图97所示，与上述场景一和场景二类似的，音频数据的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。
在场景三中，如图97所示，与上述场景二类似的，显示数据的显示时延S＝主设备显示时延S1+显示传输时延S2+从设备显示时延S3≈显示传输时延S2。
那么，音频数据和显示数据之间的同步时延T＝音频时延L-显示时延S≈(主设备音频时延L1+音频传输时延L2+从设备音频时延L3)-显示传输时延S2。
以手机与音箱之间的网络连接为第一Wi-Fi连接，手机与电视之间的网络连接为第二Wi-Fi连接举例，手机HAL中的Wi-Fi HAL可以通过第一Wi-Fi连接向音箱发送第一测试数据包，并接收音箱响应第一测试数据包发来的第一响应数据包，从而根据发送第一测试数据包与接收第一响应数据包之间的时间间隔计算出当前手机与音箱之间的音频传输时延L2。同样，Wi-Fi HAL可以通过第二Wi-Fi连接向电视发送第二测试数据包，并接收电视响应第二测试数据包发来的第二响应数据包，从而根据发送第二测试数据包与接收第二响应数据包之间的时间间隔计算出当前手机与电视之间的显示传输时延S2。
也就是说，在场景三中，手机的Wi-Fi HAL可以动态检测并更新音频传输时延L2和显示传输时延S2。这样，DMSDP Audio HAL可在Wi-Fi HAL中读取到最新的音频传输时延L2和显示传输时延S2。
并且，DMSDP Audio HAL可按照场景一中的方法获取到最新的主设备音频时延L1和从设备音频时延L3。进而，DMSDP Audio HAL根据最新的主设备音频时延L1、音频传输时延L2以及从设备音频时延L3可以计算出最新的音频时延L。进而，DMSDP Audio HAL根据最新的音频时延L和显示传输时延S2可计算出最新的同步时延T(同步时延T＝音频时延L-显示传输时延S2)。
后续，与图105或图106中的过程类似的，手机中的DMSDP Audio HAL每次计算出最新的同步时延T后，可将最新的同步时延T通过AudioFlinger存储在AudioService中，使得视频APP或播放器可在AudioService中获取到最新的音频时延L，从而按照最新的音频时延L设置进行的音画同步处理的同步策略。
或者，手机中的DMSDP Audio HAL也可以将最新的音频时延L和显示传输时延S2通过AudioFlinger上报给AudioService。由AudioService根据最新的音频时延L和显示传输时延S2计算得到最新的同步时延T，从而按照最新的音频时延L设置进行的音画同步处理的同步策略。
同样，由于APP或播放器获取到最新的同步时延T能够较为准确的指示同一时刻的音频数据和显示数据在两个从设备(即音箱和电视)上分别播放时的时间差，因此，视频APP或播放器按照上述同步时延T进行音画同步处理时，能够使电视中播放的图像和音箱中播放的音频更好的达到音画同步的效果，提高用户的音画同步体验。
在另一些实施例中，用户还可以在手机的音频输出设备上连接其他音频输出设备。例如，用户将电视选为手机的音频输出设备后，手机可将视频APP产生的音频数据发送给电视播放。如图110所示，当电视为手机的音频输出设备时，用户还可以将电视 与音箱连接，此时，电视可将手机发来的音频数据再发送至音箱播放，即音箱此时为电视的音频输出设备。
仍如图110所示，在上述多个音频输出设备级联的场景下，音频数据的音频时延L＝主设备音频时延L1+音频传输时延L2+从设备音频时延L3。不同的是，从设备音频时延L3具体包括：音频数据的数据包在电视中处理所花费的第一时延Y1，该数据包在电视和音箱之间传输时花费的第二时延Y2，以及音箱接收到该数据包后，音箱开始处理该数据包到最终播放该数据包中音频数据所花费的第三时延Y3，即L3＝Y1+Y2+Y3。
那么，与场景一中手机获取主设备音频时延L1、音频传输时延L2以及从设备音频时延L3的方法类似的，电视作为音箱的主设备也可按照上述方法获取当前的第一时延Y1、第二时延Y2以及第三时延Y3，从而计算得到最新的从设备音频时延L3。进而，电视可将最新的从设备音频时延L3携带在音频能力参数中上报给手机，由手机按照场景一中所述的方法更新当前音频数据的音频时延L。
这样一来，手机在多个音频输出设备级联的场景下也可以动态更新当前音频数据的音频时延L，使得视频APP或播放器能够按照最新的音频时延L确定对应的同步时延T进行音画同步处理，提高多个音频输出设备级联场景下的音画同步效果。
上述实施例中是以手机运行视频APP进行音画同步的场景举例说明的，可以理解的是，手机在运行其他应用时也可能需要调用getLatency()接口从AudioService中获取音频数据的音频时延L。由于本申请实施例中提供的方法可以动态更新AudioService中存储的音频时延L，使得该音频时延L能够更加准确的反映出播放当前音频数据需要花费的时间，因此，其他应用按照上述音频时延L进行的其他处理的准确率也会相应提高。
例如，如图111中的(a)所示，手机在运行K歌应用时可在控制中心中显示与音频输出能力对应的第一按钮20101以及与音频输入能力对应的第二按钮20102。用户可通过第一按钮20101和第二按钮20102分别控制手机的音频输出和输入功能在从设备上的切换。例如，如果检测到用户点击第一按钮20101，则图111中的(b)所示，手机可显示具有音频输出功能的候选设备的设备列表20103，其中，手机当前的音频输出设备为手机本机。用户可在设备列表20103中切换手机的音频输出设备。类似的，如果检测到用户点击第二按钮20102，则图111中的(c)所示，手机可显示具有音频输入功能的候选设备的设备列表20104，其中，手机当前的音频输入设备为音箱。用户可在设备列表20104中切换手机的音频输入设备。这样，用户可以按照自身的需求将手机的音频输出和输入能力分别切换至对应的设备中，分开控制手机的音频输出和输入功能。
以用户在设备列表20104中选择音箱为音频输入设备举例，与手机通过DMSDP Audio HAL将音频数据输出至音频输出设备类似的，手机可通过DMSDP Audio HAL接收音箱采集到的录音数据，并将录音数据上报给K歌应用，从而将手机的音频输入功能(也可称为音频录制或录音功能)分布至从设备中实现。
与上述实施例中播放音频数据的音频时延L类似的，上述录音数据的音频时延可称为录音时延R，录音数据的一个数据包的录音时延R＝主设备录音时延R1+录音传输 时延R2+从设备录音时延R3。
示例性的，从设备录音时延R3的起始时刻可以是从设备(例如音箱)采集到用户输入的录音数据中一个数据包的时刻，从设备录音时延R3的结束时刻可以是该数据包从音箱输出的时刻。录音传输时延R2的起始时刻可以是该数据包从音箱输出的时刻(即从设备录音时延R3的结束时刻)，录音传输时延R2的结束时刻可以是主设备(例如手机)接收到该数据包的时刻。主设备录音时延R1的起始时刻可以是手机接收到该数据包的时刻(即录音传输时延R2的结束时刻)，主设备录音时延R1的结束时刻可以是手机中对应应用(例如K歌应用)获取到该数据包的时刻。
与DMSDP Audio HAL按照上述实施例中的方法动态获取最新的主设备音频时延L1、音频传输时延L2以及从设备音频时延L3类似的，在上述录音场景下，DMSDP Audio HAL也可以动态获取最新的主设备录音时延R1、录音传输时延R2以及从设备录音时延R3，从而计算出最新的录音数据的录音时延R，并将录音时延R更新在AudioService中。后续，K歌应用也可调用getLatency()接口从AudioService中获取录音数据的录音时延R。进而，K歌应用可根据录音时延R将录音数据和当前播放的伴奏音乐进行混音，得到录制的歌曲文件。
例如，如图112所示，当录音数据的音频时延L＝400ms时，说明K歌应用接收到录音数据的时间比用户实际发声的时间晚了400ms，也说明当前的录音数据比伴奏音乐晚了400ms，那么，K歌应用可将当前接收到的录音数据与400ms之前的伴奏音乐进行混音，从而得到与伴奏音乐同步更加准确的歌曲文件。
又或者，除了上述K歌应用外，手机在运行音乐APP时也可以将来自音乐APP的音频数据(例如歌曲)投射至从设备(例如音箱)中播放。那么，音乐APP也可以按照上述实施例中的方法从AudioService中获取最新的音频时延L，进而，音乐APP可按照该音频时延L对播放的歌词数据与音频数据进行同步，使得用户看到的歌词与听到的歌曲是对应的。也就是说，主设备按照上述实施例中的方法动态的更新了音频时延L后，本领域技术人员可以根据实际经验或实际应用场景设置相关应用获取最新的音频时延L，从而按照最新的音频时延L进行与音频相关的同步处理，使得同步处理的结果更加准确。
目前，主设备(例如上述手机)在与从设备进行投屏的过程中，手机需要对音频数据和显示数据先解码再按照预设的格式编码，使得投屏时的数据处理过程较为复杂，从而导致投屏过程的时延较大。
以用户使用手机中的视频APP向电视投屏举例，视频APP运行时播放的视频文件通常是以数据包的形式获取到的。例如，视频APP可以从网络侧的服务器中获取视频文件的一个或多个数据包。又例如，视频APP可以从手机本地的存储器中获取视频文件的一个或多个数据包。也就是说，一个视频文件中可以包括一个或多个数据包，当然，视频文件中还可以包括视频文件的格式、时长、名称等其他信息，这些信息与视频文件的数据包共同构成了该视频文件。
如图113所示，上述视频文件的数据包一般包括包头(head)和数据(data)部分。
其中，上述数据(data)部分包括具体的显示数据和音频数据。例如，数据包1的数据(data)部分包括3帧音频数据和2帧显示数据。这些显示数据和音频数据一 般是视频文件的制作者按照一定的编码格式进行编码后的数据。编码后的显示数据和音频数据通常数据量较小，使得编码后的显示数据和音频数据可以携带在数据包中较为快速的进行传输。
上述包头(head)包括对应数据包中data部分的音频参数和显示参数。例如，包头(head)中可以包括显示数据的编码格式、分辨率等显示参数。该显示参数具体可以是视频文件的制作者在编码该显示数据时使用的参数。又例如，包头(head)中可以包括音频数据的编码格式、采样率、声道数目等音频参数。该音频参数具体可以是视频文件的制作者在编码该音频数据时使用的参数。
另外，上述包头(head)中还可以包括视频文件的一些信息，例如，视频文件的格式(例如MP4格式)、视频文件的名称(例如**电影)、视频文件的时长(例如120分钟)等，本申请实施例对此不做任何限制。
手机中的视频APP在播放上述视频文件时，如图114所示，手机可解析视频文件中数据包的包头(head)。通过解析包头，手机可提取到包头中对应的音频参数和显示参数。并且，手机可对数据包中的数据(data)部分进行解封装。通过解封装，手机可从data部分提取到对应的X(X＞0)帧音频数据和Y(Y＞0)帧显示数据。这X帧音频数据和Y帧显示数据均为经过编码的数据。示例性的，在图114中可将经过解封装后得到的音频数据称为音频数据1，类似的，在图114中可将经过解封装后得到的显示数据称为显示数据1。
进一步地，仍如图114所示，手机可按照解析得到的音频参数，对上述X帧音频数据(即音频数据1)进行解码。例如，如果上述音频参数中指示data部分的音频数据是按照ACC格式编码的，则手机可按照ACC格式对提取到的X帧音频数据1进行解码，获得解码后的X帧音频数据，即图114中的音频数据2。例如，解码后的音频数据2可以为PCM格式的音频数据。
类似的，仍如图114所示，手机还可以按照解析得到的显示参数，对上述Y帧显示数据(即显示数据1)进行解码。例如，如果上述显示参数中指示data部分的显示数据是按照H.265格式编码的，则手机可按照H.265格式对提取到的Y帧显示数据1进行解码，获得解码后的Y帧显示数据，即图4中的显示数据2。例如，解码后的显示数据2可以为YUV(Y表示明亮度，U和V表示色度)格式的显示数据。
那么，对于视频文件的每个数据包，手机均可按照上述方法进行解析、解封装和解码等操作，最终由手机播放解码后得到的显示数据和音频数据，从而实现视频APP中对应视频文件在手机中的播放功能。
目前，当用户将手机中的视频投屏至从设备(例如电视)中播放时，仍如图114所示，手机可按照相关投屏协议，将解码后的显示数据2和音频数据2重新按照预设的格式进行编码。例如，如果投屏协议中规定主设备与从设备之间交互的显示数据统一为H.264格式、音频数据统一为ACC格式，则手机需要对解码后的显示数据重新按照H.264格式进行编码，并将解码后的音频数据重新按照ACC格式进行编码。进而，手机可将重新编码后的显示数据(即图114中的显示数据3)和音频数据(即图114中的音频数据3)发送给电视。相应的，电视可按照投屏协议的规定按照相关的格式对接收到的显示数据3和音频数据3进行解码，得到解码后的显示数据2和音频数据 2。进而，电视可播放解码后的显示数据2和音频数据2，实现视频APP中对应视频文件在电视上的投屏功能。
可以看出，主设备(例如手机)在投屏时需要对视频文件的数据包进行解析、解封装、解码以及重新编码等一些列处理，使得从用户触发主设备进行投屏，到从设备(例如电视)开始播放显示数据和音频数据这一过程的耗时较长，即投屏过程的时延较大，用户的使用体验不佳。
对此，在本申请实施例中，如图115所示，主设备(例如手机)在投屏时可借助从设备(例如电视)的解码能力，将主设备从数据包中提取的经过编码的音频数据1和显示数据1直接发送给电视。进而，电视可使用自身的解码能力对接收到的音频数据1和显示数据1进行解码，得到解码后的显示数据2和音频数据2。进而，电视可播放解码后的音频数据2和显示数据2，完成视频APP中视频文件的投屏过程。
这样一来，主设备在投屏时不需要对数据包中已编码的音频数据和显示数据进行解码和重新编码等处理，而是直接将视频文件中经过编码的音频数据和显示数据发送给从设备，由从设备解码后播放解码后的音频数据和显示数据，使得整个投屏过程的时延缩短，从而提高投屏场景下用户的使用体验。
并且，由于主设备向从设备发送的音频数据和显示数据是视频文件中没有经过解码和重新编码的数据，因此，从设备接收到的音频数据和显示数据不会出现由于主设备解码和重新编码带来的失真，从而实现音频数据和显示数据在主设备和从设备之间的无损传输，提高投屏场景下音频和图像的保真度。
以手机中的操作系统为Android系统举例，目前，如图116所示，当应用程序层中的APP需要播放音频或视频时，可在应用程序框架层中创建对应的音视频播放器，例如Nuplayer。以视频APP举例，视频APP在运行时可将获取到的视频文件以数据包的形式实时的下发给Nuplayer。Nuplayer可调用多媒体提取器(MediaExtractor)对接收到的数据包进行解析和解封装。通过解析操作，Nuplayer可获取到数据包包头中携带的音频参数和显示参数；通过解封装操作，Nuplayer可从数据包的data部分提取出对应的显示数据1和音频数据1。此时，解封装后的提取到的显示数据1和音频数据1为视频文件中已经经过编码的显示数据和音频数据。
进一步地，Nuplayer可调用音频解码器(audio decoder)按照解析得到的音频参数对解封装后的音频数据1进行解码，得到解码后的音频数据2，例如PCM数据。并且，Nuplayer可调用图像解码器(video decoder)按照解析得到的显示参数对解封装后的显示数据1进行解码，得到解码后的显示数据2，例如YUV数据。
进而，Nuplayer可将解码后的音频数据2输入给音频管理器。仍如图116所示，音频管理器中可以包括音频播放器(AudioTrack)、音频处理器(AudioFlinger)以及音频策略模块(AudioPolicy)。具体的，Nuplayer可将解码后的音频数据2输入给AudioTrack，由AudioTrack调用AudioFlinger对解码后的音频数据2进行混音、重采样、音效设置等处理。AudioFlinger在处理上述音频数据2时，AudioPolicy可为当前AudioFlinger处理的音频数据设置对应的音频策略(例如混音策略、采样策略等)，AudioPolicy可将设置的音频策略发送给AudioFlinger，使得AudioFlinger可按照该音频策略处理解码后的音频数据2。
并且，仍如图116所示，Nuplayer可将解码后的显示数据2输入给surface模块，例如SurfaceFlinger，由SurfaceFlinger绘制该解码后的显示数据2。
后续，仍如图116所示，AudioFlinger可将输出的音频数据(此时的音频数据仍为经过解码的音频数据2)发送至HAL中对应的HAL。其中，HAL中提供了与手机的不同硬件模块对应的HAL，例如，Audio HAL、Camera HAL、Wi-Fi HAL、display HAL等。AudioFlinger可调用Audio HAL，将处理后的音频数据发送给Audio HAL，由Audio HAL将该音频数据2发送给对应的音频输出设备(例如扬声器、耳机等)进行播放。
示例性的，根据音频输出设备的不同，Audio HAL又可以进一步包括Primary HAL、A2dp HAL等。例如，当手机的音频输出设备为手机本机时，AudioFlinger可调用Primary HAL将音频数据2输出至手机的扬声器(speaker)进行播放。又例如，当手机的音频输出设备为蓝牙耳机时，AudioFlinger可调用A2dp HAL将音频数据2输出至与手机相连的蓝牙耳机进行播放。
类似的，仍如图116所示，SurfaceFlinger可将绘制出的显示数据2通过display HAL发送至手机的显示输出设备中显示。例如，SurfaceFlinger可通过display HAL将显示数据2输出至手机的显示屏中显示。
通过上述处理过程，视频APP在运行时待播放的视频文件的各个数据包都可以按照上述方法被解析、解封装以及解码后播放，使得手机可通过运行视频APP向用户播放相关的视频文件。
在本申请实施例中，仍以手机为主设备举例，如图117所示，手机在运行视频APP播放视频文件A时，可在应用程序框架层中创建播放该视频文件A的Nuplayer。进而，视频APP可将获取到的视频文件A以数据包的形式实时的下发给Nuplayer。当手机中的DV APP与电视203建立网络连接后，DV APP可向视频APP发送第一广播消息，以通知视频APP将正在播放的视频文件A投射至电视203中播放。视频APP接收到上述第一广播消息后，可继续向Nuplayer发送视频文件A中待播放的数据包，例如数据包1。
以Nuplayer接收到来自视频APP下发的数据包1举例，Nuplayer接收到数据包1后可调用MediaExtractor对数据包1进行解析和解封装。
通过解封装数据包1，Nuplayer可提取到数据包1的data部分携带的显示数据和音频数据。该显示数据和音频数据为视频文件A中按照一定编码格式编码后的数据。本申请实施例对视频文件A的数据包内显示数据和音频数据的编码格式不做任何限制。
通过解析数据包1，Nuplayer可获取到数据包1的包头中携带的音频参数1和显示参数1。其中，音频参数1为数据包1中的音频数据进行编码时使用的参数。
例如，音频参数1可以包括编码音频数据时使用的编码格式(例如，AAC格式等)。又例如，每一种编码格式中可能包括各种不同的编码规格或版本，例如，AAC格式中又包括低延迟规格(Low Delay，LD)、可变采样率规格(Scaleable Sample Rate，SSR)、高效率规格(High Efficiency，HE)、低复杂度规格(Low Complexity，LC)等9种不同的编码规格。那么，上述音频参数1还可以包括编码数据包1中音频数据时使用的编码格式中的具体编码规格或版本，例如AAC-LC。又例如，上述音频参数1还可以包括编码音频数据时使用的采样率、声道数目等参数，本申请实施例对此不做任何 限制。
上述显示参数1为数据包1中的显示数据进行编码时使用的参数。例如，显示参数1可以包括编码数据包1中显示数据时使用的编码格式(例如，H.265格式、H.264格式等)。同样，每一种编码格式中可能包括各种不同的编码规格或版本，那么，上述显示参数1还可以包括编码数据包1中显示数据时使用的编码格式中的具体编码规格或版本，例如H.265的3.1版本。又例如，上述显示参数2还可以包括编码数据包1中显示数据时显示数据的分辨率，例如1080*720。
当然，数据包1的包头中还可以携带当前播放的视频文件A的名称、时长或文件格式等参数，本申请实施例对此不做任何限制。
在一些实施例中，当视频APP接收到DV APP发送的上述第一广播消息后，视频APP还可以向Nuplayer发送第一通知消息(也可称为投屏指示)，Nuplayer收到第一通知消息后可按照投屏模式开始将接收到的数据包中的显示数据和音频数据投射至电视203中播放。例如，如果Nuplayer在接收到上述投屏指示后接收到数据包1，说明Nuplayer需要将数据包1投射至从设备(即电视203)中播放。
仍如图117所示，在投屏模式下，Nuplayer可通过DV APP将解析得到的上述音频参数1和显示参数1发送给电视203。或者，DV APP也可以以系统服务(图117中的代理service)的形式运行在应用程序框架层中。此时，Nuplayer可通过代理service将解析得到的上述音频参数1和显示参数1发送给电视203。
电视203接收到上述音频参数1和显示参数1后，可按照该音频参数1和显示参数1查询自身是否具有对应的音频解码能力和图像解码能力。例如，如果音频参数1中指示了音频数据编码时使用的编码格式为AAC格式、编码规格为AAC-LC、采样率为44100Hz、声道数目为2个，则电视203可按照上述音频参数1查询自身是否能够对对应的音频数据进行解码。如果可以对对应的音频数据进行解码，则说明电视203具有对数据包1中音频数据的音频解码能力。类似的，如果显示参数1中指示了显示数据编码时使用的编码格式为H.265格式、编码版本为3.1版本、分辨率为1080*720，则电视203可按照上述显示参数1查询自身是否能够对对应的显示数据进行解码。如果可以对对应的显示数据进行解码，则说明电视203具有对数据包1中显示数据的图像解码能力。
进而，仍如图117所示，如果电视203具有对应的图像解码能力和音频解码能力，则电视203可向手机的DV APP(或代理service)发送第一响应消息，用于指示电视203能够对数据包1中的音频数据和显示数据进行解码。DV APP(或代理service)可将第一响应消息发送给Nuplaye，触发Nuplayer将数据包1中解封装后的显示数据和音频数据发送至电视203。
例如，Nuplayer可通过手机的DV APP(或代理service)将数据包1中解封装后的显示数据和音频数据发送至电视203。或者，Nuplayer可通过手机的Wi-Fi模块将数据包1中解封装后的显示数据和音频数据发送至电视203，或者，Nuplayer可通过已创建的DMSDP Audio HAL将数据包1中解封装后的显示数据和音频数据发送至电视203，本申请实施例对此不做任何限制。
电视203从手机接收到的显示数据和音频数据是经过解封装但未经过解码的数据， 电视203可利用自身的图像解码能力对接收到的显示数据进行解码，同样，电视203可利用自身的音频解码能力对接收到的音频数据进行解码。进而，电视203可播放解码后的显示数据和音频数据，从而将手机中视频APP播放的视频文件A投射至电视203中播放。
并且，在上述投屏过程中，手机(即主设备)只需要对视频文件的数据包进行解析和解封装，无需对数据包中的音频数据和显示数据进行解码，也无需像现有技术一样对解码后的音频数据和显示数据按照统一格式进行重新编码，简化了投屏时主设备对音频数据和显示数据的处理过程。因此，主设备在向电视203(即从设备)进行投屏过程的耗时也将大大缩短，从而降低了投屏时的时延，提高用户投屏时的使用体验。
另外，如果电视203不具有对数据包1中音频数据的音频解码能力，和/或，不具有对数据包1中显示数据的图像解码能力，则电视203可向手机的DV APP(或代理service)发送第二响应消息，用于指示电视203无法对数据包1中的音频数据和/或显示数据进行解码。此时，DV APP(或代理service)可向视频APP发送投屏失败的消息，视频APP接收该消息后可向用户提示本次投屏失败。
或者，视频APP接收到投屏失败的消息后也可以按照现有的投屏方式，指示Nuplayer通过解码器对数据包1中的音频数据和显示数据进行解码。例如，Nuplayer可使用audio decoder对数据包1中的音频数据进行解码，并使用video decoder对数据包1中的显示数据进行解码。进而，Nuplayer可调用相关的编码器按照预设的统一格式重新对解码后的音频数据和显示数据进行重新编码，并将重新编码后的音频数据和显示数据发送给电视203。电视203可按照预设的统一格式对接收到的音频数据和显示数据解码后播放。
在一些实施例中，仍以手机投屏时的从设备为电视203举例，电视203中操作系统的软件架构可与手机的操作系统的软件架构类似。如图118所示，电视203中可以包括应用程序层、应用程序框架层以及HAL等。在电视203的应用程序层中可以安装系统级的系统应用，例如，代理APP。代理APP通过与手机中的DV APP交互可实现手机与电视203之间的交互过程。例如，代理APP可与DV APP交互完成手机与电视203之间建立网络连接的过程。电视203中的代理APP也可以以系统服务(图118中电视203内的代理service)的形式运行在应用程序框架层中。
又例如，仍如图118所示，在投屏过程中，手机的Nuplayer可将解析得到的数据包1中的音频参数1和显示参数1发送至电视203的代理APP(或代理service)。电视203的代理APP(或代理service)可按照上述音频参数1查询自身是否具有对应的音频解码能力，同样，代理APP(或代理service)可按照上述显示参数1查询自身是否具有对应的图像解码能力。如果电视203具有对应的音频解码能力和图像解码能力，则代理APP(或代理service)可向手机的DV APP(或代理service)发送上述第一响应消息，用于指示电视203能够对数据包1中的音频数据和显示数据进行解码。相应的，如果电视203不具有对应的音频解码能力和/或图像解码能力，则电视203的代理APP(或代理service)可向手机的DV APP(或代理service)发送上述第二响应消息，用于指示电视203无法对数据包1中的音频数据和/或显示数据进行解码。
如果电视203的代理APP(或代理service)向手机的DV APP(或代理service) 发送了上述第一响应消息，则可触发手机的Nuplayer将数据包1中解封装后的显示数据和音频数据发送至电视203的代理APP(或代理service)。例如，可将数据包1中解封装后的显示数据称为显示数据1，将数据包1中解封装后的音频数据称为音频数据1，显示数据1和音频数据1均为视频文件A中已编码的数据。
仍如图118所示，电视203的应用程序框架层中也包括Nuplayer。当电视203的代理APP(或代理service)接收到手机发来的显示数据1和音频数据1后，代理APP(或代理service)可将该显示数据1和音频数据1发送至电视203的Nuplayer。由于手机发来的数据包1中的显示数据1和音频数据1为视频文件A中经过编码的数据，因此，Nuplayer可创建对应的audio decoder和video decoder。进而，Nuplayer可将接收到的音频数据1发送至audio decoder中进行解码，得到解码后的音频数据2。并且，Nuplayer可将接收到的显示数据1发送至video decoder中进行解码，得到解码后的显示数据2。
在一些实施例中，当电视203中的代理APP(或代理service)确定出自身能够对数据包1中的音频数据1和显示数据1进行解码时，便可指示Nuplayer按照接收到的音频参数1创建对应的audio decoder，并且，可指示Nuplayer按照接收到的显示参数1创建对应的video decoder。这样，当Nuplayer接收到来自手机发送的数据包1中的显示数据1和音频数据1时，可直接将该显示数据1输入至video decoder进行图像解码，并将该音频数据1输入至audio decoder进行音频解码。这样，电视203在投屏时处理音频数据1和显示数据1的耗时将进一步缩短，可进一步降低投屏时的时延。
后续，仍如图118所示，audio decoder可将解码后的音频数据2通过AudioTrack输入AudioFlinger，由AudioFlinger对解码后的音频数据2进行音效设置等音频处理。video decoder可将解码后的显示数据2输入SurfaceFlinger，由SurfaceFlinger绘制解码后的显示数据2。进而，AudioFlinger可将输出的音频数据2通过HAL层的Audio HAL发送至音频输出设备(例如电视203的扬声器)中进行播放；SurfaceFlinger可将输出的显示数据2通过HAL层的display HAL发送至显示输出设备(例如电视203的显示屏)中进行显示，从而将手机中视频APP播放的视频文件A投射至电视203中播放。
可以看出，手机投屏时向电视203发送的视频文件A中的音频数据和显示数据是没有被解码的数据，也就是说，电视203接收到的音频数据和显示数据均为视频文件A中未经解码的源数据，因此，该音频数据和显示数据中不会出现因手机解码或重新编码等操作带来的失真。进而，电视203可直接对视频文件A中未经解码的源数据进行解码后播放，使得播放出的视频的保真度更高。
上述实施例中是以手机投屏时向电视203投射数据包1中的音频数据和显示数据举例说明的。可以理解的是，视频APP在手机中播放视频文件A时中还包括数据包1之后的其他数据包，其他数据包在投屏时的处理过程也可参见上述实施例中数据包1的处理过程。
例如，视频APP将视频文件A的数据包1下发给Nuplayer后，可继续将视频文件A的数据包2下发给Nuplayer。Nuplayer可调用MediaExtractor对数据包2进行解析和解封装。与上述实施例不同的是，上述视频文件A中每个数据包内音频数据的音频参数和显示数据的显示参数一般是统一的，例如，数据包1、数据包2以及该音频 文件中的其他数据包中的音频数据都是按照ACC-LC这一编码规格统一编码的，编码时的采样率、声音通道数等音频参数均一致。又例如，数据包1、数据包2以及该音频文件中的其他数据包中的显示数据都是按照H.265的3.1版本统一编码的，编码时的分辨率等显示参数均一致。那么，如果电视203对数据包1中的音频数据和显示数据具有对应的解码能力，则电视203对数据包2以及该音频文件中的其他数据包内的音频数据和显示数据均具有对应的解码能力。
那么，当Nuplayer通过MediaExtractor提取到数据包2中的音频数据和显示数据后，无需在向电视203发送对应的音频参数和显示参数，Nuplayer可直接将提取到的数据包2中的音频数据和显示数据发送至电视203。此时，该音频数据和显示数据仍然是视频文件A中未经解码的数据。后续，可由电视203对接收到的音频数据和显示数据进行解码，并播放解码后的音频数据和显示数据，从而将手机中视频APP播放的视频文件A投射至电视203中播放。
如果手机在投屏时视频APP播放新的视频文件(例如视频文件B)，则视频APP可创建播放视频文件B的Nuplayer(即新的Nuplayer)，并向新的Nuplayer中输入视频文件B的数据包。并且，视频APP可向新的Nuplayer发送第二通知消息，新的Nuplayer接收到第二通知消息后可开始将接收到的数据包中的显示数据和音频数据投射至电视203中播放。例如，新的Nuplayer接收到视频文件B的数据包(例如数据包3)时，可按照上述实施例中数据包1的处理过程，将解析得到的数据包3中的音频参数和显示参数发送给电视203，触发电视203查询是否具有解码数据包3中音频数据和显示数据的解码能力。如果电视203具有对应的解码能力，则电视203可向手机发送第一响应消息，用于指示电视203能够对数据包3中的音频数据和显示数据进行解码。进而，手机中新的Nuplayer可将数据包3以及后续的其他数据包中提取到的显示数据和音频数据发送给电视203，由电视203对接收到的显示数据和音频数据解码后播放。
在一些实施例中，手机在投屏时还可能更换从设备。例如，在手机运行视频APP将上述视频文件A投射至电视203播放的过程中，如果检测到用户输入将从设备从电视203修改为笔记本电脑的操作，则手机中的DV APP可断开与电视203之间的网络连接，并将笔记本电脑作为新的从设备与笔记本电脑建立网络连接。
如图119所示，手机的DV APP与笔记本电脑建立网络连接后，DV APP可向正在播放视频文件A的视频APP发送第二广播消息，以通知视频APP将正在播放的视频文件A投射至笔记本电脑中播放。视频APP接收到第二广播消息后，除了继续向Nuplayer发送视频文件A中待播放的数据包(例如数据包4)外，还可以向Nuplayer发送第三通知消息(也可称为变更消息)，第三通知消息中可以包括新的从设备(即笔记本电脑)的标识。Nuplayer接收到第三通知消息后可确定手机的从设备从电视203变更为笔记本电脑。
仍如图119所示，Nuplayer接收到上述第三通知消息后，可开始将接收到的数据包中的显示数据和音频数据投射至笔记本电脑中播放。例如，Nuplayer可调用MediaExtractor对数据包4进行解析和解封装，得到数据包4中的显示数据和音频数据，以及该显示数据的显示参数2和该音频数据的音频参数2。当Nuplayer接收到上述变 更消息后，还需要获取笔记本电脑是否能够解码视频文件A中显示数据和音频数据的解码能力。仍如图119所示，Nuplayer可将解析得到的显示参数2和音频参数2发送给笔记本电脑，触发笔记本电脑查询是否具有解码数据包4中音频数据和显示数据的解码能力。
如果笔记本电脑具有对应的解码能力，则笔记本电脑可向手机发送第一响应消息，用于指示笔记本电脑能够对数据包4中的音频数据和显示数据进行解码。进而，仍如图119所示，手机中的Nuplayer可将数据包4中提取到的显示数据和音频数据发送给笔记本电脑，由笔记本电脑对接收到的显示数据和音频数据解码后播放。
并且，在Nuplayer再次接收到从设备的变更消息之前，Nuplayer可将数据包4之后视频文件A中其他数据包内的显示数据和音频数据发送给笔记本电脑，由笔记本电脑对接收到的显示数据和音频数据解码后播放。这样，当手机投屏时的从设备发生变化时，手机也可将视频APP中播放的视频文件A投射至电视203中播放。其中，笔记本电脑对接收到的显示数据和音频数据的处理过程与上述实施例中电视203对接收到的显示数据和音频数据的处理过程类似，故此处不予赘述。
同样，在切换了手机(即主设备)投屏时的从设备后，如果从设备具有对当前播放的视频文件的解码能力，则手机只需要对视频文件的数据包进行解析和解封装。手机无需对数据包中的音频数据和显示数据进行解码，也无需像现有技术一样对解码后的音频数据和显示数据按照统一格式进行重新编码。从而简化了投屏时主设备对音频数据和显示数据的处理过程，也缩短了主设备向笔记本电脑(即从设备)进行投屏的耗时。
并且，上述笔记本电脑接收到的音频数据和显示数据均为视频文件A中未经解码的源数据，因此，该音频数据和显示数据中不会出现因手机解码或重新编码等操作带来的失真。后续，笔记本电脑可直接对视频文件A中未经解码的源数据进行解码后播放，使得播放出的视频的保真度更高。
在一些实施例中，在手机运行视频APP向从设备投屏的过程中，如图120所示，手机中的Nuplayer1接收到视频文件的数据包后，可直接将数据包中提取到的未经解码的音频数据和显示数据发送至从设备，由从设备对接收到的音频数据和显示数据进行解码后播放。
也就是说，手机中的Nuplayer1不需要调用相关的解码器对数据包中的音频数据和显示数据进行解码，那么，Nuplayer1也不需要将解码后的音频数据通过AudioTrack输入至AudioFlinger进行音频处理，同样，Nuplayer1也不需要将解码后的显示数据输入至SurfaceFlinger进行绘制。也就是说，手机在向从设备投屏的过程中，手机中的AudioTrack、AudioFlinger以及SurfaceFlinger等用于播放音视频数据的功能模块没有被视频APP占用，处于空闲状态。
这样一来，仍如图120所示，手机在运行视频APP进行投屏的过程中，手机还可以运行其他应用，使用上述AudioTrack、AudioFlinger以及SurfaceFlinger等功能模块播放其他应用产生的显示数据和/或音频数据。例如，用户可以将手机中运行的视频APP切换至后台，此时，手机中的Nuplayer1可继续向从设备发送来自视频APP未经解码的音频数据和显示数据。
视频APP切换至后台，如果用户在手机中打开微信APP，仍如图120所示，微信APP可创建对应的Nuplayer2，由Nuplayer2对来自微信APP的显示数据1和/或音频数据1进行解析、解封装等操作。进而，Nuplayer2可将音频数据1输入至audio decoder中进行解码，得到解码后的音频数据2。和/或，Nuplayer2可将显示数据1输入至video decoder中进行解码，得到解码后的显示数据2。进一步地，audio decoder可将解码后的音频数据2输入给AudioTrack，由AudioTrack调用AudioFlinger对解码后的音频数据2进行混音、重采样、音效设置等处理。和/或，video decoder可将解码后的显示数据2输入给SurfaceFlinger，由SurfaceFlinger绘制该解码后的显示数据2。
后续，手机中的AudioFlinger可调用Audio HAL，将AudioFlinger输出的已解码的音频数据2发送给Audio HAL，由Audio HAL将该音频数据2发送给手机的扬声器或耳机等音频输出设备播放。类似的，手机中的SurfaceFlinger可将已解码的显示数据2通过display HAL发送至手机的显示屏中显示。这样，手机在向从设备投射视频APP中视频文件的同时，还可以运行其他的应用(例如上述微信APP)，播放其他应用中的显示数据和/或音频数据，使得用户可以在使用手机投屏的同时还能够使用手机中其他应用提供的应用功能。
当然，手机在运行视频APP进行投屏的过程中，Nuplayer1也可以按照上述方法对接收到的视频文件中的音频数据和显示数据进行解码，进而使用上述AudioTrack、AudioFlinger以及SurfaceFlinger等功能模块播放视频APP中的音频数据和/或显示数据，使得手机在投屏时可与从设备同步播放相关视频文件中的音频数据和/或显示数据，本申请实施例对此不做任何限制。
上述实施例中是以手机将视频APP中的视频文件投射至从设备中播放进行举例说明的，在本申请的另一些实施例中，手机还可以将应用中的音频文件投射至从设备中播放。同样，一个音频文件中也可以包括一个或多个数据包，当然，音频文件中还可以包括音频文件的格式、时长、名称等其他信息，这些信息与音频文件的数据包共同构成了该视频文件。
如图121所示，与运行视频APP类似的，手机在运行音乐APP播放音频文件A时，可在应用程序框架层中创建播放该音频文件A的Nuplayer。并且，音乐APP可将音频文件A以数据包的形式实时的下发给Nuplayer。
手机在运行音乐APP时，如果用户将音箱设置为手机的音频输出设备，如图121所示，则手机中的DV APP可将音箱作为从设备与音箱建立网络连接。进而，DV APP可向音乐APP发送第一广播消息，以通知音乐APP将正在播放的音频文件A投射至电视203中播放。音乐APP接收到上述第一广播消息后，可继续向Nuplayer发送音频文件A中待播放的数据包，例如数据包5。与上述视频文件A(或视频文件B)不同的是，音频文件A的数据包内包括相应的音频数据，但不包括显示数据。
如图121所示，Nuplayer接收到来自音乐APP下发的数据包5后，可调用MediaExtractor对数据包5进行解析和解封装，得到数据包5中的音频数据1以及该音频数据1的音频参数A。同样，音频参数A为数据包5中的音频数据1进行编码时使用的参数，例如编码格式、编码规格或版本、采样率、声道数目等参数，本申请实施例对此不做任何限制。
如图121所示，Nuplayer可通过DV APP将上述音频参数A发送给音箱的代理APP(或代理service)。音箱的代理APP(或代理service)可按照该音频参数A查询自身是否具有对应的音频解码能力。如果音箱具有对应的解码能力，则音箱的代理APP(或代理service)可向手机的DV APP(或代理service)发送第一响应消息，用于指示音箱能够对数据包5中的音频数据1进行解码。进而，手机的DV APP(或代理service)将第一响应消息发送给手机的Nuplayer，以指示音箱能够对数据包5中的音频数据1进行解码。并且，当音箱的代理APP(或代理service)确定自身具有对数据包5中音频数据1的音频解码能力后，还可以指示音箱的Nuplayer按照上述音频参数A创建对应的audio decoder。
后续，仍如图121所示，手机中的Nuplayer可将数据包5中提取到的未经解码的音频数据1发送给音箱的代理APP(或代理service)，音箱的代理APP(或代理service)可将该音频数据1发送至电视203的Nuplayer。Nuplayer可将接收到的音频数据1发送至audio decoder中进行解码，得到解码后的音频数据2。进而，audio decoder可将解码后的音频数据2通过AudioTrack输入AudioFlinger，由AudioFlinger对解码后的音频数据2进行音效设置等音频处理。最终，AudioFlinger可将输出的已解码的音频数据2通过HAL层的Audio HAL发送至音箱的扬声器中播放。
如果手机的音频输出设备没有发生改变，则Nuplayer可将数据包5之后音频文件A中其他数据包内的音频数据按照上述方法发送给音箱，由音箱利用自身的解码能力对接收到的音频数据解码后播放，从而将手机中音乐APP播放的音频文件A投射至音箱中播放。
与视频文件的投射过程类似的，手机在向从设备投射音频文件时，如果从设备具有对当前播放的音频文件的解码能力，则手机只需要对音频文件的数据包进行解析和解封装，将音频文件中未经解码的音频数据直接发送给从设备(例如音箱)。手机无需对数据包中的音频数据进行解码，也无需像现有技术一样对解码后的音频数据按照统一格式进行重新编码。从而简化了音频切换时主设备对音频数据的处理过程，也缩短了主设备向从设备进行投屏的耗时。
并且，上述音箱接收到的音频数据为音频文件A中未经解码的源数据，因此，该音频数据中不会出现因手机解码或重新编码等操作带来的失真。后续，音箱可直接对音频文件A中未经解码的源数据进行解码后播放，使得播放出的音频的保真度更高。
需要说明的是，与视频文件的投射过程类似的，当手机播放新的音频文件，或手机的音频输出设备(即从设备)改变时，手机可重新获取从设备对当前播放的音频文件的解码能力。如果从设备能够对当前播放的音频文件进行解码，则手机可按照上述方法将音频文件中未经解码的音频数据发送给从设备，由从设备对接收到的音频数据进行解码并播放，以降低主设备向从设备投射音频时的时延。
在分布式音频场景中，主设备可将自身的一项或多项与音频功能相关的业务(例如，音频播放业务、录音业务、视频播放业务或相机业务等)切换至从设备上执行，从而呈现多设备协同工作的分布式场景。
其中，某一业务可与应用中的一项或多项功能对应。例如，视频APP可提供用于实现投屏功能的视频播放业务。又例如，音频APP可提供用于实现音频播放功能的音 频播放业务，也可以提供用于实现音频录制功能的K歌业务。在分布式场景下，主设备可将某一业务切换至从设备上，此时，主设备可与从设备协同执行该业务。
示例性的，主设备可将正在播放的音频数据发送至从设备，由从设备播放该音频数据，从而将主设备的音频播放业务切换至从设备上执行。又例如，主设备可将视频中的显示数据发送至一个从设备播放，同时将视频中的音频数据发送至另一个从设备播放，从而将主设备的视频播放业务切换至多个从设备上执行。其中，一项业务中可以包括一个或多个子任务。例如，上述视频播放业务可以包括与显示功能相关的显示子任务以及与音频功能相关的音频子任务。
又例如，主设备可使用从设备的麦克风采集音频数据，并将采集到的音频数据发送至主设备保存或播放，从而将主设备的录音业务切换至从设备上执行。又例如，主设备可使用从设备的摄像头采集拍摄图像，并将拍摄图像发送至主设备显示，从而将主设备的相机业务切换至从设备上执行。
但是，在上述分布式音频场景中，主设备在向从设备切换某一业务时，可能会因为设备性能的差别等原因出现音频质量变差、显示质量变差、音画不同步或时延较长等业务质量问题。
对此，在本申请实施例中，主设备可以预测将当前业务切换至不同从设备上执行时的业务质量，进而，主设备可以根据预测结果向用户推荐执行上述业务的一个或多个电子设备。这样，用户可以按照主设备的推荐选择合适的设备与主设备协同工作执行相应的业务，从而提高分布式场景中主设备与从设备协同工作时的业务质量。
示例性的，如图122所示，主设备可以与一个或多个从设备建立网络连接。进而，当主设备准备将业务1切换至一个或多个从设备上执行时，主设备可以从每个从设备获取与业务1关联的设备参数。
例如，当业务1为相机业务时，与业务1关联的设备参数可以包括从设备支持的图像处理算法、摄像头的数目、摄像头的分辨率或者摄像头的FOV等。
又例如，当业务1为音频播放业务时，与业务1关联的设备参数可以包括从设备支持的音效算法、声道数目、采样率、混音策略以及喇叭的型号等。
又例如，当业务1为录音业务时，与业务1关联的设备参数可以包括从设备支持的语音处理算法、音频数据的编解码算法以及麦克风的数目等。
又例如，当业务1为显示业务时，与业务1关联的设备参数可以包括从设备支持的分辨率、帧率以及显示数据的编解码算法等。
仍如图122所示，主设备从每个从设备获取到与业务1关联的设备参数后，可根据获取到的设备参数预测各个从设备执行业务1的业务质量。进而，主设备可根据各个从设备执行业务1的业务质量确定对应的推荐设备。例如，主设备可以将执行业务1的业务质量最高的从设备确定为推荐设备。或者，主设备也可以在将业务1切换至某一从设备执行后，即主设备与从设备协同执行某一业务的过程中，从每个从设备获取与业务1关联的设备参数，并按照上述方法确定对应的推荐设备。
主设备确定出对应的推荐设备后，可将确定出的推荐设备推荐给用户。例如，主设备可显示提示消息，提示消息中可以携带推荐设备的标识。如果检测到用户点击推荐设备的标识，则可触发主设备将业务1重新切换至对应的推荐设备执行。
这样，用户可以通过上述提示消息及时获知当前分布式场景下适合执行上述业务1的具体设备。并且，用户可以通过上述提示消息中的标识快速切换执行上述业务1的具体设备，从而提高分布式场景中多设备协同工作时的业务质量，同时提高了用户的使用体验。
仍以手机为上述主设备举例，基于图6所示的Android系统的软件架构，如图123所示，可以在手机的应用程序框架层中设置预测感知模块21301。当手机与一个或多个从设备建立网络连接后，预测感知模块21301可以实时检测当前运行的业务。例如，音频播放业务、视频通话业务、直播业务或录音业务等。进而，预测感知模块21301可以根据当前运行的业务，从各个从设备中获取与该业务对应的设备参数。例如，该设备参数可以包括音频参数、显示参数或者相机参数等一项或多项参数。
其中，上述音频参数可以包括从设备支持的音效算法、声道数目、采样率、混音策略、音频数据的编解码算法、麦克风的数目和型号以及喇叭的数目和型号等一项或多项。音频参数可以反映出从设备的音频能力(例如放音能力或录音能力)。
上述显示参数可以包括从设备支持的分辨率、帧率以及显示数据的编解码算法等一项或多项。显示参数可以反映出从设备的显示能力。
上述相机参数可以包括从设备支持的图像处理算法、摄像头的数目、摄像头的分辨率或者摄像头的FOV(field of view，视场角)等一项或多项。相机参数可以反映出从设备的拍摄能力。
示例性的，手机的预测感知模块21301确定出与当前业务对应的设备参数后，可通过对应的DMSDP HAL从对应的从设备中获取该设备参数。例如，仍如图123所示，预测感知模块21301可以通过DMSDP HAL 1向从设备1发送获取请求，从设备1可响应该获取请求将自身的设备参数发送至手机的DMSDP HAL 1，再由DMSDP HAL 1将从设备1的设备参数发送至预测感知模块21301。这样，按照上述方法，预测感知模块21301可以从各个从设备获取到与当前业务对应的设备参数。
后续，预测感知模块21301可根据获取到的设备参数预测各个从设备执行上述业务时的业务质量。例如，预测感知模块21301可根据每个从设备的设备参数，对该从设备执行上述业务时的业务质量进行打分。进而，预测感知模块21301可将打分较高的一个或多个从设备作为推荐设备推荐给用户。例如，预测感知模块21301可将确定出的推荐设备上报给正在运行当前业务的APP，由APP将上述推荐设备携带在提示消息中，并将该提示消息显示在显示界面中。
这样，用户可以获知当前分布式场景下适合执行上述业务的推荐设备，从而将当前的业务切换至预测感知模块21301确定的推荐设备上执行，以提高分布式场景中多设备协同工作时的业务质量，同时提高了用户的使用体验。
以下将结合具体场景和示例详细阐述手机在分布式场景中向用户推荐执行不同业务时推荐设备的方法。
示例性的，用户可以在手机中选择一个或多个电子设备作为手机的从设备。例如，手机检测到用户打开控制中心的操作后，可以检测当前与手机接入同一通信网络的电子设备。例如，手机可以搜索与手机位于同一Wi-Fi网络中的一个或多个电子设备。又例如，手机可以在服务器中查询与手机登录同一账号(例如华为账号)的一个或多 个电子设备。进而，如图124所示，手机可将检测到的一个或多个电子设备显示在控制中心21401中。此时，用户可以在控制中心21401中选择一个或多个电子设备作为手机的从设备。
仍如图124所示，控制中心21401中显示有手机检测到的电视21402、音箱21403、手表21404以及电视21405。如果检测到用户点击电视21402，则手机的DV APP可将电视21402作为一个从设备与电视21402建立网络连接。进而，如图125所示，手机的DV APP可基于该网络连接从电视21402获取电视21402的能力参数，例如，电视21402的拍摄能力参数、音频能力参数以及显示能力参数等。后续，手机的DV APP可按照电视21402的能力参数在HAL中创建对应的DMSDP HAL 1，使得手机可通过DMSDP HAL 1与电视21402交互。
类似的，如果还检测到用户点击音箱21403，仍如图125所示，则手机可按照上述方法获取音箱21403的能力参数，并按照音箱21403的能力参数在HAL中创建对应的DMSDP HAL 2。如果还检测到用户点击电视21405，则手机可按照上述方法获取电视21405的能力参数，并按照电视21405的能力参数在HAL中创建对应的DMSDP HAL3。这样一来，手机可作为主设备可通过对应的DMSDP HAL与电视21402、音箱21403和电视21405这三个从设备进行交互，实现分布式场景下的各项业务。
手机或从设备执行的业务一般涉及音频功能、显示功能或相机功能中的一项或多项。例如，与音频功能相关的业务可包括音频播放、录音、K歌、游戏、语音通话或视频通话等业务。例如，与显示功能相关的业务可包括视频播放、视频通话、游戏等业务。又例如，与相机功能相关的业务可包括拍照、录像、直播、扫码或视频通话等业务。
在本申请实施例中，手机与上述从设备(例如电视21402、音箱21403和电视21405)建立网络连接后，手机中的预测感知模块21301可实时检测手机在分布式场景下正在执行的具体业务(后续实施例中可称为目标业务)。
示例性的，预测感知模块21301可以获取手机正在运行的应用的标识(例如应用的包名)，进而根据应用的标识确定正在执行的目标业务。例如，如果正在运行的应用为视频APP，则预测感知模块21301可确定目标业务为视频播放业务。
或者，预测感知模块21301还可以获取手机中各个器件的使用状态，结合器件的使用状态确定正在执行的目标业务。例如，当手机正在运行微信APP时，如果手机的前置摄像头为工作状态，则预测感知模块21301可确定目标业务为视频通话业务。相应的，如果手机的后置摄像头为工作状态，则预测感知模块21301可确定目标业务为扫码业务。
不同业务在运行时影响业务质量的设备参数可能不同。例如，对于音频播放业务，设备的喇叭数目、音效算法以及混音策略对业务质量的影响较大。又例如，对于直播业务，设备的显示分辨率、摄像头的型号、图像处理算法以及时延对业务质量的影响较大。
那么，如表21所示，手机中可预先存储不同业务与相关联的设备参数之间的对应关系。手机的预测感知模块21301确定出当前的目标业务后，可以根据表21所示的对应关系确定与目标业务关联的具体设备参数。进而，仍如图125所示，手机的预测感 知模块21301可通过对应的DMSDP HAL从每个从设备中获取与目标业务关联的设备参数。
表21
业务 设备参数
业务A 设备参数A、设备参数B
业务B 设备参数A、设备参数B、设备参数C
…… ……
以目标业务为音频播放业务举例，如图126所示，手机在运行音乐APP播放歌曲A时，用户可通过音频切换功能将歌曲A切换至电视21402中播放。手机的预测感知模块21301识别出当前的目标业务为音频播放业务后，可根据表21所示的对应关系确定出与音频播放业务相关的设备参数包括喇叭数目、音效算法以及混音策略这三项音频参数。进而，手机的预测感知模块21301通过调用DMSDP HAL 1，可从电视21402中获取电视21402的设备参数1，设备参数1中包括电视21402的喇叭数目、音效算法以及混音策略。并且，手机的预测感知模块21301通过调用DMSDP HAL 2，可从音箱21403中获取音箱21403的设备参数2，设备参数2中包括音箱21403的喇叭数目、音效算法以及混音策略。同样，手机的预测感知模块21301通过调用DMSDP HAL3，可从电视21405中获取电视21405的设备参数3，设备参数3中包括电视21405的喇叭数目、音效算法以及混音策略。
进而，手机的预测感知模块21301可根据获取到的设备参数1、设备参数2以及设备参数3，预测各个从设备执行音频播放业务时的业务质量。示例性的，手机中可预先存储不同业务中与各个设备参数对应的质量参数。例如，如表22所示，针对不同的业务，预先设置了与业务关联的各个设备参数的质量参数，每项质量参数可反映出对应业务对设备参数的需求。例如，在音频播放业务中，可设置与喇叭数目对应的质量参数为2个或2个以上，说明2个或2个以上的喇叭能够满足音频播放业务的业务需求。又例如，在直播业务中，可设置与时延对应的质量参数为500ms以内，说明500ms以内的时延可以满足直播业务的业务需求。
表22
Figure PCTCN2021104105-appb-000020
那么，手机的预测感知模块21301从电视21402中获取到设备参数1后，可结合表22中与音频播放业务对应的各项质量参数，预测电视21402使用设备参数1执行音频播放业务时的业务质量分数1。
例如，预测感知模块21301可结合表22中与音频播放业务对应的各项质量参数，对设备参数1中的每一项设备参数进行打分，即确定每一项设备参数的业务质量分数。例如，如果设备参数1中的喇叭数目为0个，则喇叭数目这一项设备参数的分数F1为0分；如果设备参数1中的喇叭数目为2个，则喇叭数目这一项设备参数的分数F1为60分；如果设备参数1中的喇叭数目为4个，则喇叭数目这一项设备参数的分数F1为80分。
按照上述打分方法，预测感知模块21301可以得到对设备参数1中喇叭数目打分的分数F1、对设备参数1中音效算法打分的分数F2以及对设备参数1中混音策略打分的分数F3。进而，预测感知模块21301可根据分数F1、分数F2以及分数F3计算电视21402使用设备参数1执行音频播放业务时的业务质量分数1。例如，预测感知模块21301可以按照预设的权重，计算分数F1、分数F2以及分数F3的加权平均值，并将计算出的加权平均值作为业务质量分数1。
类似的，预测感知模块21301从音箱21403中获取到设备参数2后，可按照上述方法预测音箱21403使用设备参数2执行音频播放业务时的业务质量分数2。并且，预测感知模块21301从电视21405中获取到设备参数3后，可按照上述方法预测电视21405使用设备参数3执行音频播放业务时的业务质量分数3。
在另一些实施例中，手机中也可预先存储不同业务中与各个设备参数对应的质量参数打分曲线或打分规则。仍以音频播放业务举例，如图127中的(a)所示，在音频播放业务中，不同喇叭数目与质量参数打分之间的对应关系为曲线1。预测感知模块21301可以根据曲线1，确定与设备参数1中喇叭数目这一项设备参数的分数F1。如图127中的(b)所示，为音频播放业务中，不同音效算法与质量参数打分之间的打分规则1。预测感知模块21301可以根据打分规则1，确定与设备参数1中音效算法这一项设备参数的分数F2。类似的，如图127中的(c)所示，为音频播放业务中，不同混音策略与质量参数打分之间的打分规则2。预测感知模块21301可以根据打分规则2，确定与设备参数1中混音策略这一项设备参数的分数F3。
进而，预测感知模块21301可根据分数F1、分数F2以及分数F3计算电视21402使用设备参数1执行音频播放业务时的业务质量分数1。当然，预测感知模块21301还可以按照上述方法获取音箱21403使用设备参数2执行音频播放业务时的业务质量分数2，以及电视21405使用设备参数3执行音频播放业务时的业务质量分数3。
手机的预测感知模块21301获取到上述业务质量分数1、业务质量分数2以及业务质量分数3后，可根据这些业务质量分数确定与当前音频播放业务对应的推荐设备。例如，如果业务质量分数2＞业务质量分数1＞业务质量分数3，说明音箱21403执行音频播放业务的业务质量高于当前电视21402执行音频播放业务的业务质量，则预测感知模块21301可将音箱21403确定为推荐设备。此时，仍如图125所示，预测感知模块21301可将确定出的推荐设备(即音箱21403)的标识上报给正在运行的APP(即音乐APP)。
进而，如图128所示，音乐APP可根据预测感知模块21301上报的推荐设备，在显示界面21801中显示提示消息21801。提示消息21801用于提示用户使用业务质量更高的音箱21403执行当前的音频播放业务。例如，提示消息21801中可以包括音箱 21403的标识21802。这样，在分布式场景中用户通过提示消息21801可以感知到其他从设备执行某一业务时的业务质量。后续，如果检测到用户点击音箱21403的标识21802，则手机可将当前的音频播放业务切换至音箱21403中继续执行，同时停止在电视21402上继续执行上述音频播放业务，从而提高音频播放业务的业务质量。
在一些实施例中，手机的预测感知模块21301也可以根据某一项设备参数的业务质量分数确定对应的推荐设备。例如，如果音箱21403的混音策略这一设备参数的打分高于其他从设备的混音策略这一设备参数的打分，但电视21402的音效算法这一设备参数的打分高于其他从设备的音效算法这一设备参数的打分，说明音箱21403的混音能力较高，而电视21402对音频数据的音效处理能力较高。此时，预测感知模块21301可将音箱21403作为推荐设备，并向音乐APP通知音箱21403的混音能力高于其他从设备。进而，如图129所示，音乐APP可在提示消息21901中提示用户音箱21403在音频播放业务中的混音能力更强。当然，音乐APP还可以在提示消息21901中提示用户当前播放音频数据的电视21402的音效处理能力更强。
这样，在分布式场景中用户可以感知到不同从设备执行某一业务时的不同业务能力，从而有选择性的选择相应的从设备执行该业务。
或者，预测感知模块21301可将确定出的推荐设备(例如音箱21403)通知给其他APP，例如，通知中心APP等系统APP。以通知中心APP举例，通知中心APP接收到来自预测感知模块21301发送的推荐设备的标识后，与图128或图129类似的，通知中心APP可以通知消息的形式提示用户使用业务质量更高的音箱21403执行当前的音频播放业务，本申请实施例对此不做任何限制。
又或者，预测感知模块21301还可以将确定出的推荐设备通过对应的DMSDP HAL1通知给正在执行音频播放业务的电视21402。进而，如图130所示，电视21402获取到手机发送的推荐设备的标识后可以显示提示消息22001，提示用户使用业务质量更高的音箱21403执行当前的音频播放业务。后续，如果电视21402检测到用户选中提示消息22001中音箱21403的标识，则电视21402可停止执行上述音频播放业务。同时，电视21402可向手机发送业务切换消息，使得手机可响应该业务切换消息将当前的音频播放业务切换至音箱21403中继续执行，从而提高音频播放业务的业务质量。
当然，如果预测感知模块21301确定出当前正在执行音频播放业务的电视21402为业务质量最高的设备，则预测感知模块21301可以向音乐APP通知当前执行音频播放业务的电视21402已为最优设备。此时，手机或电视21402可以不再向用户推荐其他设备执行该音频播放业务。
在另一些实施例中，手机的预测感知模块21301除了可以预测各个从设备(例如电视21402、音箱21403以及电视21405)执行音频播放业务时的业务质量分数外，还可以预测手机自身执行音频播放业务时的业务质量分数。
例如，手机的预测感知模块21301还可以获取与当前的音频播放业务关联的设备参数4，即手机中的喇叭数目、音效算法以及混音策略。进而，预测感知模块21301可按照上述方法预测手机使用设备参数4执行音频播放业务时的业务质量分数4。后续，预测感知模块21301可结合业务质量分数4以及与各个从设备对应的业务质量分数确定本次的推荐设备。也就是说，主设备(即手机)也可以作为推荐设备的一个候 选设备，当主设备执行目标业务(例如上述音频播放业务)的业务质量较高时，也可以提示用户使用主设备执行上述目标业务。
上述实施例中是以音频播放业务为例进行说明的，可以理解的是，当手机在分布式场景中执行其他与音频功能相关的业务时，也可以按照上述方法向用户推荐执行其他业务时业务质量更高的推荐设备。
示例性的，如图131所示，手机在运行视频APP时，手机可响应用户的投屏操作将视频APP中播放的视频B投射至电视21402中播放。在投屏过程中，手机可通过DMSDP HAL 1将视频B的显示数据发送给电视21402，同时，手机可通过DMSDP HAL1将视频B的音频数据发送给电视21402。
并且，在投屏过程中，手机的预测感知模块21301可识别出当前的目标业务为视频播放业务。进而，预测感知模块21301可根据表21所示的对应关系确定出与视频播放业务关联的设备参数。例如，与视频播放业务关联的设备参数可以包括显示屏的分辨率等与显示功能相关的显示参数，还可以包括麦克风的数目、音效算法等与音频功能相关的音频参数。
仍以手机的从设备包括电视21402、音箱21403以及电视21405举例，手机的预测感知模块21301确定出与视频播放业务关联的设备参数后，可通过对应的DMSDP HAL从每个从设备中获取与视频播放业务关联的设备参数。进而，预测感知模块21301可按照上述实施例中的方法，根据获取到的设备参数预测每个从设备执行视频播放业务时的业务质量分数，并根据每个从设备执行视频播放业务时的业务质量分数确定相应的推荐设备。
例如，如果电视21405执行视频播放业务时的业务质量分数高于电视21402执行视频播放业务时的业务质量分数，并且，电视21405执行视频播放业务时的业务质量分数高于音箱21403执行视频播放业务时的业务质量分数，则预测感知模块21301可将电视21405确定为本次执行视频播放业务的推荐设备。
进而，如图132中的(a)所示，预测感知模块21301可向视频APP通知当前的推荐设备为电视21405，使得视频APP可在显示界面中显示提示消息22201，提示用户使用业务质量更高的电视21405执行当前的视频播放业务。其中，提示消息22201中可以包括电视21405的标识。如果检测到用户点击电视21405的标识，则手机可将当前的视频播放业务切换至电视21405中继续执行，同时停止在电视21402上继续执行上述视频播放业务，从而提高本次视频播放业务的业务质量。
或者，如图132中的(b)所示，预测感知模块21301可将确定出的推荐设备通过对应的DMSDP HAL 1通知给正在执行视频播放业务的电视21402。电视21402确定本次执行视频播放业务的推荐设备为电视21405后，可以显示提示消息22202，以提示用户使用业务质量更高的电视21405执行当前的视频播放业务。类似的，如果电视21402检测到用户选中提示消息22202中电视21405的标识，则电视21402可停止执行上述视频播放业务。同时，电视21402可向手机发送业务切换消息，使得手机可响应该业务切换消息将当前的视频播放业务切换至电视21405中继续执行，从而提高音频播放业务的业务质量。
当然，如果预测感知模块21301确定出当前正在执行视频播放业务的电视21402 为业务质量最高的设备，则预测感知模块21301可以向视频APP通知当前执行视频播放业务的电视21402已为最优设备。此时，手机或电视21402可以不再向用户推荐其他设备执行该视频播放业务。
在另一些实施例中，手机的预测感知模块21301也可以根据不同从设备中不同设备参数的业务质量分数，确定多个从设备执行当前的视频播放业务(即目标业务)。此时，预测感知模块21301确定出的推荐设备可以有多个。
例如，预测感知模块21301可以从电视21402中获取与视频播放业务关联的设备参数1。设备参数1中包括电视21402的音频参数和显示参数。同样，预测感知模块21301可以从音箱21403中获取与视频播放业务关联的设备参数2。设备参数2中包括音箱21403的音频参数和显示参数。如果预测感知模块21301对设备参数1中显示参数的业务质量打分高于对设备参数2中显示参数的业务质量打分，则说明电视21402的显示能力比音箱21403的显示能力高。如果预测感知模块21301对设备参数2中音频参数的业务质量打分高于对设备参数1中音频参数的业务质量打分，则说明音箱21403的音频能力比电视21402的显示能力高。
此时，预测感知模块21301可以将音箱21403和电视21402这两个设备均确定为推荐设备，其中，电视21402可用于执行视频播放业务中与显示功能相关的第一子任务，音箱21403可用于执行视频播放业务中与音频功能相关的第二子任务。进而，预测感知模块21301可向手机的视频APP通知电视21402为执行第一子任务的推荐设备，音箱21403为执行第二子任务的推荐设备。进而，如图133所示，视频APP可按照预测感知模块21301通知的推荐设备显示提示消息22301。提示消息22301中可提示用户使用“电视21402+音箱21403”组成的设备组协同执行上述视频播放业务，使得用户可以享受到最优的视频播放业务质量。
后续，如果检测到用户选择提示消息22301中的确认按钮22302，则手机可将正在播放的视频B中的显示数据切换至电视21402播放(即将视频播放业务中的第一子任务切换至电视21402)，同时，将视频B中的音频数据切换至音箱21403播放(即将视频播放业务中的第二子任务切换至音箱21403)，通过多设备协同工作的方式提高视频播放业务的业务质量。
也就是说，主设备(例如手机)可以将当前的目标业务划分为多个子任务，进而根据各个从设备的设备参数为各个子任务确定最佳的推荐设备，从而将目标业务分布至多个推荐设备中执行，通过多设备协同工作的方式提高目标业务的业务质量。
除了在上述音频播放业务和视频播放业务中手机可以根据从设备的设备参数推荐对应的推荐设备外，当手机在执行与相机功能相关的业务时，手机也可以按照上述方法向用户推荐业务质量更高的推荐设备。
示例性的，手机在运行微信APP时，用户可打开微信APP的视频通话功能与联系人(例如联系人Sam)进行视频通话。如图134所示，在视频通话的过程中，手机可使用电视21402的摄像头采集图像数据，并且，手机可使用电视21402的显示屏显示视频通话界面。此时，手机可通过DMSDP HAL 1获取电视21402的摄像头采集到的图像数据，并且，手机可通过DMSDP HAL 1将视频通话界面的显示数据发送至电视21402中显示。
在视频通话的过程中，手机的预测感知模块21301可识别出当前的目标业务为视频通话业务。进而，预测感知模块21301可根据表21所示的对应关系确定出与视频通话业务关联的设备参数。例如，与视频通话业务关联的设备参数可以包括显示屏的分辨率等与显示功能相关的显示参数，还可以包括麦克风的数目、音效算法等与音频功能相关的音频参数，还可以包括摄像头的数目等与相机功能相关的相机参数，还可以包括时延等参数。
仍以手机的从设备包括电视21402、音箱21403以及电视21405举例，手机的预测感知模块21301确定出与视频通话业务关联的设备参数后，可通过对应的DMSDP HAL从每个从设备中获取与视频通话业务关联的设备参数。进而，预测感知模块21301可按照上述实施例中的方法，预测每个从设备执行视频通话业务时的业务质量分数，并根据每个从设备执行视频通话业务时的业务质量分数确定推荐设备。
例如，如果电视21405执行视频通话业务时的业务质量分数高于电视21402执行视频通话业务时的业务质量分数，并且，电视21405执行视频通话业务时的业务质量分数高于音箱21403执行视频通话业务时的业务质量分数，则预测感知模块21301可将电视21405确定为本次执行视频通话业务的推荐设备。
进而，如图135中的(a)所示，预测感知模块21301可向微信APP通知当前的推荐设备为电视21405，使得微信APP可在显示界面中显示提示消息22501，提示用户使用业务质量更高的电视21405执行当前的视频通话业务。或者，如图135中的(b)所示，预测感知模块21301可将确定出的推荐设备通过对应的DMSDP HAL 1通知给正在执行视频通话业务的电视21402，由电视21402显示提示消息22502，以提示用户使用业务质量更高的电视21405执行当前的视频通话业务。
另外，对于视频通话业务、直播业务或K歌业务等实时性需求较高的业务，手机的预测感知模块21301还可以预测执行对应业务所需的时延，基于预测出的时延推荐相应的推荐设备。也就是说，对于实时性需求较高的业务，可将各个设备执行该业务所需的时延作为该业务质量高低的判断标准。例如，手机在计算各个设备执行该业务的业务质量分数时可将时延这一设备参数的权重值设置为1，此时，当前业务的业务质量完全依赖于时延这一设备参数。
仍以视频通话业务举例，手机的预测感知模块21301识别出当前的目标业务为视频通话业务后，可获取与每个从设备之间的网络时延，以及每个从设备执行视频通话业务的处理时延。这样，在分布式场景下每个从设备执行视频通话业务的时延为网络时延与处理时延之和。
以电视21402与手机之间的网络连接为Wi-Fi连接举例，手机的预测感知模块21301可调用Wi-Fi HAL检测手机与电视21402之间的网络时延L11。并且，预测感知模块21301可通过DMSDP HAL 1从电视21402获取电视21402执行视频通话业务的处理时延L12。进而，预测感知模块21301可计算出电视21402执行视频通话业务的时延L1＝L11+L12。类似的，预测感知模块21301还可以按照上述方法计算出音箱21403执行视频通话业务的时延L2以及电视21405执行视频通话业务的时延L3。
示例性的，如果表22中设置了视频通话业务中时延的质量参数为500ms以内，说明500ms以内的时延可以满足视频通话业务的业务质量需求。那么，如果手机的预 测感知模块21301计算出电视21402执行视频通话业务的时延L1大于500ms，而电视21405执行视频通话业务的时延L3小于500ms，则预测感知模块21301可将电视21405确定为本次视频通话业务的推荐设备。此时，如图136所示，预测感知模块21301可向微信APP通知当前的推荐设备为电视21405，使得微信APP按照该推荐设备在显示界面中显示提示消息22601，提示用户使用时延更低的电视21405执行当前的视频通话业务。当然，也可以在正在执行视频通话业务的电视21402中显示上述提示消息，本申请实施例对此不做任何限制。
在一些实施例中，当电视21402执行视频通话业务的时延L1大于500ms时，手机的预测感知模块21301还可以进一步分析时延L1超过500ms的具体原因。例如，如果是因为电视21402与手机之间的网络时延L11大于阈值1导致时延L1超过500ms，说明当前的网络状态较差，与各个从设备交互时的时延均较长，则预测感知模块21301可将手机自身确定为执行本次视频通话业务的推荐设备。此时，如图137中的(a)所示，预测感知模块21301可通知手机中的微信APP(或电视21402)显示提示消息22701，在提示消息22701中提示用户当前的网络状态较差，建议用户使用手机执行当前的视频通话业务。
或者，如果是因为电视21402执行视频通话业务的处理时延L12大于阈值2导致时延L1超过500ms，则预测感知模块21301可简化电视21402执行视频通话业务的处理过程。例如，预测感知模块21301可确定视频通话策略1，在视频通话策略1中电视21402无需对音频数据进行音效处理。又例如，预测感知模块21301可确定视频通话策略2，在视频通话策略2中电视21402可使用指定的编解码算法对显示数据进行编解码处理。进而，如图137中的(b)所示，预测感知模块21301可通知手机中的微信APP(或电视21402)按照确定出的视频通话策略显示提示消息22702，在提示消息22702中提示用户简化电视21402执行视频通话业务的处理过程，以降低执行视频通话业务的时延。后续，如果检测到用户选择提示消息22702中的确认按钮，则预测感知模块21301可通过对应的DMSDP HAL 1向电视21402发送上述视频通话策略，使得电视21402可按照该视频通话策略简化执行视频通话业务的处理过程，从而降低整个视频通话业务的时延，提高视频通话业务的业务质量。
当然，手机的预测感知模块21301也可以在确定出简化视频通话业务处理过程的视频通话策略后，直接向电视21402发送上述视频通话策略，使得电视21402可以按照该视频通话策略简化执行视频通话业务的处理过程。此时，手机(或电视21402)可显示提示消息提示用户已经简化了视频通话业务的处理过程，以降低整个视频通话业务的时延。
又或者，如果电视21402与手机之间的网络时延L11大于阈值1，且电视21402执行视频通话业务的处理时延L12大于阈值2，则预测感知模块21301可在其他从设备中选择执行视频通话业务时时延小于500ms的从设备作为推荐设备。进而，与图136类似的，预测感知模块21301可通知手机中的微信APP(或电视21402)显示对应的提示消息，提示用户使用时间更低的电子设备执行当前的视频通话业务。
上述实施例中是以手机作为主设备在与从设备协同执行某一项业务的过程中向用户推荐更适合执行该业务的推荐设备为例说明的，在另一些实施例中，手机还可以在 检测到手机将作为主设备执行某一业务时，提前向用户推荐更适合执行该业务的推荐设备。
仍以手机的从设备包括电视21402、音箱21403以及电视21405举例，如图138中的(a)所示，手机的下拉菜单22801中可以设置投屏按钮22802。如果检测到用户点击投屏按钮22802，说明手机开启了投屏功能准备执行投屏业务(例如视频播放业务)。此时，手机的预测感知模块21301可按照上述实施例中的方法从各个从设备中获取与投屏业务关联的设备参数，并且根据获取到的设备参数预测各个从设备执行投屏业务时的业务质量分数，从而按照预测出的业务质量分数向用户推荐对应的推荐设备。
例如，当预测感知模块21301预测出电视21405执行投屏业务时的业务质量分数1高于电视21402执行投屏业务时的业务质量分数2，且电视21402执行投屏业务时的业务质量分数2高于音箱21403执行投屏业务时的业务质量分数3时，说明电视21405、电视21402以及音箱21403这三个从设备执行投屏业务的业务质量依次降低。那么，如图138中的(b)所示，手机可响应用户点击投屏按钮22802的操作显示设备列表222803。在设备列表222803中，手机可以按照执行投屏业务的业务质量分数由高至低的顺序排列各个从设备。用户可在设备列表222803中选择将手机中的内容投射至哪个从设备中播放，上述排列顺序可推荐用户使用业务质量分数较高的设备执行本次投屏业务，以提高后续投屏业务的业务质量。
又或者，手机的预测感知模块21301可根据获取到的设备参数预测不同从设备在执行投屏业务时的具体业务质量。例如，预测感知模块21301可根据电视21402的设备参数预测电视21402在执行投屏业务时可能出现音画不同步的现象。又例如，预测感知模块21301可根据音箱21403的设备参数预测音箱21403在执行投屏业务时无法显示显示数据。进而，如图139所示，手机可响应用户点击投屏按钮22802的操作显示设备列表222803。在设备列表222803中，手机可向用户提示每一从设备执行本次投屏业务的具体业务质量，即向用户通知推荐或不推荐某一设备执行该投屏业务的具体原因。
也就是说，在分布式场景中，手机作为主设备可以在执行某一业务之前，预测出将该业务切换至各个从设备上执行时的具体业务质量，从而在用户选择执行该业务的从设备时向用户提示业务质量较好的从设备。这样，手机可以在与多设备协同工作之前向用户推荐适合执行本次业务的推荐设备，从而方便用户将本次业务切换至推荐设备上执行，以提高分布式场景中多设备协同工作时的业务质量，同时提高用户的使用体验。
目前，如图140所示，在室内进行超声波定位时需要安装多个超声波接收器23001，超声波接收器23001可与控制器(图中未示出)相连。电子设备23002开启定位功能后发射超声波信号。不同位置的超声波接收器23001接收到电子设备23002发出的超声波信号后，控制器可基于超声波信号到达不同超声波接收器23001的到达时间(Time of Arrival，TOA)或到达时间差(Time Different Of Arrival，TDOA)对电子设备23002进行定位。在这种定位场景中，用户需要购买并安装超声波接收器23001等器件，才能实现对电子设备23002的定位，操作过程较为复杂，且实现成本较高。
在本申请实施例中，主设备上可以设置多个超声波接收器。例如，这多个超声波接收器可以为麦克风阵列中的多个麦克风，每个麦克风可用于采集到超声波信号。从设备上可以设置超声波发生器。例如，该超声波发生器可以为扬声器，扬声器可用于发射超声波信号。主设备可用于通过超声波信号对从设备进行定位。
仍以手机为主设备举例，手机的多个超声波接收器可以设置在手机内部，或者，也可以将多个超声波接收器组装在手机的外部。在一些场景下，用户可向手机输入查询手机附近设备所在位置的指令。例如，如图141所示，手机的控制中心23101中设置有查询附近设备的按钮23102，如果检测到用户点击按钮23102，则手机可获取当前与手机接入同一通信网络的电子设备。例如，手机可以搜索与手机位于同一Wi-Fi网络中的一个或多个电子设备。又例如，手机可以在服务器中查询与手机登录同一账号(例如华为账号)的一个或多个电子设备。
以手机与电视、音箱1和音箱2位于同一通信网络举例，手机搜索到电视、音箱1和音箱2后，可将电视、音箱1和音箱2作为从设备，对从设备进行定位，以确定手机附近的电视、音箱1和音箱2(即从设备)的位置。
在一些实施例中，手机可以分别向电视、音箱1和音箱2发送定位指令。电视接收到上述定位指令后，可响应该定位指令通过超声波发生器发射超声波信号1。手机中麦克风阵列内的多个麦克风均可接收到超声波信号1，进而，手机基于麦克风阵列中各个麦克风接收到超声波信号1的时间，通过TDOA算法可计算定位结果1，即电视的位置。其中，上述超声波发生器可以为扬声器，这样，电视等从设备不需要额外新增超声波发生器来适配本申请实施例提供的超声波定位方法。同样，手机等主设备中用于接收超声波信号的超声波接收器可以为手机的麦克风，使得手机也不需要额外新增超声波接收器来适配本申请实施例提供的超声波定位方法，从而降低室内定位的实现成本和难度。
类似的，音箱1接收到上述定位指令后，可响应该定位指令通过超声波发生器(例如扬声器)发射超声波信号2。手机中麦克风阵列内的多个麦克风均可接收到超声波信号2。进而，手机基于麦克风阵列中各个麦克风接收到超声波信号2的时间，通过TDOA算法可计算定位结果2，即音箱1的位置。
类似的，音箱2接收到上述定位指令后，可响应该定位指令通过超声波发生器(例如扬声器)发射超声波信号3。手机中麦克风阵列内的多个麦克风均可接收到超声波信号3。进而，手机基于麦克风阵列中各个麦克风接收到超声波信号3的时间，通过TDOA算法可计算定位结果3，即音箱2的位置。
后续，如图142所示，手机可根据计算出的定位结果1、定位结果2以及定位结果3，显示定位界面23201，定位界面23201中呈现出了手机与电视、音箱1和音箱2之间的位置关系，使用户可以直观的看到手机与附近的各个设备之间的位置关系。
在另一些实施例中，仍以手机作为主设备，将电视、音箱1和音箱2作为从设备，主设备对从设备进行定位举例。首先，手机可在电视、音箱1和音箱2中选择一个从设备作为协同设备，协同设备后续可与手机协同完成对其他从设备的定位过程。例如，手机可将电视、音箱1和音箱2中定位能力较强的设备作为协同设备。以电视为协同设备举例，手机可首先对电视进行定位，得到手机与电视之间的相对位置关系，即得 到第一定位结果。例如，手机可向电视发送定位指令，电视可响应该定位指令通过扬声器等超声波发生器发射超声波信号1。手机中麦克风阵列内的多个麦克风可接收到超声波信号1，那么，手机基于麦克风阵列中各个麦克风接收到超声波信号1的时间，通过TDOA算法可计算手机与电视之间的位置关系。
进而，手机可向其他从设备发送定位指令，并且，手机可指示电视打开定位功能协同手机对其他从设备进行定位。例如，手机可向音箱1发送定位指令，并向电视发送协同定位指令。如图143所示，音箱1可响应手机发送的定位指令发射超声波信号2。电视可响应手机发送的协同定位指令打开其麦克风阵列，通过其麦克风阵列中的多个麦克风接收到超声波信号2。并且，手机也可通过其麦克风阵列中的多个麦克风接收到超声波信号2。
在一种实现方式中，电视可将自身检测到的超声波数据(例如，该超声波数据可包括每个麦克风接收到的超声波信号2的波形，超声波信号2的到达时间等信息)发送给手机。这样，手机不仅可以获取到自身麦克风阵列检测到的超声波数据(即第一超声波数据)，还可以获取到电视中的麦克风阵列检测到的超声波数据(即第二超声波数据)。当手机已经确定出与电视之间的位置关系后，手机可以将电视中的麦克风阵列作为自身麦克风阵列中的一部分。那么，手机可以将手机和电视中的各个麦克风作为一个完整的麦克风阵列，根据第一超声波数据和第二超声波数据计算出音箱1的位置。
在另一种实现方式中，电视中麦克风阵列的各个麦克风检测到超声波信号2后，电视可以根据超声波信号2到达各个麦克风的时间计算对音箱1的超声定位结果(即第一超声定位结果)。并且，电视可将第一超声定位定位结果发送给手机。手机中麦克风阵列的各个麦克风检测到超声波信号2后，也可以根据超声波信号2到达各个麦克风的时间计算对音箱1的定位结果(第二超声定位结果)。当手机接收到电视发来的第一超声定位定位结果后，还以根据第一超声定位定位结果对自身计算出的第二超声定位结果进行修正，最终确定出音箱1的位置。
在上述手机与电视协同工作对音箱1定位的场景中，音箱1发射的超声波信号2可以被手机和电视1中的麦克风接收，使得检测超声波信号2的麦克风的数量更多，因此，手机根据超声波信号2到达各个麦克风的时间计算出的定位结果的精度更高。并且，检测超声波信号2的麦克风来自手机和电视中的不同位置，使得手机可以根据多个方向检测到的超声波信号2对音箱1进行定位，也可以提高对音箱1的定位精度。
上述实施例中是以手机与电视协同对音箱1进行定位举例说明的，可以理解的是，手机与电视还可以通过上述方法对音箱2进行定位，得到音箱2的位置。当然，如果手机的从设备还包括其他设备，则手机还可以按照上述方法对其他设备进行定位，本申请实施例对此不做任何限制。
最终，与图142所示的定位界面401类似的，手机(即主设备)可根据对各个从设备的定位结果向用户呈现出手机以及各个从设备之间的位置关系，使用户可以直观的看到手机与附近的各个设备之间的位置关系。
可以看出，本申请实施例中，主设备可以利用电子设备中现有的超声波定位能力(例如，扬声器发射超声波信号的能力或麦克风接收超声波信号的能力)，通过多设 备协同的方式同时开启多个设备的麦克风接收从设备发出的超声波信号，对从设备进行定位，从而提高从设备的定位精度，同时也简化了室内定位的操作过程和实现成本。
仍以手机为主设备举例，基于图6所示的Android系统架构，如图144所示，手机的应用程序框架层中设置有AudioRecord、AudioTrack、AudioFlinger以及超声波处理模块等一个或多个音频功能模块。
示例性的，手机可具有接收超声波信号的能力。例如，AudioRecord可从AudioFlinger中获取手机麦克风等器件录制的超声波信号。当手机设置有多个麦克风(即麦克风阵列)时，AudioFlinger可接收到多个麦克风上报的多路超声波信号。此时，超声波处理模块可将AudioFlinger中的多路超声波信号进行合并后发送给AudioRecord，AudioRecord可将录制得到的超声波信号上报给定位应用等应用。
示例性的，手机可具有发射超声波信号的能力。例如，AudioTrack可响应定位应用等应用的指令调用AudioFlinger，通过AudioFlinger控制手机的扬声器等器件发射超声波信号。
仍如图144所示，手机的HAL中提供了与手机的不同硬件模块对应的HAL，例如，Audio HAL、Camera HAL、Wi-Fi HAL等。
其中，Audio HAL通过内核层的超声波驱动可与麦克风等超声波接收器对应。当手机设置有多个麦克风时，这多个麦克风分别与内核层的多个超声波驱动对应。每个麦克风可将接收到的超声波信号通过对应的超声波驱动上报给Audio HAL。Audio HAL可将接收到的多路超声波信号上报给AudioFlinger，由AudioFlinger将接收到的超声波信号发送给超声波处理模块。
例如，超声波处理模块接收到N路超声波信号后，可将这N路超声波信号合并为一组超声波数据。该超声波数据中可以包括每一路超声波信号的波形、每一路超声波信号到达对应麦克风的时间等信息。进而，超声波处理模块可根据上述超声波数据，使用TOA算法或TDOA算法确定发射该超声波信号的设备(例如从设备1)的定位结果。后续，超声波处理模块可将本次定位结果通过AudioRecord上报给定位应用。
或者，超声波处理模块将上述N路超声波信号合并为一组超声波数据后，可将该超声波数据通过AudioRecord上报给定位应用。进而，可由定位应用根据上述超声波数据确定发射该超声波信号的设备(例如从设备1)的定位结果，本申请实施例对此不做任何限制。
在本申请实施例中，如图145所示，手机可在HAL中创建与从设备(例如从设备1)对应的DMSDP HAL。DMSDP HAL与手机当前连接的从设备1对应。手机可作为主设备通过DMSDP HAL与从设备1进行数据收发，将从设备1作为手机的一个虚拟设备，与从设备1协同完成分布式场景中的各项业务。
例如，当手机与从设备1的位置关系一定时，如果手机需要对另一从设备(例如从设备2)进行定位，则手机可向从设备2发送定位指令，使得从设备2响应该定位指令使用扬声器等超声波发生器发射超声波信号。同时，手机可向从设备1发送协同定位指令，使得从设备1响应该协同定位指令打开自身的麦克风阵列接收超声波信号。
一方面，仍如图145所示，手机中的N个麦克风均可用于接收从设备2发射的超声波信号，即手机可采集到N路超声波信号(即第一超声波数据)。这N个麦克风可 分别将采集到的超声波信号上报给Audio HAL，使得Audio HAL获取到N路超声波信号。Audio HAL可将获取到的N路超声波信号通过AudioFlinger上报给超声波处理模块。
另一方面，仍如图145所示，从设备1打开自身的麦克风阵列后，该麦克风阵列中的M个麦克风也可用于接收从设备2发射的超声波信号，即从设备1可采集到M路超声波信号(即第二超声波数据)。那么，从设备1可将采集到的M路超声波信号通过手机中的DMSDP HAL发送给手机的AudioFlinger，进而由AudioFlinger将这M路超声波信号上报给超声波处理模块。
这样一来，手机的超声波处理模块既可以获取到手机中麦克风阵列采集到的N路超声波信号(即第一超声波数据)，还可以获取到从设备1中麦克风阵列采集到的M路超声波信号(即第二超声波数据)。后续，超声波处理模块可以将上述N路超声波信号和M路超声波信号合并成一组多声道超声数据。该多声道超声数据可以包括：上述N路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间，以及上述M路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间。进而，超声波处理模块可将上述多声道超声数据上报给定位应用，由定位应用根据该多声道超声数据使用预设的定位算法(例如TOA算法或TDOA算法)计算从设备2的位置。
或者，超声波处理模块可直接根据该多声道超声数据使用预设的定位算法计算从设备2的位置，并将从设备2的位置上报给定位应用，本申请实施例对此不做任何限制。
可以看出，手机在对从设备2进行定位时，可利用从设备1的定位能力，通过与从设备1协同的方式同时开启手机和从设备1的麦克风接收从设备2发出的超声波信号。这样，在定位场景下，采集超声波信号的麦克风的数量增加，并且，采集超声波信号的麦克风位于手机和从设备1的不同位置，手机可以根据更多数量和更多方向的超声波信号对从设备2进行定位，从而提高设备的定位精度。
同时，上述定位过程中利用了手机以及从设备(例如从设备1和从设备2)中现有的超声波定位能力(例如，扬声器发射超声波信号的能力或麦克风接收超声波信号的能力)，不需要改变手机以及从设备中的硬件结构，可简化用户进行室内定位时的操作过程并降低室内定位的实现成本。
仍以手机为主设备举例，以下将结合附图具体阐述本申请实施例提供的一种超声波定位方法。
在一些实施例中，如图146所示，手机可在下拉菜单23601等位置设置投屏按钮23602。当用户需要使用手机的投屏功能时，可点击投屏按钮23602。如果检测到用户点击投屏按钮23602，手机需要向用户呈现附近的电子设备，以便用户选择具体的投屏设备，触发手机将手机中的内容投射至投屏设备中播放。在本申请实施例中，当检测到用户点击投屏按钮23602后，手机可使用本申请实施例提供的超声波定位方法对手机附近的电子设备进行定位，并根据定位结果向用户呈现手机附近的电子设备，以便用户选择相应的投屏设备。
示例性的，手机检测到用户点击投屏按钮23602后，手机可搜索当前与手机接入 同一通信网络的一个或多个电子设备。例如，手机可通过服务器查询与手机登录同一账号的一个或多个电子设备。例如，当前与手机登录同一账号的电子设备包括电视1、音箱2、音箱3以及空气净化器4。进而，手机可获取电视1、音箱2、音箱3以及空气净化器4的定位能力。例如，服务器中可以存储电视1、音箱2、音箱3以及空气净化器4的定位能力。手机可以从服务器中获取到电视1、音箱2和音箱3具有定位能力，而空气净化器4不具有定位能力。其中，电视1的定位能力高于音箱2和音箱3的定位能力。那么，手机可将具有定位能力的电视1、音箱2和音箱3作为本次定位过程中手机的从设备，对电视1、音箱2和音箱3进行定位。
示例性的，当某一电子设备上设置的麦克风的数量越多时，可设置该电子设备的定位能力越高。或者，当某一电子设备上设置的麦克风之间的间距越大时，可设置该电子设备的定位能力越高。或者，当某一电子设备的处理器等硬件参数的性能越高时，可设置该电子设备的定位能力越高，本申请实施例对此不做任何限制。
在一些实施例中，手机可在电视1、音箱2和音箱3中选择定位能力最高的电视1作为协同设备。确定电视1为协同设备后，手机可首先对电视1进行定位，进而，手机可与电视1协同完成对其他从设备(例如音箱2和音箱3)的定位过程。
示例性的，如图147所示，电视1中操作系统的架构与手机中操作系统的架构类似。电视1的应用程序层中可以安装代理应用，代理应用用于与其他设备(例如手机)进行数据收发。电视1的应用程序框架层中设置有AudioTrack、AudioFlinger、AudioRecord(图中未示出)等音频功能模块。电视1的HAL中设置有Audio HAL，Audio HAL与电视1内核层的超声波驱动对应。电视1的超声波驱动可驱动硬件层中的扬声器等超声波发生器发射超声波信号。或者，电视1的超声波驱动还可以驱动电视1的麦克风阵列(图147中未示出)采集超声波信号。
仍如图147所示，手机将电视1确定为协同设备后，手机可通过定位应用向电视1中的代理应用发送定位指令1，定位指令1用于触发电视1发射超声波信号。电视1的代理应用接收到定位指令1后，可响应定位指令1调用AudioTrack，由AudioTrack通过AudioFlinger向Audio HAL发送超声波发射指令。Audio HAL可响应该超声波发射指令向超声波驱动发送驱动信号，使得超声波驱动可响应该驱动信号驱动电视1的扬声器发射超声波信号。
仍如图147所示，手机上的麦克风阵列可采集到电视1的扬声器发射的超声波信号。以手机的麦克风阵列中包括N个麦克风举例，这N个麦克风中的每个麦克风均可将采集到的超声波信号通过对应的超声波驱动上报给手机的Audio HAL。那么，手机的Audio HAL可以接收到超声波信号1、超声波信号2等N路超声波信号。手机的Audio HAL可将这N路超声波信号通过AudioFlinger上报给手机的超声波处理模块。如图148所示，由于手机的N个麦克风设置在手机的不同位置，因此，不同麦克风采集到的超声波信号的波形可能不同，不同麦克风采集到超声波信号的时间也可能不同。超声波处理模块可将接收到的N路超声波信号合并为一个多声道超声数据，该多声道超声数据中的N个声道与上述N路超声波信号一一对应，并且，该多声道超声数据中记录有每一个超声波信号的采集时间，即超声波信号达到对应麦克风的时间。进而，手机的超声波处理模块可根据上述多声道超声数据，使用预设的定位算法对电视1进 行定位，得到电视1的定位结果1。
例如，手机的超声波处理模块可根据超声波信号达到对应麦克风的时间，使用TOA算法或TDOA算法对电视1进行定位。当然，本领域技术人员还可以设置超声波处理模块使用其他定位算法对电视1进行定位，本申请实施例对此不做任何限制。
示例性的，上述超声波处理模块对电视1计算出的定位结果1可以为电视1在预设坐标系中的绝对位置坐标，也可以是电视1与手机之间的相对位置关系，本申请实施例对此不做任何限制。
例如，以手机为坐标原点O(0，0)，上述定位结果1可以包括电视1在坐标系中的位置坐标A1(X1，Y1)。此时，位置坐标A1(X1，Y1)可以指示电视1与手机之间的相对位置。手机的超声波处理模块可将定位结果1通过AudioRecord上报给定位应用，使得定位应用获知电视1的位置坐标。或者，手机的超声波处理模块也可以直接将上述多声道超声数据通过AudioRecord上报给定位应用，由定位应用根据该多声道超声数据计算电视1的定位结果1，本申请实施例对此不做任何限制。
此时，如图149所示，手机的定位应用获取到电视1的定位结果1后，可以根据定位结果1在交互界面23901中通过文字、动画或图标等形式显示电视1与手机的位置关系。例如，电视1位于手机正前方5米。由于手机还未得到音箱2、音箱3等其他从设备的定位结果，因此，定位应用可在交互界面23901中显示正在定位的提示信息23902，提示用户等待手机对其他从设备的进行定位。
示例性的，手机的定位应用获取到电视1的定位结果1后，手机可利用电视1的定位能力，通过与电视1协同完成对音箱2、音箱3等其他从设备的定位过程。
以手机与电视1协同对音箱2定位举例，如图150所示，音箱2中操作系统的架构与手机(或电视1)中操作系统的架构类似。音箱2的应用程序层中可以安装代理应用，代理应用用于与其他设备(例如手机和电视1)进行数据收发。音箱2的应用程序框架层中设置有AudioRecord(图中未示出)、AudioTrack、AudioFlinger等音频功能模块。音箱2的HAL中设置有Audio HAL，Audio HAL与音箱2内核层的超声波驱动对应。超声波驱动可驱动硬件层中的扬声器等超声波发生器发射超声波信号。
示例性的，仍如图150所示，手机的定位应用获取到电视1的定位结果1后，手机的定位应用可向音箱2的代理应用发送定位指令2，定位指令2用于触发音箱2发射超声波信号。同时，手机的定位应用可向电视1的代理应用发送协同定位指令，该协同定位指令用于触发电视1使用其M个超声波接收器检测音箱2发射的超声波信号。
与电视1响应上述定位指令1的过程类似的，音箱2的代理应用接收到定位指令2后，可响应定位指令2调用AudioTrack，由AudioTrack通过AudioFlinger向Audio HAL发送超声波发射指令。Audio HAL可响应该超声波发射指令向超声波驱动发送驱动信号，使得超声波驱动可响应该驱动信号驱动音箱2的扬声器发射超声波信号。
另一方面，仍如图150所示，电视1的代理应用接收到手机发来的协同定位指令后，电视1的代理应用可响应该协同定位指令打开自身的麦克风阵列接收超声波信号。此时电视1接收到的超声波信号为音箱2的扬声器发射的超声波信号。以电视1的麦克风阵列中包括M个麦克风举例，这M个麦克风中的每个麦克风均可将采集到的超声波信号通过对应的超声波驱动上报给电视1的Audio HAL。那么，电视1的Audio  HAL可以接收到超声波信号1、超声波信号2等M路超声波信号。电视1的Audio HAL可将这M路超声波信号上报给电视1的AudioFlinger，再由电视1的AudioRecord从AudioFlinger中录制得到上述M路超声波信号，并将这M路超声波信号上报给电视1的代理应用。电视1的代理应用可将自身采集到的M路超声波信号发送给手机的DMSDP HAL，由手机的DMSDP HAL将电视1采集到的M路超声波信号通过AudioFlinger上报给手机的超声波处理模块。也就是说，在对音箱2进行超声波定位时，手机的超声波处理模块可获取到协同设备(例如电视1)采集到的音箱2发射的超声波信号。
同时，仍如图150所示，手机上的麦克风阵列也可采集到音箱2的扬声器发射的超声波信号。例如，音箱2发射超声波信号后，手机上的N个麦克风可以可将采集到的超声波信号通过对应的超声波驱动上报给手机的Audio HAL。那么，手机的Audio HAL可以接收到超声波信号1、超声波信号2等N路超声波信号。手机的Audio HAL可将这N路超声波信号通过AudioFlinger上报给手机的超声波处理模块。
这样一来，手机在对音箱2进行超声波定位时，手机的超声波处理模块既可以获取到手机中麦克风阵列采集到的N路超声波信号(即第一超声波数据)，还可以获取到电视1中麦克风阵列采集到的M路超声波信号(即第二超声波数据)。进而，手机的超声波处理模块可以根据第一超声波数据和第二超声波数据对音箱2进行超声波定位。例如，手机的超声波处理模块可以将上述N路超声波信号和M路超声波信号合并成一组多声道超声数据。该多声道超声数据可以包括：上述N路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间，以及上述M路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间。进而，手机的超声波处理模块可基于上述多声道超声数据对音箱2进行超声波定位。
在一些实施例中，手机中麦克风阵列采集上述N路超声波信号时的采样率1可与电视1中麦克风阵列采集上述M路超声波信号时的采样率相同。例如，手机向电视1发送协同定位指令时，可在协同定位指令中携带预设的采样率A。这样，电视1可按照协同定位指令中携带的采样率A使用自身的麦克风阵列采集到上述M路超声波信号，同时，手机也可以按照上述采样率A使用自身的麦克风阵列采集到上述N路超声波信号。这样，手机的超声波处理模块可以对采样率相同的M路超声波信号和N路超声波信号进行合并，得到对应的多声道超声数据。
由于手机已经获取到电视1的定位结果1，即手机与电视1之间的位置关系是确定的，那么，电视1上的M个麦克风也可作为手机的麦克风使用，相当于手机的一部分麦克风(例如上述N个麦克风)设置在手机本机上，手机的另一部分麦克风(例如上述M个麦克风)设置在电视1上。进而，手机的超声波处理模块可以根据电视1的定位结果1(即上述M个麦克风的位置)、上述多声道超声数据中超声波信号分别到达上述M个麦克风和N个麦克风的时间，对发射超声波信号的音箱2进行定位，得到音箱2的定位结果2。
类似的，上述超声波处理模块对音箱2计算出的定位结果2可以为音箱2在预设坐标系中的绝对位置坐标，也可以是音箱2与手机之间的相对位置关系，本申请实施例对此不做任何限制。
例如，仍以手机为坐标原点O(0，0)，上述定位结果2可以包括音箱2在坐标系中的位置坐标A2(X2，Y2)。此时，位置坐标A2(X2，Y2)可以指示音箱2与手机之间的相对位置。手机的超声波处理模块可将定位结果2通过AudioRecord上报给定位应用，使得定位应用获知音箱2的位置坐标。或者，手机的超声波处理模块也可以直接将上述多声道超声数据通过AudioRecord上报给定位应用，由定位应用根据该多声道超声数据计算音箱2的定位结果2，本申请实施例对此不做任何限制。
此时，如图151所示，手机的定位应用获取到音箱2的定位结果2后，可以根据定位结果2在交互界面24101中通过文字、动画或图标等形式显示音箱2与手机等附近的设备之间的位置关系。例如，音箱2位于电视1的左边，并位于手机的左前方。
可以看出，手机在对音箱2进行定位时，可利用已定位的电视1的定位能力，通过与电视1协同的方式同时开启手机和电视1的麦克风接收音箱2发出的超声波信号。这样，在定位场景下，采集超声波信号的麦克风的数量增加，并且，采集超声波信号的麦克风的朝向的角度也更多，手机可以根据更多数量和更多方向的超声波信号对音箱2进行定位，从而提高设备的定位精度。
类似的，手机也可以按照上述方法与电视1协同对音箱3进行定位，得到音箱3的定位结果3。定位结果3中可以包括音箱3在上述坐标系中的位置坐标A3(X3，
Y3)。进而，如图152所示，手机的定位应用获取到音箱3的定位结果3后，可以根据定位结果3在交互界面24201中通过文字、动画或图标等形式显示音箱3与手机等附近的设备之间的位置关系。例如，音箱3位于电视的右边，并位于手机的右前方。如果此时手机的从设备除了电视1、音箱2以及音箱3之外没有其他需要定位的从设备，则手机的定位应用还可以在交互界面24201中提示用户已经完成对附近设备的搜索和定位，用户可以选择相应的设备进行投屏。
当然，手机的定位应用也可以在获取到电视1、音箱2以及音箱3等所有从设备的定位结果后，再在界面中显示手机与各个从设备之间的位置关系，本申请实施例对此不做任何限制。
在一些实施例中，手机在与电视1协同的过程中可以同时对音箱2和音箱3进行定位。例如，手机可以同时向音箱2和音箱3发送定位指令，触发音箱2和音箱3开始发射超声波信号。不同的是，音箱2和音箱3可在发射的超声波信号中携带自身的标识，例如，音箱2发送的超声波信号1中包括音箱2的标识，音箱3发送的超声波信号2中包括音箱3的标识。这样，手机可根据采集到的超声波信号中携带的标识识别来自音箱2的超声波信号1以及来自音箱3的超声波信号2。
在另一些实施例中，手机可以先与电视1协同对音箱2进行定位，再与电视1协同对音箱3进行定位。或者，手机可以先与电视1协同对音箱3进行定位，再与电视1协同对音箱2进行定位，直至获取到当前所有从设备的定位结果。
在另一些实施例中，手机还可以协同多个从设备对未定位的其他从设备进行定位。例如，手机按照上述方法对电视1定位后可得到电视1的定位结果1，并且，手机按照上述方法与电视1协同对音箱2定位后可得到音箱2的定位结果2。进而，手机可将电视1和音箱2均作为协同设备，继续对音箱3进行定位。
例如，手机向音箱3发送定位指令3的同时，还可以向电视1和音箱2(即两个 协同设备)发送协同定位指令。进而，与上述实施例中电视1作为协同设备与手机协同对其他从设备定位的方法类似的，音箱3可响应定位指令3使用扬声器发射超声波信号，电视1和音箱2可响应协同定位指令打开自身的麦克风阵列采集超声波信号，并将采集到的多路超声波信号发送给手机。同时，手机也可打开自身的麦克风阵列采集超声波信号。
以手机的麦克风阵列中包括N个麦克风，电视1的麦克风阵列中包括M个麦克风，音箱2的麦克风阵列中包括Z个麦克风举例，手机在对音箱3定位时可以获取到来自手机自身的N路超声波信号(即第一超声波数据)、来自电视1的M路超声波信号(即第二超声波数据)以及来自音箱2的Z路超声波信号(即第三超声波数据)。进而，手机可将这N路超声波信号、M路超声波信号以及Z路超声波信号合并为对应的多声道超声数据，使得手机的超声波处理模块(或定位应用)可根据该多声道超声数据计算音箱3的定位结果3。
这样一来，手机在对音箱3进行定位时，可同时利用已定位的电视1和音箱2这两个协同设备的定位能力，通过多设备协同的方式同时开启手机、电视1和音箱2的麦克风接收音箱3发出的超声波信号。这样，在定位场景下，采集超声波信号的麦克风的数量更多，并且，采集超声波信号的麦克风的朝向的角度也更多，手机可以根据更多数量和更多方向的超声波信号对音箱3进行定位，从而提高设备的定位精度。
当然，如果手机的从设备还包括其他设备未定位的设备，例如音箱4等，则手机可以按照上述方法增加新的协同设备继续对其他未定位的设备进行定位，本申请实施例对此不做任何限制。
另外，当手机采集到上述N路超声波信号后，无需对这N路超声波信号进行音效设置、混音等音频处理操作，以保证手机获取到的N路超声波信号为从设备发射的较为原始的超声波信号，从而提高后续定位过程的定位精度。类似的，手机的协同设备(例如上述电视1)采集到上述M路超声波信号后，也无需对这M路超声波信号进行音效设置、混音等音频处理操作，以保证手机获取到的M路超声波信号为从设备发射的较为原始的超声波信号，从而提高后续定位过程的定位精度。
在另一些实施例中，仍以手机与电视1协同对音箱2进行定位举例，如图153所示，电视1的应用程序层中也可以安装定位应用，电视1的应用程序框架层中也可以包括超声波处理模块。
在对音箱2进行定位时，手机中的N个麦克风可将采集到的超声波信号通过对应的超声波驱动上报给手机的Audio HAL，使得手机的Audio HAL可以接收到超声波信号1、超声波信号2等N路超声波信号。进而，手机的Audio HAL可将这N路超声波信号上报给手机的AudioFlinger。此时，手机的超声波处理模块可从AudioFlinger中获取到上述N路超声波信号，进而，手机的超声波处理模块可将这N路超声波信号合并为对应的多声道超声数据1，该多声道超声数据1可以包括：上述N路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间。进而，手机的超声波处理模块或定位应用可根据上述多声道超声数据1对音箱2进行定位，得到音箱2的定位结果2。
类似的，在对音箱2进行定位时，电视1中的M个麦克风可将采集到的超声波信 号通过对应的超声波驱动上报给电视1的Audio HAL，使得电视1的Audio HAL可以接收到超声波信号1、超声波信号2等M路超声波信号。电视1的Audio HAL可将这M路超声波信号上报给电视1的AudioFlinger。此时，电视1的超声波处理模块可从AudioFlinger中获取到上述M路超声波信号，进而，电视1的超声波处理模块可将这M路超声波信号合并为对应的多声道超声数据2，该多声道超声数据2可以包括：上述M路超声波信号中每一路超声波信号的波形以及每一路超声波信号到达对应麦克风的时间。那么，电视1的超声波处理模块或定位应用可根据上述多声道超声数据2对音箱2进行定位，此时，电视1也可以得到音箱2的定位结果2’。
进而，电视1中的定位应用可将计算出的音箱2的定位结果2’发送给手机的DMSDP HAL，由手机的DMSDP HAL将上述定位结果2’上报给手机的超声波处理模块。这样，手机的超声波处理模块既可以获取到手机对音箱2进行定位时计算的定位结果2，也可以获取到电视1对音箱2进行定位时计算的定位结果2’。进而，手机的超声波处理模块可以根据定位结果2’对自身计算出的定位结果2进行校正，得到校正后的音箱2的定位结果2，以提高音箱2的定位精度。
例如，手机对音箱2进行定位时计算得到的定位结果2包括音箱2的位置坐标A21，电视1对音箱2进行定位时计算得到的定位结果2’包括音箱2的位置坐标A22。那么，手机的超声波处理模块可以根据位置坐标A21和位置坐标A22使用预设的修正算法计算音箱2的位置坐标A2，即音箱2最终的定位结果。例如，手机的超声波处理模块可以对位置坐标A21和位置坐标A22进行加权平均后得到音箱2的位置坐标A2，本申请实施例对此不做任何限制。
当然，手机还可以按照上述方法继续对手机的其他从设备(例如音箱3)进行定位，本申请实施例对此不做任何限制。
仍以手机的从设备包括电视1、音箱2以及音箱3举例，如图154所示，手机在界面24201中显示出手机与电视1、音箱2以及音箱3之间的位置关系后，用户可以根据界面24201中显示出的各个从设备的位置关系方便、快捷的完成跨设备的内容投射操作。
例如，如果检测到用户拖动界面24201中手机的标识24401移动至定位出的电视1的位置，说明用户需要将手机中播放的内容投射至电视1中播放，则手机可以开始向电视1进行投屏操作。例如，手机可以通过Miracast协议或DLNA(DIGITAL LIVING NETWORK ALLIANCE，数字生活网络联盟)协议开始向电视1进行投屏操作，本申请实施例对此不做任何限制。
又例如，如果检测到用户拖动界面24201中手机的标识24401移动至定位出的音箱3的位置，说明用户需要将手机中的音频内容投射至音箱3中播放，则手机可以通过蓝牙协议将手机播放的音频内容投射至音箱3中播放。
上述实施例中是以用户在投屏或投音乐等场景下触发手机对从设备进行定位举例说明的，可以理解的是，本领域技术人员还可以设置在其他应用场景下使用上述超声波定位方法，本申请实施例对此不做任何限制。
示例性的，当用户将手机中播放的视频投射至电视1中播放后，手机可以自动按照上述实施例中提供的超声波定位方法开始对搜索到的从设备进行定位。如图155所 示，如果手机检测到电视1的左右两侧分别设置有音箱，例如音箱2和音箱3，则手机可以在界面24501中提示用户设置双声道立体声效果。例如，如果检测到用户点击界面24501中的确定按钮24502，则手机可以将向电视1投射的左声道音频数据发送给音箱2播放，并将向电视1投射的右声道音频数据发送给音箱3播放，从而在投屏过程中为用户呈现双声道立体声的音频播放效果。
在另一些实施例中，除了按照上述实施例中所述的定位方法通过超声波信号对电子设备进行定位外，上述实施例中所述的定位方法同样可以适用于其他声波信号，例如人耳可以识别的20Hz-20000Hz的声音信号。
示例性的，在会议场景中，可以为每一位参会用户的位置上设置具有上述定位功能的电子设备。如图156所示，当某一参会用户在发言时，各个电子设备可打开自身的麦克风阵列采集参会用户发言时发出的声音信号，进而按照上述定位方法确定发言的参会用户与其他参会用户之间的位置关系。此时，电子设备也可以在界面中显示此时发言的参会用户与其他参会用户之间的位置关系，从而向参会用户提示当前会议中正在发言的用户的位置。
需要说明的是，上述实施例中是以手机为定位场景中的主设备举例说明的，可以理解的是，定位场景中的主设备还可以是平板电脑、电视等具有上述定位功能的电子设备，本申请实施例对此不做任何限制。
需要说明的是，上述实施例中是以手机为分布式音频场景中的主设备举例说明的，可以理解的是，分布式音频场景中的主设备还可以是平板电脑、电视等具有音频功能的电子设备，本申请实施例对此不做任何限制。
另外，上述实施例中是以Android系统为例阐述的各个功能模块之间实现音频控制的具体方法，可以理解的是，也可以在其他操作系统中设置相应的功能模块实现上述音频控制方法。只要各个设备和功能模块实现的功能和本申请的实施例类似，即属于本申请权利要求及其等同技术的范围之内。
如图157所示，本申请实施例公开了一种电子设备，该电子设备可以为上述主设备(例如手机)。该电子设备具体可以包括：触摸屏24701，所述触摸屏24701包括触摸传感器24706和显示屏24707；一个或多个处理器24702；存储器24703；通信模块24708；一个或多个应用程序(未示出)；以及一个或多个计算机程序24704，上述各器件可以通过一个或多个通信总线24705连接。其中，上述一个或多个计算机程序24704被存储在上述存储器24703中并被配置为被该一个或多个处理器24702执行，该一个或多个计算机程序24704包括指令，该指令可以用于执行上述实施例中主设备执行的相关步骤。
如图158所示，本申请实施例公开了一种电子设备，该电子设备可以为上述从设备(例如音箱、电视等)。该电子设备具体可以包括：一个或多个处理器24802；存储器24803；通信模块24806；一个或多个应用程序(未示出)；以及一个或多个计算机程序24804，上述各器件可以通过一个或多个通信总线24805连接。当然，从设备中也可以设置触摸屏等器件，本申请实施例对此不做任何限制。其中，上述一个或多个计算机程序24804被存储在上述存储器24803中并被配置为被该一个或多个处理器24802执行，该一个或多个计算机程序24804包括指令，该指令可以用于执行上述实 施例中从设备执行的相关步骤。
通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (179)

  1. 一种音频控制方法，其特征在于，包括：
    响应于用户输入的第一操作，第一设备显示候选设备列表，所述候选设备列表中包括至少一个具有音频输出功能的候选设备；
    响应于用户在所述候选设备列表中选择第二设备的操作，所述第一设备获取所述第二设备的音频能力参数，所述音频能力参数用于指示所述第二设备播放音频的硬件能力以及所述第二设备播放音频的软件能力；所述第二设备为音箱，或电视，或手机；
    所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略；
    所述第一设备按照所述第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据；
    所述第一设备将所述第二音频数据发送至所述第二设备，以使得所述第二设备对所述第二音频数据进行处理后播放，或者，以使得所述第二设备播放所述第二音频数据。
  2. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括音效参数，所述音效参数用于指示所述第二设备是否开启音效模式；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    若所述第二设备开启了音效模式，则所述第一设备在所述第一音频播放策略中设置对所述第一音频数据不进行音效处理；
    若所述第二设备没有开启音效模式，则所述第一设备在所述第一音频播放策略中设置对所述第一音频数据进行音效处理。
  3. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括音效参数，所述音效参数用于指示所述第二设备支持的音效模式；所述第一音频应用将音频播放的音效模式设置为第一音效模式；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    若所述第一音效模式为所述第二设备支持的音效模式，则所述第一设备在所述第一音频播放策略中设置对所述第一音频数据不进行音效处理；
    若所述第一音效模式不是所述第二设备支持的音效模式，则所述第一设备在所述第一音频播放策略中设置对所述第一音频数据按所述第一音效模式进行音效处理。
  4. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括目标采样率，所述目标采样率为所述第二设备支持的采样率；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    所述第一设备在所述第一音频播放策略中设置对所述第一音频数据按照所述目标采样率进行采样。
  5. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括目标声道数，所述目标声道数为所述第二设备支持的声道个数；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略， 包括：
    所述第一设备在所述第一音频播放策略中设置对所述第一音频数据按照所述目标声道数进行混音。
  6. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括时延参数，所述时延参数用于指示所述第二设备是否支持低时延的音频处理能力；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    若所述第二设备支持低时延的音频处理能力，则所述第一设备在所述第一音频播放策略中设置按照低时延模式处理所述第一音频数据；
    若所述第二设备不支持低时延的音频处理能力，则所述第一设备在所述第一音频播放策略中设置按照非低时延模式处理所述第一音频数据。
  7. 根据权利要求1所述的方法，其特征在于，所述音频能力参数包括时延参数，所述时延参数用于指示所述第二设备的音频播放时延；
    其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    若所述第二设备的音频播放时延小于预设值，则所述第一设备在所述第一音频播放策略中设置按照低时延模式处理所述第一音频数据；
    若所述第二设备的音频播放时延大于或等于预设值，则所述第一设备在所述第一音频播放策略中设置按照非低时延模式处理所述第一音频数据。
  8. 根据权利要求1-7中任一项所述的方法，其特征在于，所述第一设备的应用程序层安装有第一预设应用；其中，所述第一设备获取所述第二设备的音频能力参数，包括：
    所述第一设备通过运行所述第一预设应用从所述第二设备中获取所述第二设备的音频能力参数。
  9. 根据权利要求8所述的方法，其特征在于，在所述第一设备获取所述第二设备的音频能力参数之后，还包括：
    所述第一预设应用按照所述第二设备的音频能力参数在硬件抽象层HAL创建对应的硬件抽象模块；
    其中，所述第一设备将所述第二音频数据发送至所述第二设备，包括：
    所述第一设备调用所述硬件抽象模块，将所述第二音频数据发送至所述第二设备。
  10. 根据权利要求9所述的方法，其特征在于，所述第一设备的应用程序框架层包含音频策略模块；其中，所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略，包括：
    所述第一预设应用将所述第二设备的音频能力参数发送至所述音频策略模块，以使得所述音频策略模块根据所述第二设备的音频能力参数确定所述第一音频播放策略。
  11. 根据权利要求10所述的方法，其特征在于，所述第一设备的应用程序框架层包含音频处理器；其中，所述第一设备按照所述第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据，包括：
    所述音频处理器接收来自所述第一音频应用的第一音频数据；
    所述音频处理器按照所述音频策略模块输出的第一音频播放策略对所述第一音频数据进行第一处理后，输出第二音频数据。
  12. 根据权利要求11所述的方法，其特征在于，所述方法还包括：
    当所述第二设备的音频能力参数更新时，所述第一预设应用获取所述第二设备更新后的音频能力参数；
    所述第一预设应用将更新后的音频能力参数发送给所述音频策略模块，使得所述音频策略模块按照更新后的音频能力参数将所述第一音频播放策略更新为第二音频播放策略；
    所述音频策略模块将所述第二音频播放策略输出至所述音频处理器，以使得所述音频处理器按照所述第二音频播放策略对接收到的音频数据进行第二处理。
  13. 根据权利要求12所述的方法，其特征在于，在所述第一预设应用获取所述第二设备更新后的音频能力参数之后，还包括：
    所述第一预设应用按照更新后的音频能力参数更新所述硬件抽象模块，以使得所述硬件抽象模块支持向所述第二设备发送经过所述第二处理的音频数据。
  14. 根据权利要求11所述的方法，其特征在于，在所述第一设备将所述第二音频数据发送至所述第二设备之后，还包括：
    所述第一设备接收用户设置音量大小的第二操作；
    所述音频策略模块响应所述第二操作在所述第一音频播放策略中设置音量等级，得到第三音频播放策略；
    所述音频策略模块将所述第三音频播放策略输出至所述音频处理器，以使得所述音频处理器按照所述第三音频播放策略中设置的音量等级修改接收到的音频数据的增益。
  15. 根据权利要求11所述的方法，其特征在于，所述第一设备的应用程序层安装有第二音频应用；在所述第一设备将所述第二音频数据发送至所述第二设备之后，还包括：
    所述音频处理器接收来自所述第二音频应用的音频数据；
    当所述第二音频应用的音频数据与所述第一音频应用的音频数据的类型不同时，所述音频策略模块将所述第一音频播放策略更新为第四音频播放策略；
    所述音频策略模块将所述第四音频播放策略输出至所述音频处理器，以使得所述音频处理器按照所述第四音频播放策略对接收到的音频数据进行第三处理；
    所述音频处理器将经过所述第三处理的音频数据通过所述硬件抽象模块发送至所述第二设备。
  16. 根据权利要求11所述的方法，其特征在于，在所述第一设备将所述第二音频数据发送至所述第二设备之后，还包括：
    所述第一设备接收用户选择第三设备进行音频播放的第三操作，所述第三设备与所述第二设备不同；
    响应于所述第三操作，所述第一预设应用从所述第三设备中获取所述第三设备的音频能力参数；
    所述第一预设应用将所述第三设备的音频能力参数发送给所述音频策略模块，使 得所述音频策略模块按照所述第三设备的音频能力参数将所述第一音频播放策略更新为第五音频播放策略；
    所述音频策略模块将所述第五音频播放策略输出至所述音频处理器，以使得所述音频处理器按照所述第五音频播放策略对接收到的音频数据进行第四处理。
  17. 根据权利要求16所述的方法，其特征在于，在所述第一预设应用从所述第三设备中获取所述第三设备的音频能力参数之后，还包括：
    所述第一预设应用按照所述第三设备的音频能力参数更新所述硬件抽象模块，以使得更新后的所述硬件抽象模块支持向所述第三设备发送经过所述第四处理的音频数据。
  18. 根据权利要求1-7中任一项所述的方法，其特征在于，所述第一设备的应用程序层安装有第二预设应用，所述第二预设应用与第一预设应用相同或不同；其中，所述第一设备将所述第二音频数据发送至所述第二设备，包括：
    所述第一设备将所述第二音频数据发送至所述第二预设应用，由所述第二预设应用将所述第二音频数据发送至所述第二设备。
  19. 根据权利要求1-18中任一项所述的方法，其特征在于，在所述第一设备显示候选设备列表之前，还包括：
    所述第一设备显示所述第一音频应用的应用界面，所述应用界面中设置有音频切换按钮；
    其中，所述第一操作为用户点击所述音频切换按钮的操作。
  20. 根据权利要求1-18中任一项所述的方法，其特征在于，在所述第一设备显示候选设备列表之前，还包括：
    所述第一设备显示控制中心，所述控制中心设置有音频切换按钮；
    其中，所述第一操作为用户点击所述音频切换按钮的操作。
  21. 根据权利要求1-20中任一项所述的方法，其特征在于，在所述第一设备根据所述第二设备的音频能力参数确定第一音频播放策略之后，还包括：
    所述第一设备根据所述第一音频播放策略确定是否对所述第一音频数据进行所述第一处理；
    其中，所述第一设备按照所述第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据，包括：
    若所述第一设备确定对所述第一音频数据进行所述第一处理，则所述第一设备按照所述第一音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到第二音频数据。
  22. 根据权利要求21所述的方法，其特征在于，在所述第一设备根据所述第一音频播放策略确定是否对所述第一音频数据进行所述第一处理之后，还包括：
    若所述第一设备确定对所述第一音频数据不进行所述第一处理，则所述第一设备将所述第一音频数据发送至所述第二设备进行播放。
  23. 根据权利要求1-7中任一项所述的方法，其特征在于，所述第二设备的音频能力参数包括录制参数，所述录制参数用于指示所述第二设备的音频输入能力；所述方法还包括：
    所述第一设备根据所述录制参数确定音频录制策略；
    所述第一设备接收到所述第二设备录制的第一录音数据后，按照所述音频录制策略处理所述第一录音数据，得到第二录音数据；
    所述第一设备将所述第二录音数据上报给所述第一音频应用。
  24. 一种音频控制方法，其特征在于，包括：
    响应于用户输入的第一操作，第一设备显示候选设备列表，所述候选设备列表中包括至少一个具有音频输出功能的候选设备；
    响应于用户在所述候选设备列表中选择第二设备和第三设备的操作，所述第一设备分别获取所述第二设备的音频能力参数以及所述第三设备的音频能力参数，所述第二设备的音频能力参数用于指示所述第二设备播放音频的硬件能力以及所述第二设备播放音频的软件能力，所述第三设备的音频能力参数用于指示所述第三设备播放音频的硬件能力以及所述第三设备播放音频的软件能力；
    所述第一设备根据所述第二设备的音频能力参数和所述第三设备的音频能力参数确定多设备音频播放策略；
    所述第一设备按照所述多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与所述第二设备对应的第二音频数据以及与所述第三设备对应的第三音频数据；
    所述第一设备将所述第二音频数据发送至所述第二设备进行播放，并将所述第三音频数据发送至所述第三设备进行播放。
  25. 根据权利要求24所述的方法，其特征在于，所述第二设备的音频能力参数和所述第三设备的音频能力参数不同，所述多设备音频播放策略包括第一策略和第二策略；
    其中，所述第一设备按照所述多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与所述第二设备对应的第二音频数据以及与所述第三设备对应的第三音频数据，包括：
    所述第一设备将所述第一音频数据复制后得到第一数据和第二数据，所述第一数据与所述第一音频数据相同，所述第二数据与所述第一音频数据相同；
    所述第一设备按照所述第一策略处理所述第一数据，得到所述第二音频数据；
    所述第一设备按照所述第二策略处理所述第二数据，得到所述第三音频数据。
  26. 根据权利要求25所述的方法，其特征在于，所述第一设备的应用程序层安装有第一预设应用；在所述第一设备分别获取所述第二设备的音频能力参数以及所述第三设备的音频能力参数之后，还包括：
    所述第一预设应用按照所述第二设备的音频能力参数在硬件抽象层HAL创建第一硬件抽象模块，并且，所述第一预设应用按照所述第三设备的音频能力参数在HAL创建第二硬件抽象模块；
    其中，所述第一设备将所述第二音频数据发送至所述第二设备，并将所述第三音频数据发送至所述第三设备，包括：
    所述第一设备通过所述第一硬件抽象模块将所述第二音频数据发送至所述第二设备，并且，所述第一设备通过所述第二硬件抽象模块将所述第三音频数据发送至所述 第三设备。
  27. 根据权利要求24所述的方法，其特征在于，所述第二设备的音频能力参数和所述第三设备的音频能力参数相同；
    其中，所述第一设备按照所述多设备音频播放策略对来自第一音频应用的第一音频数据进行第一处理，得到与所述第二设备对应的第二音频数据以及与所述第三设备对应的第三音频数据，包括：
    所述第一设备按照所述多设备音频播放策略对所述第一音频数据进行第一处理，得到所述第二音频数据；
    所述第一设备将所述第二音频数据复制后得到所述第三音频数据。
  28. 根据权利要求27所述的方法，其特征在于，所述第一设备的应用程序层安装有第一预设应用；在所述第一设备分别获取所述第二设备的音频能力参数以及所述第三设备的音频能力参数之后，还包括：
    所述第一预设应用按照所述第二设备的音频能力参数或所述第三设备的音频能力参数在HAL创建硬件抽象模块；
    其中，所述第一设备将所述第二音频数据发送至所述第二设备，并将所述第三音频数据发送至所述第三设备，包括：
    所述第一设备通过所述硬件抽象模块将所述第二音频数据发送至所述第二设备，并且，所述第一设备通过所述硬件抽象模块将所述第三音频数据发送至所述第三设备。
  29. 一种音频控制方法，其特征在于，包括：
    响应于用户输入的第一操作，第一设备显示候选设备列表，所述候选设备列表中包括至少一个具有音频输入功能的候选设备；
    响应于用户在所述候选设备列表中选择第二设备的操作，所述第一设备获取所述第二设备的音频能力参数，所述音频能力参数用于指示所述第二设备录制音频的硬件能力以及所述第二设备录制音频的软件能力；所述第二设备为音箱，或电视，或手机；
    所述第一设备根据所述第二设备的音频能力参数确定第一音频录制策略；
    当所述第一设备接收到所述第二设备发送的第一录音数据时，所述第一设备按照所述第一音频录制策略对所述第一录音数据进行第一处理，得到第二录音数据。
  30. 根据权利要求29所述的方法，其特征在于，在所述第一设备获取所述第二设备的音频能力参数之后，还包括：
    当所述第二设备的音频能力参数更新时，所述第一设备获取所述第二设备更新后的音频能力参数；
    所述第一设备按照更新后的音频能力参数将所述第一音频录制策略更新为第二音频录制策略；
    当所述第一设备接收到所述第二设备发送的第三录音数据时，所述第一设备按照所述第二音频录制策略对所述第三录音数据进行第二处理，得到第四录音数据。
  31. 根据权利要求29所述的方法，其特征在于，在所述第一设备获取所述第二设备的音频能力参数之后，还包括：
    所述第一设备接收用户选择第三设备进行音频录制的第二操作，所述第三设备与所述第二设备不同；
    响应于所述第二操作，所述第一设备从所述第三设备中获取所述第三设备的音频能力参数；
    所述第一设备根据所述第三设备的音频能力参数确定第三音频录制策略；
    当所述第一设备接收到所述第三设备发送的第五录音数据时，所述第一设备按照所述第三音频录制策略对所述第五录音数据进行第三处理，得到第六录音数据。
  32. 根据权利要求29-31中任一项所述的方法，其特征在于，在所述第一设备获取所述第二设备的音频能力参数之后，还包括：
    所述第一设备按照所述第二设备的音频能力参数在硬件抽象层HAL中创建对应的硬件抽象模块；
    其中，所述第一设备接收所述第二设备发送的第一录音数据，包括：
    所述第一设备通过所述硬件抽象模块接收所述第二设备发送的所述第一录音数据。
  33. 一种音频控制方法，其特征在于，包括：
    第二设备向第一设备发送第一音频能力参数，所述第一音频能力参数用于指示所述第二设备播放音频的硬件能力以及所述第二设备播放音频的软件能力，所述第二设备为音箱，或电视，或手机；
    所述第二设备接收所述第一设备发送的第一音频数据，所述第一音频数据为所述第一设备按照所述第一音频能力参数处理后得到的；
    所述第二设备播放所述第一音频数据，或者，所述第二设备对所述第一音频数据进行处理后播放。
  34. 根据权利要求33所述的方法，其特征在于，所述第二设备中的应用程序层安装有预设应用；
    其中，第二设备向第一设备发送所述第一音频能力参数，包括：
    所述第二设备通过运行所述预设应用向所述第一设备发送所述第一音频能力参数；
    其中，所述第二设备接收所述第一设备发送的第一音频数据，包括：
    所述第二设备通过运行所述预设应用接收所述第一设备发送的第一音频数据。
  35. 根据权利要求33或34所述的方法，其特征在于，在所述第二设备播放所述第一音频数据，或者，所述第二设备对所述第一音频数据进行处理后播放之后，还包括：
    所述第二设备将第三设备设置为音频输出设备，所述第三设备与所述第二设备不同，所述第三设备与所述第一设备不同；
    所述第二设备向所述第一设备发送第二音频能力参数，所述第二音频能力参数用于指示所述第三设备播放音频的硬件能力以及所述第三设备播放音频的软件能力；
    所述第二设备接收所述第一设备发送的第二音频数据，所述第二音频数据为所述第一设备按照所述第二音频能力参数处理后得到的；
    所述第二设备播放所述第二音频数据，或者，所述第二设备对所述第二音频数据进行处理后播放。
  36. 根据权利要求33或34所述的方法，其特征在于，在所述第二设备播放所述第一音频数据，或者，所述第二设备对所述第一音频数据进行处理后播放之后，还包括：
    当所述第二设备的音频能力变化时，所述第二设备将所述第一音频能力参数更新为第三音频能力参数；
    所述第二设备向所述第一设备发送所述第三音频能力参数；
    所述第二设备接收所述第一设备发送的第三音频数据，所述第三音频数据为所述第一设备按照所述第三音频能力参数处理后得到的；
    所述第二设备播放所述第三音频数据，或者，所述第二设备对所述第三音频数据进行处理后播放。
  37. 根据权利要求33-36中任一项所述的方法，其特征在于，所述第一音频能力参数还用于指示所述第二设备录制音频的硬件能力以及所述第二设备录制音频的软件能力；
    其中，在第二设备向第一设备发送第一音频能力参数之后，还包括：
    所述第二设备开始录制音频，得到录音数据；
    所述第二设备将所述录音数据发送给所述第一设备，以使得所述第一设备按照所述第一音频能力参数对所述录音数据进行处理。
  38. 根据权利要求33-37中任一项所述的方法，其特征在于，所述方法还包括：
    所述第二设备接收所述第一设备发送的音频策略，所述音频策略为所述第一设备根据所述第一音频能力参数确定的，所述音频策略包括音频播放策略和/或音频录制策略；
    其中，所述第二设备对所述第一音频数据进行处理后播放，包括：
    所述第二设备按照所述音频播放策略处理所述第一音频数据，并播放处理后的所述第一音频数据。
  39. 一种音频控制方法，其特征在于，包括：
    当第一设备与第二设备建立网络连接后，所述第一设备获取与所述第二设备对应的设备选择策略；
    所述第一设备获取待播放的第一音频数据，所述第一音频数据的类型为第一类型；
    所述第一设备根据所述第一类型以及所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放；
    若所述第一音频数据允许在所述第二设备中播放，则所述第一设备将所述第一音频数据发送至所述第二设备进行播放。
  40. 根据权利要求39所述的方法，其特征在于，所述设备选择策略包括：所述第二设备允许播放的音频数据的类型以及所述第二设备不允许播放的音频数据的类型中的至少一个；
    其中，所述第一设备根据所述第一类型和所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放，包括：
    所述第一设备在所述设备选择策略中查询所述第二设备是否允许播放所述第一类型的音频数据；
    若所述第二设备允许播放所述第一类型的音频数据，则所述第一设备确定所述第一音频数据允许在所述第二设备中播放；若所述第二设备不允许播放所述第一类型的音频数据，则所述第一设备确定所述第一音频数据不允许在所述第二设备中播放。
  41. 根据权利要求39所述的方法，其特征在于，所述设备选择策略包括：所述第二设备允许播放的音频数据来自的应用以及所述第二设备允许播放的音频数据的类型， 和/或，所述第二设备不允许播放的音频数据来自的应用以及所述第二设备不允许播放的类型；
    其中，所述第一设备根据所述第一类型和所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放，包括：
    所述第一设备确定所述第一音频数据来自于第一应用；
    所述第一设备在所述设备选择策略中查询所述第二设备是否允许播放来自所述第一应用的所述第一类型的音频数据；
    若第二设备允许播放来自所述第一应用的所述第一类型的音频数据，则所述第一设备确定所述第一音频数据允许在所述第二设备中播放；若第二设备不允许播放来自所述第一应用的所述第一类型的音频数据，则所述第一设备确定所述第一音频数据不允许在所述第二设备中播放。
  42. 根据权利要求40或41所述的方法，其特征在于，所述设备选择策略还包括不同类型的音频数据的音频输出设备；所述方法还包括：
    若所述第一音频数据不允许在所述第二设备中播放，则所述第一设备根据所述第一类型在所述设备选择策略中查询所述第一音频数据的音频输出设备为第三设备，所述第三设备与所述第二设备不同；
    所述第一设备将所述第一音频数据发送至所述第三设备进行播放。
  43. 根据权利要求42所述的方法，其特征在于，所述第三设备为除所述第二设备外最近接入所述第一设备的音频输出设备。
  44. 根据权利要求39所述的方法，其特征在于，所述设备选择策略包括：不同类型的音频数据与不同音频输出设备之间的对应关系；
    其中，所述第一设备根据所述第一类型和所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放，包括：
    所述第一设备在所述设备选择策略中查询与所述第一类型的音频数据对应的音频输出设备是否包含所述第二设备；
    若包含所述第二设备，则所述第一设备确定所述第一音频数据允许在所述第二设备中播放；若不包含所述第二设备，则所述第一设备确定所述第一音频数据不允许在所述第二设备中播放。
  45. 根据权利要求39所述的方法，其特征在于，所述设备选择策略包括：不同应用、不同类型的音频数据与不同音频输出设备之间的对应关系；
    其中，所述第一设备根据所述第一类型和所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放，包括：
    所述第一设备确定所述第一音频数据来自于第一应用；
    所述第一设备在所述设备选择策略中查询与所述第一类型和所述第一应用对应的音频输出设备是否包含所述第二设备；
    若包含所述第二设备，则所述第一设备确定所述第一音频数据允许在所述第二设备中播放；若不包含所述第二设备，则所述第一设备确定所述第一音频数据不允许在所述第二设备中播放。
  46. 根据权利要求39-45中任一项所述的方法，其特征在于，
    当所述第二设备为音箱类型的电子设备时，在所述设备选择策略中所述第二设备允许播放音乐类型的音频数据，所述第二设备不允许播放通知类型的音频数据；
    当所述第二设备为车载设备类型的电子设备时，在所述设备选择策略中所述第二设备允许播放导航类型的音频数据，所述第二设备不允许播放通知类型的音频数据；
    当所述第二设备为大屏设备类型的电子设备时，在所述设备选择策略中所述第二设备允许播放来自第一应用的音频数据，所述第二设备不允许播放来自第二应用的音频数据。
  47. 根据权利要求39-46中任一项所述的方法，其特征在于，所述第一设备的应用程序层安装有预设应用，所述第一设备的应用程序框架层包括音频策略模块；
    其中，所述第一设备获取与所述第二设备对应的设备选择策略，包括：
    所述预设应用确定所述第二设备的设备类型；
    所述预设应用按照所述第二设备的设备类型获取对应的设备选择策略；
    所述预设应用将所述设备选择策略下发至所述音频策略模块。
  48. 根据权利要求47所述的方法，其特征在于，所述第一设备的应用程序框架层还包括音频处理器；
    其中，所述第一设备根据所述第一类型以及所述设备选择策略确定所述第一音频数据是否允许在所述第二设备中播放，包括：
    当所述音频处理器接收到所述第一音频数据后，向所述音频策略模块发送查询请求，所述查询请求中包括所述第一类型的标识；
    响应于所述查询请求，所述音频策略模块根据所述设备选择策略确定所述第一类型的所述第一音频数据是否允许在所述第二设备中播放。
  49. 根据权利要求48所述的方法，其特征在于，在第一设备与第二设备建立网络连接之后，还包括：
    所述第一设备在硬件抽象层HAL创建与所述第二设备对应的第一硬件抽象模块；
    其中，若所述第一音频数据允许在所述第二设备中播放，则所述第一设备将所述第一音频数据发送至所述第二设备进行播放，包括：
    所述音频处理器接收到所述音频策略模块发送的第一指示，所述第一指示用于指示所述第一音频数据的音频输出设备为所述第二设备；
    响应于所述第一指示，所述音频处理器调用所述第一硬件抽象模块将所述第一音频数据发送至所述第二设备。
  50. 根据权利要求49所述的方法，其特征在于，所述HAL中包括与第三设备对应的第二硬件抽象模块；所述方法还包括：
    所述音频处理器接收到所述音频策略模块发送的第二指示，所述第二指示用于指示所述第一音频数据的音频输出设备为所述第三设备；
    响应于所述第二指示，所述音频处理器调用所述第二硬件抽象模块将所述第一音频数据发送至所述第三设备。
  51. 根据权利要求39-50中任一项所述的方法，其特征在于，在所述第一设备获取与所述第二设备对应的设备选择策略之后，还包括：
    所述第一设备显示音频输出设备的设置界面；
    所述第一设备接收用户在所述设置界面中设置与所述第二设备对应的设备选择策略；
    响应于用户的设置，所述第一设备更新所述设备选择策略。
  52. 根据权利要求39-51中任一项所述的方法，其特征在于，所述方法还包括：
    在所述第二设备播放所述第一音频数据时，所述第一设备获取待播放的第二音频数据，所述第二音频数据的类型为第二类型；
    所述第一设备根据所述第二类型和所述设备选择策略确定所述第二音频数据是否允许在所述第二设备中播放；
    若所述第二音频数据允许在所述第二设备中播放，则所述第一设备将所述第一音频数据和所述第二音频数据混音后发送至所述第二设备进行播放；或者，所述第一设备将未经混音的所述第一音频数据和所述第二音频数据发送至所述第二设备进行播放。
  53. 根据权利要求39-51中任一项所述的方法，其特征在于，所述方法还包括：
    当所述第一设备停止向所述第二设备发送所述第一音频数据后，所述第一设备获取待播放的第二音频数据，所述第二音频数据的类型为第二类型；
    所述第一设备根据所述第二类型和所述设备选择策略确定所述第二音频数据是否允许在所述第二设备中播放；
    若所述第二音频数据允许在所述第二设备中播放，则所述第一设备将所述第二音频数据发送至所述第二设备进行播放。
  54. 一种音频控制方法，其特征在于，包括：
    当第一设备与第二设备建立网络连接后，所述第一设备获取与所述第二设备对应的混音策略；
    所述第一设备获取到待播放的第一音频数据和第二音频数据，所述第一音频数据的类型为第一类型，所述第二音频数据为第二类型；
    所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音；
    若不需要对所述第一音频数据和所述第二音频数据混音，则所述第一设备将所述第一音频数据和所述第二音频数据发送至所述第二设备进行播放；
    若需要对所述第一音频数据和所述第二音频数据混音，则所述第一设备将所述第一音频数据和所述第二音频数据混音为第三音频数据，在所述第三音频数据中所述第一音频数据和/或所述第二音频数据的音频特征发生改变；所述第一设备将所述第三音频数据发送至所述第二设备进行播放。
  55. 根据权利要求54所述的方法，其特征在于，所述混音策略包括：需要混音的音频数据的类型和/或不需要混音的音频数据的类型；
    其中，所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音，包括：
    所述第一设备在所述混音策略中查询所述第一类型的音频数据是否需要混音，以及所述第二类型的音频数据是否需要混音；
    若所述第一类型的音频数据和所述第二类型的音频数据中的至少一个不需要混音，则所述第一设备确定不需要对所述第一音频数据和所述第二音频数据混音；若所述第 一类型的音频数据和所述第二类型的音频数据都需要混音，则所述第一设备确定需要对所述第一音频数据和所述第二音频数据混音。
  56. 根据权利要求54所述的方法，其特征在于，所述混音策略包括：需要混音的音频数据的类型以及需要混音的音频数据来自的应用，和/或，不需要混音的音频数据的类型以及不需要混音的音频数据来自的应用；
    其中，所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音，包括：
    所述第一设备确定所述第一音频数据来自于第一应用，所述第二音频数据来自于第二应用；
    所述第一设备在所述混音策略中查询来自所述第一应用的所述第一类型的音频数据是否需要混音，以及来自所述第二应用的所述第二类型的音频数据是否需要混音；
    若来自所述第一应用的所述第一类型的音频数据与来自所述第二应用的所述第二类型的音频数据中的至少一个不需要混音，则所述第一设备确定不需要对所述第一音频数据和所述第二音频数据混音；若来自所述第一应用的所述第一类型的音频数据和来自所述第二应用的所述第二类型的音频数据都需要混音，则所述第一设备确定需要对所述第一音频数据和所述第二音频数据混音。
  57. 根据权利要求54所述的方法，其特征在于，所述混音策略包括：不同类型的音频数据与不允许混音的音频输出设备之间的对应关系；
    其中，所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音，包括：
    所述第一设备在所述混音策略中查询与所述第一类型的音频数据对应的第一音频输出设备是否包含所述第二设备；
    所述第一设备在所述混音策略中查询与所述第二类型的音频数据对应的第二音频输出设备是否包含所述第二设备；
    若所述第一音频输出设备包含所述第二设备和/或所述第二音频输出设备包含所述第二设备，则所述第一设备确定不需要对所述第一音频数据和所述第二音频数据混音；若所述第一音频输出设备不包含所述第二设备且所述第二音频输出设备不包含所述第二设备，则所述第一设备确定需要对所述第一音频数据和所述第二音频数据混音。
  58. 根据权利要求54所述的方法，其特征在于，所述混音策略包括：不同类型的音频数据、不同应用与不允许混音的音频输出设备之间的对应关系；
    其中，所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音，包括：
    所述第一设备确定所述第一音频数据来自于第一应用，所述第二音频数据来自于第二应用；
    所述第一设备在所述混音策略中查询与所述第一应用、所述第一类型对应的第一音频输出设备是否包含所述第二设备；
    所述第一设备在所述混音策略中查询与所述第二应用、所述第二类型对应的第二音频输出设备是否包含所述第二设备；
    若所述第一音频输出设备包含所述第二设备和/或所述第二音频输出设备包含所 述第二设备，则所述第一设备确定不需要对所述第一音频数据和所述第二音频数据混音；若所述第一音频输出设备不包含所述第二设备且所述第二音频输出设备不包含所述第二设备，则所述第一设备确定需要对所述第一音频数据和所述第二音频数据混音。
  59. 根据权利要求54-58中任一项所述的方法，其特征在于，
    当所述第二设备为音箱类型的电子设备时，在所述混音策略中向所述第二设备发送音乐类型的音频数据时不需要混音；
    当所述第二设备为车载设备类型的电子设备时，在所述混音策略中向所述第二设备发送导航类型的音频数据时不需要混音；
    当所述第二设备为大屏设备类型的电子设备时，在所述混音策略中向所述第二设备发送通知类型的音频数据时需要混音。
  60. 根据权利要求54-59中任一项所述的方法，其特征在于，所述第一设备将所述第一音频数据和所述第二音频数据发送至所述第二设备，包括：
    所述第一设备对所述第一音频数据进行打包，得到至少一个第一数据包；
    所述第一设备对所述第二音频数据进行打包，得到至少一个第二数据包；
    所述第一设备将所述第一数据包和所述第二数据包发送至所述第二设备。
  61. 根据权利要求60所述的方法，其特征在于，所述第一数据包内包括第一标识，所述第一标识用于指示所述第一音频数据；所述第二数据包内包括第二标识，所述第二标识用于指示第二音频数据。
  62. 根据权利要求60所述的方法，其特征在于，所述第一数据包内包括第一特征信息，所述第一特征信息用于指示所述第一音频数据的音频特征；所述第二数据包内包括第二特征信息，所述第二特征信息用于指示所述第二音频数据的音频特征。
  63. 根据权利要求62所述的方法，其特征在于，
    所述第一特征信息包括所述第一音频数据所属的应用、所述第一音频数据的类型、所述第一音频数据的音量等级、所述第一音频数据的播放格式以及所述第一音频数据的音轨信息中的至少一个；
    所述第二特征信息包括所述第二音频数据所属的应用、所述第二音频数据的类型、所述第二音频数据的音量等级、所述第二音频数据的播放格式以及所述第二音频数据的音轨信息中的至少一个。
  64. 根据权利要求54-63中任一项所述的方法，其特征在于，当第一设备与第二设备建立网络连接后，还包括：
    所述第一设备获取与所述第二设备对应的设备选择策略；
    在所述第一设备获取到待播放的第一音频数据和第二音频数据之后，还包括：
    所述第一设备根据所述第一类型、所述第二类型以及所述设备选择策略确定所述第一音频数据和所述第二音频数据的音频输出设备为所述第二设备。
  65. 根据权利要求54-64中任一项所述的方法，其特征在于，所述第一设备的应用程序层安装有预设应用，所述第一设备的应用程序框架层包括音频策略模块；
    其中，所述第一设备获取与所述第二设备对应的混音策略，包括：
    所述预设应用确定所述第二设备的设备类型；
    所述预设应用按照所述第二设备的设备类型获取对应的混音策略；
    所述预设应用将所述混音策略下发至所述音频策略模块。
  66. 根据权利要求65所述的方法，其特征在于，所述第一设备的应用程序框架层还包括音频处理器；
    其中，所述第一设备获取到待播放的第一音频数据和第二音频数据，包括：
    所述音频处理器获取到来自应用程序层的第一音频数据和第二音频数据；
    其中，所述第一设备根据所述第一类型、所述第二类型以及所述混音策略确定是否需要对所述第一音频数据和所述第二音频数据混音，包括：
    所述音频处理器向所述音频策略模块发送查询请求，所述查询请求中包括第一类型的标识和所述第二类型的标识；
    响应于所述查询请求，所述音频策略模块根据所述混音策略确定是否需要对所述第一类型的所述第一音频数据和所述第二类型的所述第二音频数据混音。
  67. 根据权利要求66所述的方法，其特征在于，在第一设备与第二设备建立网络连接之后，还包括：
    所述第一设备在硬件抽象层HAL创建与所述第二设备对应的硬件抽象模块；
    其中，若不需要对所述第一音频数据和所述第二音频数据混音，则所述方法还包括：
    所述音频处理器接收到所述音频策略模块发送的第一指示，所述第一指示用于指示对所述第一音频数据和所述第二音频数据不进行混音；
    响应于所述第一指示，所述音频处理器将所述第一音频数据封装为至少一个第一数据包，并将所述第一数据包存储在所述音频处理器的缓存中；
    响应于所述第一指示，所述音频处理器将所述第二音频数据封装为至少一个第二数据包，并将所述第二数据包存储在所述音频处理器的缓存中；
    所述音频处理器将所述音频处理器的缓存中的第一数据包和第二数据包发送给所述硬件抽象模块。
  68. 根据权利要求67所述的方法，其特征在于，所述第一设备将所述第一音频数据和所述第二音频数据发送至所述第二设备，包括：
    所述硬件抽象模块将所述音频处理器的缓存中的第一数据包和第二数据包发送给所述第二设备，使得所述第二设备通过解析所述第一数据包和所述第二数据包还原出所述第一音频数据和所述第二音频数据；或者；
    所述硬件抽象模块通过解析所述第一数据包和所述第二数据包还原出所述第一音频数据和所述第二音频数据，并将所述第一音频数据和所述第二音频数据发送至所述第二设备。
  69. 根据权利要求54-68中任一项所述的方法，其特征在于，在所述第一设备获取与所述第二设备对应的混音策略之后，还包括：
    所述第一设备显示音频输出设备的设置界面；
    所述第一设备接收用户在所述设置界面中设置与所述第二设备对应的混音策略；
    响应于用户的设置，所述第一设备更新所述混音策略。
  70. 根据权利要求54-69中任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一设备获取到所述第一音频数据和所述第二音频数据时，所述第一设备 还获取到待播放的第三音频数据，所述第三音频数据的类型为第三类型；
    所述第一设备根据所述第一类型、所述第二类型、所述第三类型以及所述混音策略，确定所述第一音频数据不需要混音，所述第二音频数据和所述第三音频数据需要混音；
    所述第一设备将所述第一音频数据发送至所述第二设备，并且，所述第一设备将所述第二音频数据和所述第三音频数据混音后发送至所述第二设备。
  71. 一种音频控制方法，其特征在于，包括：
    第二设备与第一设备建立网络连接；
    所述第二设备从所述第一设备获取未经混音的第一音频数据和第二音频数据，所述第一音频数据的类型为第一类型，所述第二音频数据为第二类型；
    所述第二设备播放所述第一音频数据和所述第二音频数据。
  72. 根据权利要求71所述的方法，其特征在于，所述第二设备从所述第一设备获取未经混音的第一音频数据和第二音频数据，包括：
    所述第二设备从所述第一设备获取与所述第一音频数据对应的第一数据包以及与所述第二音频数据对应的第二数据包；
    所述第二设备通过解析所述第一数据包和所述第二数据包还原出所述第一音频数据和所述第二音频数据。
  73. 根据权利要求72所述的方法，其特征在于，所述第一数据包内包括第一标识，所述第一标识用于指示所述第一音频数据；所述第二数据包内包括第二标识，所述第二标识用于指示第二音频数据；
    其中，所述第二设备通过解析所述第一数据包和所述第二数据包还原出所述第一音频数据和所述第二音频数据，包括：
    所述第二设备通过解析所述第一数据包和所述第二数据包，将携带有所述第一标识的数据包中的音频数据还原为所述第一音频数据，将携带有所述第二标识的数据包中的音频数据还原为所述第二音频数据。
  74. 根据权利要求72所述的方法，其特征在于，所述第一数据包内包括第一特征信息，所述第一特征信息用于指示所述第一音频数据的音频特征；所述第二数据包内包括第二特征信息，所述第二特征信息用于指示所述第二音频数据的音频特征；
    其中，所述第二设备播放所述第一音频数据和所述第二音频数据，包括：
    所述第二设备按照所述第一特征信息播放所述第一音频数据，同时，所述第二设备按照所述第二特征信息播放所述第二音频数据。
  75. 一种多音频任务的播放方法，其特征在于，包括：
    电子设备在显示界面中显示第一窗口和第二窗口，所述第一窗口中运行有第一应用，所述第二窗口中运行有第二应用；
    所述电子设备接收用户输入的第一操作；
    响应于所述第一操作，所述电子设备建立所述第一窗口与第一音频输出设备的关联关系；
    所述电子设备接收用户输入的第二操作；
    响应于所述第二操作，所述电子设备建立所述第二窗口与第二音频输出设备的关 联关系；
    当所述电子设备获取到来自所述第一应用的第一音频数据时，所述电子设备根据所述第一窗口与所述第一音频输出设备的关联关系，将所述第一音频数据发送至所述第一音频输出设备播放；
    当所述电子设备获取到来自所述第二应用的第二音频数据时，所述电子设备根据所述第二窗口与所述第二音频输出设备的关联关系，将所述第二音频数据发送至所述第二音频输出设备播放。
  76. 根据权利要求75所述的方法，其特征在于，在电子设备在显示界面中显示第一窗口和第二窗口之后，还包括：
    所述电子设备在所述第一窗口中显示第一对话框，所述第一对话框中包括具有音频播放功能的至少一个第一候选设备；其中，所述第一操作是用户在所述至少一个第一候选设备中选择所述第一音频输出设备的操作；
    所述电子设备在所述第二窗口中显示第二对话框，所述第二对话框中包括具有音频播放功能的至少一个第二候选设备；其中，所述第二操作是用户在所述至少一个第二候选设备中选择所述第二音频输出设备的操作。
  77. 根据权利要求75或76所述的方法，其特征在于，所述电子设备建立所述第一窗口与第一音频输出设备的关联关系，包括：
    所述电子设备记录所述第一窗口的第一音频配置信息，所述第一音频配置信息包括所述第一窗口与所述第一音频输出设备的关联关系；
    所述电子设备建立所述第二窗口与第二音频输出设备的关联关系，包括：
    所述电子设备记录所述第二窗口的第二音频配置信息，所述第二音频配置信息包括所述第二窗口与所述第二音频输出设备的关联关系。
  78. 根据权利要求77所述的方法，其特征在于，所述方法还包括：
    当所述第一应用在所述第一窗口中运行时，所述电子设备记录所述第一窗口与所述第一应用之间的第一对应关系；
    当所述第二应用在所述第二窗口中运行时，所述电子设备记录所述第二窗口与所述第二应用之间的第二对应关系。
  79. 根据权利要求78所述的方法，其特征在于，所述电子设备记录所述第一窗口与所述第一应用之间的第一对应关系，包括：
    所述第一应用申请获取所述第一窗口的第一音频焦点；
    当所述第一应用获取到所述第一音频焦点时，所述电子设备记录所述第一窗口与所述第一应用之间的第一对应关系；
    所述电子设备记录所述第二窗口与所述第二应用之间的第二对应关系，包括：
    所述第二应用申请获取所述第二窗口的第二音频焦点；
    当所述第二应用获取到所述第二音频焦点时，所述电子设备记录所述第二窗口与所述第二应用之间的第二对应关系。
  80. 根据权利要求78所述的方法，其特征在于，在所述电子设备将所述第一音频数据发送至所述第一音频输出设备播放之前，还包括：
    所述电子设备确定所述第一音频数据来自于所述第一应用；
    所述电子设备根据所述第一对应关系，确定所述第一音频数据对应所述第一窗口；
    所述电子设备根据所述第一音频配置信息，确定所述第一音频数据的音频输出设备为与所述第一窗口关联的第一音频输出设备；
    在所述电子设备将所述第二音频数据发送至所述第二音频输出设备播放之前，还包括：
    所述电子设备确定所述第二音频数据来自于所述第二应用；
    所述电子设备根据所述第二对应关系，确定所述第二音频数据对应所述第二窗口；
    所述电子设备根据所述第二音频配置信息，确定所述第二音频数据的音频输出设备为与所述第二窗口关联的第二音频输出设备。
  81. 根据权利要求77-80中任一项所述的方法，其特征在于，
    所述第一音频配置信息还包括，允许在所述第一音频输出设备中播放的音频数据的类型，和/或，允许在所述第一音频输出设备中播放的音频数据的音量大小；
    所述第二音频配置信息还包括，允许在所述第二音频输出设备中播放的音频数据的类型，和/或，允许在所述第二音频输出设备中播放的音频数据的音量大小。
  82. 根据权利要求81所述的方法，其特征在于，所述第一音频配置信息还包括，允许在所述第一音频输出设备中播放的音频数据的音量大小；
    在电子设备在显示界面中显示第一窗口和第二窗口之后，所述方法还包括：
    所述电子设备在所述第一窗口中显示第一音量调节条；
    若检测到用户在所述第一音量调节条上输入第一音量调节操作，则所述电子设备修改所述第一音频配置信息中第一类型的音频数据的音量大小，所述第一类型为所述第一窗口中正在播放的音频数据的类型或预设的音频数据的类型。
  83. 根据权利要求81所述的方法，其特征在于，所述第二音频配置信息还包括，允许在所述第二音频输出设备中播放的音频数据的音量大小；
    在电子设备在显示界面中显示第一窗口和第二窗口之后，所述方法还包括：
    所述电子设备在所述第二窗口中显示第二音量调节条；
    若检测到用户在所述第二音量调节条上输入第二音量调节操作，则所述电子设备修改所述第二音频配置信息中第二类型的音频数据的音量大小，所述第二类型为所述第二窗口中正在播放的音频数据的类型或预设的音频数据的类型。
  84. 根据权利要求77-83中任一项所述的方法，其特征在于，在所述电子设备建立所述第一窗口与第一音频输出设备的关联关系之后，还包括：
    响应于用户输入的第三操作，所述电子设备更新所述第一音频配置信息，更新后的所述第一音频配置信息包括所述第一窗口与第三音频输出设备的关联关系。
  85. 根据权利要求77-83中任一项所述的方法，其特征在于，在所述电子设备建立所述第二窗口与第二音频输出设备的关联关系之后，还包括：
    响应于用户输入的第四操作，所述电子设备更新所述第二音频配置信息，更新后的所述第二音频配置信息包括所述第二窗口与第四音频输出设备的关联关系。
  86. 根据权利要求75-85中任一项所述的方法，其特征在于，所述电子设备的应用程序框架层包括音频策略模块和音频处理器，所述方法还包括：
    当所述音频处理器接收到所述第一音频数据时，所述音频处理器向所述音频策略 模块发送第一查询请求；响应于所述第一查询请求，所述音频策略模块确定所述第一音频数据的音频输出设备为所述第一音频输出设备；
    当所述音频处理器接收到所述第二音频数据时，所述音频处理器向所述音频策略模块发送第二查询请求；响应于所述第二查询请求，所述音频策略模块确定所述第二音频数据的音频输出设备为所述第二音频输出设备。
  87. 根据权利要求86所述的方法，其特征在于，所述电子设备的应用程序框架层包括窗口管理器，所述窗口管理器用于将所述第一窗口与所述第一应用的第一对应关系、所述第二窗口与所述第二应用的第二对应关系、所述第一窗口的第一音频配置信息以及所述第二窗口的第二音频配置信息发送至所述音频策略模块。
  88. 根据权利要求86所述的方法，其特征在于，所述电子设备的硬件抽象层HAL中包括与所述第一音频输出设备对应的第一音频抽象模块以及与所述第二音频输出设备对应的第二音频抽象模块；
    其中，所述电子设备将所述第一音频数据发送至所述第一音频输出设备，包括：
    所述音频处理器通过所述第一音频抽象模块将所述第一音频数据发送至所述第一音频输出设备；
    其中，所述电子设备将所述第二音频数据发送至所述第二音频输出设备，包括：
    所述音频处理器通过所述第二音频抽象模块将所述第二音频数据发送至所述第二音频输出设备。
  89. 根据权利要求75-88中任一项所述的方法，其特征在于，所述电子设备的硬件抽象层HAL包括显示抽象模块；所述方法还包括：
    所述显示抽象模块获取与所述第一窗口对应的第一显示数据以及与所述第二窗口对应的第二显示数据；
    所述显示抽象模块将所述第一显示数据和所述第二显示数据合成为与所述显示界面对应的第三显示数据。
  90. 根据权利要求89所述的方法，其特征在于，所述电子设备的显示输出设备为所述电子设备的显示屏，在所述显示抽象模块将所述第一显示数据和所述第二显示数据合成为第三显示数据之后，还包括：
    所述显示抽象模块将所述第三显示数据发送至所述电子设备的显示屏进行显示。
  91. 根据权利要求89所述的方法，其特征在于，所述电子设备的显示输出设备为第一显示设备，在所述显示抽象模块将所述第一显示数据和所述第二显示数据合成为待显示的第三显示数据之后，还包括：
    所述显示抽象模块将所述第三显示数据发送至所述第一显示设备进行显示。
  92. 根据权利要求91所述的方法，所述电子设备根据所述第一窗口与所述第一音频输出设备的关联关系，将所述第一音频数据发送至所述第一音频输出设备播放，包括：
    所述电子设备将所述第一音频数据和所述第一窗口与第一音频输出设备的关联关系发送给所述第一显示设备，以使得所述第一显示设备按照所述第一窗口与第一音频输出设备的关联关系，将所述第一音频数据发送至所述第一音频输出设备播放；
    其中，所述电子设备根据所述第二窗口与所述第二音频输出设备的关联关系，将 所述第二音频数据发送至所述第二音频输出设备播放，包括：
    所述电子设备将所述第二音频数据和所述第二窗口与第二音频输出设备的关联关系发送给所述第一显示设备，以使得所述第一显示设备按照所述第二窗口与第二音频输出设备的关联关系，将所述第二音频数据发送至所述第二音频输出设备播放。
  93. 根据权利要求75-88中任一项所述的方法，其特征在于，所述电子设备的硬件抽象层HAL包括显示抽象模块；与所述第一窗口对应的显示输出设备为第一显示设备，与所述第二窗口对应的显示输出设备为第二显示设备；所述方法还包括：
    所述显示抽象模块获取与所述第一窗口对应的第一显示数据，并将所述第一显示数据发送至所述第一显示设备进行显示；
    所述显示抽象模块获取与所述第二窗口对应的第二显示数据，并将所述第二显示数据发送至所述第二显示设备进行显示。
  94. 一种录屏方法，其特征在于，包括：
    响应于用户打开第一设备中录屏功能的操作，所述第一设备显示录屏设备列表，所述录屏设备列表中包括与所述第一设备接入同一通信网络的一个或多个电子设备；
    响应于用户在所述录屏设备列表中选择第二设备的操作，所述第一设备向所述第二设备发送录屏指令，以使得所述第二设备响应于所述录屏指令执行录屏操作；
    所述第一设备执行录屏操作，得到所述第一设备的第一屏幕数据；
    所述第一设备获取所述第二设备执行录屏操作得到的第二屏幕数据；
    所述第一设备根据所述第一屏幕数据和所述第二屏幕数据生成录屏文件。
  95. 根据权利要求94所述的方法，其特征在于，所述第一屏幕数据包括第一显示数据和第一音频数据；
    所述第一显示数据包括：所述第一设备播放的显示数据和/或所述第一设备采集的显示数据；所述第一音频数据包括：所述第一设备播放的音频数据和/或所述第一设备采集的音频数据。
  96. 根据权利要求95所述的方法，其特征在于，在所述第一设备执行录屏操作，得到所述第一设备的第一屏幕数据之前，还包括：
    所述第一设备获取所述第一设备执行录屏操作使用的第一录屏参数，所述第一录屏参数包括显示录制参数和音频录制参数；
    其中，所述第一设备执行录屏操作，得到所述第一设备的第一屏幕数据，包括：
    所述第一设备按照所述显示录制参数录制得到所述第一显示数据；
    所述第一设备按照所述音频录制参数录制得到所述第一音频数据。
  97. 根据权利要求96所述的方法，其特征在于，在所述第一设备向所述第二设备发送录屏指令之前，还包括：
    所述第一设备获取所述第二设备执行录屏操作使用的第二录屏参数，所述第二录屏参数包括显示录制参数和音频录制参数；
    其中，所述第一设备向所述第二设备发送录屏指令，包括：
    所述第一设备将所述第二录屏参数携带在录屏指令中发送给所述第二设备。
  98. 根据权利要求97所述的方法，其特征在于，所述第一设备获取所述第一录屏参数和所述第二录屏参数，包括：
    所述第一设备获取所述第一设备的第一录屏能力参数，所述第一录屏能力参数用于反映所述第一设备的录屏能力；
    所述第一设备获取所述第二设备的第二录屏能力参数，所述第二录屏能力参数用于反映所述第二设备的录屏能力；
    所述第一设备根据所述第一录屏能力参数和所述第二录屏能力参数，确定与所述第一设备对应的第一录屏参数以及与所述第二设备对应的第二录屏参数。
  99. 根据权利要求98所述的方法，其特征在于，
    当所述第一录屏能力参数中所述第一设备的分辨率大于所述第二录屏能力参数中所述第二设备的分辨率时，所述第一录屏参数和所述第二录屏参数中的分辨率为所述第二设备的分辨率；或者，
    当所述第一录屏能力参数中所述第一设备的每英寸点数DPI大于所述第二录屏能力参数中所述第二设备的DPI时，所述第一录屏参数和所述第二录屏参数中的DPI为所述第二设备的DPI；或者，
    当所述第一录屏能力参数中所述第一设备的采样率大于所述第二录屏能力参数中所述第二设备的采样率时，所述第一录屏参数和所述第二录屏参数中的采样率为所述第二设备的采样率。
  100. 根据权利要求95-99中任一项所述的方法，其特征在于，所述第二屏幕数据包括第二显示数据和第二音频数据；
    所述第二显示数据包括：所述第二设备播放的显示数据和/或所述第二设备采集的显示数据；所述第二音频数据包括：所述第二设备播放的音频数据和/或所述第二设备采集的音频数据。
  101. 根据权利要求100所述的方法，其特征在于，所述第一设备根据所述第一屏幕数据和所述第二屏幕数据生成录屏文件，包括：
    所述第一设备将所述第一显示数据和所述第二显示数据合成为第三显示数据；
    所述第一设备将所述第三显示数据、所述第一音频数据和所述第二音频数据制作为录屏文件。
  102. 根据权利要求100所述的方法，其特征在于，所述录屏文件包括第一文件和第二文件；
    其中，所述第一设备根据所述第一屏幕数据和所述第二屏幕数据生成录屏文件，包括：
    所述第一设备将所述第一显示数据和所述第一音频数据制作为所述第一文件；
    所述第一设备将所述第二显示数据和所述第二音频数据制作为所述第二文件。
  103. 根据权利要求94-102中任一项所述的方法，其特征在于，在所述第一设备显示录屏设备列表之前，还包括：
    所述第一设备检测与所述第一设备接入同一通信网络的N个电子设备，N为大于0的整数；
    所述第一设备确定所述N个电子设备中具有录屏功能的电子设备；
    其中，所述第一设备显示录屏设备列表，包括：
    所述第一设备将确定出的具有录屏功能的电子设备显示在所述录屏设备列表中。
  104. 根据权利要求94-103中任一项所述的方法，其特征在于，所述第一设备的应用程序层包括录屏应用，所述第一设备的应用程序框架层包括屏幕录制器，所述第一设备的硬件抽象层HAL包括预设的硬件抽象模块；
    其中，所述第一设备执行录屏操作，得到所述第一设备的第一屏幕数据，包括：
    所述录屏应用调用所述屏幕录制器执行录屏操作，得到所述第一设备的第一屏幕数据；
    其中，所述第一设备获取所述第二设备执行录屏操作得到的第二屏幕数据，包括：
    所述屏幕录制器通过所述硬件抽象模块获取所述第二设备执行录屏操作得到的第二屏幕数据。
  105. 一种录屏方法，其特征在于，包括：
    第二设备获取第一设备发送的录屏指令，所述录屏指令中包括所述第二设备执行录屏操作使用的录屏参数，所述录屏参数包括显示录制参数和音频录制参数；
    响应于所述录屏指令，所述第二设备按照所述录屏参数执行录屏操作，得到所述第二设备的屏幕数据；
    所述第二设备将所述第二设备的屏幕数据发送给所述第一设备。
  106. 根据权利要求105所述的方法，其特征在于，所述第二设备的屏幕数据包括显示数据和音频数据；
    所述显示数据包括：所述第二设备播放的显示数据和/或所述第二设备采集的显示数据；所述音频数据包括：所述第二设备播放的音频数据和/或所述第二设备采集的音频数据。
  107. 根据权利要求106所述的方法，其特征在于，所述第二设备按照所述录屏参数执行录屏操作，得到所述第二设备的屏幕数据，包括：
    所述第二设备按照所述显示录制参数录制得到所述显示数据；
    所述第二设备按照所述音频录制参数录制得到所述音频数据。
  108. 根据权利要求105-107中任一项所述的方法，其特征在于，所述第二设备的应用程序层包括预设应用，所述第二设备的应用程序框架层包括屏幕录制器；
    所述预设应用用于：接收来自所述第一设备的所述录屏指令；调用所述屏幕录制器按照所述录屏参数执行录屏操作，得到所述第二设备的屏幕数据；将所述第二设备的屏幕数据发送至所述第一设备。
  109. 一种音频时延的更新方法，其特征在于，包括：
    第一设备与第二设备建立网络连接；
    若所述第二设备被设置为所述第一设备的音频输出设备，则所述第一设备获取第一时延、第二时延和第三时延，其中，所述第一时延为音频数据在所述第一设备中处理时产生的时延，所述第二时延为音频数据在所述第一设备与所述第二设备之间传输时的产生的时延，所述第三时延为音频数据在所述第二设备中播放时产生的时延；
    所述第一设备确定当前的音频时延，所述音频时延为基于所述第一时延、所述第二时延以及所述第三时延计算得到的。
  110. 根据权利要求109所述的方法，其特征在于，在第一设备与第二设备建立网络连接之后，还包括：
    所述第一设备获取所述第二设备的音频能力参数，所述音频能力参数用于指示所述第二设备播放音频的硬件能力以及所述第二设备播放音频的软件能力；
    其中，所述第一设备获取第三时延，包括：
    所述第一设备从所述音频能力参数中获取所述第三时延。
  111. 根据权利要求110所述的方法，其特征在于，在所述第一设备获取所述第二设备的音频能力参数之后，还包括：
    所述第一设备按照所述音频能力参数确定音频策略；
    其中，所述第一设备获取第一时延，包括：
    所述第一设备根据所述音频策略确定所述第一时延。
  112. 根据权利要求111所述的方法，其特征在于，所述音频策略包括对音频数据的N个处理过程，N为大于0的整数；
    其中，所述第一设备根据所述音频策略确定所述第一时延，包括：
    所述第一设备确定所述N个处理过程中每个处理过程的耗时；
    所述第一设备基于每个处理过程的耗时计算得到所述第一时延。
  113. 根据权利要求111或112所述的方法，其特征在于，若所述第二设备被设置为所述第一设备的音频输出设备，则所述方法还包括：
    所述第一设备获取所述第二设备更新后的所述音频能力参数；
    所述第一设备按照更新后的所述音频能力参数更新所述音频策略；
    所述第一设备根据更新后的所述音频能力参数更新所述第三时延；
    所述第一设备根据更新后的所述音频策略更新所述第一时延。
  114. 根据权利要求109-113中任一项所述的方法，其特征在于，所述第一设备的硬件抽象层HAL中包括用于传输音频数据的第一硬件抽象模块；
    在所述第一设备与所述第二设备建立网络连接之后，还包括：
    所述第一设备在所述HAL中创建与所述第二设备对应的第二硬件抽象模块；
    其中，所述第一设备获取第二时延，包括：
    所述第二硬件抽象模块从所述第一硬件抽象模块中获取所述第二时延。
  115. 根据权利要求114所述的方法，其特征在于，所述方法还包括：
    所述第一硬件抽象模块向所述第二设备发送测试数据包；
    所述第一硬件抽象模块接收所述第二设备响应所述测试数据包发送的响应数据包；
    所述第一硬件抽象模块根据发送所述测试数据包以及接收所述响应数据包之间的时间间隔计算并保存所述第二时延。
  116. 根据权利要求109-115中任一项所述的方法，其特征在于，所述第一设备确定当前的音频时延，包括：
    当所述第一时延、所述第二时延或所述第三时延中的至少一个更新时，所述第一设备更新当前的音频时延。
  117. 根据权利要求109-116中任一项所述的方法，其特征在于，所述第一设备输出的显示数据在所述第一设备的显示屏中显示；
    其中，在所述第一设备确定当前的音频时延之后，还包括：
    所述第一设备中运行的第一应用获取所述音频时延；
    当所述第一应用为视频应用时，所述第一应用按照所述音频时延对所述第一应用的音频数据和显示数据进行同步；当所述第一应用为音乐应用时，所述第一应用按照所述音频时延对所述第一应用的音频数据和歌词数据进行同步；当所述第一应用为K歌应用时，所述第一应用按照所述音频时延对所述第一应用的音频数据和伴奏音乐进行同步。
  118. 根据权利要求109-116中任一项所述的方法，其特征在于，所述第一设备输出的显示数据在第三设备的显示屏中显示；所述方法还包括：
    所述第一设备确定当前的显示时延，所述显示时延包括显示数据在所述第一设备与所述第三设备之间传输时的产生的时延；
    所述第一设备基于所述音频时延和所述显示时延确定当前的同步时延；
    所述第一设备中运行的第二应用按照当前的同步时延对所述第二应用的音频数据和显示数据进行同步。
  119. 根据权利要求118所述的方法，其特征在于，所述同步时延为所述音频时延和所述显示时延之间的差值。
  120. 根据权利要求109-119中任一项所述的方法，其特征在于，所述音频时延为所述第一时延、所述第二时延以及所述第三时延之和。
  121. 根据权利要求109-120中任一项所述的方法，其特征在于，若第四设备被设置为所述第一设备的音频输出设备，所述第四设备与所述第二设备连接，则所述方法还包括：
    所述第一设备获取所述第一时延和所述第二时延；
    所述第一设备获取第四时延，所述第四时延包括：音频数据在所述第二设备中处理时产生的时延、音频数据在所述第二设备与所述第四设备之间传输时产生的时延以及音频数据在所述第四设备中播放时产生的时延；
    所述第一设备确定当前的音频时延，所述音频时延为基于所述第一时延、所述第二时延以及所述第四时延计算得到的。
  122. 根据权利要求121所述的方法，其特征在于，所述音频时延为所述第一时延、所述第二时延以及所述第四时延之和。
  123. 一种音频时延的更新方法，其特征在于，包括：
    第一设备与第二设备建立网络连接；
    若所述第二设备被设置为所述第一设备的音频输出设备和显示输出设备，则所述第一设备获取第一时延和第二时延，所述第一时延为音频数据在所述第一设备中处理时产生的时延，所述第二时延为音频数据在所述第二设备中播放时产生的时延；
    所述第一设备基于所述第一时延和所述第二时延确定当前的同步时延。
  124. 根据权利要求123所述的方法，其特征在于，在所述第一设备基于所述第一时延和所述第二时延确定当前的同步时延之后，还包括：
    所述第一设备中运行的第一应用获取所述同步时延；
    所述第一应用按照所述同步时延对所述第一应用的音频数据和显示数据进行同步。
  125. 根据权利要求123或124所述的方法，其特征在于，所述同步时延为所述第一时延和所述第二时延之和。
  126. 一种音视频文件的播放方法，其特征在于，包括：
    第一设备接收用户输入的第一操作，所述第一操作用于将所述第一设备中播放的第一文件投射至第二设备中播放，所述第一文件为音频文件或视频文件；
    所述第一设备获取所述第一文件的第一数据包，所述第一文件包括N个数据包，所述第一数据包为所述N个数据包中的一个，N＞0；
    所述第一设备提取所述第一数据包中的第一音频参数和第一音频数据，所述第一音频数据为经过编码后的音频数据，所述第一音频参数为编码所述第一音频数据时使用的编码参数；
    所述第一设备将所述第一音频参数发送至所述第二设备，以使得所述第二设备按照所述第一音频参数确定是否具有解码所述第一音频数据的能力；
    若所述第二设备具有解码所述第一音频数据的能力，则所述第一设备将所述第一音频数据发送给所述第二设备，以使得所述第二设备解码所述第一音频数据后播放。
  127. 根据权利要求126所述的方法，其特征在于，所述第一数据包包括包头和数据部分；
    其中，所述第一设备提取所述第一数据包中的第一音频参数和第一音频数据，包括：
    所述第一设备从所述第一数据包的包头提取所述第一音频参数；
    所述第一设备从所述第一数据包的数据部分提取所述第一音频数据。
  128. 根据权利要求126或127所述的方法，其特征在于，所述第一音频参数包括：编码所述第一音频数据时使用的编码格式、编码规格、版本、采样率或声道数目中的至少一项。
  129. 根据权利要求126所述的方法，其特征在于，所述第一文件为视频文件；在所述第一设备获取所述第一文件的第一数据包之后，还包括：
    所述第一设备提取所述第一数据包中的第一显示参数和第一显示数据，所述第一显示数据为经过编码后的显示数据，所述第一显示参数为编码所述第一显示数据时使用的编码参数；
    所述第一设备将所述第一显示参数发送至所述第二设备，以使得所述第二设备按照所述第一显示参数确定是否具有解码所述第一显示数据的能力；
    若所述第二设备具有解码所述第一显示数据的能力，则所述第一设备将所述第一显示数据发送给所述第二设备，以使得所述第二设备解码所述第一显示数据后播放。
  130. 根据权利要求129所述的方法，其特征在于，所述第一数据包包括包头和数据部分；
    其中，所述第一设备提取所述第一数据包中的第一显示参数和第一显示数据，包括：
    所述第一设备从所述第一数据包的包头提取所述第一显示参数；
    所述第一设备从所述第一数据包的数据部分提取所述第一显示数据。
  131. 根据权利要求129或130所述的方法，其特征在于，所述第一显示参数包括：编码所述第一显示数据时使用的编码格式、编码规格、版本或分辨率中的至少一项。
  132. 根据权利要求126-131中任一项所述的方法，其特征在于，所述第一设备包括 第一应用、第二应用和第一音视频播放器，所述第一应用用于与所述第二设备通信，所述第二应用用于将待播放的所述第一文件的数据包发送至所述第一音视频播放器；
    在第一设备接收用户输入的第一操作之后，还包括：
    响应于所述第一操作，所述第一应用与所述第二设备建立网络连接；
    所述第一应用向所述第二应用发送第一广播消息，所述第一广播消息用于通知所述第二应用将所述第一文件投射至所述第二设备播放；
    响应于所述第一广播消息，所述第二应用向所述第一音视频播放器发送第一通知消息，以使得所述第一音视频播放器开始向所述第二设备投射音视频文件。
  133. 根据权利要求132所述的方法，其特征在于，所述第一设备还包括第一多媒体提取器；
    其中，所述第一设备提取所述第一数据包中的第一音频参数和第一音频数据，包括：
    响应于所述第一通知消息，所述第一多媒体提取器调用所述多媒体提取器对所述第一数据包进行解析，得到所述第一音频参数；
    响应于所述第一通知消息，所述第一多媒体提取器调用所述多媒体提取器对所述第一数据包进行解封装，得到所述第一音频数据。
  134. 根据权利要求132所述的方法，其特征在于，在所述第一设备将所述第一音频数据发送给所述第二设备之后，还包括：
    所述第一音视频播放器从所述第二应用获取所述第一文件的第二数据包；
    所述第一音视频播放器提取所述第二数据包中的第二音频数据；
    所述第一音视频播放器将所述第二音频数据发送至所述第二设备，以使得所述第二设备解码所述第二音频数据后播放。
  135. 根据权利要求132所述的方法，其特征在于，在所述第一设备将所述第一音频数据发送给所述第二设备之后，还包括：
    响应于用户输入的第二操作，所述第一应用与第三设备建立网络连接；
    所述第一应用向所述第二应用发送第二广播消息，所述第二广播消息用于通知所述第二应用将所述第一文件投射至所述第三设备播放；
    响应于所述第二广播消息，所述第二应用向所述第一音视频播放器发送第二通知消息，以使得所述第一音视频播放器开始向所述第三设备投射音视频文件。
  136. 根据权利要求135所述的方法，其特征在于，在所述第二应用向所述第一音视频播放器发送第二通知消息之后，还包括：
    所述第一音视频播放器从所述第二应用获取所述第一文件的第三数据包；
    所述第一音视频播放器提取所述第三数据包中的第二音频参数和第三音频数据，所述第三音频数据为经过编码后的音频数据，所述第二音频参数为编码所述第三音频数据时使用的编码参数；
    所述第一音视频播放器将所述第二音频参数发送至所述第三设备，以使得所述第三设备按照所述第二音频参数确定是否具有解码所述第三音频数据的能力；
    若所述第三设备具有解码所述第三音频数据的能力，则所述第一音视频播放器将所述第三音频数据发送给所述第三设备，以使得所述第三设备解码所述第三音频数据 后播放。
  137. 根据权利要求132所述的方法，其特征在于，在所述第一设备将所述第一音频数据发送给所述第二设备之后，还包括：
    响应于用户输入的第三操作，所述第二应用将当前播放的所述第一文件切换为第二文件，所述第二文件为音频文件或视频文件；
    所述第二应用创建第二音视频播放器，所述第二音视频播放器用于接收来自所述第二文件的数据包；
    所述第二应用向所述第二音视频播放器发送第三通知消息，以使得所述第二音视频播放器开始向所述第二设备投射音视频文件。
  138. 根据权利要求137所述的方法，其特征在于，在所述第二应用向所述第二音视频播放器发送第三通知消息之后，还包括：
    所述第二音视频播放器从所述第二应用获取所述第二文件的第四数据包；
    所述第二音视频播放器提取所述第四数据包中的第三音频参数和第四音频数据，所述第四音频数据为经过编码后的音频数据，所述第三音频参数为编码所述第四音频数据时使用的编码参数；
    所述第二音视频播放器将所述第三音频参数发送至所述第二设备，以使得所述第二设备按照所述第三音频参数确定是否具有解码所述第四音频数据的能力；
    若所述第二设备具有解码所述第四音频数据的能力，则所述第二音视频播放器将所述第四音频数据发送给所述第二设备，以使得所述第二设备解码所述第四音频数据后播放。
  139. 根据权利要求126-138中任一项所述的方法，其特征在于，在所述第一设备将所述第一音频数据发送给所述第二设备之后，还包括：
    所述第一设备运行第三应用；
    所述第一设备播放来自所述第三应用的音频文件或视频文件。
  140. 一种音视频文件的播放方法，其特征在于，包括：
    第二设备接收第一设备发送的第一音频参数，所述第一音频参数为编码第一数据包中第一音频数据时使用的编码参数，所述第一数据包为第一文件的数据包；
    所述第二设备根据所述第一音频参数确定是否具有解码所述第一音频数据的能力；
    若具有解码所述第一音频数据的能力，则所述第二设备向所述第一设备发送第一响应消息，所述第一响应消息用于指示所述第一设备向所述第二设备发送所述第一音频数据；
    所述第二设备接收到所述第一设备发送的所述第一音频数据后，对所述第一音频数据进行解码，得到解码后的第二音频数据；
    所述第二设备播放所述第二音频数据。
  141. 根据权利要求140所述的方法，其特征在于，所述第二设备对所述第一音频数据进行解码，得到解码后的第二音频数据，包括：
    所述第二设备使用第一解码参数对所述第一音频数据进行解码，得到解码后的第二音频数据，所述第一解码参数与所述第一音频参数对应。
  142. 根据权利要求140或141所述的方法，其特征在于，所述第一数据包还包括 第一显示数据；所述方法还包括：
    所述第二设备接收所述第一设备发送的第一显示参数，所述第一显示参数为编码所述第一显示数据时使用的编码参数；
    所述第二设备根据所述第一显示参数确定是否具有解码所述第一显示数据的能力；若具有解码所述第一显示数据的能力，则所述第一响应消息还用于指示所述第一设备向所述第二设备发送所述第一显示数据；
    所述第二设备接收到所述第一设备发送的所述第一显示数据后，对所述第一显示数据进行解码，得到解码后的第二显示数据；
    所述第二设备播放所述第二显示数据。
  143. 根据权利要求142所述的方法，其特征在于，所述第二设备对所述第一显示数据进行解码，得到解码后的第二显示数据，包括：
    所述第二设备使用第二解码参数对所述第一显示数据进行解码，得到解码后的第二显示数据，所述第二解码参数与所述第一显示参数对应。
  144. 根据权利要求140-143中任一项所述的方法，其特征在于，在所述第二设备接收到所述第一设备发送的所述第一音频数据后，还包括：
    若所述第二设备接收到所述第一文件中的第三音频数据，则所述第二设备对所述第三音频数据解码后播放；和/或，
    若所述第二设备接收到所述第一文件中的第三显示数据，则所述第二设备对所述第三显示数据解码后播放。
  145. 根据权利要求142-144中任一项所述的方法，其特征在于，在所述第二设备根据所述第一音频参数确定是否具有解码所述第一音频数据的能力之后，还包括：
    若具有解码所述第一音频数据的能力，则所述第二设备按照所述第一音频参数创建音频解码器，所述音频解码器用于解码所述第一文件中的音频数据；
    在所述第二设备根据第一显示参数确定是否具有解码所述第一显示数据的能力之后，还包括：
    若具有解码所述第一显示数据的能力，则所述第二设备按照所述第一显示参数创建图像解码器，所述图像解码器用于解码所述第一文件中的显示数据。
  146. 一种设备推荐方法，其特征在于，包括：
    第一设备接收用户打开第一业务的第一操作；
    响应于所述第一操作，所述第一设备从N个电子设备中分别获取与所述第一业务关联的设备参数，所述N个电子设备与所述第一设备位于同一通信网络，N为大于0的整数；
    所述第一设备根据所述设备参数预测所述N个电子设备中每个电子设备执行所述第一业务的业务质量；
    所述第一设备按照所述N个电子设备中每个电子设备执行所述第一业务的业务质量显示设备列表，所述设备列表中包括所述N个电子设备中至少一个电子设备的设备标识。
  147. 根据权利要求146所述的方法，其特征在于，所述N个电子设备中包括第二设备；所述第一设备从所述第二设备获取到的设备参数包括M项参数，M为大于0的 整数；
    其中，所述第一设备根据所述设备参数预测所述第二设备执行所述第一业务的业务质量，包括：
    所述第一设备确定与所述M项参数一一对应的M项分数；
    所述第一设备根据所述M项分数计算所述第二设备执行所述第一业务的业务质量分数；当所述业务质量分数越高时，所述第一业务的业务质量越高。
  148. 根据权利要求147所述的方法，其特征在于，所述N个电子设备中还包括第三设备；
    当所述第二设备执行所述第一业务的业务质量分数高于所述第三设备执行所述第一业务的业务质量分数时，所述第二设备在所述设备列表中的排列顺序位于所述第三设备之前。
  149. 根据权利要求147所述的方法，其特征在于，
    当所述第二设备执行所述第一业务的业务质量分数高于所述N个电子设备中其他电子设备执行所述第一业务的业务质量分数时，所述第二设备在所述设备列表中被标记为推荐设备。
  150. 根据权利要求147所述的方法，其特征在于，所述M项参数中包括与第一功能对应的第一参数；
    当所述第二设备的第一参数的分数高于所述N个电子设备中其他电子设备的第一参数的分数时，所述设备列表中包括第一提示信息，所述第一提示信息用于推荐用户使用所述第二设备实现所述第一功能。
  151. 根据权利要求147所述的方法，其特征在于，所述M项参数中包括与第一功能对应的第一参数；
    当所述第二设备的第一参数的分数低于所述N个电子设备中其他电子设备的第一参数的分数时，所述设备列表中包括第二提示信息，所述第二提示信息包括不推荐用户使用所述第二设备实现所述第一功能的原因。
  152. 根据权利要求146-151中任一项所述的方法，其特征在于，所述N个电子设备中包括第二设备；
    在所述第一设备按照所述N个电子设备中每个电子设备执行所述第一业务的业务质量显示设备列表之后，还包括：
    所述第一设备接收用户在所述设备列表中选择所述第二设备的第二操作；
    响应于所述第二操作，所述第一设备将所述第一业务切换至所述第二设备中执行。
  153. 根据权利要求152所述的方法，其特征在于，在所述第一设备将所述第一业务切换至所述第二设备中执行之后，还包括：
    所述第一设备从所述N个电子设备中分别获取与所述第一业务关联的设备参数；
    所述第一设备根据所述设备参数预测所述N个电子设备中每个电子设备执行所述第一业务的业务质量；
    当所述第二设备不是所述N个电子设备中执行所述第一业务的业务质量最高的电子设备时，所述第一设备显示第一提示消息，所述第一提示消息用于提示用户使用推荐设备执行所述第一业务，所述推荐设备为所述N个电子设备中的一个或多个。
  154. 根据权利要求153所述的方法，其特征在于，所述第一设备根据所述设备参数预测所述N个电子设备中每个电子设备执行所述第一业务的业务质量，包括：
    所述第一设备根据从每个电子设备获取的设备参数，计算每个电子设备执行所述第一业务的业务质量分数。
  155. 根据权利要求154所述的方法，其特征在于，所述N个电子设备中包括第三设备；
    当所述第三设备执行所述第一业务的业务质量分数高于所述N个电子设备中的其他电子设备时，所述推荐设备为所述第三设备；或者，
    当所述第三设备执行所述第一业务中第一子任务的业务质量分数高于所述N个电子设备中的其他电子设备时，所述推荐设备为所述第三设备。
  156. 根据权利要求154所述的方法，其特征在于，所述第一业务包括第一子任务和第二子任务，所述N个电子设备中包括第三设备和第四设备；
    当所述第三设备执行所述第一子任务的业务质量分数高于所述N个电子设备中的其他电子设备，且所述第四设备执行所述第二子任务的业务质量分数高于所述N个电子设备中的其他电子设备时，所述推荐设备为所述第三设备和所述第四设备。
  157. 根据权利要求154-156中任一项所述的方法，其特征在于，所述方法还包括：
    所述第一设备预测所述第一设备执行所述第一业务的业务质量分数；
    其中，当所述第一设备执行所述第一业务的业务质量分数高于所述N个电子设备时，所述推荐设备为所述第一设备。
  158. 根据权利要求153-157中任一项所述的方法，其特征在于，所述第一提示消息中包括所述推荐设备的设备标识；
    在所述第一设备显示第一提示消息之后，还包括：
    所述第一设备接收用户在所述第一提示消息中选择所述推荐设备的第三操作；
    响应于所述第三操作，所述第一设备将所述第一业务切换至所述推荐设备中执行。
  159. 根据权利要求153-158中任一项所述的方法，其特征在于，当所述第二设备不是所述N个电子设备中执行所述第一业务的业务质量最高的电子设备时，所述方法还包括：
    所述第一设备向所述第二设备通知所述推荐设备，以使得所述第二设备显示第二提示消息，所述第二提示消息用于提示用户使用推荐设备执行所述第一业务。
  160. 根据权利要求146-159中任一项所述的方法，其特征在于，所述设备参数包括音频参数、显示参数、相机参数或时延中的一个或多个。
  161. 一种超声波定位方法，其特征在于，包括：
    响应于用户打开投屏功能的操作，第一设备检测与所述第一设备接入同一通信网络的K个电子设备，K为大于1的整数；
    所述第一设备对第二设备进行超声波定位，得到所述第二设备的第一定位结果，所述第二设备为所述K个电子设备中的电子设备；
    所述第一设备对第三设备进行超声波定位，得到所述第三设备的第二定位结果，所述第三设备为所述K个电子设备中除所述第二设备之外的电子设备；
    所述第一设备在交互界面中显示所述第二设备的标识和所述第三设备的标识，所 述第二设备的标识在所述交互界面中的位置与所述第一定位结果相关，所述第三设备的标识在所述交互界面中的位置与所述第二定位结果相关。
  162. 根据权利要求161所述的方法，其特征在于，所述第一设备对第二设备进行超声波定位，包括：
    所述第一设备向所述第二设备发送第一定位指令，所述第一定位指令用于触发所述第二设备发射第一超声波信号；
    所述第一设备根据所述第一超声波信号分别到达所述第一设备中N个超声波接收器的时间对所述第二设备进行定位，N为大于1的整数。
  163. 根据权利要求161或162所述的方法，其特征在于，所述第一设备对第三设备进行超声波定位，包括：
    所述第一设备向所述第三设备发送第二定位指令，所述第二定位指令用于触发所述第三设备发射第二超声波信号；
    所述第一设备获取第一超声波数据，所述第一超声波数据包括所述第二超声波信号分别到达所述第一设备中N个超声波接收器的时间，N为大于1的整数；
    所述第一设备获取第二超声波数据，所述第二超声波数据包括所述第二超声波信号分别到达所述第二设备中M个超声波接收器的时间，M为大于1的整数；
    所述第一设备根据所述第一超声波数据和所述第二超声波数据对所述第三设备进行定位。
  164. 根据权利要求163所述的方法，其特征在于，在所述第一设备向所述第三设备发送第二定位指令之前，还包括：
    所述第一设备在所述K个电子设备中将所述第二设备确定为协同设备，所述协同设备用于协同所述第一设备进行超声波定位；
    所述第一设备向所述第二设备发送第一协同定位指令，所述第一协同定位指令用于触发所述第二设备使用所述M个超声波接收器检测所述第二超声波信号。
  165. 根据权利要求164所述的方法，其特征在于，所述第一设备在所述K个电子设备中将所述第二设备确定为协同设备，包括：
    当所述第二设备为所述K个电子设备中定位能力最高的电子设备时，所述第一设备将所述第二设备确定为所述协同设备。
  166. 根据权利要求163-165中任一项所述的方法，其特征在于，所述第一设备根据所述第一超声波数据和所述第二超声波数据对所述第三设备进行定位，包括：
    所述第一设备根据所述第二设备的第一定位结果、所述第一超声波数据和所述第二超声波数据对所述第三设备进行定位。
  167. 根据权利要求163-165中任一项所述的方法，其特征在于，所述N个超声波接收器为所述第一设备的麦克风阵列中的N个麦克风；和/或，所述M个超声波接收器为所述第二设备的麦克风阵列中的M个麦克风；
    其中，所述第一设备获取第一超声波数据，包括：
    所述第一设备使用所述N个麦克风检测所述第二超声波信号，得到N路第二超声波信号；
    其中，所述第一设备获取第二超声波数据，包括：
    所述第一设备获取所述第二设备使用所述M个麦克风检测到的M路第二超声波信号。
  168. 根据权利要求167所述的方法，其特征在于，所述第一设备根据所述第一超声波数据和所述第二超声波数据对所述第三设备进行定位，包括：
    所述第一设备将所述N路第二超声波信号和所述M路第二超声波信号合并为多声道超声数据；
    所述第一设备根据所述多声道超声数据，使用预设的定位算法对所述第三设备进行定位。
  169. 根据权利要求161或162所述的方法，其特征在于，所述第一设备对第三设备进行超声波定位，包括：
    所述第一设备向所述第三设备发送第二定位指令，所述第二定位指令用于触发所述第三设备发射第二超声波信号；
    所述第一设备获取第一超声定位结果，所述第一超声定位结果为所述第一设备根据所述第二超声波信号达到所述第一设备中N个超声波接收器的时间确定的，N为大于1的整数；
    所述第一设备获取第二超声定位结果，所述第二超声定位结果为所述第二设备根据所述第二超声波信号达到所述第二设备中M个超声波接收器的时间确定的，M为大于1的整数；
    所述第一设备根据所述第一超声定位结果和所述第二超声定位结果对所述第三设备进行定位。
  170. 根据权利要求169所述的方法，其特征在于，所述N个超声波接收器为所述第一设备的麦克风阵列中的N个麦克风；
    其中，所述第一设备获取第一超声定位结果，包括：
    所述第一设备使用所述N个麦克风检测所述第二超声波信号；
    所述第一设备根据所述N个麦克风中每个麦克风检测到所述第二超声波信号的时间对所述第三设备进行定位，得到所述第一超声定位结果。
  171. 根据权利要求161-170中任一项所述的方法，其特征在于，所述K个电子设备中还包括第四设备；所述方法还包括：
    所述第一设备对所述第四设备进行超声波定位，得到所述第四设备的第三定位结果；
    所述第一设备在所述交互界面中显示所述第二设备的标识、所述第三设备的标识以及所述第四设备的标识，其中，所述第二设备的标识在所述交互界面中的位置与所述第一定位结果相关，所述第三设备的标识在所述交互界面中的位置与所述第二定位结果相关，所述第四设备的标识在所述交互界面中的位置与所述第三定位结果相关。
  172. 根据权利要求171所述的方法，其特征在于，所述第一设备对所述第四设备进行超声波定位，包括：
    所述第一设备向所述第四设备发送第三定位指令，所述第三定位指令用于触发所述第四设备发射第三超声波信号；
    所述第一设备获取第三超声波数据，所述第三超声波数据包括所述第三超声波信 号分别到达所述第一设备中N个超声波接收器的时间；
    所述第一设备获取第四超声波数据，所述第四超声波数据包括所述第三超声波信号分别到达所述第二设备中M个超声波接收器的时间；
    所述第一设备根据所述第三超声波数据和所述第四超声波数据对所述第四设备进行定位。
  173. 根据权利要求172所述的方法，其特征在于，在所述第一设备向所述第四设备发送第三定位指令之后，还包括：
    所述第一设备获取第五超声波数据，所述第五超声波数据包括所述第三超声波信号分别到达所述第三设备中Z个超声波接收器的时间，Z为大于1的整数；
    其中，所述第一设备根据所述第三超声波数据和所述第四超声波数据对所述第四设备进行定位，包括：
    所述第一设备根据所述第三超声波数据、所述第四超声波数据以及所述第五超声波数据对所述第四设备进行定位。
  174. 根据权利要求173所述的方法，其特征在于，在所述第一设备向所述第四设备发送第三定位指令之前，还包括：
    所述第一设备将所述第二设备和所述第三设备均确定为协同设备；
    当所述第一设备向所述第四设备发送第三定位指令时，还包括：
    所述第一设备向所述第二设备和所述第三设备发送第二协同定位指令，所述第二协同定位指令用于触发所述第二设备使用所述M个超声波接收器检测所述第三超声波信号，并且，所述第二协同定位指令用于触发所述第三设备使用所述Z个超声波接收器检测所述第三超声波信号。
  175. 根据权利要求161-174中任一项所述的方法，其特征在于，在所述第一设备在交互界面中显示所述第二设备的标识和所述第三设备的标识之后，还包括：
    响应于用户选中所述第二设备的标识的操作，所述第一设备将所述第一设备播放的内容投射至所述第二设备播放；或者，
    响应于用户选中所述第三设备的标识的操作，所述第一设备将所述第一设备播放的内容投射至所述第三设备播放。
  176. 一种电子设备，其特征在于，所述电子设备为第一设备，所述第一设备包括：
    显示屏；
    一个或多个处理器；
    存储器；
    通信模块；
    其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述第一设备执行时，使得所述第一设备执行如权利要求1-175中任一项所述的方法。
  177. 一种电子设备，其特征在于，所述电子设备为第二设备，所述第二设备包括：
    一个或多个处理器；
    存储器；
    通信模块；
    其中，所述存储器中存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述第二设备执行时，使得所述第二设备执行如权利要求1-175中任一项所述的方法。
  178. 一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-175中任一项所述的方法。
  179. 一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在电子设备上运行时，使得所述电子设备执行如权利要求1-175中任一项所述的方法。
PCT/CN2021/104105 2020-07-02 2021-07-01 一种音频控制方法、系统及电子设备 WO2022002218A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21833204.7A EP4167580A4 (en) 2020-07-02 2021-07-01 AUDIO CONTROL METHOD, SYSTEM AND ELECTRONIC DEVICE
US18/013,904 US20230297324A1 (en) 2020-07-02 2021-07-01 Audio Control Method, System, and Electronic Device

Applications Claiming Priority (18)

Application Number Priority Date Filing Date Title
CN202010628962.7 2020-07-02
CN202010628962 2020-07-02
CN202010701720.6 2020-07-20
CN202010701720 2020-07-20
CN202010700459 2020-07-20
CN202010700459.8 2020-07-20
CN202010718939 2020-07-23
CN202010718939.7 2020-07-23
CN202010774729 2020-08-04
CN202010774729.X 2020-08-04
CN202010847900.5 2020-08-21
CN202010847900 2020-08-21
CN202011058010.2 2020-09-29
CN202011058010 2020-09-29
CN202011149031 2020-10-23
CN202011149031.5 2020-10-23
CN202011546105.9A CN113890932A (zh) 2020-07-02 2020-12-23 一种音频控制方法、系统及电子设备
CN202011546105.9 2020-12-23

Publications (1)

Publication Number Publication Date
WO2022002218A1 true WO2022002218A1 (zh) 2022-01-06

Family

ID=79315119

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/104105 WO2022002218A1 (zh) 2020-07-02 2021-07-01 一种音频控制方法、系统及电子设备

Country Status (3)

Country Link
US (1) US20230297324A1 (zh)
EP (1) EP4167580A4 (zh)
WO (1) WO2022002218A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130125192A1 (en) * 2011-11-15 2013-05-16 FeiJun Li Method of outputting video content from a digital media server to a digital media renderer and related media sharing system
CN104010210A (zh) * 2014-06-12 2014-08-27 广东欧珀移动通信有限公司 一种多播放设备的播放控制方法、装置及系统
CN104023261A (zh) * 2013-03-01 2014-09-03 致伸科技股份有限公司 数字媒体播放系统
CN106686519A (zh) * 2017-03-09 2017-05-17 广东欧珀移动通信有限公司 音频播放设备立体声配对的方法、装置及终端
CN110270096A (zh) * 2019-06-19 2019-09-24 杭州绝地科技股份有限公司 游戏应用中的音频资源配置方法、装置、设备及存储介质
CN111078448A (zh) * 2019-08-06 2020-04-28 华为技术有限公司 一种处理音频异常的方法及电子设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8706275B2 (en) * 2010-02-10 2014-04-22 Lenovo (Singapore) Pte. Ltd. Systems and methods for application sound management
CN104240738B (zh) * 2014-08-28 2018-05-11 杰发科技（合肥）有限公司 一种音效设置方法及电子装置
KR102351368B1 (ko) * 2015-08-12 2022-01-14 삼성전자주식회사 전자 장치에서 오디오 출력 방법 및 장치
KR102347069B1 (ko) * 2015-12-14 2022-01-04 삼성전자주식회사 전자 장치 및 그 동작방법
US20180098151A1 (en) * 2016-10-03 2018-04-05 Blackfire Research Corporation Enhanced multichannel audio interception and redirection for multimedia devices

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130125192A1 (en) * 2011-11-15 2013-05-16 FeiJun Li Method of outputting video content from a digital media server to a digital media renderer and related media sharing system
CN104023261A (zh) * 2013-03-01 2014-09-03 致伸科技股份有限公司 数字媒体播放系统
CN104010210A (zh) * 2014-06-12 2014-08-27 广东欧珀移动通信有限公司 一种多播放设备的播放控制方法、装置及系统
CN106686519A (zh) * 2017-03-09 2017-05-17 广东欧珀移动通信有限公司 音频播放设备立体声配对的方法、装置及终端
CN110270096A (zh) * 2019-06-19 2019-09-24 杭州绝地科技股份有限公司 游戏应用中的音频资源配置方法、装置、设备及存储介质
CN111078448A (zh) * 2019-08-06 2020-04-28 华为技术有限公司 一种处理音频异常的方法及电子设备

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4167580A4

Also Published As

Publication number Publication date
US20230297324A1 (en) 2023-09-21
EP4167580A1 (en) 2023-04-19
EP4167580A4 (en) 2023-11-29

Similar Documents

Publication Publication Date Title
US11818420B2 (en) Cross-device content projection method and electronic device
US11880628B2 (en) Screen mirroring display method and electronic device
CN113890932A (zh) 一种音频控制方法、系统及电子设备
US20220400305A1 (en) Content continuation method and electronic device
US10834503B2 (en) Recording method, recording play method, apparatuses, and terminals
KR20110054609A (ko) 블루투스 디바이스의 원격 제어 방법 및 장치
AU2013211541B2 (en) Mobile apparatus and control method thereof
CN112398855B (zh) 应用内容跨设备流转方法与装置、电子设备
WO2022143883A1 (zh) 一种拍摄方法、系统及电子设备
US20170195817A1 (en) Simultaneous Binaural Presentation of Multiple Audio Streams
JP2022546542A (ja) 通話方法、通話装置、通話システム、サーバ及びコンピュータプログラム
CN114697527A (zh) 一种拍摄方法、系统及电子设备
US11870941B2 (en) Audio processing method and electronic device
WO2022156721A1 (zh) 一种拍摄方法及电子设备
WO2022135527A1 (zh) 一种视频录制方法及电子设备
EP4152756A1 (en) Device recommendation method and electronic device
WO2022002218A1 (zh) 一种音频控制方法、系统及电子设备
CN115167802A (zh) 一种音频切换播放方法及电子设备
WO2023185589A1 (zh) 音量控制方法及电子设备
EP4284005A1 (en) Video dubbing method, related device, and computer readable storage medium
WO2023212879A1 (zh) 对象音频数据的生成方法、装置、电子设备和存储介质
WO2023024973A1 (zh) 一种音频控制方法及电子设备
CN113709652A (zh) 音频播放控制方法和电子设备
CN115942253A (zh) 一种提示方法及相关装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21833204

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021833204

Country of ref document: EP

Effective date: 20230111

NENP Non-entry into the national phase

Ref country code: DE