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 US18/013,904 priority Critical patent/US20230297324A1/en
Priority to EP21833204.7A priority patent/EP4167580A4/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

Definitions

  • the present application relates to the field of terminals, and in particular, to an audio control method, system and electronic device.
  • Smart terminals such as mobile phones generally have audio input and output functions.
  • a mobile phone can use its own speaker (speaker) to play audio, and can also use its own microphone (mic) to record audio.
  • the mobile phone can also output audio through an audio output device such as a wired headset, a Bluetooth headset, or a Bluetooth speaker.
  • a user or family often has multiple terminal devices.
  • a user's home may include an interconnected system composed of terminals such as several mobile phones, TVs, speakers, and PCs.
  • terminals such as several mobile phones, TVs, speakers, and PCs.
  • how to flexibly play and control the audio data of a certain terminal on one or more other terminals has become an urgent problem to be solved.
  • the present application provides an audio control method, system and electronic device, which can flexibly switch the audio of a certain terminal to play on one or more other terminals, thereby improving the user's audio experience.
  • the present application provides an audio control method, comprising: in response to a first operation input by a user, a first device may display a list of candidate devices, where the list of candidate devices includes at least one candidate device with an audio output function; if The first device detects that the user selects the second device in the above candidate device list, indicating that the user wants to switch the audio function of the first device to the second device. At this time, the first device is the master device and the second device is the slave device.
  • the second device can be an electronic device with an operating system, such as a speaker, a TV, or a mobile phone); furthermore, the first device can acquire the audio capability parameter of the second device, and the audio capability parameter is used to indicate the hardware capability of the second device to play audio And the software capability of the second device to play audio; like this, the first device can determine the first audio playback strategy according to the audio capability parameter of the second device, thereby performing the first audio data from the first audio application according to the first audio playback strategy. In the first process, second audio data is obtained; further, the first device may send the second audio data to the second device for playback.
  • the first device can obtain the audio capability parameter of the slave device (that is, the second device) when performing audio switching, because the audio capability parameter can reflect the software processing capability and hardware processing capability of the second device when playing audio,
  • the first device is enabled to determine, according to the audio capability parameter of the second device, a first audio playback strategy matching the audio capability of the second device.
  • the software processing capability of the second device when playing audio is mainly determined by software characteristics (such as sound effect processing algorithms), and the hardware processing capability of the second device when playing audio is mainly determined by hardware characteristics (such as speaker devices, etc.). Specifically, This will be explained in the detailed description.
  • first processing may include sound effect processing, performing sound mixing according to the number of channels, etc., which will be described in detail below with reference to possible implementations.
  • the first device can send the second audio data obtained after processing to the second device, so that the slave device can play the same audio capability as its own. matching audio data from the first device.
  • the second device may directly play the second audio data after playing the received second audio data, or may process the second audio data before playing.
  • the first device can flexibly switch its own audio playback function to one or more other slave devices, and control the audio playback process of the slave device according to the audio capability of the slave device, thereby providing users with better audio Using the experience, it can also use the audio processing capability of the slave device to cooperate with the master device to complete the processing and playback of audio data.
  • the above-mentioned audio capability parameter may specifically include a sound effect parameter, and the sound effect parameter is used to indicate whether the second device enables the sound effect mode; in this case, the first device determines the first audio frequency according to the audio capability parameter of the second device Playing strategy, including: if the second device enables the sound effect mode, the first device can set in the first audio playback strategy not to perform sound effect processing on the first audio data; if the second device does not enable the sound effect mode, the first device Performing sound effect processing on the first audio data may be set in the first audio playback strategy.
  • the first processing performed by the first device on the first audio data may specifically include sound effect processing, such as adding a subwoofer sound effect. If it is set in the first audio playback policy not to perform sound effect processing on the first audio data, the first device does not need to perform sound effect processing on the first audio data, and the second device can subsequently perform sound effect processing on the received audio data.
  • the above-mentioned audio capability parameters may specifically include sound effect parameters, and the sound effect parameters are used to indicate the sound effect mode supported by the second device, for example, Dolby sound effect, histen sound effect, etc.;
  • the sound effect mode of audio playback is set to the first sound effect mode; at this time, the first device determines the first audio playback strategy according to the audio capability parameter of the second device, including: if the first sound effect mode is the sound effect mode supported by the second device, It means that the second device is capable of completing the first sound effect, then the first device can set in the first audio playback policy not to perform sound effect processing on the first audio data; if the first sound effect mode is not a sound effect mode supported by the second device, explain If the second device is not capable of completing the first sound effect, the first device may set in the first audio playback policy to perform sound effect processing on the first audio data according to the first sound effect mode.
  • the first device may set the first device or the second device to perform sound effect processing by default in the first audio playback policy.
  • the first processing performed by the first device on the first audio data may specifically be adding the first sound effect to the first audio data. ; If it is set in the first audio playback strategy that the first audio data is not processed by the first sound effect mode, then the first device does not need to add the first sound effect to the first audio data, and the second device can receive it later. The first sound effect is added to the audio data.
  • the above-mentioned audio capability parameter may specifically include a target sampling rate, and the target sampling rate is a sampling rate supported by the second device (for example, 48KHz or 96KHz, etc.);
  • the audio capability parameter determines the first audio playback strategy, including: setting by the first device in the first audio playback strategy to sample the first audio data according to the target sampling rate.
  • the first processing performed by the first device on the first audio data may specifically be resampling according to the target sampling rate.
  • the first audio data of 96KHz is down-sampled to the second audio data of 48KHz.
  • the first audio data of 48KHz is upsampled to the second audio data of 96KHz.
  • the above-mentioned audio capability parameter may specifically include the number of target channels, and the number of target channels is the number of channels supported by the second device (for example, two-channel, four-channel, etc.);
  • a device determining the first audio playback strategy according to the audio capability parameter of the second device includes: the first device configures in the first audio playback strategy to mix the first audio data according to the target number of channels.
  • the first processing performed by the first device on the first audio data may specifically be performing audio mixing according to the above target number of channels.
  • 8-channel first audio data is down-mixed into 4-channel second audio data.
  • the first audio data of two channels is upmixed into the second audio data of eight channels.
  • the above-mentioned audio capability parameter may specifically include a delay parameter, and the delay parameter is used to indicate whether the second device supports low-latency audio processing capability;
  • the audio capability parameter determines the first audio playback strategy, including: if the second device supports a low-latency audio processing capability, the first device may be set in the first audio playback strategy to process the first audio data according to the low-latency mode; if If the second device does not support the low-latency audio processing capability, the first device may set in the first audio playback policy to process the first audio data in a non-low-latency mode.
  • the first device can set the duration of each frame of audio data to be smaller, so as to shorten the delay for the second device to process the frame of audio data.
  • the above audio capability parameter may include a delay parameter, and the delay parameter is used to indicate the audio playback delay of the second device, that is, the time required for the second device to process one frame of audio data, for example, 10ms or 5ms; at this time, the first device determines the first audio playback strategy according to the audio capability parameter of the second device, including: if the audio playback delay of the second device is less than the preset value, indicating that the second device supports low-latency audio processing capability, the first device can be set in the first audio playback strategy to process the first audio data in a low-latency mode; if the audio playback delay of the second device is greater than or equal to the preset value, the second device does not support low-latency delay audio processing capability, the first device is set in the first audio playback policy to process the first audio data in a non-low-latency mode.
  • the delay parameter is used to indicate the audio playback delay of the second device, that is, the time required for the second device to process one frame of audio data, for example
  • the first processing performed by the first device on the first audio data may specifically be dividing the first audio data into each frame of audio data according to the first duration. If the non-low time delay mode is set in the first audio playback strategy, then the first processing that the first equipment carries out to the first audio data can specifically be that the first audio data is divided into each frame of audio data according to the second duration, The second duration is greater than the first duration.
  • the application layer of the first device is installed with a first preset application, such as a DV APP; wherein, the first device acquires the audio capability parameters of the second device, including: the first device runs the first device by running the A preset application obtains the audio capability parameter of the second device from the second device, that is, obtains the audio capability of the slave device through the installed DV APP.
  • a first preset application such as a DV APP
  • the first device acquires the audio capability parameters of the second device, including: the first device runs the first device by running the A preset application obtains the audio capability parameter of the second device from the second device, that is, obtains the audio capability of the slave device through the installed DV APP.
  • an application adapted to the first preset application may be installed in the second device, so as to provide the first device with the audio capability parameter of the second device, and receive the second audio data.
  • the first device and the second device can be provided by different manufacturers, and the second device only needs to install the corresponding application to cooperate with the first device to execute this solution, so this solution can be adapted to Equipped with equipment provided by various manufacturers, it can be widely used.
  • the method further includes: the first preset application (for example, a DV APP) can create a corresponding audio capability parameter in the HAL according to the audio capability parameter of the second device.
  • Hardware abstraction module for example, DMSDP Audio HAL
  • the first device sends the second audio data to the second device, including: the first device calls the DMSDP Audio HAL to send the second audio data to the second device. That is to say, the first device can dynamically create a corresponding DMSDP Audio HAL according to the audio capability parameters of the slave device when performing audio switching, so as to use the DMSDP Audio HAL to send audio data to the slave device.
  • the application framework layer of the first device includes an audio policy module (for example, AudioPolicy); at this time, the first device determines the first audio playback policy according to the audio capability parameter of the second device, including: A preset application sends the audio capability parameter of the second device to the audio strategy module, and the audio strategy module determines the first audio playback strategy according to the audio capability parameter of the second device.
  • an audio policy module for example, AudioPolicy
  • the application framework layer of the first device includes an audio processor (for example, AudioFlinger); at this time, the first device performs the first audio data from the first audio application according to the first audio playback strategy.
  • the first processing to obtain the second audio data includes: the audio processor can receive the first audio data from the first audio application; and the audio processor can obtain the first audio playback strategy from the audio strategy module, and then the audio processor The first audio data may be processed according to the first audio playback strategy, and the second audio data obtained after the processing may be output.
  • the first processing includes depends on the specific content of the first audio playback strategy. For example, if the first audio playback strategy requires the first device to add a first sound effect, the first processing may include adding the first sound effect. Sound processing process. For another example, if the first audio playback strategy requires the first device to sample at a sampling rate of 48KHz, then the process of sampling at a 48KHz sampling rate is performed at a 48KHz sampling rate. In some cases, the first audio playback strategy may also be empty, that is, the first device does not need to perform any processing on the first audio data from the first audio APP. In this case, the first device does not need to perform the first audio data on the first audio data. Once processed, the first audio data can be directly sent to the second device.
  • the above method may further include: when the audio capability parameter of the second device is updated, for example, the sound effect mode of the second device is adjusted from Dolby sound effect to subwoofer sound effect, at this time, the first preset It is assumed that the application can obtain the updated audio capability parameter of the second device; and, the first preset application can send the updated audio capability parameter to the audio strategy module, so that the audio strategy module can convert the first audio according to the updated audio capability parameter.
  • the playback strategy is updated to the second audio playback strategy; then, the audio strategy module can output the second audio playback strategy to the audio processor, and the audio processor performs the second audio data on the received audio data according to the updated second audio playback strategy. deal with. Similar to the first process described above, what the second process includes depends on the specific content of the second audio playback strategy.
  • the first preset application may also update the above-mentioned DMSDP Audio HAL according to the updated audio capability parameters, so that the updated DMSDP Audio HAL can It supports sending the audio data that has undergone the above second processing to the second device.
  • the first device can dynamically update the audio playback strategy for processing audio data, and can also dynamically update the corresponding DMSDP Audio HAL , that is, keep the DMSDP Audio HAL and the audio playback strategy matched with the capability of the slave device in time, so that the first device can perform audio switching with the second device according to the updated audio capability of the second device.
  • the method further includes: the first device can receive a second operation for setting the volume by the user, such as clicking the volume + button or the volume - The operation of the button; the audio strategy module can set the volume level in the first audio playback strategy in response to the above-mentioned second operation, for example, the volume is set to 120 by 100, and the audio playback strategy after the setting is the third audio playback strategy; The strategy module can output the third audio playback strategy to the audio processor, so that the audio processor modifies the gain of the received audio data according to the volume level set in the third audio playback strategy, thereby modifying the audio data played subsequently by the second device volume level.
  • a second operation for setting the volume by the user such as clicking the volume + button or the volume - The operation of the button
  • the audio strategy module can set the volume level in the first audio playback strategy in response to the above-mentioned second operation, for example, the volume is set to 120 by 100, and the audio playback strategy after the setting is the third audio playback strategy
  • the strategy module can
  • the first device can also dynamically update the audio playback strategy for processing the audio data, that is, re-customize the audio playback strategy that matches the audio capability of the second device.
  • the second audio application is installed in the application layer of the first device; after the first device sends the second audio data to the second device, the method further includes: the audio processor receives audio from the second audio The audio data of application; When the audio data of the second audio application is different from the type of the audio data of the first audio application, the audio strategy module can update the first audio playback strategy to the fourth audio playback strategy; And then, the audio strategy module will The fourth audio playback strategy is output to the audio processor, and the audio processor performs third processing on the received audio data according to the fourth audio playback strategy; the audio processor sends the third processed audio data to the third audio data through the hardware abstraction module. Second equipment. Similar to the above-mentioned first process, the specific content of the third process depends on the specific content of the fourth audio playback strategy.
  • the first device can also dynamically update the audio playback strategy for processing the audio data, so that the audio data received by the second device is the same as its own. audio capabilities to match.
  • the method further includes: the first device receives a third operation of the user selecting the third device to play audio, that is, the user sends the first audio data to the second device.
  • the slave device of the device is changed from the second device to the third device; in response to the third operation, the first preset application can obtain the audio capability parameter of the third device from the third device;
  • the audio capability parameter is sent to the audio strategy module, so that the audio strategy module updates the first audio playback strategy to the fifth audio playback strategy according to the audio capability parameter of the third device; the audio strategy module outputs the fifth audio playback strategy to the audio processor, So that the audio processor performs the fourth processing on the received audio data according to the fifth audio playing strategy.
  • the specific content of the fourth process depends on the specific content of the fifth audio playback strategy.
  • the first preset application may also update the DMSDP Audio HAL according to the audio capability parameter of the third device, so that the updated DMSDP Audio HAL The HAL supports sending the fourth processed audio data to the third device.
  • the first device when the slave device connected to the first device changes, the first device can dynamically update the audio playback strategy for processing audio data, and can also dynamically update the corresponding DMSDP Audio HAL, that is, keep the DMSDP Audio HAL and audio playback.
  • the policy matches the capability of the slave device in time, so that the first device can perform audio switching with the third device according to the audio capability of the new slave device (ie, the third device).
  • the application layer of the first device may install a second preset application, and the second preset application may be the same as or different from the above-mentioned first preset application;
  • the sending of the audio data to the second device includes: the first device sends the second audio data to a second preset application, and the second preset application sends the second audio data to the second device.
  • the first preset application does not need to create a corresponding DMSDP Audio HAL in the HAL.
  • the method further includes: the first device displays an application interface of the first audio application, and an audio switching button can be set in the application interface;
  • the operation is the operation of the user clicking the audio switch button. That is, the user can enter the audio switching function from the audio switching button set in the audio application during the running process of the audio application.
  • the first device before the first device displays the candidate device list, it further includes: the first device displays a control center, and an audio switching button can be set in the control center; at this time, the above-mentioned first operation is that the user clicks the audio switching button button operation. That is to say, the user can enter the audio switching function on the audio switching button in the control center.
  • the audio capability parameter of the second device may include a recording parameter, and the recording parameter is used to indicate the audio input capability of the second device, that is, the recording capability; similar to the above audio playback process, the above method also further The method includes: the first device determines an audio recording strategy according to the recording parameter; after receiving the first recording data recorded by the second device, the first device processes the first recording data according to the audio recording strategy to obtain the second recording data; and then the first The device may report the second recording data to the audio application with the recording function enabled. That is to say, in addition to distributing the audio output function to the slave devices for implementation, the first device may also distribute the audio input function to the slave devices for implementation.
  • the present application provides an audio control method, comprising: in response to a first operation input by a user, the first device displays a list of candidate devices, where the list of candidate devices includes at least one candidate device with an audio output function; In the operation of selecting the second device in the candidate device list, the first device obtains the audio capability parameter of the second device, and the audio capability parameter is used to indicate the hardware capability of the second device to play audio and the software capability of the second device to play audio; A device may determine, according to the audio capability parameter of the second device, that it does not need to process the audio data from the first audio application; for example, since the audio capability parameter of the second device indicates that the second device has capabilities such as sampling and sound effect processing, then , the first device can determine that the first device does not need to sample the audio data from the first audio application, add sound effects, etc., but the second device processes the audio data from the first audio application; then, the first The device may directly send the audio data of the first audio application to the second device.
  • the second device After receiving the audio data sent by the first device, the second device can perform corresponding processing (eg, sampling, adding sound effects, etc.) to the audio data according to its own audio capabilities, and play the processed audio data.
  • processing eg, sampling, adding sound effects, etc.
  • the second device may directly play the audio data, which is not limited in this embodiment of the present application.
  • the first device may determine that the first device does not need to perform sound effect processing of Dolby sound effects on the above-mentioned audio data. After the second device receives the audio data sent by the first device, the audio data can be processed with Dolby sound effects. For another example, if the audio capability parameter of the second device indicates that the second device has a sound mixing capability, the first device may determine that the first device does not need to perform sound mixing processing on the above-mentioned audio data. After the second device receives the audio data sent by the first device, the audio data can be mixed. In this way, when performing audio switching, the first device can make full use of the audio processing capability of the slave device, and cooperate with the slave device to complete the audio data processing process more efficiently and flexibly.
  • the above-mentioned processing refers to a processing operation related to the audio capability parameter of the second device.
  • the first device can still perform conventional processing operations such as parsing, encoding, decoding, encapsulating or decapsulating the audio data to be sent, and these processing operations are usually not directly related to the audio capability parameters of the second device.
  • the first device may also send to the second device an audio policy when the second device processes the audio data. For example, if the sound effect mode is not enabled on the first device but the sound effect mode is enabled on the second device, the first device may set in the audio policy that the second device performs sound effect processing on the received audio data. Then, after receiving the audio strategy and the audio data from the first audio application, the second device can perform sound effect processing on the audio data according to the audio strategy, thereby reducing the operating load of the first device.
  • the present application provides an audio control method, comprising: in response to a first operation input by a user, a first device displays a candidate device list, where the candidate device list includes at least one candidate device with an audio output function; in response to a user input In the operation of selecting the second device and the third device in the candidate device list, the first device obtains the audio capability parameters of the second device and the audio capability parameters of the third device respectively.
  • the slave devices of the first device include the second device. and the third device, the audio capability parameter of the second device is used to indicate the hardware capability of the second device to play audio and the software capability of the second device to play audio, and the audio capability parameter of the third device is used to indicate the third device.
  • the hardware capability of playing audio and the software capability of playing audio of the third device further, the first device can determine the multi-device audio playback strategy according to the audio capability parameter of the second device and the audio capability parameter of the third device; and, the first device can Perform the first processing on the first audio data from the first audio application according to the multi-device audio playback strategy to obtain the second audio data corresponding to the second device and the third audio data corresponding to the third device; The device may send the second audio data to the second device for playback, and send the third audio data to the third device for playback.
  • the second device can directly play the second audio data. Audio data, and the second audio data may also be processed before being played. Similarly, after the first device sends the third audio data to the third device, the third device may directly play the third audio data, or may process the third audio data before playing. In this way, the first device can switch its own audio playback function to multiple slave devices at the same time, so as to realize the distributed audio capability across the devices.
  • the above-mentioned multi-device audio playback strategy includes a first strategy and a second strategy;
  • the device audio playback strategy performs first processing on the first audio data from the first audio application to obtain second audio data corresponding to the second device and third audio data corresponding to the third device, including: After the audio data is copied, first data and second data are obtained (the first data is the same as the first audio data, and the second data is the same as the first audio data); further, the first device can process the first data stream according to the first strategy , to obtain the second audio data; and, the first device may process the second data stream according to the second strategy to obtain the third audio data.
  • a first preset application (for example, a DV APP) is installed in the application layer of the first device; after the first device obtains the audio capability parameters of the second device and the audio capability parameters of the third device respectively, due to the second The audio capability parameter of the device is different from the audio capability parameter of the third device. Therefore, the first preset application can create the first hardware abstraction module in the HAL according to the audio capability parameter of the second device, and, according to the audio capability parameter of the third device Create a second hardware abstraction module in the HAL; at this time, the first device can send the second audio data to the second device through the first hardware abstraction module, and the first device can send the third audio data through the second hardware abstraction module sent to a third device.
  • a first preset application for example, a DV APP
  • the first device when the audio capability parameter of the second device is the same as the audio capability parameter of the third device, the first device performs playback on the first audio data from the first audio application according to the above-mentioned multi-device audio playback strategy.
  • the first process to obtain the second audio data corresponding to the second device and the third audio data corresponding to the third device includes: the first device performs a first process on the first audio data according to the above-mentioned multi-device audio playback strategy, and obtains second audio data; the first device obtains third audio data after copying the second audio data.
  • the first preset application installed by the first device may be based on the audio capability parameter of the second device (or the audio capability of the third device).
  • parameter) Create a hardware abstraction module in the HAL at this time only one hardware abstraction module needs to be created; the first device can send the second audio data to the second device through the hardware abstraction module, and the first device can pass the hardware abstraction module.
  • the present application provides an audio control method, comprising: in response to a first operation input by a user, the first device displays a list of candidate devices, where the list of candidate devices includes at least one candidate device with an audio input function; In the operation of selecting the second device (the second device is a speaker, or a TV, or a mobile phone) in the candidate device list, the first device obtains the audio capability parameter of the second device, and the audio capability parameter is used to indicate the hardware of the second device to record audio capability and the software capability of the second device to record audio; the first device can determine the first audio recording strategy according to the audio capability parameter of the second device; subsequently, when the first device receives the first recording data sent by the second device, the first device A device may perform first processing on the first audio recording data according to the above-mentioned first audio recording strategy to obtain the second audio recording data.
  • the first device ie the master device
  • the second device ie the slave device
  • the capability related to the audio output function in the parameters determines the corresponding first audio recording strategy.
  • the first device can flexibly switch its own audio input function to the slave device according to the first audio recording strategy, and can also use the audio recording capability of the slave device to cooperate with the master device to complete the audio data recording process.
  • the first processing includes depends on the specific content of the first audio recording strategy. For example, if the first audio recording strategy requires the first device to use the 3A algorithm to perform echo cancellation, the first processing may include using the 3A algorithm to perform echo cancellation. processing process. In some cases, the first audio recording strategy may also be empty, that is, the first device does not need to perform any processing on the first recorded data sent by the second device. In this case, the first device does not need to perform the first recording on the first recorded data. one processing.
  • the method further includes: when the audio capability parameter of the second device is updated, the first device may acquire the updated audio capability of the second device parameter; further, the first device can update the first audio recording strategy to the second audio recording strategy according to the updated audio capability parameter; subsequently, when the first device receives the third recording data sent by the second device, the first The device may perform second processing on the third recording data according to the second audio recording strategy to obtain fourth recording data.
  • the first device can dynamically update the audio recording policy for processing the recording data.
  • the processing ie, the second processing
  • the processing of the subsequently received recording data by the first device will also be adjusted accordingly, so that the first device can perform audio switching with the second device according to the updated audio recording capability of the second device.
  • what the second process includes depends on the specific content of the second audio playback strategy.
  • the method further includes: the first device can receive a second operation for the user to select the third device for audio recording, that is, the user selects the first device to perform audio recording.
  • the audio input device is changed from the second device to the third device; in response to the second operation, the first device can obtain the audio capability parameter of the third device from the third device;
  • the capability parameter determines the third audio recording strategy; subsequently, when the first device receives the fifth recording data sent by the third device, the first device performs the third processing on the fifth recording data according to the third audio recording strategy, and obtains the sixth recording data.
  • the first device can dynamically update the audio playback strategy for processing the recording data.
  • the processing ie, the third processing
  • the processing of the subsequently received recording data by the first device will also be adjusted accordingly, so that the first device can perform audio switching with the third device according to the audio recording capability of the third device.
  • what the third process includes depends on the specific content of the third audio playback strategy.
  • the method further includes: the first device creates a corresponding hardware abstraction module in the HAL according to the audio capability parameter of the second device; at this time,
  • the first device receiving the first recording data sent by the second device includes: the first device receiving the first recording data sent by the second device through a hardware abstraction module. That is to say, when the first device performs audio switching, it can dynamically create a corresponding DMSDP Audio HAL according to the audio capability parameters of the slave device, so as to use the DMSDP Audio HAL to receive the recording data sent by the slave device.
  • the first device can also update the above-mentioned DMSDP Audio HAL according to the latest audio capability parameter, so that the update The latter DMSDP Audio HAL can send and receive data with the current slave device.
  • the first device may also include a first preset application (such as DV APP), an audio policy module (such as AudioPolicy), and an audio processor (such as AudioFlinger), etc.
  • a first preset application such as DV APP
  • an audio policy module such as AudioPolicy
  • an audio processor such as AudioFlinger
  • the present application provides an audio control method, comprising: a second device sending a first audio capability parameter to the first device, where the first audio capability parameter is used to indicate the hardware capability of the second device to play audio and the second device to play The software capability of audio, the second device is a speaker, or a TV, or a mobile phone; subsequently, the second device can receive the first audio data sent by the first device, and the first audio data is processed by the first device according to the first audio capability parameter. Further, the second device may play the first audio data, or the second device may process the first audio data and then play it.
  • a preset application is installed in the application layer in the second device; wherein, the second device sending the first audio capability parameter to the first device includes: the second device sends the preset application to the first device by running the preset application.
  • the first device sends the first audio capability parameter; wherein, the second device receiving the first audio data sent by the first device includes: the second device receives the first audio data sent by the first device by running a preset application.
  • the second device that is, the slave device of the first device
  • the second device only needs to install the above-mentioned preset application (which may be called a proxy APP), and then can report itself to the first device through the proxy APP
  • the audio capability parameter is obtained from the first device, and audio data matching its own audio capability is acquired and played. Since there is no need to change the operating system of the second device, the first device and the second device can be provided by different manufacturers, and the second device only needs to install the corresponding application to cooperate with the first device to execute this solution, so this solution can be adapted to Equipped with equipment provided by various manufacturers, it can be widely used.
  • the method further includes: the second device sets the third device as an audio output device (The third device is different from the second device, and the third device is different from the first device); the second device sends a second audio capability parameter to the first device, and the second audio capability parameter is used to indicate the hardware capability of the third device to play audio And the software capability of the third device to play audio; the second device receives the second audio data sent by the first device, and the second audio data is obtained after the first device is processed according to the second audio capability parameter; the second device plays the second audio data, or the second device plays the second audio data after processing.
  • the second device when the second device is connected to other audio output devices (such as the third device), the second device can act as the master device of the third device and re-report its own audio capability parameters (ie, the second audio capability parameters),
  • the second audio capability parameter reflects the audio capability of the third device, so that the first device can process audio data according to the new audio capability parameter to implement the audio switching function.
  • the method further includes: when the audio capability of the second device changes, the second device The device updates the first audio capability parameter to the third audio capability parameter; the second device sends the third audio capability parameter to the first device; the second device receives the third audio data sent by the first device, and the third audio data is the first The device is obtained after processing according to the third audio capability parameter; the second device plays the third audio data, or the second device processes the third audio data and then plays it.
  • the second device when the audio capability of the second device changes, the second device can re-report its own audio capability parameter (that is, the third audio capability parameter), so that the first device can process the audio data according to the new audio capability parameter, Implement audio switching function.
  • the above-mentioned first audio capability parameter may also indicate the hardware capability of the second device to record audio and the software capability of the second device to record audio, that is, the first audio capability parameter may also include the ability to record audio.
  • a parameter reflecting the recording capability of the second device such as an echo cancellation algorithm used by the second device, etc.; then, after the second device sends the first audio capability parameter to the first device, it also includes: the second device starts to record audio, and obtains recording data; the second device sends the recording data to the first device, so that the first device processes the recording data according to the first audio capability parameter.
  • the above method further includes: the second device receives an audio strategy sent by the first device, where the audio strategy is determined by the first device according to the first audio capability parameter, and the audio strategy may include an audio playback strategy and/or an audio recording strategy; at this time, the second device may process the first audio data according to the audio playback strategy, and play the processed first audio data. That is to say, the first device as the master device can instruct the second device which processing needs to be performed during audio switching according to the audio capability parameter of the second device, so as to give full play to the audio capability of the second device and provide users with better audio Use experience.
  • the present application provides an audio control method, comprising: a second device sending a first audio capability parameter to the first device, where the first audio capability parameter is used to indicate the hardware capability of the second device to record audio and the second device to record
  • the software capability of audio the second device can be a speaker, a TV, or a mobile phone; further, the second device can call the microphone to start recording audio, and obtain the first recording data; the second device sends the first recording data to the first device, So that the first device processes the first recording data according to the above-mentioned first audio capability parameter.
  • a preset application is installed in the application layer in the second device; wherein, the second device sending the first audio capability parameter to the first device includes: the second device sends the preset application to the first device by running the preset application.
  • the second device only needs to install the above-mentioned preset application (which may be referred to as a proxy APP), and then can report and communicate with the first device through the proxy APP. Audio capability parameters related to its own audio recording capability, and send the recording data to the first device. Since there is no need to change the operating system of the second device, the first device and the second device can be provided by different manufacturers, and the second device only needs to install the corresponding application to cooperate with the first device to execute this solution, so this solution can be adapted to Equipped with equipment provided by various manufacturers, it can be widely used.
  • a proxy APP which may be referred to as a proxy APP
  • the method further includes: the second device sets the third device as an audio input device (the third device is different from the second device, The third device is different from the first device); the second device sends a second audio capability parameter to the first device, and the second audio capability parameter is used to indicate the hardware capability of the third device to record audio and the software capability of the third device to record audio; The second device sends the second recording data recorded by the third device to the first device, so that the first device processes the second recording data according to the above-mentioned second audio capability parameter.
  • the second device when the second device is connected to other audio input devices (such as the third device), the second device can act as the master device of the third device and re-report its own audio capability parameters (that is, the second audio device) to the first device.
  • the second audio capability parameter reflects the audio recording capability of the third device, so that the first device can process the recording data according to the new audio capability parameter, and realize the audio switching function.
  • the method further includes: when the audio recording capability of the second device changes, the second device updates the first audio capability parameter to the third audio capability parameter; the second device sends the third audio capability parameter to the first device; the second device sends the recorded third recording data to the first device, so that the first device processes the third audio capability parameter according to the above-mentioned third audio capability parameter Three recording data.
  • the second device when the audio recording capability of the second device changes, the second device can re-report its own audio capability parameter (ie, the third audio capability parameter), so that the first device can process the second device according to the new audio capability parameter.
  • the recording data reported by the device realizes the audio switching function.
  • the above method further includes: the second device receives an audio recording strategy sent by the first device, where the audio recording strategy is determined by the first device according to the first audio capability parameter; in this case, the second device Audio can be recorded according to the audio playback strategy to obtain the above-mentioned first recording data. That is to say, the first device as the master device can instruct the second device which processing needs to be performed when recording according to the audio capability parameter of the second device, so as to give full play to the audio capability of the second device and provide users with better audio usage experience.
  • the present application provides an audio control method, comprising: after the first device establishes a network connection with the second device, the first device can use the second device as a slave device to obtain a device selection policy corresponding to the second device ; Subsequent, when the first device obtains the first audio data to be played (the type of the first audio data is the first type), the first device can determine whether the first audio data is allowed according to the first type and the above-mentioned device selection strategy. Play in the second device, that is, determine whether the audio output device of the first audio data is the second device; if the first audio data is allowed to be played in the second device, the first device can send the first audio data to the second device. device to play.
  • the first device ie the master device
  • the second device ie the slave device
  • it can send specific types of audio data to the second device for playback according to the corresponding device selection strategy , so as to filter out some audio data that is not suitable for playing on the second device for the user, so that different audio output devices can play corresponding audio to the user in a targeted manner, and the adaptability of audio data and audio output device is higher, Improve the user's audio experience.
  • the above-mentioned device selection strategy may specifically include: the type of audio data that the second device is allowed to play and the type of audio data that is not allowed to play; at this time, the first device selects according to the first type and the device
  • the strategy for determining whether the first audio data is allowed to be played in the second device includes: the first device inquires whether the second device is allowed to play the first type of audio data in the above device selection strategy; if the second device is allowed to play the first type of audio data audio data, the first device determines that the first audio data is allowed to be played in the second device; if the second device does not allow the playback of the first type of audio data, the first device determines that the first audio data is not allowed to be played in the second device play.
  • the first device when the first device switches audio to the second device, it can project the audio data of one or more types allowed to be played by the second device to the second device for playback according to the device selection policy, and the second device in the device selection policy One-to-many types of audio data that are not allowed to be played will not be projected to the second device for playback, thereby filtering out some audio data that are not suitable for playing on the second device for the user.
  • the above-mentioned device selection strategy may specifically include: the application from which the audio data that the second device is allowed to play comes from and the type of audio data that the second device is allowed to play, and the audio data that the second device does not allow to play comes from The application and the type that the second device does not allow to play; that is, the device selection policy can use the application as the dimension to set the audio data that is allowed or not allowed to be played by the second device.
  • the first device determines whether the first audio data is allowed to be played in the second device according to the first type and the device selection policy, including: the first device determines that the first audio data comes from the first application; further, the first device may In the device selection policy, query whether the second device allows to play the first type of audio data from the first application; if the second device allows to play the first type of audio data from the first application, the first device determines that the first audio The data is allowed to be played in the second device; if the second device is not allowed to play the audio data of the first type from the first application, the first device determines that the first audio data is not allowed to be played in the second device.
  • the first device when the first device switches audio to the second device, the first device can output different types of audio data generated by an application to the corresponding audio output device for playback according to the device selection strategy, so that different audio output devices A specific type of audio data in a specific application can be played in a targeted manner to improve the user's audio experience.
  • the above device selection strategy also includes audio output devices of different types of audio data; generally, the audio output device of the audio data that the second device allows to play is the second device itself, and the second device does not allow
  • the audio output device of the played audio data may be other electronic devices such as the first device.
  • the first device determines that the first audio data is not allowed to be played in the second device according to the above device selection strategy, the first device can query the first audio data in the device selection strategy according to the first type of the first audio data
  • the specific audio output device is a third device (the third device is different from the second device); further, the first device can send the first audio data to be played to the third device for playback. In this way, the first audio data that is not suitable for playing in the second device can be shunted to the third device for playing, so as to avoid the audio data to be played in the first device being omitted.
  • the above-mentioned third device may be an audio output device that has recently been connected to the first device except the second device. That is, when the first audio data is not suitable to be played on the second device, the first device may select an audio output device for the first audio data according to the principle of priority after access.
  • the above-mentioned device selection strategy may specifically include: correspondence between different types of audio data and different audio output devices; for example, the audio output devices for music-type audio data are TVs, speakers, and mobile phones. .
  • the first device determines whether the first audio data is allowed to be played in the second device according to the first type and the device selection policy, including: the first device may query the audio data corresponding to the first type of audio data in the device selection policy Whether the output device includes the second device; if the second device is included, the first device determines that the first audio data is allowed to be played in the second device; if the second device is not included, the first device determines that the first audio data is not allowed to be played in the second device. playback on the second device.
  • the above device selection strategy may specifically include: the correspondence between different applications, different types of audio data and different audio output devices; for example, the audio data of music type audio data generated in the WeChat application
  • the output devices are TVs, speakers and mobile phones.
  • the first device determines whether the first audio data is allowed to be played in the second device according to the first type and the device selection policy, including: the first device determines that the first audio data comes from the first application; further, the first device may In the device selection policy, query whether the audio output device corresponding to the first type and the first application includes the second device; if the second device is included, the first device determines that the first audio data is allowed to be played in the second device; if not If the second device is included, the first device determines that the first audio data is not allowed to be played in the second device.
  • the second device when the second device is an electronic device of a speaker type, it can be set in the device selection policy that the second device is allowed to play audio data of music type, and the second device is not allowed to play audio data of notification type;
  • a device can project music-type audio data to the speaker for playback, but not notification-type audio data to the speaker for playback, so as to avoid the user being disturbed by the notification sound in the first device when using the speaker to play audio.
  • the second device when the second device is an electronic device of the vehicle-mounted device type, it can be set in the device selection policy that the second device is allowed to play the audio data of the navigation type, and the second device is not allowed to play the audio data of the notification type;
  • a device can project navigation-type audio data to the in-vehicle device for playback, but does not project notification-type audio data to the in-vehicle device for playback, so as to avoid the user being disturbed by the notification sound in the first device when using the in-vehicle device to play audio.
  • the second device when the second device is an electronic device of a large-screen device type, it can be set in the device selection policy that the second device is allowed to play audio data from the first application, and the second device is not allowed to play audio from the second application. data.
  • the first device can project the audio data of the first application to the large-screen device for playback, without projecting the audio data of the second application to the large-screen device for playback, so as to avoid the user being affected by the first An app on the device produces an audio interruption.
  • the first device may specifically be a mobile phone, a tablet computer, or a laptop computer with strong computing and processing capabilities. equipment.
  • a preset application such as a DV APP
  • the application framework layer of the first device includes an audio policy module, such as AudioPolicy
  • the device selection strategy corresponding to the two devices includes: after the first device establishes a network connection with the second device, the preset application can determine the device type of the second device; further, the preset application can obtain the corresponding device according to the device type of the second device. The device selection policy of the device; and deliver the device selection policy to the audio policy module.
  • the device selection policy of various audio output devices can be pre-stored in the first device, and the first device can dynamically issue the corresponding device selection policy to AudioPolicy according to the device type of the currently connected second device, so as to select the policy according to the device selection policy.
  • the audio output device that adjusts the audio data in time.
  • the application framework layer of the first device further includes an audio processor, such as AudioFlinger; wherein the first device determines whether the first audio data is allowed to be stored in the second device according to the first type and the device selection policy Play in the middle of the audio processing, including: when the audio processor receives the first audio data, it can send a query request to the audio strategy module, and the query request includes the identification of the first type; then, in response to the query request, the audio strategy module can select according to the device The policy determines whether the first audio data of the first type is allowed to be played in the second device.
  • an audio processor such as AudioFlinger
  • the method further includes: the first device creates a first hardware abstraction module corresponding to the second device in the hardware abstraction layer HAL, such as DMSDP Audio HAL ; wherein, if the first audio data is allowed to be played in the second device, the first device sends the first audio data to the second device for playback, including: the audio processor receives the first instruction sent by the audio strategy module, the first An indication is used to indicate that the audio output device of the first audio data is the second device; in response to the first indication, the audio processor can call the first hardware abstraction module to send the first audio data to the second device.
  • HAL hardware abstraction layer
  • the HAL also includes a second hardware abstraction module corresponding to the third device, such as Primary HAL, A2dp HAL, etc.; the above method further includes: the audio processor receives the second hardware abstraction module sent by the audio strategy module. Indication, the second indication is used to indicate that the audio output device of the first audio data is the third device, that is, the first audio data is not allowed to be played on the second device; then, in response to the second indication, the audio processor can call the second The hardware abstraction module sends the second audio data to the third device.
  • the audio processor receives the second hardware abstraction module sent by the audio strategy module. Indication, the second indication is used to indicate that the audio output device of the first audio data is the third device, that is, the first audio data is not allowed to be played on the second device; then, in response to the second indication, the audio processor can call the second The hardware abstraction module sends the second audio data to the third device.
  • the method further includes: the first device displays a setting interface of the audio output device; the first device receives the user's setting in the setting interface and The device selection policy corresponding to the second device; in response to the user's setting, the first device updates the device selection policy.
  • the first device displays a setting interface of the audio output device; the first device receives the user's setting in the setting interface and The device selection policy corresponding to the second device; in response to the user's setting, the first device updates the device selection policy.
  • the above method further includes: when the second device plays the first audio data, the first device acquires the second audio data to be played (the type of the second audio data is the second type), that is The audio data to be played includes both the first audio data and the second audio data; furthermore, the first device can determine whether the second audio data is allowed to be played in the second device according to the above-mentioned second type and the device selection strategy; If the data is allowed to be played in the second device, the first device can mix the first audio data and the second audio data and send them to the second device for playback; or, the first device can mix the unmixed first audio The data and the second audio data are sent to the second device for playback, which is not limited in this embodiment of the present application.
  • the above method further includes: after the first device stops sending the first audio data to the second device, the first device obtains the second audio data to be played (the type of the second audio data is the first audio data) two types), that is, the audio data to be played is changed from the first audio data to the second audio data; then, similar to the above-mentioned first audio data, the first device can determine the second audio according to the above-mentioned second type and the device selection strategy. Whether the data is allowed to be played in the second device; if the second audio data is allowed to be played in the second device, the first device sends the second audio data to the second device for playback. In this way, when playing different types of audio data, the first device can dynamically determine the audio output device of each channel of audio data according to the device selection strategy, so that each channel of audio data can be played on the most suitable audio output device.
  • the first device can also play according to the third device (ie The device selection strategy of the new slave device) selects an appropriate audio output device for playback of the audio data to be played at this time.
  • the present application provides an audio control method, comprising: after the first device establishes a network connection with the second device, the first device can use the second device as a slave device to obtain a mixing strategy corresponding to the second device
  • the first device can use the second device as a slave device to obtain a mixing strategy corresponding to the second device
  • the first device can determine whether it needs to mix the first audio data and the second audio data according to the above-mentioned first type, the second type and the mixing strategy; If the second audio data is mixed, the first device can send the unmixed first audio data and the second audio data to the second device for playback; correspondingly, if the first audio data and the second audio data need to be mixed audio, then the first device can mix the first audio data and the second audio data into third audio data, then, the audio characteristics of the first audio data and/or the second audio data in the mixed third audio data (eg loudness, frequency, etc.) will change; further, the first device can send the mixed third audio data to the second device for playback.
  • the first device can send the mixed third audio data to the second device for playback.
  • the first device ie the master device
  • the second device ie the slave device
  • it may not mix some of the audio data according to the corresponding mixing strategy sent to the second device.
  • the first audio data and the second audio data obtained by the second device from the first device have not undergone mixing processing, so the first audio data and the second audio data can more realistically reflect their audio characteristics.
  • the first audio data and the second audio data to be played obtained by the second device do not have distortion caused by the sound mixing processing of the first device.
  • the second device is playing the above-mentioned first audio data and second audio data.
  • the distortion phenomenon generated during the audio switching is also reduced accordingly, thereby reducing the distortion of multi-channel audio data when playing across devices, and improving the audio output quality of audio switching scenarios.
  • the above-mentioned sound mixing strategy may specifically include: the type of audio data that needs to be mixed and/or the type of audio data that does not need to be mixed;
  • the determining by the first device whether to mix the first audio data and the second audio data according to the first type, the second type and the mixing strategy includes: the first device querying the audio data of the first type in the mixing strategy Whether audio mixing is required, and whether audio data of the second type requires audio mixing; if at least one of the audio data of the first type and the audio data of the second type does not require audio mixing, the first device may determine that no audio mixing is required for the first type of audio data.
  • the audio data and the second audio data are mixed; if the audio data of the first type and the audio data of the second type both need to be mixed, the first device may determine that the first audio data and the second audio data need to be mixed.
  • the above-mentioned sound mixing strategy may specifically include: the type of audio data that needs to be mixed and the application from which the audio data that needs to be mixed comes, and/or the type of audio data that does not need to be mixed, and The application from which the audio data does not need to be mixed;
  • the determining by the first device whether to mix the first audio data and the second audio data according to the first type, the second type and the mixing strategy includes: the first device determining that the first audio data comes from the first application; The second audio data comes from the second application; furthermore, the first device can query in the mixing strategy whether the audio data of the first type from the first application needs to be mixed, and whether the audio data of the second type from the second application is Mixing is required; if at least one of the audio data of the first type from the first application and the audio data of the second type from the second application does not need to be mixed, the first device may determine that the first audio data does not need to be mixed mixing with the second audio data; if both the audio data of the first type from the first application and the audio data of the second type from the second application need to be mixed, the first device may determine that the first audio data and the audio data of the second type need to be mixed.
  • the second audio data is mixed.
  • the above-mentioned sound mixing strategy may specifically include: correspondence between different types of audio data and audio output devices that do not allow sound mixing; Audio output devices for audio include cell phones, speakers, and TVs.
  • the first device determines whether to mix the first audio data and the second audio data according to the first type, the second type and the mixing strategy, including: the first device querying the audio mixing strategy with the first type Whether the first audio output device corresponding to the data includes the second device; and the first device inquires in the mixing strategy whether the second audio output device corresponding to the second type of audio data includes the second device; if the first audio output The device includes the second device and/or the second audio output device includes the second device, that is, at least one of the first audio data and the second audio data does not need to be mixed, the first device may determine that the first audio data does not need to be mixed Mixing with the second audio data; if the first audio output device does not include the second device and the second audio output device does not include the second device, that is, both the first audio data and the second audio data need to be mixed, then the first device It may be determined that the first audio data and the second audio data need to be mixed.
  • the first device can query whether the second device allows to mix each channel of audio data in the above-mentioned mixing strategy according to the type of the current multi-channel audio data and the type of the current slave device (ie, the second device). If there is a channel of audio data that is not allowed to be mixed, the first device can independently transmit the channel of audio data to the second device, so as to reduce the distortion of the audio data caused by the sound mixing.
  • the corresponding relationship between different types of audio data and audio output devices that allow audio mixing can also be set in the audio mixing policy; for example, the audio output devices that allow audio mixing corresponding to the audio data of the notification type include: Headphones and TV.
  • the first device may query in the audio mixing strategy whether the first audio output device corresponding to the first type of audio data includes the second device; and, the first device may query in the audio mixing strategy Whether the second audio output device corresponding to the second type of audio data includes the second device; if the first audio output device includes the second device and the second audio output device includes the second device, indicate the first audio data and the second audio If all data needs to be mixed, the first device may determine that the first audio data and the second audio data need to be mixed; if the first audio output device does not include the second device and/or the second audio output device does not include the second device , indicating that at least one of the first audio data and the second audio data does not need to be mixed, the first device may determine that the first audio data and the second audio data do not need to be mixed.
  • the above-mentioned sound mixing strategy may specifically include: the correspondence between different types of audio data, different applications and audio output devices that do not allow sound mixing; Audio output devices corresponding to audio data that are not allowed to mix include mobile phones, speakers, and TVs.
  • the determining by the first device whether to mix the first audio data and the second audio data according to the first type, the second type and the mixing strategy includes: the first device determining that the first audio data comes from the first application; The second audio data comes from the second application; and the first device inquires in the mixing strategy whether the first audio output device corresponding to the first application and the first type includes the second device; In the policy, query whether the second audio output device corresponding to the second application and the second type includes the second device; if the first audio output device includes the second device and/or the second audio output device includes the second device, that is, the first audio output device includes the second device.
  • the first device may determine that the first audio data and the second audio data do not need to be mixed; if the first audio output device does not include the second device and the first audio output device The second audio output device does not include the second device, that is, both the first audio data and the second audio data need to be mixed, and the first device may determine that the first audio data and the second audio data need to be mixed.
  • the corresponding relationship between different types of audio data, different applications and audio output devices that allow audio mixing can also be set in the audio mixing policy; for example, the audio mixing allowed corresponding to the audio data of the notification type from the video APP Audio output devices include headphones and a TV.
  • the first device can query in the audio mixing strategy whether the first audio output device corresponding to the first type and the first application includes the second device; and, the first device is in the audio mixing strategy Query whether the second audio output device corresponding to the second type and the second application includes the second device; if the first audio output device includes the second device and the second audio output device includes the second device, it indicates that the first audio data and the first audio output device include the second device.
  • the first device may determine that the first audio data and the second audio data need to be mixed; if the first audio output device does not include the second device and/or the second audio output device does not include the first audio data
  • the second device indicates that at least one of the first audio data and the second audio data does not need to be mixed, and the first device may determine that the first audio data and the second audio data do not need to be mixed.
  • the second device when the second device is a speaker-type electronic device, it can be set in the mixing strategy that no audio mixing is required when sending music-type audio data to the second device; in this way, the first device can mix the music-type audio data.
  • the data is not mixed with other audio data and is independently projected to the second device for playback, so that the second device can reduce audio distortion when playing audio data of a music type.
  • the second device when the second device is an in-vehicle device type electronic device, it can be set in the audio mixing strategy that no audio mixing is required when sending the navigation type audio data to the second device; in this way, the first device can mix the navigation type audio data.
  • the audio data is not mixed with other audio data and is independently projected to the second device for playback, so that the second device can reduce audio distortion when playing the navigation type audio data.
  • the second device when the second device is an electronic device of a large-screen device type, it may be set in the audio mixing policy that audio mixing is required when sending audio data of the notification type to the second device. That is to say, when the multi-channel audio data containing the notification type needs to be sent to the second device, since the user does not pay much attention to the notification sound on the large-screen device, the first device can combine the audio data of the notification type with the notification sound. The other audio data is mixed and sent to the second device for playback.
  • the master device can choose not to mix some audio data in the multi-channel audio data according to the current mixing strategy of the slave device, and transmit it to the slave device independently. Play, so as to avoid the distortion of a certain type of audio data caused by the mixing process, and improve the audio output quality of the audio switching scene.
  • sending the first audio data and the second audio data to the second device by the first device includes: the first device packages the first audio data to obtain at least one first data packet; A device packages the second audio data to obtain at least one second data package; the first device sends the first data package and the second data package to the second device.
  • the first data packet includes a first identifier, and the first identifier is used to indicate the first audio data; the second data packet includes a second identifier, and the second identifier is used to indicate the second audio data.
  • the second device may restore the corresponding unmixed first audio data and second audio data according to the first identifier in the first data packet and the second identifier in the second data packet.
  • the first data packet includes first feature information, and the first feature information is used to indicate the audio feature of the first audio data; the second data packet includes second feature information, and the second feature information is used to indicate the first audio data.
  • Audio features of audio data are used to indicate the audio feature of the first audio data.
  • the first feature information may include at least an application to which the first audio data belongs, a type of the first audio data, a volume level of the first audio data, a playback format of the first audio data, and track information of the first audio data.
  • the second feature information may include at least the application to which the second audio data belongs, the type of the second audio data, the volume level of the second audio data, the playback format of the second audio data, and the track information of the second audio data.
  • the second feature information may include at least the application to which the second audio data belongs, the type of the second audio data, the volume level of the second audio data, the playback format of the second audio data, and the track information of the second audio data.
  • These feature information can reflect the actual audio features of the audio data, so that the second device that receives the data packet can truly restore the audio data and related features of the audio data by parsing the feature information in the data packet, so that according to the audio data
  • the feature information plays the corresponding audio data to reduce the distortion of the audio data in the audio switching process.
  • the first device may specifically be a mobile phone, a tablet computer, or a laptop computer with strong computing and processing capabilities. equipment.
  • the method further includes: acquiring the device selection policy corresponding to the second device by the first device; acquiring the first device to be played on the first device
  • the method further includes: the first device determines the audio output device of the first audio data and the second audio data as the second device according to the first type, the second type and the device selection policy. That is, when there are multiple channels of audio data to be played in the first device, the first device may first determine the audio output device of each channel of audio data in the multiple channels of audio data. If the audio output devices of the multiple channels of audio data are the same, the first device may further determine whether to mix the multiple channels of audio data according to the mixing strategy.
  • the application layer of the first device is installed with a preset application, such as a DV APP, and the application framework layer of the first device includes an audio policy module, such as AudioPolicy;
  • the sound mixing strategy corresponding to the second device includes: a preset application determines the device type of the second device; the preset application obtains the corresponding sound mixing strategy according to the device type of the second device; the preset application delivers the sound mixing strategy to the audio strategy module. That is, the first device can pre-store the mixing policies of various audio output devices, and the first device can dynamically deliver the corresponding mixing policies to the AudioPolicy according to the device type of the currently connected second device, so as to follow the mixing policy. Timely adjust whether the audio data is mixed or not.
  • the application framework layer of the first device further includes an audio processor, such as AudioFlinger; wherein, the first device acquires the first audio data and the second audio data to be played, including: when the audio After the processor obtains the first audio data and the second audio data from the application layer, the audio processor can send a query request to the audio strategy module, and the query request includes the first type of identification and the second type of identification; then , in response to the query request, the audio strategy module may determine whether it is necessary to mix the first audio data of the first type and the second audio data of the second type according to the mixing strategy.
  • an audio processor such as AudioFlinger
  • the method further includes: the first device creates a hardware abstraction module corresponding to the second device at the hardware abstraction layer HAL, such as DMSDP Audio HAL; wherein , if it is not necessary to mix the first audio data and the second audio data, the method further includes: the audio processor can receive the first instruction sent by the audio strategy module, and the first instruction is used to indicate that the first audio data and the second audio data are mixed. The audio data is not to be mixed; then, in response to the first instruction, the audio processor may encapsulate the first audio data into at least one first data packet, and store the first data packet in a buffer of the audio processor.
  • HAL hardware abstraction layer
  • the audio processor may encapsulate the second audio data into at least one second data packet, and store the second data packet in the buffer of the audio processor; further, the audio processor may The first data packet and the second data packet in the processor's cache are sent to the hardware abstraction module.
  • the first device sends the first audio data and the second audio data to the second device, including: the hardware abstraction module can send the first data packet and the second data packet in the buffer of the audio processor to the second device , so that the second device restores the first audio data and the second audio data by parsing the first data packet and the second data packet, at this time, the first device does not need to parse the first data packet and the second data packet; Or; The hardware abstraction module can first parse the first data packet and the second data packet, restore the corresponding first audio data and the second audio data, and then send the first audio data and the second audio data to the second device. At this time, The second device does not need to parse the audio data sent by the first device.
  • the method further includes: the first device displays a setting interface of the audio output device; the first device receives the user's setting in the setting interface with The sound mixing strategy corresponding to the second device; in response to the user's setting, the first device updates the sound mixing strategy.
  • the first device displays a setting interface of the audio output device; the first device receives the user's setting in the setting interface with The sound mixing strategy corresponding to the second device; in response to the user's setting, the first device updates the sound mixing strategy.
  • the above method further includes: when the first device acquires the first audio data and the second audio data, the first device may also acquire the third audio data to be played (the third audio data
  • the type is the third type), that is, the audio data to be played includes three channels of audio data at the same time; further, the first device can determine the first audio data according to the first type, the second type, the third type and the mixing strategy. No mixing is required, the second audio data and the third audio data need to be mixed; then, the first device can send the first audio data to the second device without mixing, and the first device sends the second audio data Mixed with the third audio data and sent to the second device.
  • the first device may also determine that the first audio data, the second audio data, and the third audio data do not need to be mixed according to the above-mentioned mixing strategy, or the first audio data, the second audio data, and the third audio data do not need to be mixed. All audio mixing is required, and this embodiment of the present application does not impose any limitation on this.
  • the first device can also follow the instructions of the third device.
  • the sound mixing strategy of the new slave device determines whether the multi-channel audio data to be played at this time needs to be mixed.
  • the present application provides an audio control method, comprising: establishing a network connection between a second device and a first device; acquiring unmixed first audio data and second audio data from the first device, One audio data type is the first type, and the second audio data is the second type; the second device plays the first audio data and the second audio data.
  • acquiring the unmixed first audio data and the second audio data from the first device by the second device includes: acquiring, by the second device, the first audio data corresponding to the first audio data from the first device. A data packet and a second data packet corresponding to the second audio data; the second device restores the first audio data and the second audio data by parsing the first data packet and the second data packet.
  • the first data packet includes a first identifier, and the first identifier is used to indicate the first audio data;
  • the second data packet includes a second identifier, and the second identifier is used to indicate the second audio data.
  • the second device restores the first audio data and the second audio data by analyzing the first data packet and the second data packet, including: the second device will carry the first data packet and the second data packet by analyzing the first data packet and the second data packet The audio data in the data packet with a mark is restored to the first audio data, and the audio data in the data packet carrying the second mark is restored to the second audio data.
  • the first data packet includes first feature information, and the first feature information is used to indicate an audio feature of the first audio data;
  • the second data packet includes second feature information, and the second feature information Used to indicate the audio features of the second audio data; wherein, the second device plays the first audio data and the second audio data, including: the second device plays the first audio data according to the first feature information, and at the same time, the second device plays the first audio data according to the first The second feature information plays the second audio data.
  • the present application provides a method for playing multi-audio tasks, comprising: an electronic device displaying a first window and a second window in a display interface, wherein the first window runs a first application, and the second window runs There is a second application, at this time, the electronic device enters a split-screen mode; further, the electronic device can receive a first operation input by the user; in response to the first operation, the electronic device can establish an association relationship between the first window and the first audio output device , that is, the user can manually set the audio output device associated with the first window to be the first audio output device; similarly, if the electronic device receives the second operation input by the user, the electronic device can establish a relationship between the second window and the second audio output device Association relationship, that is, the user can manually set the audio output device associated with the second window as the second audio output device; in this way, when the electronic device acquires the first audio data from the first application, the electronic device can The association relationship of the first audio output device sends the first audio data to the first
  • the audio data output by the audio task in each window can be played using the audio output device associated with the window.
  • the electronic device can send the audio data output by the related audio tasks in each window to the corresponding audio output device for playback.
  • the multi-channel audio data concurrently generated by the electronic device will not interfere with each other.
  • the multi-channel audio data can be played to different users through different audio output devices, and each user can use the audio output device associated with the relevant window to listen to the corresponding Audio data will not be affected by audio data from other windows, thereby improving the user's audio experience.
  • the method further includes: the electronic device may display a first dialog in the first window, where the first dialog includes a At least one first candidate device for the audio playback function, for example, the electronic device can display the audio output device located in the same Wi-Fi network as the electronic device in the first dialog box; wherein, the above-mentioned first operation is that the user performs the at least one first operation.
  • An operation of selecting a first audio output device from a candidate device similarly, the electronic device may display a second dialog box in the second window, and the second dialog box includes at least one second candidate device with an audio playback function, for example, an electronic device
  • the device may display an audio output device with an audio playback function connected to the electronic device in the second dialog box; wherein the above-mentioned second operation is an operation by the user to select a second audio output device from at least one second candidate device.
  • the electronic device establishes an association relationship between the first window and the first audio output device, which specifically includes: the electronic device can record the first audio configuration information of the first window, and the first audio configuration information includes the first audio configuration information.
  • the association relationship between a window and the first audio output device similarly, the electronic device establishes the association relationship between the second window and the second audio output device, specifically including: the electronic device can record the second audio configuration information of the second window, the second audio
  • the configuration information includes an association relationship between the second window and the second audio output device.
  • the above method further includes: when the first application runs in the first window, the electronic device may record the first correspondence between the first window and the first application, that is, the The application information is used to indicate the application running in the first window; similarly, when the second application is running in the second window, the electronic device may record the second correspondence between the second window and the second application, that is, the first The application information of the second window is used to indicate the application running in the second window.
  • the electronic device records the first correspondence between the first window and the first application, which specifically includes: the first application can apply for acquiring the first audio focus of the first window; when the first application acquires the first audio focus , the electronic device can record the first correspondence between the first window and the first application; similarly, the electronic device records the second correspondence between the second window and the second application, which specifically includes: the second application applies for obtaining the first The second audio focus of the two windows; when the second application acquires the second audio focus, the electronic device may record the second correspondence between the second window and the second application.
  • the electronic device can set an audio focus (Audio Focus) for each window in split-screen mode.
  • an application in each window needs to play an audio task, it needs to obtain the audio focus of the window first.
  • the electronic device can maintain the audio focus application corresponding to each window, so as to determine which window the audio data comes from when acquiring the audio data to be played. Audio focus application in .
  • the method before the electronic device sends the first audio data to the first audio output device for playback, the method further includes: the electronic device determines that the first audio data comes from the first application; A corresponding relationship can determine the first window corresponding to the first audio data; furthermore, the electronic device can determine, according to the first audio configuration information, that the audio output device of the first audio data is the first audio output device associated with the first window .
  • the method further includes: the electronic device determines that the second audio data comes from the second application; further, the electronic device determines the the second window corresponding to the second audio data; furthermore, the electronic device may determine, according to the second audio configuration information, that the audio output device of the second audio data is the second audio output device associated with the second window.
  • the first audio configuration information may further include: the type of audio data allowed to be played in the first audio output device, and/or the type of audio data allowed to be played in the first audio output device volume;
  • the second audio configuration information may further include: the type of audio data allowed to be played in the second audio output device, and/or the volume of the audio data allowed to be played in the second audio output device.
  • the electronic device can output a specific type of audio data to a corresponding audio output device for playback according to the first audio configuration information and the second audio configuration information, and control the volume of the corresponding audio data.
  • the electronic device displays the first window and the second window in the display interface , further comprising: the electronic device displays a first volume adjustment bar in the first window; if it is detected that the user inputs a first volume adjustment operation on the first volume adjustment bar, the electronic device can modify the first type of audio configuration information in the first audio
  • the volume of the audio data is controlled, thereby controlling the volume of the audio output in the first audio output device, and the first type is the type of the audio data being played in the first window or the type of the preset audio data.
  • the electronic device displays the first window and the second window in the display interface , further comprising: the electronic device displays a second volume adjustment bar in the second window; if it is detected that the user inputs a second volume adjustment operation on the second volume adjustment bar, the electronic device can modify the second type of audio configuration information in the second audio
  • the volume size of the audio data thereby controlling the volume of the audio output in the second audio output device, and the second type is the type of the audio data being played in the second window or the type of the preset audio data.
  • the method further includes: in response to a third operation input by the user, the electronic device updates the first audio configuration information, and after the update, the electronic device updates the first audio configuration information.
  • the first audio configuration information includes the association relationship between the first window and the third audio output device.
  • the method further includes: in response to a fourth operation input by the user, the electronic device updates the second audio configuration information, and after the update, the electronic device updates the second audio configuration information.
  • the second audio configuration information includes the association relationship between the second window and the fourth audio output device.
  • the user can manually update the audio output device associated with each window, so as to set the audio output device of each window with the window as the granularity according to his own needs, so that the audio data in each window can be distributed to the user according to the user's settings. Play on the corresponding audio output device.
  • the application framework layer of the electronic device includes an audio policy module (for example, AudioPolicy) and an audio processor (for example, AudioFlinger).
  • the method further includes: when the audio processor receives the first audio data, the audio The processor sends a first query request to the audio strategy module; in response to the first query request, the audio strategy module can determine that the audio output device of the first audio data is the first audio output device; similarly, when the audio processor receives the second When audio data is present, the audio processor sends a second query request to the audio strategy module; in response to the second query request, the audio strategy module may determine that the audio output device of the second audio data is the second audio output device.
  • AudioPolicy for example, AudioPolicy
  • AudioFlinger for example, AudioFlinger
  • the application framework layer of the electronic device includes a window manager, and the window manager can be used to map the first correspondence between the first window and the first application, and the second window and the second application.
  • the correspondence, the first audio configuration information of the first window, and the second audio configuration information of the second window are sent to the audio strategy module.
  • the audio strategy module can determine the audio output devices of the first audio data and the second audio data according to these parameters.
  • the window manager can send the updated application information and audio configuration information to the audio strategy module, so that the audio strategy module follows the latest update.
  • the application information and audio configuration information determine the audio output device corresponding to each window.
  • the HAL of the electronic device includes a first audio abstraction module corresponding to the first audio output device and a second audio abstraction module corresponding to the second audio output device;
  • Sending the audio data to the first audio output device includes: the audio processor sends the first audio data to the first audio output device through the first audio abstraction module; wherein the electronic device sends the second audio data to the second audio output device , comprising: the audio processor sends the second audio data to the second audio output device through the second audio abstraction module.
  • the first audio output device may be a speaker
  • the first audio abstraction module may be a DMSDP Audio HAL
  • AudioFlinger may send the first audio data to the speaker for playback through the DMSDP Audio HAL
  • the second audio output device may be a Bluetooth headset
  • the second audio abstraction module may be an A2dp HAL
  • AudioFlinger may send the second audio data to the Bluetooth headset for playback through the A2dp HAL.
  • the HAL of the electronic device includes a display abstraction module (for example, Display HAL); the above method further includes: the display abstraction module obtains first display data corresponding to the first window and first display data corresponding to the second window. 2. Display data; further, the display abstraction module can synthesize the first display data and the second display data into third display data corresponding to the display interface.
  • a display abstraction module for example, Display HAL
  • the above method further includes: the display abstraction module obtains first display data corresponding to the first window and first display data corresponding to the second window. 2. Display data; further, the display abstraction module can synthesize the first display data and the second display data into third display data corresponding to the display interface.
  • the method further includes: the display abstraction module combines the third display data with the third display data.
  • the display data is sent to the display screen of the electronic device for display.
  • the method further includes: The display abstraction module sends the third display data to the first display device for display.
  • the main device can control the distribution process of display data and audio data respectively, and the main device distributes the audio data in different windows to the corresponding audio output device for playback.
  • Sending the first audio data to the first audio output device for playback specifically includes: the electronic device sends the first audio data and the association relationship between the first window and the first audio output device to the first display device, so that the first display device can According to the relationship between the first window and the first audio output device, the first audio data is sent to the first audio output device for playback; similarly, the electronic device sends the second audio data to the second audio output device according to the relationship between the second window and the second audio output device.
  • Sending the data to the second audio output device to play specifically includes: the electronic device sends the second audio data and the association relationship between the second window and the second audio output device to the first display device, so that the first display device can follow the second audio output device.
  • the associated relationship between the window and the second audio output device sends the second audio data to the second audio output device for playback.
  • the master device can send both the display data and audio data generated in each window to the slave device.
  • the master device can send the application information and audio configuration information of each window to the slave device, so that the slave device can distribute the audio data of different windows in the master device to the corresponding audio output device according to the application information and audio configuration information. Play in the middle of the screen to achieve the isolation effect that the audio data between multiple windows does not interfere with each other.
  • the HAL of the electronic device may include a display abstraction module (eg Display HAL); if the display output device corresponding to the first window is the first display device, the display output device corresponding to the second window is the second display device; then the above method further includes: the display abstraction module can obtain the first display data corresponding to the first window, and send the first display data to the first display device for display; and the display abstraction module can obtain and The second display data corresponding to the second window is sent to the second display device for display. That is to say, when in the split-screen mode, the electronic device can send the display data in different windows to different display output devices (including the mobile phone itself) for display, so as to realize the screen projection function with the window as the granularity. At this time, the display data in each display output device will not interfere with each other, and the audio data in each display output device will not interfere with each other, thereby improving the user's audio experience.
  • a display abstraction module eg Display HAL
  • the present application provides a screen recording method, comprising: in response to a user's operation of turning on a screen recording function in the first device, the first device may display a screen recording device list, where the screen recording device list includes the same
  • the device is connected to one or more electronic devices of the same communication network (for example, the same Wi-Fi network); if it is detected that the user selects the second device in the above screen recording device list, on the one hand, the first device can send a message to the second device.
  • the first device can perform a screen recording operation to obtain the first screen data of the first device; and the first device can obtain The second screen data obtained by the second device performing the screen recording operation; in this way, the first device generates the current screen recording file according to the first screen data and the second screen data.
  • the user may select the first device to simultaneously record screen data in multiple devices such as the first device and the second device.
  • the first device can generate this screen recording file according to the screen data recorded by the two devices.
  • the screen recording file can restore both the audio and picture of the first device and the audio and picture of the second device, so as to be more comprehensive. Record and restore the business scenarios implemented on the first device and the second device to improve the user experience in the distributed system.
  • the above-mentioned first screen data may include first display data and first audio data;
  • the first display data includes: display data played by the first device (for example, display data played on a display screen in the first device) data) and/or display data collected by the first device (such as display data collected by a camera of the first device);
  • the first audio data includes: audio data played by the first device (such as audio played by the speaker or earpiece of the first device) data) and/or audio data collected by the first device (eg, audio data collected by a microphone or earphone of the first device).
  • the first device when the first device performs screen recording, there may be various sources of the recorded display data, and there may also be various sources of the recorded audio data, which are not limited in this embodiment of the present application.
  • the method further includes: the first device acquiring the first screen recording parameters used by the first device to perform the screen recording operation , the first screen recording parameters include display recording parameters and audio recording parameters; wherein, the display recording parameters may include resolution, DPI and other parameters that need to be used when recording display data, such as screen recording.
  • the display recording parameter may also indicate the specific source of the display data recorded this time, for example, recording display data collected from a camera, or recording display data played on the display screen.
  • the audio recording parameters may include parameters that need to be used when recording audio data, such as the sampling rate of the audio data by the first device, sound effect settings, and the like.
  • the audio recording parameter may also indicate the specific source of the audio data recorded this time, for example, recording audio data played from a speaker, or recording audio data collected from a microphone.
  • the first device performs a screen recording operation to obtain the first screen data of the first device, which specifically includes: the first device records and obtains the first display data according to the above display recording parameters; the first device records and obtains the first display data according to the above audio recording parameters. an audio data.
  • the above-mentioned first screen recording parameters may also only include display recording parameters or audio recording parameters.
  • the first device can record and obtain the first display data according to the above-mentioned display recording parameters, and at this time, the first display data is the first screen data recorded by the first device.
  • the first screen recording parameters only include display audio parameters
  • the first device can record and obtain the first audio data according to the above-mentioned audio recording parameters, and at this time, the first audio data is the first screen data recorded by the first device.
  • the method further includes: the first device obtains the second screen recording parameters used by the second device to perform the screen recording operation, which is the same as the above-mentioned first recording parameter.
  • the second screen recording parameters include display recording parameters (such as resolution, DPI, etc.) and audio recording parameters (such as sampling rate, etc.); wherein, the first device sends a screen recording instruction to the second device, including: the first device A device may carry the above-mentioned second screen recording parameter in the screen recording instruction and send it to the second device. In this way, the second device can perform a screen recording operation according to the second screen recording parameters carried in the screen recording instruction to obtain the second screen data.
  • the first device obtains the above-mentioned first screen recording parameters and the second screen recording parameters, which specifically includes: the first device may obtain the first screen recording capability parameters of the first device, the first screen recording capability The parameter is used to reflect the screen recording capability of the first device; and the first device can obtain the second screen recording capability parameter of the second device, and the second screen recording capability parameter is used to reflect the screen recording capability of the second device; the first device According to the first screen recording capability parameter and the second screen recording capability parameter, the first screen recording parameter corresponding to the first device and the second screen recording parameter corresponding to the second device may be determined.
  • the first device when multiple devices synchronize screen recording, the first device, as the master device, can determine the screen recording parameters used when the mobile phone and the slave device synchronize screen recording this time in combination with the screen recording capabilities of the first device and the second device.
  • the parameters for processing display data and audio data in the first screen recording parameter and the second screen recording parameter are generally the same, for example, the resolution, DPI and sampling rate in the first screen recording parameter and the second screen recording parameter and other parameters are the same.
  • the first screen data recorded by the first device using the first screen recording parameters and the second screen data recorded by the second device using the second screen recording parameters can be made into a unified screen recording file.
  • the source of the screen data set in the first screen recording parameter and the second screen recording parameter may be different.
  • the first screen recording parameter may set the first device to record display data from the display screen
  • the second screen recording parameter may set the second device to record and collect the display data from the camera.
  • the first screen recording parameter and the second screen recording parameter when the resolution of the first device in the first screen recording capability parameter is greater than the resolution of the second device in the second screen recording capability parameter, the first screen recording parameter and the second screen recording parameter
  • the resolution in is the resolution of the second device, that is, the smaller resolution is selected as the resolution in the first screen recording parameter and the second screen recording parameter to ensure that the first device and the second device are capable of corresponding Record the screen at the resolution in the screen recording parameters.
  • the DPI in the first screen recording parameter and the second screen recording parameter is the DPI of the second device , that is, a smaller DPI is selected as the DPI in the first screen recording parameter and the second screen recording parameter, so as to ensure that both the first device and the second device are capable of recording the screen according to the DPI in the corresponding screen recording parameter.
  • the sampling rate in the first screen recording parameter and the second screen recording parameter is the second The sampling rate of the device, that is, select the smaller sampling rate as the sampling rate in the first screen recording parameter and the second screen recording parameter, to ensure that the first device and the second device are capable of following the sampling rate in the corresponding screen recording parameters Do a screen recording.
  • the first device may also determine the first screen recording parameters corresponding to the first device and the second screen recording parameters corresponding to the second device in combination with factors such as the current network bandwidth, business scenarios, or user habits. make any restrictions.
  • the second screen data recorded by the second device may include second display data and second audio data;
  • the second display data includes: playback by the second device The display data (such as the display data played by the display screen in the second device) and/or the display data collected by the second device (such as the display data collected by the camera of the second device);
  • the second audio data includes: Audio data (eg, audio data played by a speaker or earpiece of the second device) and/or audio data collected by the second device (eg, audio data collected by a microphone or earphone of the second device).
  • the first device generates a screen recording file according to the first screen data and the second screen data, including: the first device synthesizes the first display data and the second display data into third display data; and then , the first device makes the third display data, the first audio data and the second audio data as the current screen recording file. That is, the first device can make the first screen data and the second screen data into a screen recording file, and the pictures in the screen recording file include the first display data and the second display data.
  • the first device may make the first screen data and the second screen data as two screen recording files, for example, the first file and the second file; wherein the first device generates the first screen data and the second screen data according to the first screen data and the second screen data.
  • the screen recording file includes: the first device makes the first display data and the first audio data as a first file; the first device makes the second display data and the second audio data as a second file.
  • the method further includes: the first device detects N electronic devices connected to the same communication network as the first device, where N is an integer greater than 0; and , the first device can determine the electronic device with the screen recording function among the N electronic devices; in this way, the first device can display the determined electronic device with the screen recording function in the screen recording device list for the user to select.
  • the application layer of the first device includes a screen recording application
  • the application framework layer of the first device includes a screen recorder
  • the HAL of the first device includes a preset hardware abstraction module
  • a device performs a screen recording operation to obtain the first screen data of the first device, which specifically includes: the screen recording application invokes the screen recorder to perform the screen recording operation, and obtains the first screen data of the first device; wherein, the first device obtains the second screen data.
  • the second screen data obtained by the device performing the screen recording operation specifically includes: the screen recorder obtains the second screen data obtained by the second device performing the screen recording operation through the hardware abstraction module.
  • the screen recorder in the first device can not only record the first screen data of the first device itself, but also instruct the slave device (ie the second device) of the first device to record the second screen data of the second device. Furthermore, the screen recorder can generate a corresponding screen recording file according to the first screen data and the second screen data, so as to realize the function of synchronous screen recording by the first device and the second device.
  • the present application provides a screen recording method, including: in response to a user's operation of turning on a screen recording function in the first device, the first device may display a screen recording device list, where the screen recording device list includes the same A device accesses one or more electronic devices of the same communication network (eg, the same Wi-Fi network). If it is detected that the user selects the second device in the above screen recording device list, it means that the user needs to record the screen of the first device and the second device synchronously. At this time, the screen recording application in the first device can be obtained from the second device. The screen recording capability parameter of the second device, and the screen recording application may acquire the screen recording capability parameter of the first device.
  • the screen recording device list includes the same A device accesses one or more electronic devices of the same communication network (eg, the same Wi-Fi network).
  • the screen recording application determines the first screen recording parameters used for screen recording of the first device this time and the second screen recording parameters used for screen recording of the second device according to the screen recording capability parameters of the first device and the second device; screen recording;
  • the application can carry the second screen recording parameter in the screen recording instruction and send it to the second device, triggering the second device to perform the screen recording operation according to the second screen recording parameter;
  • the screen recording application can call the screen recorder of the application framework layer Perform the screen recording operation according to the determined first screen recording parameters; for example, the screen recorder can acquire the display data (ie, the first display data) played in the display screen in real time from the display module, and the screen recorder can call AudioRecord from AudioFlinger In this way, the screen recorder can obtain the first screen data recorded by the first device in real time (the first screen data includes the first display data and the first screen data).
  • the first display data may also be the display data collected by the camera obtained by the screen recorder from the Camera module
  • the first audio data may also be the audio data collected by the microphone of the first device obtained by the screen recorder from AudioFlinger. This does not impose any restrictions.
  • the screen recorder can also receive second screen data recorded by the second device.
  • the screen recorder can report the first screen data and the second screen data to the screen recording application, and the screen recording application can create a corresponding screen recording file according to the first screen data and the second screen data.
  • the first screen data restores the audio and picture of the first device
  • the second screen data can also restore the audio and picture of the second device, so as to more comprehensively record and restore the business scenarios implemented on the first device and the second device.
  • the present application provides a method for updating audio delay, including: after the first device establishes a network connection with the second device, if the second device is set as the audio output device of the first device, the first device is set as the audio output device of the first device.
  • the device can dynamically obtain the first delay, the second delay and the third delay, where the first delay refers to the delay generated when the audio data is processed in the first device, and the second delay refers to the audio data
  • the first device when the first device needs to project the audio data to the second device for playback, the first device can dynamically calculate the current audio delay according to the above-mentioned first delay, second delay and third delay. Subsequently, the audio delay obtained by the relevant application or player each time is also the latest audio delay calculated by the first device, and the audio delay can more accurately reflect the delay size of the current audio data. Then, when the relevant application or player performs synchronization processing such as audio and video synchronization according to the above-mentioned audio delay, a more accurate synchronization effect can be achieved, and the user experience can be improved.
  • the method further includes: the first device acquires an audio capability parameter of the second device, where the audio capability parameter is used to instruct the second device to play audio hardware capability and the software capability of the second device to play audio; at this time, obtaining the third delay by the first device includes: the first device obtaining the third delay from the above audio capability parameter. That is to say, the second device can calculate its own audio delay (ie, the third delay), and carry the third delay in the audio capability parameter and report it to the first device, so that the first device can change from the second device's audio delay to the first device. The third delay is obtained from the audio capability parameter.
  • the method further includes: the first device determines an audio strategy (for example, whether to add sound effects, whether to resample, etc.) according to the audio capability parameter.
  • the process of processing audio data includes: the first device determining the above-mentioned first time delay according to the audio strategy.
  • the above audio strategy includes N processing procedures for audio data, and N is an integer greater than 0; wherein, the first device determines the first delay according to the audio strategy, including: the first device determines each processing in the N processing procedures time consuming of the process; furthermore, the first device may obtain the first time delay based on the time consuming of each processing process. For example, the first device may add up the time-consuming of each of the N processing processes to obtain the first time delay, that is, the time-consuming required for the audio data to be processed in the first device.
  • the audio capability parameters of the second device can be dynamically updated, for example, the audio capabilities such as the sound effect mode of the second device can be updated , at this time, the first device can also obtain the updated audio capability parameters of the second device; and, the first device can update the audio strategy according to the updated audio capability parameters; when the audio capability parameters are updated, the first device can be triggered according to the The updated audio capability parameter updates the above-mentioned third delay; when the audio strategy is updated, the first device may be triggered to update the above-mentioned first delay according to the updated audio strategy. That is to say.
  • the above-mentioned first delay and third delay can be dynamically updated, so as to ensure that the first device can obtain the latest audio delay.
  • the HAL of the first device may include a first hardware abstraction module for transmitting audio data, such as a Wi-Fi HAL; in this case, after the first device establishes a network connection with the second device , also includes: the first device creates a second hardware abstraction module corresponding to the second device in the HAL, such as DMSDP Audio HAL; wherein, the first device obtains the second delay, including: the second hardware abstraction module can be obtained from the first hardware abstraction module. The second delay is obtained in the hardware abstraction module, that is, the time required for the audio data to be transmitted between the first device and the second device.
  • the specific method for acquiring the second delay by the first hardware abstraction module may include: the first hardware abstraction module sends a test data packet to the second device; the first hardware abstraction module receives a response from the second device in response to the test data packet sent data packet; further, the first hardware abstraction module can calculate and save the second delay according to the time interval between sending the test data packet and receiving the response data packet.
  • the first hardware abstraction module may periodically calculate and save the second delay according to the above method.
  • the first hardware abstraction module may notify the second hardware abstraction module to obtain the latest second delay.
  • the second hardware abstraction module may also periodically acquire the latest saved second delay from the first hardware abstraction module.
  • the first delay, the second delay or the third delay can be dynamically updated. Then, when at least one of the first delay, the second delay or the third delay is updated, the first device may recalculate the current audio delay. Alternatively, the first device may also periodically acquire the latest first delay, the second delay and the third delay, so as to periodically calculate the current latest audio delay.
  • the display data output by the first device is displayed on the display screen of the first device.
  • the first device projects the audio data to the second device for playback, and retains the display data Play in the first device; at this time, after the first device determines the current audio delay, the method further includes: the first application running in the first device obtains the audio delay; for example, the first application can call the getLatency() interface Query the current audio delay from AudioService.
  • the first application can synchronize the audio data and display data of the first application according to the audio delay, that is, perform audio and video synchronization processing, so that the video images seen by the user and the video sounds heard by the user can be synchronized. Synchronization; when the first application is a music application, the first application can synchronize the audio data and lyrics data of the first application according to the audio delay, so that the lyrics seen by the user are synchronized with the sound of the song heard; when the first application When it is a karaoke application, the first application can synchronize the audio data of the first application with the accompaniment music according to the audio delay, so that the audio data recorded by the user is synchronized with the accompaniment music. Of course, other applications can also acquire the current audio delay to perform audio-related synchronization processing, which is not limited in this embodiment of the present application.
  • the display data output by the first device is displayed on the display screen of the third device.
  • the first device projects the audio data to the second device for playback, and projects the display data. Play in the third device; at this time, in addition to determining the current audio delay, the first device can also determine the current display delay.
  • the above-mentioned display delay can include the delay generated when the display data is transmitted between the first device and the third device; furthermore, the first device The device can determine the current synchronization delay based on the acquired audio delay and display delay; subsequently, the second application running in the first device can synchronize the audio data and display data of the second application according to the current synchronization delay , to improve the synchronization effect of audio and video synchronization.
  • the above synchronization delay may be the difference between the audio delay and the display delay, so as to reflect the time difference between the audio data and the display data played at the same moment.
  • the fourth device is set as the audio output device of the first device, and the fourth device is connected to the second device, it means that when the first device is connected to the second device, the second device is connected
  • the fourth device is used as an audio output device to play audio, that is, the first device, the second device and the fourth device are in a cascade relationship.
  • the first device can obtain the first delay and the second delay according to the above method; when different, the first device also needs to obtain the fourth delay, and the fourth delay includes: the audio data is processed in the second device The delay generated when the audio data is transmitted between the second device and the fourth device, and the delay generated when the audio data is played in the fourth device; furthermore, the first device can be based on the first delay , the second delay and the fourth delay are calculated to obtain the current audio delay.
  • the audio delay is the sum of the first delay, the second delay and the fourth delay.
  • the above-mentioned fourth time delay may be carried by the second device in the audio capability parameter and reported to the first device.
  • the present application provides a method for updating audio delay, including: establishing a network connection between a first device and a second device; if the second device is set as an audio output device and a display output device of the first device, indicating The first device projects both the audio data and the display data to the second device for playback.
  • the delay caused by the transmission of the audio data and the display data between the first device and the second device is basically the same. Therefore, The first device can obtain the first delay and the second delay.
  • the first delay is the delay generated when the audio data is processed in the first device, and the second delay is generated when the audio data is played in the second device. delay; further, the first device may determine the current synchronization delay based on the first delay and the second delay.
  • the current synchronization delay is also dynamically updated along with the first delay and the second delay. For example, the synchronization delay is the sum of the first delay and the second delay.
  • the first device may further include: the first application running in the first device obtains the synchronization delay; further, the first application may obtain the synchronization delay according to the The reached synchronization delay synchronizes the audio data and the display data of the first application.
  • the synchronization delay obtained by the application each time is also the latest calculated synchronization delay, and the synchronization delay can more accurately reflect the current audio data and display time difference between data. Therefore, when the application performs synchronization processing such as audio and video synchronization according to the above synchronization delay, the audio and image played in the second device can better achieve the effect of audio and video synchronization, and improve the user's audio and video synchronization experience.
  • the present application provides a method for playing audio and video files, comprising: a first device receiving a first operation input by a user, and the first operation is used to play a first file (the first file may be played in the first device) It is an audio file or a video file) and is projected to the second device for playback; when the first device is playing the first file, it can obtain the data packets of the first file (the first file includes N data packets, N>0). After the above-mentioned first operation, if the first data packet of the first file is received, the first device can extract the first audio parameter and the first audio data in the first data packet, wherein the first audio data is encoded.
  • the first audio parameter is the encoding parameter used when encoding the first audio data; further, the first device can send the first audio parameter to the second device, so that the second device can determine whether it is itself according to the first audio parameter It has the ability to decode the first audio data; if the second device has the ability to decode the first audio data, the first device does not need to perform operations such as decoding and re-decoding the first audio data.
  • An audio data is directly sent to the second device, and the second device decodes the first audio data and plays it.
  • the first device when the first device projects the audio and video files to the second device, the first device does not need to decode and re-encode the encoded audio data in the data packets, but directly encodes the audio and video files in the encoded audio and video files.
  • the audio data is sent to the second device, and the audio data is decoded and played by using the decoding capability of the second device, so that the delay of the entire projection process of the audio and video files is shortened, thereby improving the user experience of the audio and video files in the cross-device playback scenario.
  • the audio data sent by the first device to the second device is data that has not been decoded in the video file
  • the audio data received by the second device will not be distorted due to the decoding operation of the first device, thus Realize the lossless transmission of audio and video files between the first device and the second device, and improve the fidelity of audio and video files in the scenario where audio and video files are played across devices.
  • the above-mentioned first data packet includes a header (head) and a data (data) part; wherein, the first device extracts the first audio parameters and the first audio data in the first data packet, specifically including : The first device extracts the first audio parameter from the header of the first data packet; the first device extracts the first audio data, that is, the encoded audio data, from the data part of the first data packet.
  • the above-mentioned first audio parameters may include: an encoding format (for example, AAC format) used when encoding the first audio data, an encoding specification (for example, AAC-LC), a version (for example, version 1), a sample at least one of rate or number of channels.
  • an encoding format for example, AAC format
  • AAC-LC encoding specification
  • version for example, version 1
  • sample at least one of rate or number of channels for example, a sample at least one of rate or number of channels.
  • the above-mentioned first audio parameter may also include other parameters used when encoding the first audio data, which is not limited in this embodiment of the present application.
  • the first data packet of the first file includes first display data in addition to the first audio data, and the first display data is also encoded data; then, after the first device obtains the first data packet of the first file, the method further includes: the first device extracts the first display parameter and the first display data in the first data packet, and the first display parameter is the encoded first display parameter.
  • the first device can send the first display parameters to the second device, so that the second device can determine whether it has the ability to decode the first display data according to the first display parameters; if the second device With the ability to decode the first display data, the first device does not need to decode and re-decode the first display data.
  • the first device can directly send the first display data to the second device, so that the The second device decodes the first display data and plays it.
  • the first device when the first device projects the video file to the second device, the first device does not need to decode and re-encode the encoded display data in the data packet, but directly convert the encoded display data in the video file
  • the data is sent to the second device, and the display data is decoded and played by using the decoding capability of the second device, so that the delay of the entire projection process of the video file is shortened, thereby improving the user experience in the scenario where the video file is played across devices.
  • the display data sent by the first device to the second device is data that has not been decoded in the video file
  • the display data received by the second device will not be distorted due to the decoding operation of the first device, thus The lossless transmission of the video file between the first device and the second device is realized, and the fidelity of the video file is improved in the scenario where the video file is played across devices.
  • the first device can extract the above-mentioned first audio data, first display data, first audio parameters, and first display parameters from the first data packet at one time.
  • the first device can send the extracted first audio parameters and the first display parameters to the second device together, or the first device can also send the first audio parameters and the first display parameters to the second device respectively.
  • the embodiments of the present application do not make any restrictions on this.
  • the first device extracts the first display parameter and the first display data in the first data packet, which specifically includes: the first device can extract the first data packet from the header of the first data packet. A display parameter; the first device can extract the first display data from the data portion of the first data packet.
  • the above-mentioned first display parameter may include: at least one of an encoding format (eg, H.264 format), an encoding specification, a version, or a resolution used when encoding the first display data.
  • an encoding format eg, H.264 format
  • an encoding specification e.g., a version
  • a resolution used when encoding the first display data.
  • the above-mentioned first display parameter may also include other parameters used when encoding the first display data, which is not limited in this embodiment of the present application.
  • the above-mentioned first device is provided with a first application (for example, a DV APP), a second application (for example, a video APP), and a first audio and video player (for example, Nuplayer).
  • the first application is used for communicating with the second device, and the second application is used to send the data packet of the first file to be played to the first audio and video player; after the first device receives the first operation input by the user, it also includes: responding to the first Operation, the first device can establish a network connection with the second device by running the first application; further, the first application can send a first broadcast message to the second application to notify the second application to project the first file to the second device for playback ; Then, in response to the first broadcast message, the second application may send a first notification message to the first audio and video player to notify the first audio and video player to start projecting the audio and video files to the second device. Otherwise, the second application may play the first file in the first device according to the existing audio and video playback method.
  • the first device further includes a multimedia extractor (for example, MediaExtractor); wherein, after the first audio and video player receives the above-mentioned first notification message, if the first data of the first file is obtained packet, the first multimedia extractor can call the multimedia extractor to parse the first data packet to obtain the first audio parameter; and the first multimedia extractor can call the multimedia extractor to decode the first data packet package to obtain the first audio data.
  • a multimedia extractor for example, MediaExtractor
  • the method further includes: the first audio and video player can obtain the second data packet of the first file from the second application (that is, the data following the first data packet). package); further, the first audio and video player can extract the second audio data in the second data package, and send the second audio data to the second device, so that the second device decodes the second audio data and plays it.
  • the first audio and video player does not need to extract the audio parameters in the second data packet, nor does it need to send the extracted audio parameters to the second device to trigger the second device to determine whether it has the ability to decode the second audio data, thereby Reduce the delay of projecting the first file to the second device for playback.
  • the first audio and video player may also extract the second display data in the second data packet, and send the second display data to the second device, so that the The second device decodes the second display data and plays it.
  • the method further includes: in response to a second operation input by the user, establishing a network connection between the first application and the third device; the first The application sends a second broadcast message to the second application, and the second broadcast message is used to notify the second application to project the first file to the third device for playback; that is, the user sends the slave device connected to the first device through the second operation. Switching from the second device to the third device, at this time, it is necessary to continue to play the above-mentioned first file on the third device. Then, after receiving the second broadcast message, the first audio and video player can start to project the first file to the third device.
  • the process of projecting the above-mentioned first file to the third device is similar to the process of projecting the above-mentioned first file to the second device.
  • the first audio and video player may obtain the third data package of the first file from the second application; further, the first audio and video player may extract the second audio parameters and the third audio data in the third data package, and similarly , the third audio data is the encoded audio data, and the second audio parameter is the encoding parameter used when encoding the third audio data; because the first device does not know whether the third device has the ability to decode the audio data in the first file, Therefore, the first audio and video player can send the extracted second audio parameters to the third device, so that the third device determines whether it has the ability to decode the third audio data according to the second audio parameters; if the third device has the ability to decode the third audio data The first audio and video player can directly send the third audio data to the third device, so that the third device decodes the third audio data and plays the third audio data.
  • the first audio and video player may further extract the third display data and display parameters in the third data packet, and send the display parameters in the third data packet to The third device triggers the third device to determine whether it has the ability to decode the third display data. If the third device has the ability to decode the third display data, the first audio and video player can directly send the third display data to the third device, so that the third device decodes the third display data and plays it.
  • the first audio and video player can extract the display data and/or audio data in the data packets, and send the extracted display data and/or audio data to the third device, so that the third device uses its own decoding capability to decode the received display data and/or audio data and play it.
  • the method further includes: in response to a third operation input by the user, the second application switches the currently playing first file to the first file Two files (the second file is an audio file or a video file); the second application creates a second audio and video player (such as a new Nuplayer), and the second audio and video player is used to receive data packets from the second file; that is, , the user switches the first file being played on the first device to the second file through a third operation, and at this time, the second file needs to be projected to the second device for playback. Then, the second application can send a third notification message to the second audio and video player, and after receiving the third broadcast message, the second audio and video player can start to project the second file to the second device.
  • the second application can send a third notification message to the second audio and video player, and after receiving the third broadcast message, the second audio and video player can start to project the second file to the second device.
  • the process of projecting the second file to the second device is similar to the process of projecting the first file to the second device.
  • the above-mentioned second audio and video player may obtain a data packet of the second file, such as a fourth data packet, from the second application; further, the second audio and video player may extract the third audio parameter and the fourth audio data, the fourth audio data is the encoded audio data, and the third audio parameter is the encoding parameter used when encoding the fourth audio data; because the first device does not know whether the second device has the ability to decode the audio in the second file Therefore, the second audio and video player can send the third audio parameter to the second device, so that the second device can determine whether it has the ability to decode the fourth audio data according to the third audio parameter; if the second device has the ability to decode the fourth audio data; The ability to decode the fourth audio data, the second audio and video player sends the fourth audio data to the second device, so that the second device decodes the fourth audio data and plays it.
  • the second audio and video player may further extract the fourth display data and display parameters in the fourth data packet, and send the display parameters in the fourth data packet to The second device triggers the second device to determine whether it has the ability to decode the fourth display data. If the fourth device has the ability to decode the fourth display data, the second audio and video player can directly send the fourth display data to the second device, so that the second device decodes the fourth display data and plays it.
  • the second audio and video player can extract the display data and/or audio data in the data packets, and send the extracted display data and/or audio data to the second file. device, so that the second device decodes and plays the received display data and/or audio data using its own decoding capability.
  • the method further includes: the first device runs a third application; the first device plays an audio file or a video file from the third application . That is to say, while projecting audio and video files to the second device, the first device can also run other applications (such as a third application) to play display data and/or audio data in other applications, so that the user can While playing the audio and video files, the device can also use application functions provided by other applications in the first device.
  • the first device runs a third application
  • the first device plays an audio file or a video file from the third application . That is to say, while projecting audio and video files to the second device, the first device can also run other applications (such as a third application) to play display data and/or audio data in other applications, so that the user can While playing the audio and video files, the device can also use application functions provided by other applications in the first device.
  • the present application provides a method for playing audio and video files, comprising: a second device receiving a first audio parameter sent by a first device, where the first audio parameter is used when encoding the first audio data in the first data packet
  • the first data packet is the data packet of the first file; further, the second device can determine whether it has the ability to decode the first audio data according to the first audio parameter; if it has the ability to decode the first audio data, then the first
  • the second device can send a first response message to the first device to trigger the first device to send the undecoded first audio data to the second device; after receiving the first audio data sent by the first device, the second device can One audio data is decoded to obtain decoded second audio data; further, the second device plays the second audio data to realize the cross-device playback function of the first file.
  • the second device has the ability to decode the audio of the first file played by the first device, the first device can directly send the undecoded audio data in the first file to the second device, and the second device can decode the audio data of the first file.
  • the received audio data is decoded and played, which simplifies the audio data processing process between the first device and the second device when the audio and video files are projected, and shortens the time-consuming for the first device and the second device to project the audio and video files.
  • the second device decodes the first audio data to obtain the decoded second audio data, which specifically includes: the second device may use the first decoding parameter to decode the first audio data to obtain The decoded second audio data, wherein the first decoding parameter corresponds to the first audio parameter.
  • the first decoding parameter corresponds to the first audio parameter.
  • the format used to encode the first audio data in the first audio parameter is AAC format
  • the corresponding first decoding parameter decodes the first audio data.
  • a format used for audio data is also AAC format.
  • the above-mentioned first data packet may further include first display data; at this time, the second device may also receive the first display parameter sent by the first device, and the first display parameter is the encoded first display and the second device can determine whether it has the ability to decode the first display data according to the first display parameter; if it has the ability to decode the first display data, the second device sends the first device to the first device.
  • a response message can also be used to instruct the first device to send the first display data to the second device; subsequently, when the second device receives the undecoded first display data sent by the first device, it can use its own decoding ability to A display data is decoded to obtain decoded second display data; further, the second device can play the second display data.
  • the first device can directly send the undecoded display data in the first file to the second device, and the second device can The received display data is decoded and played, which simplifies the processing of the display data between the first device and the second device when the video file is projected, and shortens the time-consuming for the first device and the second device to project the video file.
  • the second device decodes the first display data to obtain the decoded second display data, including: the second device decodes the first display data by using the second decoding parameters, and obtains the decoded second display data.
  • the second decoding parameter corresponds to the first display parameter.
  • the format used to encode the first display data in the first display parameter is H.265 format
  • the corresponding second decoding parameter decodes the first display data in the H.265 format.
  • the format used for a display data is also H.265 format.
  • the second device since the parameters used in encoding the audio data and display data in each data packet in the same audio and video file are generally unified, if the second device has the ability to decode the first audio data and the first display data If the second device has the ability to decode other audio data and display data in the first file, then, if the second device subsequently receives the third audio data in the first file, the second device can directly The third audio data is decoded and played; similarly, if the second device subsequently receives the third display data in the first file, the second device can directly decode and play the third display data.
  • the method further includes: if the second device has the ability to decode the first audio data, the second device according to the first audio parameter.
  • the audio parameter creates an audio decoder (audio decoder), which is used for decoding the audio data in the first file; after the second device determines whether it has the ability to decode the first display data according to the first display parameter, it also includes: if Having the ability to decode the first display data, the second device creates a video decoder (video decoder) according to the first display parameters, and the video decoder is used to decode the display data in the first file.
  • audio decoder audio decoder
  • video decoder video decoder
  • the second device determines that it has the ability to decode the audio and video data in the first file, it can create the corresponding audio decoder and image decoder in advance.
  • the second device can use the created audio decoder/image decoder for decoding, which further shortens the time-consuming for the first device and the second device to project the audio and video files.
  • the present application provides a device recommendation method, including: the first device can receive a first operation of a user to open a first service; in response to the first operation, the first device can receive a request from an N ( N is an integer greater than 0) the device parameters associated with the first service are respectively obtained from the electronic devices; furthermore, the first device can predict, according to the obtained device parameters, when each of the above-mentioned N electronic devices executes the first service the service quality; subsequently, the first device may display a device list according to the service quality of each electronic device in the N electronic devices performing the first service, and the device list includes the device identifier of at least one electronic device among the N electronic devices, thereby A specific device suitable for executing the first service is recommended to the user.
  • the above-mentioned first service may be a service related to an audio function, such as an audio playing service, a recording service, and the like.
  • the above-mentioned first service may be a service related to a display function, such as a video playing service, a video calling service, a game service, and the like.
  • the above-mentioned first service may be a service related to a camera function, such as a video call service, a video recording service, and the like.
  • the above-mentioned device parameters may include one or more of audio parameters related to audio functions, display parameters related to display functions, and camera parameters related to camera functions.
  • the first device as the master device can obtain relevant device parameters of the slave devices (eg, the above N electronic devices), so as to predict the service quality when each slave device executes the service. In this way, based on the predicted service quality of each slave device when executing the service, the first device can recommend the specific device that executes the service to the user by displaying the device list, thereby improving the service when multiple devices work together in a distributed scenario. quality, while improving the user experience.
  • relevant device parameters of the slave devices eg, the above N electronic devices
  • the above-mentioned N electronic devices may include a second device; the device parameters obtained by the first device from the second device may include M (M is an integer greater than 0) parameters; in this case, The first device predicts the service quality of the first service performed by the second device according to the device parameters, including: the first device determines M scores corresponding to the M parameters one-to-one; further, the first device can calculate the first score according to the M scores.
  • the second device executes the service quality score of the first service; when the service quality score is higher, the service quality of the first service is higher.
  • the first device may score the M parameters of the second device one by one to obtain the corresponding M scores, and then the first device may perform a weighted average of the M scores according to the preset weights to obtain:
  • the second device executes the service quality score of the first service.
  • the service quality scores of other devices in the above N electronic devices that perform the first service can also be calculated according to the above method, which is not limited in this application.
  • the above-mentioned N electronic devices may further include a third device; when the service quality score of the second device executing the first service is higher than the service quality score of the third device executing the first service, the third device The arrangement order of the second device in the device list is before the third device. That is to say, the first device may recommend devices that perform related services to the user through the order of the devices in the displayed device list.
  • the second device when the service quality score of the second device executing the first service is higher than the service quality score of other electronic devices executing the first service among the N electronic devices, it is indicated that the second device is the above N electronic devices. If the device is the most suitable for executing the first service among the devices, the second device may be marked as a recommended device in the above device list, thereby prompting the user to use the recommended device to execute the first service.
  • the above-mentioned M parameters may include a first parameter corresponding to the first function, for example, a display parameter corresponding to the display function; then, when the score of the first parameter of the second device is higher than When the score of the first parameter of other electronic devices among the N electronic devices indicates that the second device performs the first function of the first service with high service quality, the first device can display the first prompt information in the above device list , and the first prompt information is used to recommend the user to use the second device to implement the first function. That is to say, the first device may recommend to the user a device with a more prominent function when executing the first service.
  • the above-mentioned M parameters include a first parameter corresponding to the first function, for example, a display parameter corresponding to the display function; then, when the score of the first parameter of the second device is lower than N
  • the first device can display the second prompt information in the above device list,
  • the second prompt information includes the reason why the user is not recommended to use the second device to implement the first function. That is, the first device may prompt the user for a specific reason why it is not recommended to use a certain device to perform the first service.
  • the above-mentioned N electronic devices include a second device; after the first device displays the device list according to the quality of service of each electronic device in the N electronic devices performing the first service, the device further includes: A device receives a second operation of the user selecting the second device in the device list; then, in response to the second operation, the first device may switch the first service to the second device for execution. In this way, the user can switch the first service to the second device based on the device recommended by the first device in the device list, so as to realize a distributed service scenario in which multiple devices work together.
  • the method further includes: the first device can download from the current slave device (for example, N number of devices located in the same communication network as the mobile phone) again.
  • the device parameters associated with the first service are respectively obtained from the electronic device); similarly, the first device can predict the service quality of each of the current N electronic devices executing the first service according to the obtained device parameters; when the second device If it is not the electronic device with the highest service quality among the above N electronic devices that executes the first service, it means that the first service is currently not suitable to be executed on the second device, then the first device can display the first prompt message, and the first prompt message uses For prompting the user to use the recommended device to perform the first service, the recommended device is one or more of the N electronic devices.
  • the first device as the master device, can obtain the relevant device parameters of each slave device in real time during the process of cooperating with other devices (such as the above-mentioned second device) to perform a certain service, so as to predict that each slave device will execute the service. quality of business.
  • the first device can recommend to the user a recommended device that executes the service by displaying a prompt message, thereby improving the service quality when multiple devices work together in a distributed scenario.
  • the user experience is improved.
  • the first device predicts, according to the device parameters, the service quality of each electronic device in the N electronic devices executing the first service, including: the first device may, according to the device parameters obtained from each electronic device, A service quality score for each electronic device to perform the first service is calculated. For example, the first device may score each of the device parameters corresponding to each electronic device, and then perform a weighted average of all scores to calculate a service quality score of the corresponding electronic device executing the first service.
  • the N electronic devices include a third device; when the service quality score of the third device executing the first service is higher than that of other electronic devices in the N electronic devices, the recommended device is the third device. three devices; or, when the service quality score of the third device performing the first subtask in the first service is higher than that of other electronic devices in the N electronic devices, the above-mentioned recommended device is the third device. That is to say, when a certain device other than the second device among the above-mentioned N electronic devices executes the first service, or the service quality of a certain subtask in the first service is relatively high, the first device may determine the device as recommended device, so that the user is recommended to use the recommended device to perform the first service.
  • the above-mentioned first service may include a first subtask and a second subtask.
  • the screen projection service may include an audio playback task and a display task;
  • the above-mentioned N electronic devices may include a third subtask device and fourth device.
  • the above recommended device is a device group composed of a third device and a fourth device. That is, when multiple devices cooperate to perform the first service, higher service quality can be obtained, the first device may recommend to the user in the form of a device group to use multiple devices to jointly execute the above-mentioned first service.
  • the above method further includes: the first device predicts a service quality score of the first device executing the first service; wherein, when the service quality score of the first device executing the first service is higher than the above N electronic devices device, the above-mentioned recommended device may be the first device. That is to say, the master device (ie, the first device) can also be used as a candidate device for the recommended device, and when the first device executes the target service (for example, the first service) with high service quality, it can also prompt the user to use the first device The device executes the above-mentioned first service.
  • the above-mentioned first prompt message may include a device identifier of the recommending device; after the first device displays the first prompt message, the method further includes: the first device receiving the user's selection of a recommendation in the first prompt message A third operation of the device; in response to the third operation, the first device switches the first service to the recommended device for execution.
  • the user can quickly switch the first service to the recommended device with higher service quality for execution through the device identifier of the recommended device in the first prompt message.
  • the above method further includes: the first device may notify the second device of the above-mentioned recommended device, so that the second device displays a second prompt message, where the second prompt message is used to prompt the user to use the recommended device to perform the first service.
  • the user can quickly switch the first service to the recommended device with higher service quality through the second prompt message in the second device for execution.
  • the above-mentioned device parameters may include one or more of audio parameters, display parameters, camera parameters or time delay.
  • the audio parameters may include one or more of the sound effect algorithm supported by the slave device, the number of channels, the sampling rate, the mixing strategy, the codec algorithm of audio data, the number and model of microphones, and the number and model of speakers.
  • the above-mentioned display parameters may include one or more items such as the resolution, frame rate, and codec algorithm of the display data supported by the slave device.
  • the above camera parameters may include one or more items such as image processing algorithms supported by the slave device, the number of cameras, the resolution of the cameras, or the FOV of the cameras.
  • the present application provides an ultrasonic positioning method, including: when the first device detects that a user operates a screen-casting function (which may also be referred to as content continuation, cross-device continuation, etc.), the first device may Detecting K (K is an integer greater than 1) electronic devices connected to the same communication network as the first device, for example, the K electronic devices may be electronic devices that log into the same account as the first device; further, the first device may be Ultrasonic positioning is performed on the second device in the above-mentioned K electronic devices to obtain the positioning result of the second device (that is, the first positioning result); and, the first device can perform ultrasonic positioning on the third device in the above-mentioned K electronic devices.
  • K is an integer greater than 1
  • the K electronic devices may be electronic devices that log into the same account as the first device
  • the first device may be Ultrasonic positioning is performed on the second device in the above-mentioned K electronic devices to obtain the positioning result of the second device (that is, the first positioning result); and, the
  • the first device can display the identification of the second device and the identification of the third device in the interactive interface, wherein the identification of the second device is in the interactive interface.
  • the position of the device is related to the first positioning result
  • the position of the identifier of the third device in the interactive interface is related to the second positioning result.
  • the first device when the user triggers the screen projection function of the first device, the first device can act as the master device to perform ultrasonic positioning on the second device and the third device, and obtain the positioning results of the second device and the third device. Then, the first device can display the identifiers of the second device and the third device in the interactive interface according to the obtained positioning result, so that the user can intuitively see the currently detected positions of the second device and the third device in the interactive interface relation. In this way, the user can conveniently and accurately select the device to perform screen projection with the first device this time in the interactive interface according to the positional relationship, thereby improving the user's use experience in the screen projection scenario.
  • the above-mentioned interactive interface may be the entire interface displayed by the display screen of the first device, or may be part of the interface displayed by the display screen of the first device.
  • the first device can display the specific content (such as video or image, etc.) waiting to be projected in the display area 1 of the display screen, and at the same time, the first device can display the above-mentioned second and third devices in the display area 2 of the display screen.
  • the identification of the device. In this case, the display area 2 is the above-mentioned interactive interface.
  • the ultrasonic positioning performed by the first device on the second device includes: the first device may send a first positioning instruction to the second device, and the first positioning instruction is used to trigger the second device to transmit the first ultrasonic wave signal; while the second device transmits the first ultrasonic signal, the first device can use its own N (N is an integer greater than 1) ultrasonic receivers to collect the first ultrasonic signal; furthermore, the first device can collect the first ultrasonic signal according to the second ultrasonic signal The second device is positioned according to the time when the signals respectively arrive at the N ultrasonic receivers.
  • the first device may use a Time of Arrival (TOA) or a Time Difference Of Arrival (TDOA) algorithm to locate the second device based on the time when the second ultrasonic signal arrives at the N ultrasonic receivers respectively .
  • TOA Time of Arrival
  • TDOA Time Difference Of Arrival
  • the N ultrasonic receivers of the first device itself may specifically be N microphones in the microphone array in the first device.
  • the first device does not need to add an additional ultrasonic receiver to adapt to the ultrasonic positioning method provided by the embodiment of the present application, thereby reducing the cost and difficulty of implementing indoor positioning.
  • the first device can also perform ultrasonic positioning on the third device according to the above method, which is not limited in this application.
  • the first device performs ultrasonic positioning on the third device, which specifically includes: the first device sends a second positioning instruction to the third device, and the second positioning instruction is used to trigger the third device to transmit the second ultrasonic signal; while the third device transmits the second ultrasonic signal, the first device can acquire the first ultrasonic data, and the first ultrasonic data includes the time when the second ultrasonic signal reaches the N ultrasonic receivers in the first device respectively; In addition, the first device can acquire second ultrasonic data, and the second ultrasonic data includes the time when the second ultrasonic signal reaches M (M is an integer greater than 1) ultrasonic receivers in the second device respectively; The data and the second ultrasound data locate the third device.
  • M is an integer greater than 1
  • the first device as the master device, can use the existing ultrasonic positioning capability of the second device to simultaneously turn on the ultrasonic receivers of the first device and the second device in a coordinated manner by multiple devices to receive the data sent by the third device to be located.
  • Ultrasonic signals thereby positioning the third device according to more received ultrasonic signals, improving the positioning accuracy of the third device, and simplifying the operation process and implementation cost of indoor positioning.
  • the method further includes: the first device determines the second device as a cooperating device among the above K electronic devices, and the cooperating device is used for Cooperate with the first device to perform ultrasonic positioning; the first device sends a first co-location instruction to the second device, and the first co-location instruction is used to trigger the second device to use the M ultrasonic receivers to detect the second ultrasonic signal.
  • the second device can turn on its own M ultrasonic receivers in response to the first co-location instruction, and use the M ultrasonic receivers to detect the second ultrasonic signals, and send the detected M channels of the second ultrasonic signals as the above-mentioned second ultrasonic data to the first device.
  • the number of microphones that actually collect ultrasonic signals transmitted by the third device to be located increases, and the microphones that collect ultrasonic signals are located at different positions of the first device and the second device, so that the first device can The ultrasonic signals of more quantity and more directions locate the third device, thereby improving the positioning accuracy of the device.
  • the first device determines the second device as a cooperative device among the K electronic devices, including: when the second device is an electronic device with the highest positioning capability among the K electronic devices, the first device The second device is determined as a cooperating device. For example, when the number of microphones set on a certain electronic device is larger, the higher the positioning capability of the electronic device can be set. Alternatively, when the distance between the microphones set on a certain electronic device is larger, the positioning capability of the electronic device can be set to be higher. Alternatively, when the performance of hardware parameters such as a processor of a certain electronic device is higher, the positioning capability of the electronic device can be set to be higher. Using the second device with higher positioning capability to coordinate with the first device to locate the third device can improve the positioning accuracy of the third device.
  • the first device locates the third device according to the first ultrasonic data and the second ultrasonic data, including: when the first device has obtained the positioning result of the second device,
  • the M microphones can be used as the microphones of the first device, which is equivalent to that a part of the microphones of the first device (such as the above N microphones) are set on the local machine, and another part of the microphones of the first device (such as the above M microphones) are set on the first device. on the second device.
  • the first device may use a preset positioning algorithm to locate the third device based on the acquired first ultrasonic data and second ultrasonic data.
  • the N ultrasonic receivers may be N microphones in the microphone array of the first device; and/or the M ultrasonic receivers may be M microphones in the microphone array of the second device
  • the first device acquires the first ultrasonic data, including: the first device uses the above N microphones to detect the second ultrasonic signal, and obtains N channels of second ultrasonic signals (that is, the first ultrasonic data); The device can use the above M microphones to detect the second ultrasonic signals to obtain M channels of second ultrasonic signals (ie, second ultrasonic data), and the second device can send the second ultrasonic data to the first device.
  • the first device locates the third device according to the first ultrasonic data and the second ultrasonic data, which may include: the first device combines the above-mentioned N channels of second ultrasonic signals and M channels of second ultrasonic signals into a multi-channel ultrasonic wave Data, the multi-channel ultrasonic data may include: the waveform of each ultrasonic signal in the above-mentioned N second ultrasonic signals and the time when each ultrasonic signal reaches the corresponding microphone, and the above-mentioned M second ultrasonic signal of each ultrasonic signal. waveform and the time when each ultrasonic signal reaches the corresponding microphone; furthermore, the first device can use a preset positioning algorithm to locate the third device according to the multi-channel ultrasonic data.
  • the ultrasonic positioning of the third device by the first device may include: the first device sends a second positioning instruction to the third device, and the second positioning instruction is used to trigger the third device to transmit the second ultrasonic signal; At the same time as the second ultrasonic signal, the first device can determine the first ultrasonic positioning result according to the time when the second ultrasonic signal reaches the N ultrasonic receivers in the first device, and the second device can reach the second device according to the second ultrasonic signal The time of the M ultrasonic receivers determines the second ultrasonic positioning result. That is, the first device and the second device can perform ultrasonic positioning on the third device at the same time.
  • the second device can send the obtained second ultrasonic positioning result to the first device, and the first device corrects the first ultrasonic positioning result calculated by itself according to the second ultrasonic positioning result, and outputs the final positioning of the third device result. Since the finally output positioning result of the third device is obtained by the first device combining the first ultrasonic positioning result and the second ultrasonic positioning result, the positioning accuracy of the third device can be improved.
  • the above-mentioned N ultrasonic receivers may be N microphones in the microphone array of the first device; at this time, the first device acquiring the first ultrasonic positioning result includes: the first device uses the N microphones to detect the second ultrasonic wave. signal; the first device locates the third device according to the time when each of the N microphones detects the second ultrasonic signal, and obtains the first ultrasonic localization result.
  • the above-mentioned M ultrasonic receivers can be M microphones in the microphone array of the second device; at this time, the second device can use the above-mentioned M microphones to detect the second ultrasonic signal; When the second ultrasonic signal is detected, the third device is located to obtain a second ultrasonic location result; further, the second device can send the second ultrasonic location result to the first device.
  • the above K electronic devices further include a fourth device; then, in addition to the ultrasonic positioning of the second device and the third device by the first device according to the above method, the first device can also be performed according to the above method.
  • the method performs ultrasonic positioning on the fourth device to obtain a third positioning result of the fourth device; further, the first device can display the identification of the second device, the identification of the third device and the identification of the fourth device in the interactive interface, wherein, The position of the logo of the second device in the interactive interface is related to the first positioning result, the position of the logo of the third device in the interactive interface is related to the second positioning result, and the position of the logo of the fourth device in the interactive interface is related to the third positioning result. Positioning results are relevant.
  • the user can intuitively see the positional relationship of the currently detected second device, the third device and the fourth device in the interactive interface. Subsequently, the user can conveniently and accurately select the device to perform screen projection with the first device this time in the interactive interface according to the positional relationship, so as to improve the user's use experience in the screen projection scenario.
  • the process of performing ultrasonic positioning of the fourth device by the first device is similar to the process of performing ultrasonic positioning of the third device by the first device.
  • the first device may send the third positioning to the fourth device.
  • the third positioning instruction is used to trigger the fourth device to transmit the third ultrasonic signal; while the fourth device transmits the third ultrasonic signal, the first device can acquire the third ultrasonic data, and the third ultrasonic data includes the third ultrasonic signal respectively.
  • the time to reach the N ultrasonic receivers in the first device at the same time, the first device can acquire fourth ultrasonic data, and the fourth ultrasonic data includes the time when the third ultrasonic signal reaches the M ultrasonic receivers in the second device respectively; and then, The first device may locate the fourth device according to the third ultrasonic data and the fourth ultrasonic data.
  • the first device may also use both the second device and the third device as cooperative devices, and cooperate with the first device to locate the fourth device Perform ultrasonic localization.
  • the third device can also use its own Z ultrasonic receivers as a cooperative device to detect the above-mentioned third ultrasonic signal, and the third device can use the detected Z channels to detect the third ultrasonic signal.
  • the three ultrasonic signals are sent to the first device as fifth ultrasonic data. In this way, the first device can locate the fourth device according to the acquired third ultrasonic data, the fourth ultrasonic data and the fifth ultrasonic data, so as to use more ultrasonic signals to locate the fourth device and improve the performance of the fourth device. positioning accuracy.
  • the first device when the first device sends a third positioning instruction to the fourth device, the first device may also send a second co-locating instruction to the second device and the third device (that is, two cooperating devices), and the second co-locating instruction
  • the instruction is used to trigger the second device to use the M ultrasonic receivers to detect the third ultrasonic signal
  • the second co-location instruction is used to trigger the third device to use the Z ultrasonic receivers to detect the third ultrasonic signal.
  • the first device can still perform ultrasonic positioning on other electronic devices according to the above method, which is not limited in this embodiment of the present application.
  • the method further includes: in response to an operation of selecting the identifier of the second device by the user, the first device may The content played by the first device is projected to the second device for playback; or, in response to the user selecting the identifier of the third device, the first device can project the content played by the first device to the third device for playback. That is, the user can select the device that needs to perform screen projection with the first device according to the displayed positional relationship between the electronic devices in the interactive interface.
  • the user's operation of a certain device in the interactive interface may specifically be operations such as clicking, sliding, air gestures, or inputting a corresponding voice command, which is not limited in this application.
  • the present application provides an ultrasonic positioning method, comprising: the second device can be used as an electronic device to be positioned to receive a positioning instruction sent by the first device; in response to the positioning instruction, the second device can use its own ultrasonic wave to generate A device, such as a speaker, emits the first ultrasonic signal. Subsequently, the first device may perform ultrasonic positioning on the second device according to the time when the first ultrasonic signal reaches each ultrasonic receiver in the first device, and obtain a positioning result of the second device.
  • the present application provides an ultrasonic positioning method, comprising: a second device can serve as a cooperative device of the first device to receive a co-location instruction sent by the first device; in response to the co-location instruction, the second device can open itself
  • the M ultrasonic receivers (for example, M microphones, where M is an integer greater than 1) detect ultrasonic signals emitted by the electronic device to be located (for example, a third device).
  • the second device can send the detected M channels of ultrasonic signals (ie, the second ultrasonic data in the first aspect) to the first device, and the first device can perform ultrasonic positioning on the third device in combination with the second ultrasonic data.
  • the second device may locate the third device according to the time when the M channels of ultrasonic signals arrive at the M microphones, and send the obtained ultrasonic localization result (the second ultrasonic localization result in the first aspect) to the first device , the third device is positioned by the first device in combination with the second ultrasonic positioning result.
  • the present application provides an electronic device (such as the above-mentioned first device), comprising: a display screen, a communication module, one or more processors, one or more memories, and one or more computer programs;
  • the processor is coupled with the communication module, the display screen and the memory, the above-mentioned one or more computer programs are stored in the memory, and when the first device runs, the processor executes the one or more computer programs stored in the memory, so that the first device performs the method of any one of the above-mentioned first to twentieth aspects.
  • the present application provides an electronic device (such as the above-mentioned second device), comprising: a communication module, one or more processors, one or more memories, and one or more computer programs; wherein, processing The processor is coupled to the communication module and the memory, the above-mentioned one or more computer programs are stored in the memory, and when the second device runs, the processor executes the one or more computer programs stored in the memory, so that the second device executes The method of any one of the first to twentieth aspects above.
  • the present application provides an audio system, including the above-mentioned first device and the second device, and the first device and the second device can perform any one of the above-mentioned first to twentieth aspects through interaction. method.
  • the present application provides a computer-readable storage medium, comprising computer instructions, when the computer instructions are executed on the above-mentioned first device or the second device, the first device or the second device is caused to perform the above-mentioned first aspect. to the method of any one of the twentieth aspects.
  • the present application provides a computer program product, which, when the computer program product runs on the first device or the second device, enables the first device or the second device to execute the first to twentieth aspects above any one of the methods.
  • FIG. 1 is a schematic structural diagram of an audio system provided by an embodiment of the present application.
  • FIG. 2 is a schematic diagram 1 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 3 is a schematic diagram 2 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 4 is an interactive schematic diagram 1 of an audio control method provided by an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram 1 of an electronic device provided by an embodiment of the present application.
  • FIG. 6 is a schematic diagram 3 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram 4 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram 5 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram 6 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram 7 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram 8 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 12 is a schematic diagram 9 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 13 is a schematic diagram 10 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 14A is a schematic diagram 11 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 14B is a schematic diagram 12 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 15 is a schematic diagram 13 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 16A is a schematic diagram 14 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 16B is a schematic diagram 15 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 17 is a schematic diagram 16 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 18A is a schematic diagram 17 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 18B is a schematic diagram 18 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 19 is a schematic diagram 19 of an audio application scenario provided by an embodiment of the application.
  • FIG. 20 is a schematic diagram 20 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 21 is a schematic diagram 21 of an audio application scenario provided by an embodiment of the application.
  • FIG. 22 is a schematic diagram 22 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 23 is a schematic diagram 23 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 24 is a schematic diagram 24 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 25 is a schematic diagram 25 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 26 is a schematic diagram 26 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 27 is a schematic diagram 27 of an audio application scenario provided by an embodiment of the application.
  • FIG. 28 is a schematic diagram 28 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 29 is a schematic diagram 29 of an audio application scenario provided by an embodiment of the application.
  • FIG. 30 is a schematic diagram 30 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 31 is a schematic diagram 31 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 32 is a schematic diagram 32 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 33 is a schematic diagram 33 of an audio application scenario provided by an embodiment of the application.
  • FIG. 34 is an interactive schematic diagram 2 of an audio control method provided by an embodiment of the present application.
  • FIG. 35 is a schematic diagram 34 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 36 is a schematic diagram 35 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 37 is a schematic diagram 36 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 38 is a schematic diagram 37 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 39 is a schematic diagram 38 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 40 is a schematic diagram 39 of an audio application scenario provided by an embodiment of the present application.
  • 41 is an interactive schematic diagram 3 of an audio control method provided by an embodiment of the present application.
  • FIG. 42 is a schematic diagram 40 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 43 is a schematic diagram 41 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 44 is a schematic diagram 42 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 45 is an interactive schematic diagram 4 of an audio control method provided by an embodiment of the present application.
  • FIG. 46 is a schematic diagram 43 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 47 is a schematic diagram 44 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 48 is a schematic diagram 45 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 49 is a schematic diagram 46 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 50 is a schematic diagram 47 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 51 is a schematic diagram 48 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 52 is a schematic diagram 49 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 53 is a schematic diagram 50 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 54 is a schematic diagram 51 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 55 is a schematic diagram 52 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 56 is a schematic diagram 53 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 57 is a schematic diagram 54 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 58 is a schematic diagram 55 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 59 is a schematic diagram 56 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 60 is a schematic diagram 57 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 61 is a schematic diagram 58 of an audio application scenario provided by an embodiment of the application.
  • FIG. 62 is a schematic diagram 59 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 63 is a schematic diagram 60 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 64 is a schematic diagram 61 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 65 is a schematic diagram 62 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 66 is a schematic diagram 63 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 67 is a schematic diagram 64 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 68 is a schematic diagram 65 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 69 is a schematic diagram 66 of an audio application scenario provided by an embodiment of the application.
  • FIG. 70 is a schematic diagram 67 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 71 is a schematic diagram 68 of an audio application scenario provided by an embodiment of the application.
  • FIG. 72 is a schematic diagram 69 of an audio application scenario provided by an embodiment of the application.
  • FIG. 73 is a schematic diagram 70 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 74 is a schematic diagram 71 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 75 is a schematic diagram 72 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 76 is a schematic diagram 73 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 77 is a schematic diagram 74 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 78 is a schematic diagram 75 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 79 is a schematic diagram 76 of an audio application scenario provided by an embodiment of the application.
  • FIG. 80 is a schematic diagram 77 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 81 is a schematic diagram 78 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 82 is a schematic diagram 79 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 83 is a schematic diagram 80 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 84 is a schematic diagram 81 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 85 is an interactive schematic diagram of a screen recording method provided by an embodiment of the present application.
  • FIG. 86 is a schematic diagram 82 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 87 is a schematic diagram 83 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 88 is a schematic diagram 84 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 89 is a schematic diagram 85 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 90 is a schematic diagram 86 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 91 is a schematic diagram 87 of an audio application scenario provided by an embodiment of the application.
  • FIG. 92 is a schematic diagram 88 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 93 is a schematic diagram 89 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 94 is a schematic diagram 90 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 95 is a schematic diagram 91 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 96 is a schematic diagram 92 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 97 is a schematic diagram 93 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 98 is a schematic diagram 94 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 99 is a schematic diagram 95 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 100 is a schematic diagram 96 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 101 is a schematic diagram 97 of an audio application scenario provided by an embodiment of the application.
  • FIG. 102 is a schematic diagram 98 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 103 is a schematic diagram 99 of an audio application scenario provided by an embodiment of the application.
  • FIG. 104 is a schematic diagram 100 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 105 is an interactive schematic diagram 1 of an audio update method provided by an embodiment of the present application.
  • FIG. 106 is an interactive schematic diagram 2 of an audio update method provided by an embodiment of the present application.
  • FIG. 107 is a schematic diagram 101 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 108 is a schematic diagram 102 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 109 is a schematic diagram 103 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 110 is a schematic diagram 104 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 111 is a schematic diagram 105 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 112 is a schematic diagram 106 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 113 is a schematic diagram 107 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 114 is a schematic diagram 108 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 115 is a schematic diagram 109 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 116 is a schematic diagram 110 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 117 is a schematic diagram 111 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 118 is a schematic diagram 112 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 119 is a schematic diagram 113 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 120 is a schematic diagram 114 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 121 is a schematic diagram 115 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 122 is an interactive schematic diagram of a device recommendation method provided by an embodiment of the present application.
  • FIG. 123 is a schematic diagram 116 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 124 is a schematic diagram 117 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 125 is a schematic diagram 118 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 126 is a schematic diagram 119 of an audio application scenario provided by an embodiment of the application.
  • FIG. 127 is a schematic diagram 120 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 128 is a schematic diagram 121 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 129 is a schematic diagram 122 of an audio application scenario provided by an embodiment of the application.
  • FIG. 130 is a schematic diagram 123 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 131 is a schematic diagram 124 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 132 is a schematic diagram 125 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 133 is a schematic diagram 126 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 134 is a schematic diagram 127 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 135 is a schematic diagram 128 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 136 is a schematic diagram 129 of an audio application scenario provided by an embodiment of the application.
  • FIG. 137 is a schematic diagram 130 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 138 is a schematic diagram 131 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 139 is a schematic diagram 132 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 140 is a schematic diagram 133 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 141 is a schematic diagram 134 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 142 is a schematic diagram 135 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 143 is a schematic diagram 136 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 144 is a schematic diagram 137 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 145 is a schematic diagram 138 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 146 is a schematic diagram 139 of an audio application scenario provided by an embodiment of the application.
  • FIG. 147 is a schematic diagram 140 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 148 is a schematic diagram 141 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 149 is a schematic diagram 142 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 150 is a schematic diagram 143 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 151 is a schematic diagram 144 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 152 is a schematic diagram 145 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 153 is a schematic diagram 146 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 154 is a schematic diagram 147 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 155 is a schematic diagram 148 of an audio application scenario provided by an embodiment of the present application.
  • FIG. 156 is a schematic diagram 149 of an audio application scenario provided by an embodiment of the present application.
  • 157 is a schematic structural diagram 2 of an electronic device provided by an embodiment of the application.
  • FIG. 158 is a schematic structural diagram 3 of an electronic device provided by an embodiment of the application.
  • the audio system 200 may include a master device (master) 101 and N slave devices (slaves) 102 , where N is an integer greater than 0. Communication between the master device 101 and any one of the slave devices 102 may be performed in a wired manner or wirelessly.
  • a wired connection may be established between the master device 101 and the slave device 102 using a universal serial bus (USB).
  • the master device 101 and the slave device 102 can use the global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (code division multiple access) multiple access, CDMA), wideband code division multiple access (WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), long term evolution (long term evolution, LTE), Bluetooth, wireless fidelity (Wi-Fi), NFC, voice over Internet protocol (VoIP), and communication protocols that support network slicing architecture establish wireless connections.
  • GSM global system for mobile communications
  • GPRS general packet radio service
  • code division multiple access code division multiple access
  • CDMA code division multiple access
  • WCDMA wideband code division multiple access
  • time division code division multiple access time-division code division multiple access
  • TD-SCDMA time-division code division multiple access
  • LTE long term evolution
  • Bluetooth wireless
  • the master device 101 is used to provide audio data to be played, and output the audio data to the slave device 102 .
  • the slave device 102 is used to receive and play the audio data sent by the master device 101 .
  • the slave device 102 may also be used to collect audio data, and send the collected audio data to the master device 101 for processing such as storage. That is to say, the master device 101 can distribute its own audio input and output functions to one or more slave devices 102 for implementation, thereby realizing distributed audio capabilities across devices.
  • the main device 101 may specifically be a mobile phone, a speaker, a tablet computer, a TV (also referred to as a smart TV, a smart screen, or a large-screen device), a notebook computer, and an Ultra-mobile Personal Computer (UMPC).
  • UMPC Ultra-mobile Personal Computer
  • handheld computers netbooks, personal digital assistants (Personal Digital Assistants, PDAs), wearable electronic devices, vehicle-mounted devices, virtual reality devices and other devices with audio input and output functions, which are not limited in the embodiments of the present application.
  • the slave device 102 may be, in addition to a traditional audio output device such as a Bluetooth headset or a wired headset, a smart electronic device installed with an operating system (eg, Android system), such as a mobile phone, a TV, a speaker, or a vehicle-mounted device.
  • an operating system eg, Android system
  • the slave device 102 receives the audio data sent from the master device 101, the audio data can be sampled, mixed or added with sound effects through its operating system.
  • the user can select one or more slave devices 102 as the audio output device of the mobile phone through the control center of the mobile phone.
  • the mobile phone can display the control center 201 (also called opening the control center) in response to a preset operation (such as a pull-up operation or a pull-down operation) input by the user in the current display interface, and the control center 201 can also Called a pull-up menu or drop-down menu.
  • the control center 201 the user can set switches of some quick functions in the mobile phone, for example, the switch of the Bluetooth function, the switch of the wireless local area network (WLAN) function, the switch of the flashlight, and the adjustment switch of the brightness and volume, etc. Do not make any restrictions.
  • the mobile phone can also display a switch button 202 of the audio switch function in the control center 201 .
  • the user can click the switch button 202 to inquire about one or more electronic devices that can currently be used as the audio output device.
  • the mobile phone can display the detailed menu 301 of the audio switching function in the control center 201.
  • the details menu 301 includes one or more candidate devices 302 searched by the current mobile phone that can perform audio switching with the mobile phone.
  • the mobile phone may search for electronic devices located in the same Wi-Fi network as the mobile phone, and display the searched electronic devices as candidate devices in the details menu 301 .
  • the mobile phone may query the server for an electronic device logged into the same account as the mobile phone (for example, a Huawei account), and display the electronic device as a candidate device in the details menu 301 . In this way, the user can intuitively see one or more electronic devices currently available for audio switching with the mobile phone in the control center 201, which is convenient for the user to select.
  • the candidate devices displayed in the detail menu 301 may include the mobile phone itself (ie, this machine), earphones, speakers, televisions, or other electronic devices with audio input and output capabilities, such as mobile phones. If the user selects this device, it means that the user wishes to use the speaker of the mobile phone to output the audio of the mobile phone; if the user selects other candidate devices, it means that the user wishes to output the audio of the mobile phone through the candidate device selected by the user.
  • the candidate device of can play the audio output by the mobile phone as the slave device 102 of the mobile phone.
  • the mobile phone can establish a network connection with the slave device 102 .
  • the mobile phone can establish a network connection with the TV after detecting that the user selects the TV.
  • a mobile phone can establish a Wi-Fi connection with the TV through a router, or the mobile phone can establish a Wi-Fi P2P connection with the TV directly.
  • the mobile phone can obtain the audio capability parameter of the TV from the TV, and the audio capability parameter is used to reflect the specific audio input or output capability supported by the TV.
  • the audio capability parameter may include one or more parameters such as the playback delay of the TV, the sound effect parameter, the audio sampling rate or the number of sound channels.
  • the mobile phone can determine the audio playing strategy for audio switching based on the audio capability parameter of the TV, and then output corresponding audio data to the TV according to the audio playing strategy, thereby switching the audio on the mobile phone to playing on the TV.
  • the mobile phone obtains the audio capability parameter of the TV and indicates that the TV supports playing two-channel audio data. Then, if the audio data output by the music APP running on the mobile phone is 4-channel audio data, the mobile phone may require in the audio playback strategy to combine the 4-channel audio data into two-channel audio data. Then, the mobile phone can send the combined two-channel audio data to the TV for playback, so that the mobile phone can flexibly switch the audio to playback on the secondary device according to the current audio capability of the secondary device, providing users with a better audio experience.
  • the user can also select multiple electronic devices in the above-mentioned detail menu 301 as the slave devices 102 of the mobile phone to perform audio switching. For example, if it is detected that the user has selected the headset and the TV in the above-mentioned detail menu 301, the mobile phone can obtain the audio capability parameters of the headset and the TV respectively. Since the headset is more portable and the TV has a better display experience, the mobile phone can send the audio data corresponding to the video screen to the TV for playback when performing audio switching, while the system audio such as the ringtone and notification sound of the mobile phone can be sent to the TV for playback. The data is sent to the headset for playback. In this way, the mobile phone can distribute and play audio data on multiple slave devices according to different audio capabilities of the multiple slave devices, thereby providing the user with a better audio experience.
  • the master device 101 (eg, the above-mentioned mobile phone) can output audio data to one or more slave devices 102 for audio switching in response to the user's selection, so as to realize the distributed audio capability across devices.
  • the master device 101 can acquire the audio capability parameters of the slave device 102, and perform audio switching according to the dynamic determination of the audio capability parameters of the slave device 102. The audio playback strategy at the time.
  • the master device 101 can output customized audio data to the slave device 102 according to the actual audio capability of the slave device 102, so that the slave device 102 can also process the audio data sent by the master device according to its own audio capability, thereby flexibly
  • the audio function of the master device 101 is distributed on the slave device 102 to provide a better audio experience for the user.
  • FIG. 5 shows a schematic structural diagram of the mobile phone.
  • the mobile phone may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, Speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, etc.
  • a processor 110 an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, Speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, etc.
  • USB universal serial bus
  • the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the mobile phone.
  • the mobile phone may include more or less components than shown, or some components may be combined, or some components may be separated, or different component arrangements.
  • the illustrated components may be implemented in hardware, software, or a combination of software and hardware.
  • the processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), controller, memory, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural-network processing unit (NPU) Wait. Wherein, different processing units may be independent devices, or may be integrated in one or more processors.
  • application processor application processor, AP
  • modem processor graphics processor
  • graphics processor graphics processor
  • ISP image signal processor
  • controller memory
  • video codec digital signal processor
  • DSP digital signal processor
  • NPU neural-network processing unit
  • a memory may also be provided in the processor 110 for storing instructions and data.
  • the memory in processor 110 is cache memory. This memory may hold instructions or data that have just been used or recycled by the processor 110 . If the processor 110 needs to use the instruction or data again, it can be called directly from the memory. Repeated accesses are avoided and the latency of the processor 110 is reduced, thereby increasing the efficiency of the system.
  • the wireless communication function of the mobile phone can be realized by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modulation and demodulation processor, the baseband processor, and the like.
  • Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals.
  • the mobile communication module 150 can provide wireless communication solutions including 2G/3G/4G/5G etc. applied on the mobile phone.
  • at least part of the functional modules of the mobile communication module 150 may be provided in the processor 110 .
  • at least part of the functional modules of the mobile communication module 150 may be provided in the same device as at least part of the modules of the processor 110 .
  • the wireless communication module 160 can provide applications on the mobile phone including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system ( global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field communication technology (near field communication, NFC), infrared technology (infrared, IR) and other wireless communication solutions.
  • WLAN wireless local area networks
  • Wi-Fi wireless fidelity
  • BT wireless fidelity
  • GNSS global navigation satellite system
  • frequency modulation frequency modulation
  • FM near field communication technology
  • NFC near field communication technology
  • infrared technology infrared, IR
  • the antenna 1 of the mobile phone is coupled with the mobile communication module 150, and the antenna 2 is coupled with the wireless communication module 160, so that the mobile phone can communicate with the network and other devices through wireless communication technology.
  • the mobile phone realizes the display function through the GPU, the display screen 194, and the application processor.
  • the GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor.
  • the GPU is used to perform mathematical and geometric calculations for graphics rendering.
  • Processor 110 may include one or more GPUs that execute program instructions to generate or alter display information.
  • Display screen 194 is used to display images, videos, and the like.
  • Display screen 194 includes a display panel.
  • the display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (active-matrix organic light).
  • LED diode AMOLED
  • flexible light-emitting diode flexible light-emitting diode (flex light-emitting diode, FLED), Miniled, MicroLed, Micro-oLed, quantum dot light-emitting diode (quantum dot light emitting diodes, QLED) and so on.
  • the handset may include 1 or N display screens 194, where N is a positive integer greater than 1.
  • the mobile phone can realize the shooting function through the ISP, the camera 193, the video codec, the GPU, the display screen 194 and the application processor.
  • Camera 193 is used to capture still images or video.
  • the object is projected through the lens to generate an optical image onto the photosensitive element.
  • the photosensitive element may be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor.
  • CMOS complementary metal-oxide-semiconductor
  • the photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the ISP to convert it into a digital image signal.
  • the ISP outputs the digital image signal to the DSP for processing.
  • DSP converts digital image signals into standard RGB, YUV and other formats of image signals.
  • the mobile phone may include 1 or N cameras 193 , where N is a positive integer greater than 1.
  • the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the mobile phone.
  • the external memory card communicates with the processor 110 through the external memory interface 120 to realize the data storage function. For example to save files like music, video etc in external memory card.
  • Internal memory 121 may be used to store computer executable program code, which includes instructions.
  • the processor 110 executes various functional applications and data processing of the mobile phone by executing the instructions stored in the internal memory 121 .
  • the internal memory 121 may include a storage program area and a storage data area.
  • the storage program area can store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), and the like.
  • the storage data area can store data (such as audio data, phone book, etc.) created during the use of the mobile phone.
  • the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, universal flash storage (UFS), and the like.
  • the mobile phone can implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and an application processor. Such as music playback, recording, etc.
  • the audio module 170 is used for converting digital audio information into analog audio signal output, and also for converting analog audio input into digital audio signal. Audio module 170 may also be used to encode and decode audio signals. In some embodiments, the audio module 170 may be provided in the processor 110 , or some functional modules of the audio module 170 may be provided in the processor 110 .
  • Speaker 170A also referred to as a “speaker” is used to convert audio electrical signals into sound signals.
  • the mobile phone can listen to music through the speaker 170A, or listen to hands-free calls.
  • the receiver 170B also referred to as "earpiece" is used to convert audio electrical signals into sound signals.
  • the voice can be received by placing the receiver 170B close to the human ear.
  • the microphone 170C also called “microphone” or “microphone” is used to convert sound signals into electrical signals.
  • the user can make a sound by approaching the microphone 170C through a human mouth, and input the sound signal into the microphone 170C.
  • the mobile phone may be provided with at least one microphone 170C.
  • the mobile phone may be provided with two microphones 170C, which in addition to collecting sound signals, may also implement a noise reduction function.
  • the mobile phone can also be provided with three, four or more microphones 170C to collect sound signals, reduce noise, identify sound sources, and implement directional recording functions.
  • the earphone jack 170D is used to connect wired earphones.
  • the earphone interface 170D can be a USB interface 130, or can be a 3.5mm open mobile terminal platform (open mobile terminal platform, OMTP) standard interface, a cellular telecommunications industry association of the USA (CTIA) standard interface.
  • OMTP open mobile terminal platform
  • CTIA cellular telecommunications industry association of the USA
  • the sensor module 180 may include a pressure sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.
  • the mobile phone may also include a charging management module, a power management module, a battery, a button, an indicator, and one or more SIM card interfaces, which are not limited in this embodiment of the present application.
  • the software system of the above mobile phone may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture.
  • the embodiments of the present application take an Android system with a layered architecture as an example to exemplarily describe the software structure of a mobile phone.
  • Android system with a layered architecture as an example to exemplarily describe the software structure of a mobile phone.
  • the functions implemented by each functional module are similar to the embodiments of the present application.
  • FIG. 6 is a block diagram of a software structure of a mobile phone according to an embodiment of the present application.
  • the layered architecture divides the software into several layers, and each layer has a clear role and division of labor. Layers communicate with each other through software interfaces.
  • the Android system is divided into five layers, from top to bottom, the application layer, the application framework layer, the Android runtime (Android runtime) and the system library, and the HAL (hardware abstraction layer, hardware abstraction layer) layer and kernel layer.
  • the application layer can include a series of application packages.
  • APPs applications
  • applications such as calls, memos, browsers, contacts, cameras, gallery, calendar, maps, Bluetooth, music, videos, and short messages can be installed in the application layer.
  • these applications installed in the application layer can have audio capabilities.
  • the music app can play audio
  • the camera app can output the shutter sound preset by the system when taking pictures.
  • the video APP can output audio corresponding to the video picture while playing the video.
  • the map APP can output a navigation voice after the navigation function is enabled.
  • an application with an audio function may be referred to as an audio APP.
  • the application framework layer provides an application programming interface (application programming interface, API) and a programming framework for applications in the application layer.
  • the application framework layer includes some predefined functions.
  • the Android system is provided with an audio architecture 601 that implements an audio function for the audio APP.
  • the above-mentioned audio architecture 601 may include an audio manager (AudioManager), an audio player and an audio processor.
  • the audio player may be a player such as AudioTrack or MediaPlayer.
  • the audio processor may be a processor such as AudioFlinger.
  • the audio player can be called, and the corresponding audio data can be input to the audio player.
  • the audio APP can input the original audio data to the audio player, and after the audio player parses, decapsulates or decodes the original audio data, and obtains a frame of PCM (pulse code modulation, pulse code modulation) )data.
  • the audio APP can also directly output PCM data to the audio player.
  • the audio player can send the audio data to the audio processor for audio processing.
  • the audio processor may perform audio processing on the audio data according to the audio playback strategy output by the audio manager.
  • the audio manager may include an audio service (AudioService) and an audio policy module (AudioPolicy).
  • the audio APP can call the audio service to notify the audio policy module to set the specific audio playback policy when audio data is input and output. For example, volume level, sampling rate of audio data, sound effect setting, sound mixing setting, etc.
  • the audio strategy module can output the corresponding audio playback strategy to the audio processor in real time during the audio playback process, so that the audio processor can mix, resample, and sound the audio data output by the audio player according to the latest audio playback strategy. Setting and other processing, the processed audio data is the audio data to be played.
  • a HAL hardware abstraction layer, hardware abstraction layer
  • HAL is responsible for interacting with each hardware device of the mobile phone.
  • HAL hides the implementation details of each hardware device, and on the other hand, it can provide the Android system with an interface to call each hardware device.
  • HALs corresponding to different mobile phone hardware devices are provided in the HAL, such as Audio HAL, Camera HAL, Wi-Fi HAL, etc.
  • the Audio HAL can also be used as a part of the above-mentioned audio architecture 601 .
  • the audio processor (such as AudioFlinger) can directly call the Audio HAL, send the processed audio data to the Audio HAL, and the Audio HAL will send the audio data to the corresponding audio output device (such as speakers, headphones, etc.) for playback.
  • Audio HAL can be further divided into Primary HAL, A2dp HAL, etc.
  • AudioFlinger can call the Primary HAL to output the audio data to the speaker of the mobile phone, or AudioFlinger can call the A2dp HAL to output the audio data to the Bluetooth headset connected to the mobile phone.
  • the Bluetooth APP also known as the Bluetooth service
  • the Bluetooth APP in the application layer can create the A2dp HAL in the HAL.
  • the A2dp HAL can run in the form of an empty process. Bluetooth device connection.
  • the Bluetooth APP can register information such as the identity of the first Bluetooth headset, the Bluetooth address and other information in the audio manager, and store the relevant hardware parameters of the first Bluetooth headset. (For example, the sampling rate of the first Bluetooth headset, etc.) is sent to the A2dp HAL, so that the A2dp HAL can support data transmission and reception with the first Bluetooth headset.
  • the A2dp HAL is fixed during the process of maintaining the connection between the mobile phone and the first Bluetooth headset.
  • the Bluetooth APP can clear the relevant information of the first Bluetooth headset in the audio manager, and restore the A2dp HAL to an empty process running in the HAL.
  • the Bluetooth APP can register the second Bluetooth device in the audio manager
  • the identification of the headset, the Bluetooth address and other information, and the relevant hardware parameters of the second Bluetooth headset are sent to the A2dp HAL, so that the A2dp HAL can support data transmission and reception with the second Bluetooth headset.
  • the Bluetooth APP can clear the relevant information of the second Bluetooth headset in the audio manager, and restore the A2dp HAL to an empty process running in the HAL.
  • the application framework layer may also include a window manager, a content provider, a view system, a resource manager, a notification manager, and the like, which are not limited in this embodiment of the present application.
  • the above-mentioned window manager is used to manage window programs.
  • the window manager can get the size of the display screen, determine whether there is a status bar, lock the screen, take screenshots, etc.
  • the above content providers are used to store and retrieve data and make these data accessible to applications.
  • the data may include video, images, audio, calls made and received, browsing history and bookmarks, phone book, etc.
  • the view system described above can be used to build the display interface of an application.
  • Each display interface can consist of one or more controls.
  • controls may include interface elements such as icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets.
  • the above resource manager provides various resources for the application, such as localized strings, icons, pictures, layout files, video files and so on.
  • the notification manager described above enables applications to display notification information in the status bar, which can be used to convey notification-type messages, and can disappear automatically after a short stay without user interaction.
  • the notification manager is used to notify download completion, message reminders, etc.
  • the notification manager can also display notifications in the status bar at the top of the system in the form of graphs or scroll bar text, such as notifications of applications running in the background, and notifications on the screen in the form of dialog windows. For example, prompt text information in the status bar, send out a sound, vibrate, and flash the indicator light, etc.
  • the Android runtime includes core libraries and virtual machines. Android runtime is responsible for scheduling and management of the Android system.
  • the core library consists of two parts: one is the function functions that the java language needs to call, and the other is the core library of Android.
  • the application layer and the application framework layer run in virtual machines.
  • the virtual machine executes the java files of the application layer and the application framework layer as binary files.
  • the virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, safety and exception management, and garbage collection.
  • a system library can include multiple functional modules. For example: surface manager (surface manager), media library (Media Libraries), 3D graphics processing library (eg: OpenGL ES), 2D graphics engine (eg: SGL), etc.
  • surface manager surface manager
  • media library Media Libraries
  • 3D graphics processing library eg: OpenGL ES
  • 2D graphics engine eg: SGL
  • the surface manager is used to manage the display subsystem and provides the fusion of 2D and 3D layers for multiple applications.
  • the media library supports playback and recording of a variety of commonly used audio and video formats, as well as still image files.
  • the media library can support a variety of audio and video encoding formats, such as: MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.
  • the 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.
  • 2D graphics engine is a drawing engine for 2D drawing.
  • the kernel layer is located under the HAL and is the layer between hardware and software.
  • the kernel layer at least includes a display driver, a camera driver, an audio driver, a sensor driver, and the like, which are not limited in this embodiment of the present application.
  • a device virtualization (DeviceVirtualization) APP for implementing the audio switching function may be installed in the application layer of the mobile phone, which may be referred to later as for DV APP.
  • DV APP can run in the mobile phone as a system application.
  • the audio switching function implemented by the DV APP can also be resident in the mobile phone in the form of a system service.
  • the DV APP can trigger the phone to obtain the audio capability of the slave device, so as to follow the slave device's audio capabilities.
  • the audio capability of the device creates a corresponding virtual device in the mobile phone, so that the mobile phone can switch its own audio function to the slave device by controlling the virtual device.
  • a switch button 801 for audio switching can be displayed.
  • the mobile phone uses its own speaker to output audio data. If the user wishes to use other audio output devices to continue playing the audio data, the user can click the switch button 801 to trigger the audio switching function.
  • the DV APP can trigger the mobile phone to start detecting one or more candidate devices nearby that can perform audio switching. For example, as shown in (b) of FIG.
  • the mobile phone can detect candidate devices that are in the same Wi-Fi network as the mobile phone and have an audio output function, and display the detected candidate devices in the menu 802 .
  • the menu 802 includes three candidate devices, namely a TV 803, a speaker 804, and an earphone 805, the user can select one of the three candidate devices as a slave device that continues to play the audio data in the music APP.
  • the mobile phone can send an access request to the TV 803.
  • the television 803 may display a dialog 901 to request the user to allow the mobile phone to access the television 803 .
  • the user can select the "Allow this time” or "Always allow” button in the dialog box 901.
  • the TV 803 can send a response allowing access to the mobile phone.
  • the DV APP can trigger the mobile phone to establish a network connection with the TV 803, such as a Wi-Fi P2P connection.
  • the network connection established between the mobile phone and the slave device may specifically refer to the network connection (ie, the service connection) of the service channel.
  • the mobile phone may have established a connection with the TV 803 through the Wi-Fi network, and the connection at this time refers to the connection of the data channel (ie, data connection).
  • the network connection may be a P2P connection based on TCP (transmission control protocol, transmission control protocol) or UDP (user datagram protocol, user datagram protocol), which is not limited in this embodiment of the present application.
  • the TV 803 can display a string of randomly generated connection codes 902 as authentication information to perform identity authentication with the mobile phone, and at the same time , the TV 803 can send the connection code 902 to the mobile phone.
  • the DV APP requires the user to input the connection code 902 displayed on the TV 803 on the display screen of the mobile phone.
  • the DV APP detects that the connection code entered by the user on the mobile phone is the same as the connection code 902 sent by the TV 803 to the mobile phone, it means that the identity authentication between the mobile phone and the TV 803 has passed, and the DV APP can trigger the mobile phone and the TV 803 to establish a network connection .
  • the identity authentication has been completed between the mobile phone and the TV 803
  • the DV APP can directly establish a network connection with the TV 803 after detecting that the user selects the TV 803, without performing identity authentication again.
  • the mobile phone and the TV 803 can communicate through the network connection.
  • the DV APP in the mobile phone can use the TV 803 as a slave device of the mobile phone, and obtain the audio capability parameters of the TV 803 from the TV 803 based on the established network connection.
  • the audio capability parameter may include one or more of the audio playback delay, sound effect parameter, audio sampling rate or number of sound channels of the TV 803, and these parameters may reflect the specific output capability supported by the TV 803.
  • the DV APP can call the preset interface of the HAL, and input the acquired audio capability parameters into the preset interface, thereby creating the HAL corresponding to the TV 803 .
  • the HAL created by the DV APP to switch the audio data to the slave device may be called the DMSDP (Distributed Mobile Sensing Development Platform) Audio HAL.
  • the DMSDP Audio HAL does not correspond to the actual hardware device of the mobile phone.
  • the DMSDP Audio HAL can transmit the received audio data to the slave device of the mobile phone through the established network connection to realize the audio switching function. .
  • the TV 803 may also send display capability parameters (such as screen resolution, codec algorithm for display data, etc.) used to indicate its own display capability to the DV APP of the mobile phone through the established network connection; or, The TV 803 (that is, the slave device) can also send the camera capability parameters (such as the number of cameras, image processing algorithms, etc.) used to indicate its own camera capability to the DV APP of the mobile phone through the established network connection.
  • display capability parameters such as screen resolution, codec algorithm for display data, etc.
  • the TV 803 that is, the slave device
  • the camera capability parameters such as the number of cameras, image processing algorithms, etc.
  • the slave device can also send the relevant capability parameters to the DV APP of the mobile phone.
  • the DV APP of the mobile phone can also input these capability parameters together with the above audio capability parameters into the preset interface to create the corresponding HAL.
  • the created HAL not only integrates the audio capability of the slave device, but also integrates other various abilities.
  • the HAL created by the DV APP according to various capability parameters of the slave device may be called the DMSDP HAL, that is to say, the above-mentioned DMSDP Audio HAL may be a functional module for realizing the audio function in the DMSDP HAL.
  • the DMSDP Audio HAL can also be referred to as the DMSDP Audio HAL.
  • the mobile phone can implement service functions in various distributed scenarios such as audio, display, or camera through the DMSDP HAL and the slave device, which is not limited in this embodiment of the present application.
  • the DV APP in addition to creating a corresponding DMSDP Audio HAL for the slave device of the mobile phone in the HAL, the DV APP can also call the AudioManager to register the audio capability of the slave device in the AudioPolicy.
  • the DV APP may send the identifier of the TV 803 and the audio capability parameter of the TV 803 to the AudioPolicy for saving.
  • the AudioPolicy may determine the corresponding audio policy according to the audio capability parameter of the TV 803, and output the determined audio policy to the audio processor (eg AudioFlinger).
  • AudioFlinger can perform corresponding processing on the audio data of the music APP output by the audio player (such as AudioTrack) according to the audio policy determined by AudioPolicy, and send the processed audio data to the TV 803 through the DMSDP Audio HAL for playback, thereby
  • the audio on the mobile phone is customized and switched to be played on the slave device (ie, the TV 803 ), so as to realize the distributed audio capability across the devices.
  • the audio capability parameters of the TV 803 may include playback parameters and recording parameters of the TV 803 .
  • the playback parameters are used to reflect the audio playback capabilities of the TV 803
  • the recording parameters are used to reflect the audio recording capabilities of the TV 803 .
  • the TV 803 can encapsulate the playback parameters in the first field, and encapsulate the recording parameters in the second field and send it to the mobile phone.
  • the AudioPolicy of the mobile phone extracts the above-mentioned playback parameters from the first field, the corresponding audio playback strategy can be determined, and after the AudioPolicy extracts the above-mentioned recording parameters from the second field, the corresponding audio recording strategy can be determined.
  • the first field or the second field may also be empty, indicating that the TV 803 does not have the audio playback capability or the audio recording capability.
  • the DMSDP Audio HAL created by the DV APP in the HAL can be dynamically updated.
  • the TV 803 can dynamically send the latest audio capability parameters to the mobile phone.
  • the DV APP of the mobile phone can update the DMSDP Audio HAL according to the latest audio capability parameters of the TV 803, so that the DMSDP Audio HAL matches the audio capability of the TV 803.
  • the DV APP of the mobile phone can register the latest audio capability parameters of the TV 803 into the AudioPolicy, so that the AudioPolicy can update the current audio policy according to the latest audio capability parameters.
  • the mobile phone can also switch its own audio data to multiple slave devices for playback.
  • the user may select multiple devices from the candidate devices searched by the mobile phone as slave devices of the mobile phone.
  • the mobile phone can establish network connections with multiple slave devices respectively, and obtain the audio capability parameters of each slave device.
  • DMSDP Audio HAL corresponding to each slave device. For example, as shown in FIG.
  • the DV APP can create a DMSDP Audio HAL1 in the HAL according to the audio capability parameter 1 of the speaker 804
  • the DV APP can create a DMSDP Audio HAL2 in the HAL according to the audio capability parameter 2 of the TV 803 .
  • the AudioPolicy can customize the corresponding audio policy according to the audio capability parameters of each slave device, so that AudioFlinger can process the audio data according to the audio policy determined by the AudioPolicy.
  • AudioFlinger can send the first audio data that needs to be played by the speaker 804 to the speaker 804 through DMSDP Audio HAL1, and send the second audio data that needs to be played by the TV 803 to the TV 803 through DMSDP Audio HAL2, thereby realizing cross-device distribution. audio capability.
  • the first audio data and the second audio data may be the same or different.
  • the DV APP can establish a network connection with the corresponding slave device in response to the user's audio switching requirement, thereby obtaining the audio capability parameter of the slave device. Furthermore, the DV APP can create the corresponding DMSDP Audio HAL in the HAL according to the audio capability parameter, and register the audio capability of the slave device in the AudioPolicy, so that the AudioPolicy can customize the audio capability of the slave device to output to AudioFlinger and the audio of the slave device Ability-matched audio strategy.
  • AudioFlinger processes the audio data provided by the mobile phone according to the audio strategy, it can call the created DMSDP Audio HAL to send the processed audio data to the slave device, so that the slave device can play the audio data from the mobile phone that matches its own audio capabilities (ie master device) audio data.
  • the master device can switch its own audio function to one or more other slave devices according to the audio capability of the slave device, make full use of the audio processing capability of the slave device, and cooperate with the slave device to complete the audio switching process more efficiently and flexibly. This provides users with a better audio experience.
  • the music APP when the mobile phone runs the music APP and uses its own speaker to play the song A, as shown in Figure 11, the music APP can call the audio player (such as AudioTrack) to send the audio data 1 of the song A to the audio Processor (eg AudioFlinger). Audio data 1 is processed by AudioFlinger, such as sampling, mixing, setting sound effects or channel conversion. Since the mobile phone is not connected to other audio output devices at this time, as shown by the dotted arrow in Figure 11, AudioFlinger can call the Primary HAL in the HAL to output the processed audio data 1 to the speaker of the mobile phone for playback, realizing the localization of the mobile phone. audio playback function.
  • AudioFlinger can call the Primary HAL in the HAL to output the processed audio data 1 to the speaker of the mobile phone for playback, realizing the localization of the mobile phone. audio playback function.
  • the music APP can call the AudioManager to register the relevant information of the audio data 1 being played in the AudioPolicy when it is running.
  • the music APP may cache information such as the current sound effect mode, the number of channels, the sampling rate, and the volume of the audio data 1 in the AudioPolicy.
  • a switch button 801 for audio switching can be displayed.
  • the mobile phone can run the DV APP to realize the audio switching function in the background.
  • the music APP can communicate with the DV APP after detecting that the user clicks the above-mentioned switching button 801, and triggers the DV APP to search for one or more candidate devices nearby that can perform audio switching.
  • the DV APP can display three candidate devices, namely a TV 803 , a speaker 804 and an earphone 805 , which are located in the same Wi-Fi network as the mobile phone, in the menu 802 .
  • the DV APP can use the speaker 804 as the slave device of the mobile phone to establish a network connection with the speaker 804.
  • a preset communication APP eg, a hilink APP
  • a preset communication APP can be triggered to communicate and search for one or more nearby candidate devices that can perform audio switching.
  • the DV APP When it is detected that the user has selected a certain candidate device (for example, the speaker 804), the DV APP can be triggered, and the speaker 804 can be used as a slave device of the mobile phone to establish a network connection with the speaker 804.
  • the network connection may be a P2P connection based on TCP (transmission control protocol, transmission control protocol) or UDP (user datagram protocol, user datagram protocol).
  • the mobile phone and the speaker 804 also need to perform identity authentication.
  • identity authentication For the specific process of identity authentication, reference may be made to the relevant description of identity authentication between the mobile phone and the TV 803 in (a) and (b) of FIG. 9 , and details are not repeated here.
  • the DV APP can use the speaker 804 as a slave device of the mobile phone, and obtain the audio capability parameters of the speaker 804 from the speaker 804 .
  • the audio architecture in the speaker 804 is similar to the audio architecture in the mobile phone, and a proxy APP for implementing the audio switching function can be installed in the speaker 804 .
  • the mobile phone After the mobile phone has established a network connection with the speaker 804, it can send an acquisition request for audio capability parameters to the proxy APP of the speaker 804, and then, in response to the acquisition request, the proxy APP of the speaker 804 can call its AudioManager to obtain the speaker from the AudioPolicy or AudioFlinger of the speaker 804. 804's own audio capability parameters.
  • the proxy APP of the speaker 804 can send the audio capability parameters of the speaker 804 to the DV APP of the mobile phone.
  • a proxy APP can also be set in the mobile phone, and the proxy APP of the speaker 804 can send the audio capability parameters of the speaker 804 to the proxy APP of the mobile phone, and then the proxy APP of the mobile phone sends the audio capability parameters of the speaker 804 to the DV APP to Reduce the operating load of the DV APP.
  • the DV APP in the mobile phone obtains the audio capability parameter of the speaker 804, it can create a DMSDP Audio HAL 1101 corresponding to the speaker 804 according to the audio capability parameter.
  • the DV APP can call the AudioManager to register the audio capability of the speaker 804 in the AudioPolicy.
  • the DV APP can send the identification of the speaker 804 and the audio capability parameters of the speaker 804 to AudioPolicy.
  • the AudioPolicy can set the audio playback policy when the audio is switched to the speaker 804 according to the audio capability parameter of the speaker 804 .
  • the audio capability parameter of the speaker 804 may be used to reflect the specific audio input or output capability supported by the speaker 804 .
  • the audio capability parameter of the slave device eg, the speaker 804
  • the audio capability parameter of the slave device may include two types of parameters, one is the audio capability parameter (which may be referred to as a hardware capability parameter) mainly related to the hardware capability of the speaker 804 , such as the speaker The sampling rate, the number of channels, etc. supported by 804, these parameters can reflect the hardware capability of the speaker 804 when inputting or outputting audio; the other type is the audio capability parameter mainly related to the software capability of the speaker 804 (may be called software capability).
  • the AudioPolicy can set a corresponding audio playback policy in combination with the hardware capability and software capability of the speaker 804 when playing audio.
  • the audio capability parameter (ie, the hardware capability parameter) related to the hardware capability of the speaker 804 is mainly determined by the hardware characteristics of the speaker 804, for example, the hardware type, model interface type of the processor, speaker or microphone in the speaker 804 Wait.
  • the hardware capability parameter reported by the speaker 804 in the audio capability parameter is generally fixed.
  • the hardware capability parameters in the audio capability parameters reported by the speaker 804 to the mobile phone can also be changed.
  • the audio capability parameters (ie software capability parameters) related to the software capability of the speaker 804 are mainly determined by the software characteristics of the speaker 804, for example, the sound effect algorithm, echo cancellation algorithm, encoding or decoding algorithm used by the speaker 804, etc.
  • the software capability parameter reported by the speaker 804 in the audio capability parameter can be dynamically updated. For example, after the user turns on the sound effect switch of the sound box 804, the sound box 804 may report that the sound effect mode of the sound box 804 is on in the audio capability parameter. After the user turns off the sound effect switch of the speaker 804, the speaker 804 can update its audio capability parameter, and report that the sound effect mode of the speaker 804 is off in the audio capability parameter.
  • the audio capability parameter reported by the speaker 804 may include the parameter of audio playback delay.
  • the audio playback delay is not only related to software factors such as the audio data processing algorithm of the speaker 804 and the network environment, but also to the hardware processing capability of the speaker 804 related.
  • the audio playback delay can be used as a software capability parameter.
  • those skilled in the art can also divide the foregoing software capability parameters and hardware capability parameters according to actual application scenarios or actual experience, which is not limited in this embodiment of the present application.
  • the audio capability parameters of the sound box 804 may include sound effects capabilities (which may be referred to as sound effect parameters) supported by the sound box 804 .
  • the speaker 804 supports subwoofer sound, 3D surround sound, Dolby sound, histen sound, and the like.
  • the sound effect mode that the speaker 804 is turned on at a certain time is fixed. For example, after the speaker 804 is turned on, Dolby sound can be turned on by default. If the user wishes to modify the sound effect when the sound box 804 plays audio, the user can manually set the current sound effect mode on the sound box 804 . For example, the speaker 804 can be set from the sound mode of Dolby sound to the subwoofer sound. Then, when the speaker 804 reports the audio capability parameter to the DV APP of the mobile phone, the sound effect mode supported by the speaker 804 and the currently enabled sound effect mode can be added to the audio capability parameter as sound effect parameters. Of course, if the sound box 804 is not turned on in the sound effect mode, the sound box 804 may also indicate in the audio capability parameter that the sound box 804 has not turned on the sound effect mode.
  • the music APP can call AudioTrack to send the audio data 1 to AudioFlinger.
  • AudioFlinger can communicate with AudioPolicy before processing audio data 1, and request AudioPolicy for the audio playback policy for processing audio data 1 this time.
  • AudioPolicy can query whether the current speaker 804 has the sound effect mode enabled in the audio capability parameter of the speaker 804 . If the sound effect mode is enabled, the AudioPolicy can be set in the audio playback policy to not perform sound effect processing on the audio data 1. In this way, after AudioPolicy outputs the audio playback policy to AudioFlinger, AudioFlinger does not need to perform sound effect processing on audio data 1.
  • AudioFlinger calls DMSDP Audio HAL1101 to send the audio data 1 to the speaker 804, the speaker 804 can perform the corresponding sound effect processing on the audio data 1 and play it.
  • the AudioPolicy can be set in the audio playback policy not to perform sound effect processing on the audio data 1.
  • the AudioPolicy can be set in the audio playback policy to perform sound effect processing on the audio data 1. For example, subwoofer processing is performed on audio data 1 .
  • AudioPolicy outputs the audio playback policy to AudioFlinger
  • AudioFlinger can perform subwoofer processing on audio data 1 in response to the audio playback policy, and send the processed audio data 1 to speaker 804 through DMSDP Audio HAL 1101.
  • the speaker 804 does not have any sound effects turned on, the speaker 804 can also present a heavy bass sound effect to the user when playing the audio from the mobile phone.
  • the audio playback strategy set by AudioPolicy according to the sound effect parameters of the speaker 804 can avoid the superposition of sound effects caused by both the mobile phone (ie the master device) and the speaker 804 (ie the slave device) performing sound effects on the audio data, and can also avoid the sound effect of the mobile phone. (ie the master device) and the speaker 804 (ie the slave device) both do not perform sound effect processing on the audio data, resulting in the phenomenon of missing sound effects, thereby improving the user's audio experience.
  • the AudioPolicy may also determine the audio playback policy related to the sound effect in combination with the device type of the slave device.
  • the current slave device of the mobile phone is a wearable watch. After the mobile phone establishes a network connection with the wearable watch, the identifier of the wearable watch and the audio capability parameters of the wearable watch can be obtained. The mobile phone can determine that the device type of the current slave device is a wearable device through the identification of the wearable watch. If the audio capability parameter of the wearable watch indicates that the wearable watch has Dolby sound effect enabled, the AudioPolicy of the mobile phone can set the audio data to be played using Dolby sound effect processing in the audio playback policy.
  • AudioFlinger can add Dolby sound effects to the audio data in response to the audio playback strategy, and send the processed audio data to the wearable watch through the corresponding DMSDP Audio HAL.
  • the wearable watch does not need to perform sound effect processing when playing the audio data, which can not only reduce the operating load of the wearable watch with low audio processing capability, but also ensure that the wearable watch can present the audio data when playing the audio data. Produce better Dolby sound effects, thereby improving the user's audio experience.
  • the mobile phone when the music APP is running on the mobile phone, the mobile phone can also call AudioManager to provide the sound effect mode supported by the mobile phone and the sound effect mode supported by the slave device (such as the speaker 804 ) to the music APP, and the music APP can choose which one to use. Play the current audio data in various sound modes.
  • the music APP can display the sound effect modes supported by the mobile phone and the speaker 804 to the user in the form of a list, and the user can manually select the desired sound effect mode.
  • the AudioPolicy can set the mobile phone to not perform sound effect processing on the audio data in the audio playback policy, so that the speaker 804 will respond to the audio data sent by the mobile phone.
  • the sound effects are processed and played.
  • AudioPolicy can set the mobile phone to perform corresponding sound effect processing on the audio data in the audio playback policy, so that the speaker 804 can still present the sound effect required by the user after playing the audio data. .
  • the AudioPolicy can set the mobile phone to not perform sound effect processing on the audio data in the audio playback policy, so that the speaker 804 performs corresponding processing on the audio data sent by the mobile phone. Play after sound processing.
  • the audio capability parameter of the speaker 804 may include the sound production capability (which may be referred to as an audio quality parameter) supported by the speaker 804, for example, the sampling rate supported by the speaker 804 (that is, the The number of samples extracted from the audio signal and composed of discrete signals), the number of sound channels (that is, the number of channels), etc.
  • AudioPolicy obtains the maximum sampling rate supported by the speaker 804 in the above audio capability parameters of 96KHz, and then AudioPolicy can query the current sampling rate of audio data 1 received by AudioFlinger. If the current sampling rate of audio data 1 received by AudioFlinger is greater than 96KHz, AudioPolicy can be set in the audio playback policy to resample audio data 1, and the resampled sampling rate is 96KHz. In this way, after AudioPolicy outputs the audio playback policy to AudioFlinger, AudioFlinger can resample the audio data 1 according to the sampling rate of 96KHz, so that the resampled audio data 1 matches the sound playback capability of the speaker 804 .
  • AudioPolicy obtains that the number of sound channels in the audio capability parameter is 2 channels, and then AudioPolicy can query whether the number of sound channels of audio data 1 currently received by AudioFlinger is 2 channels. If not, AudioPolicy can set the number of sound channels to 2 in the audio playback policy. In this way, after AudioPolicy outputs the audio playback strategy to AudioFlinger, AudioFlinger can mix audio data 1 according to the number of sound channels of 2 channels, so that the mixed audio data 1 matches the sound playback capability of speaker 804.
  • some audio APPs have low-latency playback requirements when playing audio.
  • the K-song application needs to output the accompaniment audio in time to ensure the user's recording experience.
  • a video application needs to output corresponding audio in time when outputting a display screen to ensure a user's viewing experience.
  • the audio capability parameter obtained by the mobile phone from the speaker 804 may also include the audio playback delay (latency) of the speaker 804 .
  • the audio playback delay may specifically refer to the time required for the speaker 804 to process one frame of audio data.
  • audio data is generated in the form of audio streams.
  • continuous audio data can be divided into frame-by-frame audio data according to a certain time unit (also called a certain duration).
  • the audio data in the unit of 2.5ms ⁇ 60ms may be taken as one frame of audio data, and one frame of audio data is the minimum granularity when the device performs audio processing.
  • the AudioPolicy can determine whether the speaker 804 supports the low-latency audio processing capability according to the audio playback delay in the above-mentioned audio capability parameters. For example, when the audio playback delay of the speaker 804 is less than or equal to 5ms (ie, the time required for the speaker 804 to process one frame of audio data is less than or equal to 5ms), it can be determined that the speaker 804 supports the low-latency audio processing capability. Then, AudioPolicy can set the low-latency mode in the audio playback policy, so that AudioFlinger can process audio data 1 in the low-latency mode. Alternatively, the speaker 804 may indicate in the audio capability parameter whether it supports the low-latency audio processing capability.
  • the preset delay parameter field in the audio capability parameter of the speaker 804 is 0, it means that the speaker 804 supports low-latency. extended audio processing capability. At this point, AudioPolicy can set the low-latency mode in the audio playback policy.
  • the preset delay parameter field in the audio capability parameter is 1, it means that the speaker 804 does not support the low-latency audio processing capability. At this point, AudioPolicy can set non-low latency mode in the audio playback policy.
  • the low-latency audio processing capability generally requires the device to have a high processing capability for audio data.
  • AudioFlinger can set the duration of one frame of audio data to 10ms, and AudioFlinger needs to buffer 10 frames of audio data each time to ensure the continuous consistency of audio output. That is to say, the time granularity of processing each frame of audio data by the mobile phone is 10ms, and each time the mobile phone processes the audio data, one cycle is 100ms (10ms*10).
  • AudioFlinger can reduce the duration of one frame of audio data to 5ms, and the mobile phone still needs to store 10 frames of audio data in the cache. Then, in the low-latency mode, the mobile phone processes each frame of audio data.
  • the time granularity is 5ms
  • one cycle of the mobile phone processing audio data is 50ms (5ms*10).
  • AudioFlinger can send audio data 1 to the speaker 804 with a duration of 5ms as one frame of audio data. That is to say, compared with the non-low latency mode, in the low latency mode, the mobile phone can set the duration of each frame of audio data to be smaller, for example, the duration of one frame of audio data is 5ms. Subsequently, the speaker 804 may process each frame of audio data with a time granularity of 5ms according to the low-latency mode, so as to reduce the processing time of each frame of audio data and improve the user's audio experience.
  • the AudioPolicy may also query whether the currently running music APP has a low-latency playback requirement. If the Music APP has low-latency playback requirements, and the speaker 804 supports low-latency playback capability, AudioPolicy can set the low-latency mode in the audio playback policy. If the music APP has low-latency playback requirements, but the speaker 804 does not support the low-latency playback capability, AudioPolicy can minimize the processing flow of audio data 1 in the audio playback strategy. For example, AudioPolicy can be set to not perform sound effect processing on audio data 1. In this way, the delay in sending audio data from the mobile phone to the speaker 804 can be reduced, and the low-latency playback requirements of the audio APP can be met as far as possible.
  • AudioPolicy can set a low-latency mode in the audio playback policy, or set a non-low-latency mode in the audio playback policy, which is not done in this embodiment of the present application. any restrictions.
  • the audio capability parameter of the speaker 804 may include an EQ (Equalizer, equalizer) parameter of the speaker 804 .
  • EQ parameters generally include three parameters: frequency, gain, and quantize. Frequency is used to set the parameters of the frequency point that needs to be adjusted in the audio data; gain is used to adjust the audio data of a certain frequency. Parameter for gain or attenuation; quantize parameter for setting the "width" of the frequency band for gain or attenuation.
  • EQ parameters generally include three parameters: frequency, gain, and quantize. Frequency is used to set the parameters of the frequency point that needs to be adjusted in the audio data; gain is used to adjust the audio data of a certain frequency. Parameter for gain or attenuation; quantize parameter for setting the "width" of the frequency band for gain or attenuation.
  • the AudioPolicy may set the EQ parameters of the audio data 1 to the EQ parameters obtained from the speaker 804 in the audio playback policy.
  • AudioFlinger can adjust the timbre of audio data 1 according to the EQ parameters of the speaker 804, so that the audio data 1 sent by the subsequent mobile phone to the speaker matches the audio playback capability of the speaker 804.
  • the audio capability parameters of the speaker 804 may be stored in the mobile phone.
  • AudioPolicy can save the device name, identification and corresponding audio capability parameters of the slave device obtained by each DV APP in the mobile phone.
  • the identifier may specifically be an identifier that can uniquely identify the device, such as an IMEI (international mobile equipment identity, international mobile equipment identity) or a MAC (Media Access Control) address of the slave device.
  • the audio capability parameters may include sound effect parameters, audio quality parameters, audio playback delay, and EQ parameters.
  • AudioPolicy can not only customize the audio playback policy matching the audio capabilities of the speaker 804 according to the audio capability parameters of the speaker 804 in Table 1, but also later, when the mobile phone uses the speaker 804 as a slave device of the mobile phone to establish a network connection with the mobile phone, the mobile phone By obtaining the identifier of the speaker 804, it can be found in Table 1 whether the audio capability parameter of the speaker 804 is stored. If the audio capability parameter of the speaker 804 is stored, the mobile phone can determine the corresponding audio playback strategy without additionally acquiring the audio capability parameter of the speaker 804, thereby improving the switching speed of the subsequent audio switching process.
  • the above embodiment is described by taking the audio capability parameters of the speaker box 804 obtained by the mobile phone as an example including sound effect parameters, audio quality parameters, audio playback delay and EQ parameters. It can be understood that the above audio capability parameters may also include other parameters. Parameters related to the audio capability of the speaker 804, such as parameters such as signal-to-noise ratio and distortion rate, are not limited in this embodiment of the present application.
  • the AudioPolicy in the mobile phone can customize an audio playback policy that matches the audio capabilities of the speaker 804 according to the audio capability parameters of the speaker 804, so that the speaker 804 (ie the slave device) can play the audio from the phone (ie the master device) that matches its own audio capabilities. audio data.
  • the audio playback policy of the speaker 804 can also be saved. in the phone. As shown in Table 2, AudioPolicy can save the audio playback policy determined for different slave devices in the mobile phone each time. In this way, when the mobile phone uses the speaker 804 as the slave device of the mobile phone to perform audio switching again, the DV APP can find in Table 2 whether the audio playback strategy of the speaker 804 is stored by obtaining the identifier of the speaker 804.
  • the DV APP can directly deliver the audio playback policy of the speaker 804 to AudioPolicy, and the mobile phone does not need to additionally obtain the audio capability parameters of the speaker 804, nor does it need to determine the corresponding audio playback policy again. Improve the switching speed of the subsequent audio switching process.
  • the AudioPolicy of the mobile phone can re-determine the audio playback policy of the speaker 804 according to the latest audio capability parameter of the speaker 804 .
  • the AudioPolicy can update the audio playback policy of the speaker 804 in Table 2 and save it in the mobile phone.
  • the audio playback strategy of the speaker 804 can also be empty, that is, the mobile phone does not need to process the audio data to be sent to the speaker 804 related to the above audio capability parameters.
  • the first device can directly send the audio data from the audio APP to the speaker 804 .
  • the mobile phone can still perform conventional processing operations such as parsing, encoding, decoding, encapsulating or decapsulating the audio data to be sent, which is not limited in this embodiment of the present application.
  • AudioFlinger in the mobile phone processes the audio data 1 according to the audio playback policy output by the AudioPolicy, it can call the DMSDP Audio HAL 1101 to send the processed audio data 1 to the proxy APP of the speaker 804. .
  • AudioFlinger when AudioFlinger sends the audio data 1 to the speaker 804 through the DMSDP Audio HAL 1101, it can also parse, encapsulate or encode the audio data 1 according to certain rules or protocols. These processes are generally related to the speaker 804.
  • the audio capability parameter is not directly related.
  • DMSDP Audio HAL 1101 can pack the audio data 1 output by AudioFlinger into a frame-by-frame data packet, and add the relevant information of the audio data 1 (such as the type of audio data 1, audio format, etc.)
  • the data packet of data 1 is sent to the proxy APP of the speaker 804 together.
  • the proxy APP of the speaker 804 can call its audio player (eg AudioTrack) to send the audio data 1 to the audio processor (eg AudioFlinger) of the speaker 804 .
  • AudioFlinger processes the received audio data 1, and calls the Audio HAL in the HAL to output the processed audio data 1 to the speaker of the speaker 804 for playback, completing the process of switching the audio from the mobile phone to the speaker 804 to continue playing.
  • the slave device for the slave device of the mobile phone (for example, the above-mentioned speaker 804), the slave device only needs to install the above-mentioned proxy APP, and can report the audio capability parameters of the slave device to the mobile phone through the proxy APP, and obtain from the mobile phone and itself.
  • the audio data that matches the audio capability is played, so that the audio function of the master device 101 is flexibly distributed on the slave device 102 for implementation, thereby providing the user with a better audio experience.
  • the mobile phone when the mobile phone successfully switches the audio data 1 of the song A being played to the speaker 804 for playback, if it detects that the currently playing audio data changes, or detects that the audio capability of the slave device has changed, or detects that When the user switches a new slave device, the mobile phone can also dynamically adjust the current audio playback strategy, so that the slave device can play audio data from the mobile phone (ie, the master device) that matches its own audio capability.
  • the mobile phone switches the audio data 1 of the currently playing song A to the speaker 804, the mobile phone is still running the music APP.
  • the user can modify the playback volume of the audio data 1 on the speaker 804 through the volume button of the mobile phone.
  • multiple types of audio streams are predefined in the audio architecture of the Android system.
  • the types of audio streams include STREAM_ALARM (alarm), STREAM_MUSIC (music), STREAM_RING (ringtone), STREAM_SYSTEM (system), STREAM_VOICE_CALL (call), and so on.
  • a volume adjustment control 1302 can be displayed.
  • the mobile phone can call AudioManager to reset the volume according to the audio stream type of STREAM_MUSIC in AudioPolicy.
  • the mobile phone can call AudioManager to multiply the current volume of audio data 1 by a preset volume coefficient in AudioPolicy to obtain the adjusted volume.
  • AudioPolicy can multiply the current volume (for example, 100) by the volume coefficient of 120% to obtain an adjusted volume of 120.
  • AudioPolicy can multiply the current volume (for example, 100) by a volume coefficient of 80% to obtain an adjusted volume of 80.
  • AudioPolicy can output the adjusted volume to AudioFlinger, and AudioFlinger processes audio data 1 according to the adjusted volume.
  • AudioFlinger can call the stream volume() function to modify the gain of audio data 1, thereby modifying the volume of audio data 1. Furthermore, AudioFlinger can call DMSDP Audio HAL 1101 to send the processed audio data 1 to the speaker 804, and the audio data 1 played by the speaker 804 is the audio data after volume adjustment. In this way, after switching the audio in the mobile phone to the speaker 804, the user can also conveniently control the volume of the audio played on the speaker 804 through the mobile phone.
  • the mobile phone after the mobile phone switches the audio data 1 of the currently playing song A to the speaker 804, the mobile phone is still running the music APP.
  • the music APP can also modify the sound effect mode of the song A being played.
  • the user can modify the sound effect mode of song A from subwoofer sound effect 1402 to ballad sound effect 1403 in the setting menu 1401 of the music APP.
  • the music APP detects that the user clicks the folk sound effect 1403 in the setting menu 1401, it can call the AudioManager to modify the sound effect mode of the audio data 1 being played on the mobile phone in the AudioPolicy.
  • the AudioPolicy can find out whether the speaker 804 currently supports the playing mode of folk sound effects according to the audio capability parameter obtained from the speaker 804 . If the speaker 804 does not support the play mode of folk sound effects, the AudioPolicy can update the current audio playback policy, and set the use of folk sound effects to process audio data 1 in the audio playback policy. In this way, after AudioPolicy outputs the audio playback strategy to AudioFlinger, AudioFlinger can process the folk sound effect on the audio data 1. Subsequently, after AudioFlinger calls DMSDP Audio HAL 1101 to send the processed audio data 1 to the speaker 804, the audio data 1 played by the speaker 804 can present a folk sound effect to the user.
  • the AudioPolicy can also update the current audio playing strategy, and set the audio data 1 not to be processed with folk sound effects in the audio playing strategy. In this way, after AudioPolicy outputs the audio playback policy to AudioFlinger, AudioFlinger does not need to process the folk sound effect on the audio data 1. Subsequently, AudioFlinger calls DMSDP Audio HAL 1101 to send the processed audio data 1 to the speaker 804, and the speaker 804 can process the audio data 1 with folk sound effects and play it, which can also present folk sound effects for the user.
  • the mobile phone may also identify devices corresponding to various sound effect modes in the setting menu 1401 of the music APP.
  • both the mobile phone and the speaker 804 support subwoofer and Dolby sound.
  • Folk sound effects are only supported by mobile phones, and Histen sound effects are only supported by speaker 804.
  • the user can intuitively know the sound effect modes supported by the current master device and the slave device, so as to select a corresponding sound effect mode for the audio data 1 .
  • the AudioPolicy of the mobile phone can update the current audio playback policy, and in the audio playback policy, the mobile phone is set to not perform audio processing on the audio data 1, and the speaker 804 can follow it later.
  • the audio data 1 is processed with Histen sound effect and played.
  • the Sound effect mode selected by the user is only supported by the mobile phone (for example, the folk sound effect)
  • the AudioPolicy of the mobile phone can update the current audio playback strategy. After the data 1 is sent to the speaker 804, the audio data 1 played by the speaker 804 can present a folk sound effect to the user.
  • the mobile phone can use the Dolby sound effect to process the audio data 1 by default in the audio playback policy of the mobile phone (or the speaker 804 ).
  • the mobile phone can also prompt the user to choose to use the Dolby sound provided by the mobile phone or the Dolby sound provided by the speaker 804 to process the audio data by displaying a dialog box.
  • the mobile phone can set the audio data 1 to be processed by the mobile phone or the speaker 804 in the audio playback policy according to the user's selection.
  • the mobile phone may also display the sound effect modes supported by other audio output devices to the user. For example, if the phone uses the TV as a slave device for audio switching, the phone can acquire one or more sound modes supported by the TV. The phone can save one or more sound modes supported by the TV. When the mobile phone uses the speaker 804 as a slave device to perform audio switching, one or more sound effects modes supported by the TV can also be displayed in the above-mentioned setting menu 1401 .
  • the mobile phone can disconnect the network connection with the speaker 804, and use the TV as a slave device to communicate with the TV again. Establish a network connection. Furthermore, the mobile phone can output the audio data to the TV, and the TV can process and play the audio data according to the audio effect mode selected by the user. Of course, before the mobile phone replaces the slave device, the user can also be asked through a dialog box whether to update the slave device from the speaker 804 to the TV. If the user confirms to update the slave device of the mobile phone to the TV, the mobile phone can disconnect the network connection with the speaker 804 and establish a network connection with the TV.
  • the mobile phone after the mobile phone switches the audio data 1 of the running music APP to the speaker 804, if the mobile phone exits the music APP, the mobile phone can end the audio switching. At this time, AudioFlinger in the mobile phone can stop calling DMSDP Audio HAL 1101 to send the audio data generated by the subsequent mobile phone to the speaker 804, but call the Primary HAL in the HAL to output the audio data generated by the subsequent mobile phone to the speaker of the mobile phone for playback.
  • the mobile phone can continue to send the audio data generated by the mobile phone to the speaker 804 for playback, that is, the audio switching is not over.
  • the mobile phone can display the communication with the contact Mike. call interface 1501.
  • the communication APP can call AudioTrack to send the audio data 2 from the contact Mike to AudioFlinger. AudioFlinger can process audio data 2 according to the audio playback policy output by AudioPolicy, and call DMSDP Audio HAL 1101 to send the processed audio data 2 to speaker 804 for playback.
  • the mobile phone runs the communication APP
  • the user's voice needs to be recorded, and the user's voice is sent to the contact Mike.
  • the mobile phone can also send a recording instruction to the speaker 804 (ie, the slave device), so that the speaker 804 can respond to the recording instruction to enable its own audio recording function to collect the audio data input by the user, and record the collected audio data. sent to the phone.
  • the mobile phone can also switch the audio input function to other slave devices for implementation.
  • the mobile phone collects the audio data input by the user through the speaker 804, so as to realize the specific process of the audio input function, please refer to the relevant description of FIG. 26, so it will not be repeated here.
  • the communication APP can call AudioManager to register the relevant information of the audio data 2 in the AudioPolicy.
  • the communication APP may cache information such as the current sound effect mode, the number of channels, the sampling rate, and the volume of the audio data 2 in the AudioPolicy.
  • the AudioPolicy can update the corresponding audio playback policy according to the relevant information of the audio data 2 and the audio capability parameter of the speaker 804 .
  • the AudioPolicy can indicate in the updated audio playback policy to use the 8-channel audio data.
  • the audio data is converted into 4-channel audio data, so that the converted audio data 2 matches the sound playback capability of the speaker 804 .
  • the type of audio data 2 output by the communication APP is STREAM_VOICE_CALL, and the speaker 804 only supports audio streams of the STREAM_MUSIC type. Then, the AudioPolicy may instruct the mobile phone to play the above-mentioned audio data 2 in the updated audio playing policy.
  • AudioFlinger can call the Primary HAL according to the updated audio playback policy, and use the Primary HAL to output the audio data 2 to the speaker of the mobile phone for playback. That is to say, in the process of audio switching, if the audio data output by the mobile phone changes, the mobile phone can also be triggered to re-customize an audio playback strategy that matches the audio capability of the slave device.
  • the mobile phone can receive audio data 3 sent by the peer device (such as another mobile phone) through a network device such as a base station when running the call APP. Different from the general audio APP, the mobile phone can Receive audio data 3 directly through the HAL's modem HAL, without the need to process audio data 3 through AudioTrack and AudioFlinger.
  • the peer device such as another mobile phone
  • a network device such as a base station
  • the mobile phone can Receive audio data 3 directly through the HAL's modem HAL, without the need to process audio data 3 through AudioTrack and AudioFlinger.
  • the DV APP creates a DMSDP Audio HAL 1101 according to the audio capability parameters of the speaker 804, and after registering the audio capability parameters of the speaker 804 in the AudioPolicy, the AudioPolicy can indicate to the modem HAL the current
  • the output device of the audio data is the speaker 804 corresponding to the DMSDP Audio HAL 1101.
  • the modem HAL receives the audio data 3, it can send the audio data 3 to the DMSDP Audio HAL 1101, and the DMSDP Audio HAL 1101 sends the audio data 3 to the speaker 804 for playback, realizing the audio switching function in the call scene.
  • the speaker 804 can dynamically report the latest audio capability parameters to the DV APP of the mobile phone. Furthermore, the DV APP can update the DMSDP Audio HAL 1101 according to the latest audio capability parameters of the speaker 804, and update the audio capability parameters of the registered speaker 804 in the AudioPolicy.
  • the audio playback delay of the speaker 804 will increase accordingly.
  • the speaker 804 can report the latest audio playback delay to the DV APP of the mobile phone.
  • the DV APP can update the DMSDP Audio HAL 1101 in the HAL according to the latest audio playback delay.
  • the DV APP can update the audio playback delay of the speaker 804 in the AudioPolicy. If the updated audio playback delay is longer than the preset time (for example, 20ms), the AudioPolicy may determine that the speaker 804 does not support the low-latency playback capability at this time.
  • AudioPolicy can update the audio playback policy, and set a non-low latency mode in the updated audio playback policy, so that AudioFlinger processes audio data 1 according to the non-low latency mode. That is to say, when the audio capability of the slave device changes, the mobile phone can also be triggered to re-customize an audio playback strategy that matches the audio capability of the slave device.
  • the user can also manually modify the slave device currently performing audio switching with the mobile phone on the mobile phone.
  • the mobile phone continues to display the application interface 1701 of the music APP after switching the audio data 1 to the speaker 804.
  • the user may input a pull-up operation in the application interface 1701, and in response to the user's pull-up operation, the mobile phone may display the control center 1702.
  • the control center 1702 includes a switch button 1703 for the audio switch function.
  • the switch button 1703 can click the switch button 1703 to query one or more candidate devices that can currently be the slave device of the mobile phone.
  • the mobile phone can detect the candidate devices that are located in the same Wi-Fi network as the mobile phone and have the audio output function, and display the detected candidate devices in the Control Center 1702.
  • the control center 1702 may include a speaker 804 currently connected with the mobile phone, may also include the mobile phone 1704, and may also include a TV 803 and an earphone 805 detected by the mobile phone that have not established a network connection with the mobile phone.
  • the speaker 804 has been displayed in a selected state, indicating to the user that the audio currently output by the mobile phone has been switched to the speaker 804 for playback.
  • the DV APP can disconnect the network connection with the speaker 804, and the mobile phone can establish a network connection with the TV 803 using the TV 803 as the current slave device of the mobile phone.
  • the DV APP can use the TV 803 as the latest slave device of the mobile phone, and obtain the audio capability parameters of the TV 803 from the TV 803 '. Further, as shown in FIG.
  • the DV APP can call the relevant interface according to the audio capability parameter' to create a DMSDP Audio HAL 1801 corresponding to the TV 803, and close the process of the DMSDP Audio HAL 1101 created for the speaker 803.
  • the DV APP can update the DMSDP Audio HAL 1101 according to the audio capability parameters of the TV 803 , so that the updated DMSDP Audio HAL 1101 matches the audio capability of the TV 803 .
  • the DV APP can call AudioManager to register the audio capability of the TV 803 in the AudioPolicy.
  • the DV APP may send the identification of the TV 803 and the audio capability parameter' of the TV 803 to AudioPolicy.
  • the AudioPolicy can set a new audio playback policy according to the audio capability parameters of the TV 803, and output the set new audio playback policy to AudioFlinger.
  • AudioFlinger can process the audio data 1 output by the music APP according to the new audio playback policy output by AudioPolicy.
  • AudioFlinger can call the newly created DMSDP Audio HAL 1801, and send the processed audio data 1 to the TV 803, thereby switching the audio function of the mobile phone from the speaker 804 to the TV 803.
  • the user wants to switch the audio output from the mobile phone to the earphone 805 for playback, he can click the earphone 805 in the above-mentioned control center 1702 .
  • the Audio HAL corresponding to the headset 805 has been set in the existing Android system, such as A2dp HAL. Therefore, after the mobile phone detects that the user clicks on the headset 805 in the control center 1702, the mobile phone can disconnect the network connection with the speaker 804, and AudioFlinger calls A2dp HAL according to the existing audio architecture to output the audio data 1 of the music APP to the headset 805 , thereby switching the audio function of the mobile phone from the speaker 804 to the earphone 805 .
  • the DV APP when the mobile phone performs audio switching, the DV APP may not create a corresponding DMSDP Audio HAL in the HAL. Still taking the mobile phone's slave device as the TV 803 as an example, as shown in Figure 18B, after the DV APP of the mobile phone obtains the audio capability parameters of the TV 2003, it can register the audio capability parameters of the TV 2003 in the AudioPolicy, without creating the corresponding HAL. DMSDP Audio HAL. Then, after the AudioPolicy outputs the corresponding audio playback policy to AudioFlinger according to the audio capability parameters of the TV 2003, AudioFlinger can process the audio data 1 from the music APP according to the audio playback policy.
  • AudioFlinger can send the processed audio data 1 to the proxy APP in the application layer of the mobile phone, and the proxy APP sends the processed audio data 1 to the TV 2003 for playback.
  • the proxy APP in the mobile phone may also run in the mobile phone in the form of a system service, which is not limited in this embodiment of the present application.
  • the proxy APP in the mobile phone can send the processed audio data 1 to the proxy APP in the TV 2003, and the proxy APP in the TV 2003 can call its audio player (eg AudioTrack) to convert the audio data 1 from the mobile phone.
  • the above-mentioned embodiment is exemplified by the user switching the audio output device of the mobile phone from the control center of the mobile phone or the audio application that the mobile phone is running. other location of the phone.
  • the mobile phone may display the above-mentioned switch button 1703 in the pull-down menu 1901.
  • the mobile phone may also prompt the user in the form of a notification in the notification center 1902 of the pull-down menu 1901 that the audio of the current mobile phone is switched to a certain device for playback.
  • the mobile phone may also display the above-mentioned switch button 1703 in the negative one-screen menu 1903 , which is not limited in this embodiment of the present application.
  • the above embodiment takes the music APP as an example of the audio APP, and specifically describes the process of switching the audio data 1 in the music APP to the slave device to perform audio switching, and dynamically modifying the audio playback strategy during the audio switching process.
  • the user may need to switch the audio and images on the mobile phone to play on other devices at the same time. For example, when a mobile phone runs a video APP to play a video, the user may need to switch each frame of image in the video and the audio corresponding to the image to the TV for playback at the same time.
  • the mobile phone can send the display data output by the display screen in real time to the TV through the Miracast screen projection method, and at the same time, the mobile phone can send the audio data output by AudioFlinger in real time to the TV, so as to project the image and audio on the mobile phone to the TV for playback.
  • the mobile phone can send the URL (Uniform Resource Locator) of the video to the TV through the screen projection method of DLNA (digital living network alliance), and the TV can obtain the corresponding image according to the URL. and audio to play.
  • URL Uniform Resource Locator
  • the control center 2001 of the mobile phone can be opened.
  • a card 2002 can be set in the control center 2001, and the card 2002 is used to display one or more nearby devices detected by the mobile phone.
  • the mobile phone can display detected electronic devices located in the same Wi-Fi network as the mobile phone in the card 2002 for the user to select.
  • the mobile phone can display multiple electronic devices bound to the same account (such as a Huawei account) with the mobile phone on the card 2002.
  • the mobile phone If the mobile phone detects that an electronic device is connected to the Wi-Fi network where the mobile phone is located, the mobile phone can The electronic device is lit in the card 2002, thereby prompting the user that the electronic device can be used as a slave device of the mobile phone to realize the screen projection function.
  • the mobile phone can establish a network connection with the TV 2003, and, as shown in FIG. 21, the mobile phone can send the display data output by the video APP in the mobile phone to the TV 2003 for display according to the existing screen projection method.
  • the mobile phone can switch the audio data in the mobile phone to the TV 2003 according to the audio switching process in the above embodiment, instead of switching the audio data to the TV 2003 according to the screen projection method of DLNA or Miracast.
  • the mobile phone can send the display data output by the video APP to the TV 2003 .
  • the DV APP of the mobile phone can obtain the audio capability parameters of the TV 2003 from the TV 2003.
  • the DV APP can create a DMSDP Audio HAL2101 corresponding to the TV 2003 in the HAL according to the audio capability parameters of the TV 2003, and register the audio capability parameters of the TV 2003 in the AudioPolicy.
  • the AudioPolicy can set an audio playback policy that matches the audio capability of the TV 2003 during the projection process according to the audio capability parameters of the TV 2003, and output the audio playback policy to AudioFlinger.
  • AudioFlinger can process the audio data generated by the video APP according to the audio playback strategy, and call DMSDP Audio HAL2101 to send the processed audio data to TV 2003 for playback.
  • AudioFlinger can also send the processed audio data to a video APP, and the video APP sends the audio data to the TV 2003 for playback, which is not limited in this embodiment of the present application.
  • a time stamp can also be added to the audio data.
  • the mobile phone sends the display data from the video APP to the TV 2003, a time stamp can also be added to the display data.
  • the TV 2003 can play the video with the picture synchronized with the audio according to the time stamp in the display data and the time stamp of the audio data, so that the audio played by the TV 2003 is synchronized with the picture during the screen projection process.
  • the audio data output by AudioFlinger in real time is directly sent to the slave device (such as TV 2003), in the screen projection method provided by the embodiment of the present application, the mobile phone obtains the audio capability of the slave device by obtaining the audio capability.
  • the parameters can customize the audio playback strategy that matches the audio capability of the slave device, so that AudioFlinger can output the corresponding audio data according to the audio playback strategy and send it to the slave device. (that is, the main device) audio data, which improves the audio playback effect in the screen projection scene.
  • the mobile phone switches the audio data to a certain slave device to realize the audio switching function as an example.
  • the mobile phone can also switch the audio data to multiple slave devices to perform audio switching. .
  • the mobile phone running the music APP as an example, as shown in (a) in FIG. 8 , if it is detected that the user clicks the switch button 801 in the music APP, the mobile phone can be triggered to search for one or more nearby audio switches that can be switched. candidate device.
  • the difference from the above embodiment is that, as shown in FIG. 22 , after the mobile phone displays multiple candidate devices searched by the mobile phone in the menu 2201, the user can select multiple slave devices that simultaneously serve as the mobile phone from these candidate devices to perform audio recording. switch.
  • the mobile phone can establish a network connection with the first speaker 2202 and the second speaker 2203 respectively. Furthermore, as shown in FIG. 23 , the mobile phone can obtain the audio capability parameters of the first speaker 2202 and the second speaker 2203 respectively through the DV APP.
  • the audio capability parameter of the first speaker 2202 is audio capability parameter 1
  • the audio capability parameter of the second speaker 2203 is audio capability parameter 2.
  • the DV APP can register the audio capability parameter 1 of the first speaker 2202 and the audio capability parameter 2 of the second speaker 2203 in the AudioPolicy.
  • the DV APP can create a DMSDP Audio HAL 2301 corresponding to the first speaker 2202 in the HAL according to the audio capability parameter 1, and create a DMSDP Audio HAL 2302 corresponding to the second speaker 2203 according to the audio capability parameter 2.
  • the AudioPolicy can set the audio playback policy according to the audio capability parameter 1 of the first speaker 2202 and the audio capability parameter 2 of the second speaker 2203, so that AudioFlinger can process the audio data from the music APP according to the audio playback policy determined by the AudioPolicy.
  • the audio playback policy determined by AudioPolicy may include audio playback policy 1 corresponding to the first speaker 2202 and audio playback policy 2 corresponding to the second speaker 2203 .
  • the process in which AudioPolicy determines the audio playback strategy 1 according to the audio capability parameter 1 of the first speaker 2202 is similar to the process in which AudioPolicy determines the audio playback strategy according to the audio capability parameter of the speaker 803 in the above-mentioned embodiment.
  • the process of determining the audio playback strategy 2 by the audio capability parameter 2 of the audio capability parameter 2 is also similar to the process in which AudioPolicy determines the audio playback strategy according to the audio capability parameter of the speaker 803 in the above-mentioned embodiment, so it will not be repeated here.
  • AudioPolicy can instruct AudioFlinger to copy the audio data 1 from the music APP into 2 copies, for example, audio data 11 and audio data 12.
  • AudioFlinger can process audio data 11 according to audio playback policy 1 to obtain audio data matching the audio capability of the first speaker 2202 .
  • AudioPolicy outputs audio playback policy 2 to AudioFlinger
  • AudioFlinger can process audio data 12 according to audio playback policy 2 to obtain audio data matching the audio capability of the second speaker 2203 .
  • AudioFlinger can call DMSDP Audio HAL 2301 to send the processed audio data 11 to the first speaker 2202 for playback.
  • AudioFlinger can call DMSDP Audio HAL 2302 to send the processed audio data 12 to the first speaker 2202. Two speakers 2203 play.
  • the mobile phone can switch its own audio playback function to multiple slave devices at the same time, so as to realize the distributed audio capability across the devices.
  • the AudioPolicy can also customize a corresponding audio playback policy in combination with information such as the audio capability or the location of each slave device.
  • the first speaker 2202 and the second speaker 2203 may also carry their own location information in their reported audio capability parameters.
  • the placement position of the first speaker 2202 is located on the left side of the user relative to the user, and the placement position of the second speaker box 2203 is located on the user's right side relative to the user.
  • the AudioPolicy can set in the audio playback policy 1 to process the audio data 11 according to the left channel sound effect, and set the audio playback policy 2 to process the audio data 12 according to the right channel sound effect.
  • AudioFlinger calls the corresponding DMSDP Audio HAL to send the processed audio data 11 and audio data 12 to the first speaker 2202 and the second speaker 2203 respectively for playback, it can present a stereo playback effect to the user.
  • AudioPolicy can combine the audio capability parameters reported by the TV and the speakers to determine that the sound processing capability of the speakers is stronger than that of the TV. Then, AudioPolicy can be set in the audio playback policy to output the audio data that needs sound effect processing to the speaker for playback, and output the audio data that does not need sound effect processing to the TV for playback. Furthermore, AudioFlinger can split the audio data from the audio APP according to the audio playback policy output by the AudioPolicy, and obtain audio data A that needs to be processed with sound effects and audio data B that does not need to be processed with sound effects.
  • AudioFlinger can call the DMSDP Audio HAL corresponding to the speaker to send the processed audio data A to the speaker for playback, and call the DMSDP Audio HAL corresponding to the TV to send the processed audio data B to the TV for playback.
  • the DV APP can create a DMSDP Audio HAL 2401 corresponding to the audio capability parameter 1 (that is, the audio capability parameter 2) in the HAL. That is to say, the DMSDP Audio HAL created by the DV APP in the HAL corresponds to the audio capability parameters. Since the audio capability parameter 1 of the first speaker 2202 and the audio capability parameter 2 of the second speaker 2203 are the same, the audio playback policy determined by the AudioPolicy according to the audio capability parameter is also the same.
  • AudioPolicy can output the determined audio playback policy to AudioFlinger, and AudioFlinger processes the audio data from the audio APP according to the audio playback policy.
  • AudioFlinger can divide the processed audio data into two parts. For example, AudioFlinger can copy the processed audio data 1 to obtain audio data 11' and audio data 12' (the audio data 11' and audio data 12' at this time. 12' is the same). Alternatively, AudioFlinger can extract the audio data 11' corresponding to the left channel and the audio data 12' corresponding to the right channel from the processed audio data 1 (the audio data 11' and the audio data 12' are different at this time). Furthermore, AudioFlinger can call DMSDP Audio HAL 2401 to send audio data 11' and audio data 12' to the first speaker 2202 and the second speaker 2203 respectively, so as to realize the distributed audio capability across devices.
  • the mobile phone switches its own audio data to one or more slave devices to play.
  • the mobile phone creates a DMSDP Audio HAL by acquiring the audio capability of the TV, and the audio data from the audio APP is passed through the DMSDP Audio HAL. HAL switches to play on the TV.
  • the TV is a slave device of the mobile phone.
  • the slave device eg, a TV
  • the slave device of the mobile phone can also switch the corresponding audio data to other devices to perform audio switching when playing audio.
  • the slave device of the mobile phone can be used as the master device, and according to the audio switching method in the above embodiment, the audio data sent by the mobile phone is switched to other slave devices for playback again, so as to realize the continuous audio switching function between multi-level devices.
  • the TV 2501 can obtain the audio capability parameters of the speaker 2502, thereby creating a corresponding DMSDP Audio HAL.
  • the speaker 2502 can play the audio data from the TV 2501 as a slave device of the TV 2501 .
  • the TV 2501 can act as the main device to set the corresponding audio playback strategy according to the audio capability parameter of the speaker 2502, and process the audio data sent by the mobile phone according to the audio playback strategy.
  • the TV 2501 can call the DMSDP Audio HAL corresponding to the speaker 2502 to send the audio data to the speaker 2502 for playback.
  • the mobile phone finally switches the audio data to the speaker 2502 for playback, and the speaker 2502 can play audio data that matches its own audio capabilities.
  • the audio playback process is managed and controlled, so as to provide users with a better audio experience.
  • the mobile phone when the mobile phone obtains the audio capability parameters of the TV 2501, if the TV 2501 has established a Bluetooth connection with the speaker 2502, that is, the audio output device of the TV 2501 is the speaker 2502, then the TV 2501 can directly transfer the audio capability parameters of the speaker 2502 Report to the phone. In this way, the mobile phone can directly customize the corresponding audio playback strategy according to the audio capability parameters of the speaker 2502, process the audio data according to the audio playback strategy and send it to the TV 2501, and then the TV 2501 transparently transmits the audio data sent by the mobile phone to the speaker 2502 play.
  • the mobile phone can directly establish a network connection with the speaker 2502 and obtain the audio capability parameters of the speaker 2502 from the speaker 2502 .
  • the mobile phone can also directly customize the corresponding audio playback strategy according to the audio capability parameters of the speaker 2502, and process the audio data according to the audio playback strategy and send it to the speaker 2502 for playback, without the need for the TV 2501 to transparently transmit the audio data sent by the mobile phone.
  • the mobile phone switches the audio data to one or more slave devices to play as an example, that is, the audio output function of the mobile phone is distributed to one or more slave devices.
  • the audio input function (which may also be referred to as an audio recording or recording function) may be distributed among one or more slave devices. That is, the phone can use one or more of the recording functions of the slave device to input audio data and send the input audio data to the phone.
  • the audio capability parameters obtained by the mobile phone from the slave device include the audio playback capability of the slave device (such as sound effect parameters, audio quality parameters, or audio playback delay, etc.). ) and can also include the ability to record audio from the device.
  • the audio capability parameters of the speaker may include playback parameters and recording parameters.
  • the playback parameters may specifically include the sound effect parameters, audio quality parameters, or audio playback delay described in the above embodiments, and the playback parameters are used to reflect the audio output capability of the speaker;
  • the recording parameters may specifically include the sampling rate and the audio output supported by the device. Voice algorithm, etc.
  • the recording parameters are used to reflect the audio input capability of the speaker.
  • the 3A algorithm in the speech algorithm may specifically include AEC (acoustic echo canceling, echo cancellation) algorithm, AGC (automatic gain control, automatic gain control) algorithm and ANC (active noise control, active noise reduction) algorithm, used to improve recording The audio quality of the audio.
  • the mobile phone when running the communication APP, it is necessary to play the audio data from the contact, and also need to record the audio data input by the user and send it to the contact. Then, in the process of running the communication APP, if the user chooses to switch the audio function of the mobile phone to the speaker, as shown in FIG. 27, the mobile phone can display a prompt 2602 when running the communication APP, which is used to prompt the user to use the speaker and the speaker of the speaker. Microphone playback, recording sound. Also, as shown in FIG. 26 , the mobile phone can establish a network connection with the speaker and obtain the audio capability parameters of the speaker.
  • the audio capability parameters may include playback parameters and recording parameters as shown in Table 2.
  • the DV APP can create a DMSDP Audio HAL 2601 in the HAL according to the audio capability parameter.
  • the created DMSDP Audio HAL 2601 can support not only sending audio data to speakers, but also receiving audio data recorded by speakers.
  • AudioPolicy can customize the corresponding audio playback strategy according to the playback parameters in the audio capability parameters.
  • AudioPolicy can customize the corresponding audio recording strategy according to the recording parameters in the audio capability parameters. .
  • the audio capability parameters reported by the slave device do not include recording parameters, it means that the slave device does not have the audio recording capability.
  • the application examples do not impose any limitation on this.
  • the mobile phone can display the first button 2801 corresponding to the audio output capability and the audio input capability in the control center The corresponding second button 2802.
  • the user can control the switching of the audio output and input functions of the mobile phone on the slave device through the first button 2801 and the second button 2802 respectively. For example, if it is detected that the user clicks the first button 2801, as shown in (b) of FIG.
  • the mobile phone can display a device list 2803 of candidate devices with audio output function, wherein the current audio output device of the mobile phone is a speaker.
  • the user can switch the audio output device of the mobile phone in the device list 2803 .
  • the mobile phone can display a device list 2804 of candidate devices with audio input function, wherein the current audio input device of the mobile phone is also a speaker .
  • the user can switch the audio input device of the mobile phone in the device list 2804 . In this way, the user can switch the audio output and input capabilities of the mobile phone to corresponding devices according to their own needs, and control the audio output and input functions of the mobile phone separately, thereby improving the user's audio experience.
  • the AudioPolicy can set the audio recording policy according to the sampling rate and the voice algorithm in the foregoing recording parameters. For example, if the speaker supports a 16KHz sampling rate when recording audio data 1, AudioPolicy can be set in the audio recording policy to sample audio data 1 at a 16KHz sampling rate. For another example, if the speaker supports the 3A algorithm when recording audio data 1, AudioPolicy can set the audio recording policy to not use the 3A algorithm to process the audio data 1, so as to avoid the mobile phone and the speaker from repeatedly using the 3A algorithm to process the recorded audio data 1.
  • the audio recording strategy can be output to AudioFlinger, and AudioFlinger can receive the audio data recorded from the speaker by calling DMSDP Audio HAL 2601.
  • the speaker can record audio data 4 through hardware devices such as microphones in the hardware layer, and output the recorded audio data 4 to the AudioFlinger of the speaker for processing through AudioHAL, for example, using the 3A algorithm for processing. Audio data 4.
  • AudioFlinger can output the processed audio data 4 to the audio recorder (AudioRecord) of the speaker, and AudioRecord reports the recorded audio data 4 to the proxy APP installed in the speaker, and finally the proxy APP sends the recorded audio data 4 to the phone.
  • the mobile phone After the mobile phone receives the audio data 4 from the speaker, it can output the audio data 4 to the AudioFlinger of the mobile phone through DMSDP Audio HAL 2601. At this time, AudioFlinger can process the audio data 4 according to the audio recording policy output by the AudioPolicy, so that the processed audio data 4 matches the audio recording capability of the speaker. Subsequently, AudioFlinger can output the processed audio data 4 to the communication APP through an audio recorder (AudioRecord). At the same time, the audio data generated when the communication APP is running can also be switched to be played on the speaker according to the audio switching method in the above embodiment. In this way, the mobile phone can flexibly switch its own audio input and output functions to other slave devices in combination with the audio capabilities of the slave devices, so as to realize a distributed audio architecture across devices.
  • AudioFlinger can process the audio data 4 according to the audio recording policy output by the AudioPolicy, so that the processed audio data 4 matches the audio recording capability of the speaker.
  • AudioFlinger can output the processed audio data 4 to the
  • the mobile phone can also record audio data through multiple slave devices.
  • the slave device of the mobile phone may include a speaker 2701 and a speaker 2702, and both the speaker 2701 and the speaker 2702 have a recording function. Then, after the DV APP of the mobile phone obtains the audio capability parameters of the speaker 2701 and the speaker 2702, it can create the corresponding DMSDP Audio HAL 2703 and DMSDP Audio HAL 2704 in the HAL.
  • the DV APP can register the audio capability parameters of the speaker 2701 and the speaker 2702 in the AudioPolicy, so that the AudioPolicy can determine the audio recording strategy according to the audio capability parameters of the speaker 2701 and the speaker 2702.
  • the audio recording strategy may instruct AudioFlinger to mix the audio data collected by the speaker 2701 and the speaker 2702 respectively, so as to achieve a stereo sound mixing effect.
  • AudioFlinger can record audio data 5 and audio data according to the audio recording policy output by AudioPolicy. 6 for mixing processing.
  • AudioFlinger can use audio data 5 as left channel data after filtering out noise and echo in audio data 5
  • AudioFlinger can use audio data 6 as right channel data after filtering out noise and echo in audio data 6
  • AudioFlinger can combine left channel data and right channel data into one audio file.
  • AudioFlinger can output the combined audio files to the communication APP through the audio recorder (AudioRecord), so that the audio finally obtained by the communication APP can restore the real voice of the user as much as possible.
  • the mobile phone can also dynamically adjust the current audio recording policy. In this way, the mobile phone can dynamically adjust the audio recording strategy to control the audio recording process of the slave device, thereby providing the user with a better audio experience.
  • master devices can interact with slave devices for different types of audio data.
  • the songs played by the mobile phone when running the music APP are MUSIC (music) audio data
  • the short message prompt tone played when the mobile phone receives a short message is the NOTIFICATION (notification) type audio data.
  • the mobile phone is connected to a slave device (such as a speaker)
  • the mobile phone can send the audio data of the MUSIC type being played to the speaker for playback.
  • the mobile phone can also send the audio data of NOTIFICATION type to the speaker for playback. In this way, the user will be disturbed by the short message sound when listening to music using the speaker, which reduces the user's audio experience.
  • different types of audio data may be defined according to the service functions specifically implemented by the audio data.
  • the audio data received by the mobile phone in the call service and sent by the opposite end to realize the call function can be defined as the call audio; for example, the audio data generated by the mobile phone in the audio or video service to realize the audio and video playback function can be defined as the media
  • the audio data generated by the mobile phone to realize the navigation function in the navigation service can be defined as the navigation sound; for example, the audio data generated when the user clicks the button when the mobile phone realizes the button function can be defined as the button tone.
  • One or more types of audio data may be generated or received in an application.
  • the WeChat APP may generate audio data of the media tone type when playing a song
  • the audio data received by the WeChat APP during the audio call service is the audio data of the call tone type.
  • the types of audio data can be divided into: ALARM (alarm), MUSIC (music), RING (ringtone), SYSTEM (system), NOTIFICATION (notification), DTMF ( Dual-tone multi-frequency), COMMUNICATION (communication) and VOICE_CALL (call) and other types.
  • the mobile phone can control different types of audio data separately.
  • the setting application of the mobile phone may provide the user with the option of setting the volume of each type of audio data in the sound setting interface 3001 .
  • the setting interface 3001 may include a volume adjustment slider 3002 corresponding to the type of MUSIC (music).
  • the user can set the volume of the MUSIC (music) type audio data by sliding the volume adjustment slider 3002 .
  • the user can also set the volume of audio data of types such as NOTIFICATION (notification), ALARM (alarm), and VOICE_CALL (call) in the setting interface 3001 .
  • NOTIFICATION notification
  • ALARM alarm
  • VOICE_CALL call
  • audio data usually exists in the form of a data stream
  • the type of audio data can be referred to as the type of audio stream.
  • the audio data of the type of RING can also be represented as STREAM_RING (ringtone stream).
  • STREAM_RING ringtone stream
  • the mobile phone can shunt different audio data according to the set device selection strategy. For example, it can be preset in the device selection policy that the audio data of the RING type can be played simultaneously by the connected earphone and the speaker of the local machine, and the audio data of the MUSIC type is preferentially played by the earphone.
  • the mobile phone can send the MUSIC type audio data to the headset for playback according to the above device selection strategy. If the phone receives a call from a contact, the phone needs to play a ringtone of the RING type. At this time, the mobile phone can send the ringtone of the RING type to the earphone and the speaker of the local machine at the same time according to the above-mentioned device selection strategy, and the ringtone of the ring type can be played by the earphone and the speaker of the local machine at the same time.
  • the mobile phone as the master device can switch the generated audio data to one or more slave devices for playback.
  • the mobile phone can set a corresponding device selection strategy for different types of audio data in combination with the device characteristics of the current slave device, so as to perform streaming according to the device selection strategy during audio switching.
  • the speaker can be set in the device selection policy in advance to receive the audio data of MUSIC type, but not the audio data of NOTIFICATION type, when the speaker is used as the slave device of the mobile phone. Subsequently, as shown in FIG. 31 , when the user selects the speaker as the slave device for this audio switching of the mobile phone, the mobile phone can send MUSIC type audio data (eg songs) to the speaker for playback according to the above device selection strategy.
  • MUSIC type audio data eg songs
  • the mobile phone will not send the NOTIFICATION type audio data (such as SMS prompt tone) to the speaker for playback.
  • the mobile phone uses the speaker as a slave device to perform audio switching, the user can listen to the MUSIC type audio data from the mobile phone on the speaker without being disturbed by other audio data (such as SMS prompts) in other mobile phones.
  • the slave device of the mobile phone is an in-vehicle device (also referred to as an in-vehicle device)
  • the in-vehicle device plays audio data mostly in a driving scene, the user needs to maintain a relatively concentrated attention. Therefore, when the in-vehicle device can be set as the slave device of the mobile phone in the device selection policy in advance, it can receive the audio data of MUSIC type and navigation voice type, but not receive audio data of other types (eg NOTIFICATION type and SYSTEM).
  • the mobile phone can send the audio data of the MUSIC type (such as a song) or the navigation voice type to the in-vehicle device for playback according to the above-mentioned device selection strategy. . If the mobile phone receives or generates other types of audio data, the mobile phone will not send the audio data to the in-vehicle device for playback.
  • the MUSIC type such as a song
  • the mobile phone will not send the audio data to the in-vehicle device for playback.
  • the mobile phone uses the in-vehicle device as a slave device for audio switching
  • the user can listen to the audio data of the MUSIC type or VOICE_CALL type from the mobile phone on the in-vehicle device, without being affected by other audio data (such as SMS prompts) in other mobile phones. disturb.
  • the mobile phone when the mobile phone prohibits receiving a certain type of audio data from the device in the above device selection policy, for example, when the in-vehicle device is prohibited from receiving audio data of the NOTIFICATION type, the mobile phone can further set the audio data of the NOTIFICATION type in the device selection policy
  • the audio output device of the data that is, the specific device that allows to play the audio data of the NOTIFICATION type.
  • a mobile phone may set itself as an audio output device for audio data of type NOTIFICATION.
  • the mobile phone uses the in-vehicle device as a slave device for audio switching, if the audio data of NOTIFICATION type is generated, the mobile phone will not send the audio data to the in-vehicle device, but use its own speaker to play the audio data to prevent the mobile phone from generating audio data. Audio data is dropped.
  • the mobile phone can also select another device as the audio output device of NOTIFICATION type audio data during audio switching, which is not limited in this embodiment of the present application.
  • the master device such as the above-mentioned mobile phone
  • the master device when the master device (such as the above-mentioned mobile phone) outputs audio data to one or more slave devices for audio switching, it can send audio data that matches the device characteristics of the slave devices. Play it to the slave device, so as to filter out some audio data that is not suitable for playing on the slave device for the user, so that the audio data has a higher adaptability with the audio output device, and provides the user with a better audio experience.
  • the DV APP of the mobile phone can also issue a device selection policy corresponding to the current slave device to the AudioPolicy.
  • the device selection policy records the playback capability of the slave device for different types of audio data.
  • the device selection strategy of the speaker can be shown in Table 4.
  • the device selection strategy records the playback capability of the speaker for each type of audio data. For example, MUSIC type and RING type audio data are allowed to be played on the speaker, and SYSTEM type and NOTIFICATION type audio data are not allowed to be played on the speaker.
  • the audio APP after the audio APP generates a certain type of audio data, it can call the audio player to play it. Moreover, the audio APP can identify the specific type of the above audio data by setting a preset parameter (for example, a mode parameter) in the audio player. For example, when the audio APP sets the mode parameter to 01, it means that the audio data type input by the audio APP to the audio player is MUSIC type; when the audio APP sets the mode parameter to 11, it means that the audio APP inputs the audio data to the audio player.
  • a preset parameter for example, a mode parameter
  • AudioFlinger when AudioFlinger receives the audio data generated from the audio APP through the audio player, AudioFlinger can determine the type of audio data received at this time by reading the mode parameter in the audio player. Furthermore, as shown in Figure 33, AudioFlinger may request AudioPolicy to inquire whether the audio data of this type is allowed to be played on the current slave device (ie, the speaker). AudioPolicy can respond to the request and determine whether the audio output device of the current audio data is a speaker according to the device selection strategy shown in Table 4 issued by the DV APP, that is, select a suitable audio output device for the current audio data.
  • AudioPolicy can indicate to AudioFlinger that the audio output device of the current audio data is the speaker. Further, as shown by the solid arrow in Figure 33, after AudioFlinger processes the audio data, the processed audio data can be sent to the speaker through the above-mentioned DMSDP Audio HAL, and the audio data can be played by the speaker.
  • AudioPolicy can re-select an audio output device for the current audio data.
  • AudioPolicy can set the speaker of the unit as the audio output device of the current audio data.
  • AudioPolicy can indicate to AudioFlinger that the audio output device of the current audio data is the local speaker. Then, as shown by the dotted arrow in Figure 33, after AudioFlinger processes the audio data, the processed audio data can be sent to the speaker of the mobile phone through the Primary HAL, and the audio data can be played by the speaker of the mobile phone.
  • the device selection strategy of the speaker shown in Table 4 only the type of audio data allowed to be played by the speaker can be set. At this time, other types of audio data can be defaulted to audio data that the speaker is not allowed to play. Alternatively, only the types of audio data that are not allowed to be played by the speaker may be set in the device selection policy shown in Table 4. At this time, other types of audio data may be the audio data allowed to be played by the speaker by default, which is not limited in this embodiment of the present application.
  • an audio output device corresponding to each type of audio data may also be set in the device selection policy.
  • the audio data is allowed to be played on mobile phones, speakers and TVs.
  • audio data of type NOTIFICATION the audio data is allowed to be played on mobile phones and watches.
  • AudioFlinger After AudioFlinger receives a certain type of audio data, it can still request AudioPolicy to determine the specific audio output device of this type of audio data.
  • AudioPolicy can determine, according to the device selection strategy shown in Table 5, that the audio output devices that can play the audio data include mobile phones, speakers, and TVs. If the slave device currently connected to the mobile phone is a speaker, AudioPolicy can determine that the audio output device of the MUSIC type audio data is the speaker, and then instruct AudioFlinger to send the MUSIC type audio data to the speaker for playback.
  • AudioPolicy can determine that the audio output devices that can play the audio data include mobile phones and watches according to the device selection strategy shown in Table 5, that is, the speakers currently connected to the mobile phone are not allowed to play the audio data. Then, AudioPolicy The mobile phone can be determined as the audio output device of the audio data of the NOTIFICATION type, and further instructs AudioFlinger to send the audio data of the NOTIFICATION type to the speaker of the mobile phone for playback.
  • the audio APP can modify the above mode parameter in the audio player. Furthermore, when AudioFlinger reads that the above mode parameter has changed, it can determine the type of the current audio data according to the latest mode parameter. In this way, AudioFlinger can re-request AudioPolicy to query whether the new type of audio data is allowed to be played on the current slave device (ie, speaker), so as to dynamically switch different types of audio data to the corresponding audio output device for playback.
  • AudioFlinger can re-request AudioPolicy to query whether the new type of audio data is allowed to be played on the current slave device (ie, speaker), so as to dynamically switch different types of audio data to the corresponding audio output device for playback.
  • the DV APP can be triggered to issue a device selection policy corresponding to the TV to the AudioPolicy.
  • AudioPolicy can select an appropriate audio output device for the current type of audio data in real time according to the device selection policy of the TV, so as to dynamically switch different types of audio data to the corresponding audio output device for playback.
  • the master device can set a corresponding device selection policy for the slave devices in advance according to the device characteristics of each slave device.
  • the master device can send the audio data that matches the device characteristics of the slave device to the slave device for playback according to the device selection strategy of the current slave device, so as to filter out some unsuitable devices for the user to play in the slave device.
  • the audio data played on the device enables the main device to selectively switch various types of audio data to the corresponding audio output device for playback, providing users with a better audio experience.
  • an audio control method provided by an embodiment of the present application includes the following steps:
  • the mobile phone establishes a network connection with the first slave device by running the DV APP.
  • the user can switch the audio output device in the mobile phone when the mobile phone outputs audio.
  • a switch button 3501 for audio switching can be displayed. If it is detected that the user clicks the above switching button 3501, the mobile phone can search for one or more candidate devices nearby for audio switching by running the DV APP.
  • the DV APP can display candidate devices such as TVs, speakers, and headphones that are located on the same Wi-Fi network as the mobile phone in the menu 3502. The user can select one of these candidate devices as an audio output device when the mobile phone outputs audio subsequently, that is, a slave device of the mobile phone.
  • the user can also open the control center of the mobile phone, and switch the audio output device when the mobile phone outputs audio in the control center.
  • the mobile phone may display a control center 3601 .
  • a switch button 3602 for audio switching is provided in the control center 3601 . If it is detected that the user clicks the above-mentioned switch button 3602, the mobile phone can also search for one or more nearby candidate devices that can be used for audio switching by running the DV APP.
  • the DV APP can display the searched candidate devices such as TVs, speakers, and headphones that are located on the same Wi-Fi network as the mobile phone in the control center 3601. Likewise, the user can select one of these candidate devices as an audio output device when the mobile phone outputs audio subsequently, that is, a slave device of the mobile phone.
  • the DV APP can use the speaker as the slave device of the mobile phone to establish a network connection with the speaker.
  • the network connection may be a P2P connection based on TCP (transmission control protocol, transmission control protocol) or UDP (user datagram protocol, user datagram protocol), which is not limited in this embodiment of the present application.
  • the network connection established between the mobile phone and the slave device may specifically refer to a network connection of a service channel (ie, a service connection).
  • a service connection For example, before the user selects the speaker as the slave device of the mobile phone, the mobile phone may have established a connection with the speaker through the Wi-Fi network, and the connection at this time refers to the connection of the data channel (ie, the data connection).
  • the mobile phone and the speaker can establish a business connection on the basis of the established data connection.
  • the DV APP can obtain the audio capability parameter of the speaker based on the network connection.
  • the audio capability parameter can reflect the audio output function supported by the speaker.
  • the DV APP can create the corresponding DMSDP Audio HAL 3701 in the HAL according to the audio capability parameters of the speaker. Subsequently, the mobile phone can transmit audio data to the speaker through DMSDP Audio HAL 3701.
  • the user may also select multiple slave devices for outputting audio from the phone.
  • the user can select the speaker and the TV as the slave devices of the mobile phone from the above candidate devices.
  • the DV APP can establish a network connection with the speaker and the TV box and obtain the corresponding audio capability parameters.
  • the DV APP can create a first DMSDP Audio HAL corresponding to the speaker in the HAL according to the audio capability parameters of the speaker, and the DV APP can create a second DMSDP Audio HAL corresponding to the TV in the HAL according to the audio capability parameters of the TV.
  • the mobile phone can send the corresponding first audio data to the speaker through the first DMSDP Audio HAL, and send the corresponding second audio data to the TV through the second DMSDP Audio HAL (the second audio data and the first audio data can be the same or different. ).
  • the DV APP in the mobile phone sends the device selection policy of the first slave device to AudioPolicy.
  • device selection strategies for multiple audio output devices may be pre-stored in the mobile phone.
  • the device selection policy for each audio output device is used to indicate the playback capability of this type of device for different types of audio data.
  • a mobile phone can pre-store device selection strategies for four types of audio output devices, including speaker devices, large-screen devices, vehicle-mounted devices, and wearable devices.
  • the DV APP can obtain the identity of speaker 1. Furthermore, the DV APP can identify the speaker 1 as a speaker device according to the identification of the speaker 1. Furthermore, as shown in Figure 37, the DV APP can send the pre-stored device selection policy of the speaker device (ie, device selection policy 1) to AudioPolicy. AudioPolicy can associate the device selection policy 1 issued by the DV APP with the speaker 1. At this time, the device selection policy 1 can be bound to the speaker 1 as the device selection policy of the speaker 1.
  • the device selection strategy 1 of the speaker 1 (ie, the device selection strategy of the speaker device) can be as shown in Table 6.
  • the device selection strategy 1 records the playback capability of the speaker 1 for each type of audio data.
  • the audio data of the MUSIC type and the RING type is allowed to be played on the speaker 1.
  • the audio output device of the audio data of the MUSIC type and the RING type is the speaker 1.
  • the device selection strategy 1 may further set an audio output device of this type of audio data, that is, a specific audio output device that is allowed to play this type of audio data.
  • an audio output device of this type of audio data that is, a specific audio output device that is allowed to play this type of audio data.
  • audio data of SYSTEM type is not allowed to be played on speaker 1
  • the audio output device of this type of audio data is a mobile phone, that is, it is allowed to use the speaker of the mobile phone to play audio data of SYSTEM type.
  • the user can also manually modify the device selection strategy 1 of the above speaker 1 through the DV APP.
  • the DV APP can display the setting interface 3801 of the audio switching function to the user.
  • the setting interface 3801 is provided with a switch button 3802 for the audio switching function. If it is detected that the user has turned on the switch button 3802, it means that the user wishes to enable the audio switching function, and the mobile phone can allow the audio in the mobile phone to be switched to other audio output devices for playback. And, the user can further set the device selection policy of the current audio output device in the setting interface 3801 .
  • the user may select a specific type of audio data that is allowed to be played on the speaker 1 and a specific type of audio data that is not allowed to be played on the speaker 1 in the setting interface 3801 .
  • the user can also click the button 3803 to further set the audio output device of this type of audio data.
  • the DV APP can update the device selection policy 1 of the speaker 1 shown in Table 6 according to the user's selection in the setting interface 3801, and deliver the updated device selection policy 1 to AudioPolicy.
  • the AudioPolicy determines whether the current audio data is allowed to be played on the speaker 1 according to the updated device selection policy 1.
  • users can set or modify the audio types that are allowed to be played on each audio output device in the setting interface 3801 according to their own needs, that is, set a corresponding device selection policy for each audio output device, so that various types of audio data can be
  • the user's settings are distributed by the mobile phone to the corresponding audio output device for playback.
  • the mobile phone can also save the device selection policy set by the user for the speaker 1. Subsequently, when the mobile phone establishes a network connection with the speaker 1 again, the mobile phone can find the saved device selection strategy of the speaker 1 according to the identity of the speaker 1, and use the device selection strategy to determine whether to output the current audio data to the speaker 1. play.
  • the mobile phone can have multiple audio output devices at the same time, that is, the mobile phone can have multiple current slave devices.
  • a mobile phone can establish a network connection with speaker 1 and speaker 2 at the same time.
  • the DV APP in the mobile phone can send both the device selection policy of speaker 1 and the device selection policy of speaker 2 to AudioPolicy according to the above method.
  • the device selection strategy of speaker 1 and the device selection strategy of speaker 2 may be the same.
  • the user can further set the device selection strategy of speaker 1 and/or speaker 2 in the setting interface 3801 shown in FIG. 38 .
  • AudioPolicy when speaker 1 and speaker 2 support playing a certain type of audio data at the same time, AudioPolicy can send the current audio data to both speaker 1 and speaker 2, or AudioPolicy can also send the current audio The data is sent to one of Speaker 1 and Speaker 2.
  • the AudioPolicy can send the current audio data to the speaker 1 and the speaker 2 that are closer to the user for playback, which is not limited in this embodiment of the present application.
  • the mobile phone may set each audio output device by default to allow any type of audio data to be played. Then, after the mobile phone establishes a network connection with the first slave device (eg, speaker 1), the DV APP can send the device selection policy shown in Table 7 to AudioPolicy. In the device selection strategy shown in Table 7, speaker 1 is allowed to play any type of audio data. Subsequently, the mobile phone can update the device selection policy of the speaker 1 shown in Table 7 according to the user's selection in the above setting interface 1201, and deliver the updated device selection policy of the speaker 1 to AudioPolicy. The specific audio output device of the current audio data is determined by the AudioPolicy according to the updated device selection policy of the speaker 1 .
  • the device selection strategy of the audio output device may also be acquired by the mobile phone from the server, or the device selection strategy of the audio output device may also be pre-set by the developer in the mobile phone, which is not done in this embodiment of the present application. any restrictions.
  • the AudioPolicy determines whether the first slave device is allowed to play the first audio data from the audio APP according to the device selection policy of the first slave device.
  • the mobile phone can start to run the audio APP before establishing a network connection with the first slave device, or it can start to run the audio APP after establishing a network connection with the first slave device, that is, the process of running the audio APP on the mobile phone is the same as step S3401- There is no sequence relationship between S3402s. If the mobile phone has run an audio APP to generate audio data before establishing a network connection with the first slave device, since the mobile phone is not connected to other audio output devices, the mobile phone can use its own speaker to play the audio data.
  • step S3403 when the mobile phone runs the audio APP, the audio player (eg AudioTrack) can be called to input the currently generated audio data (eg audio data 1) into the audio processor (eg AudioFlinger). And, the audio APP can set the type of audio data 1 in AudioTrack. For example, the audio APP can set the mode parameter to 01 in AudioTrack to indicate that the type of audio data 1 currently input to AudioTrack is MUSIC type audio data.
  • AudioFlinger After AudioFlinger receives the audio data from the audio APP, it can identify the specific type of audio data 1 by reading the above mode parameter in AudioTrack. Further, AudioFlinger can send a query request to AudioPolicy, and the query request can include the type identifier of audio data 1 (for example, 01), to request AudioPolicy to inquire whether the slave device (ie the first slave device) currently connected to the mobile phone is allowed to play the identifier as Audio data 1 of type 01.
  • the query request can include the type identifier of audio data 1 (for example, 01), to request AudioPolicy to inquire whether the slave device (ie the first slave device) currently connected to the mobile phone is allowed to play the identifier as Audio data 1 of type 01.
  • AudioPolicy After AudioPolicy receives the query request sent by AudioFlinger, it can query whether the first slave device is allowed to play audio data 1 in the device selection policy of the first slave device issued by the DV APP according to the type identifier of the audio data in the query request. If the first slave device allows to play audio data 1, the mobile phone can continue to perform the following steps S3404; if the first slave device does not allow to play the audio data 1, the mobile phone can continue to perform the following steps S3405-S3406.
  • the DV APP of the mobile phone may also issue the device selection policies of various audio output devices to AudioPolicy in advance.
  • the DV APP can indicate the identity of the first slave device to AudioPolicy.
  • the AudioPolicy can determine the device type of the first slave device according to the identifier of the first slave device.
  • AudioPolicy can find a device selection policy corresponding to the device type of the first slave device in the device selection policies of various audio output devices, and determine the found device selection policy as the device selection policy of the first slave device.
  • the device selection policy of each audio output device may also be stored in the AudioPolicy in advance, without the need for the DV APP to issue the device selection policy of the audio output device to the AudioPolicy, which is not limited in this embodiment of the present application.
  • the AudioPolicy instructs AudioFlinger to send the first audio data to the first slave device.
  • AudioPolicy can determine that speaker 1 is allowed to play audio data 1. For example, when the audio APP is a music APP, the type of audio data 1 generated when the mobile phone runs the music APP to play a song is MUSIC. After AudioFlinger receives audio data 1, it can request AudioPolicy to inquire whether to play MUSIC type audio data 1 on speaker 1. At this time, the AudioPolicy can determine that the audio data 1 can be played by the slave device (ie, the speaker 1 ) of the mobile phone according to the device selection policy shown in Table 6 . Further, AudioPolicy may send a first instruction message to AudioFlinger, instructing AudioFlinger to send the currently generated audio data 1 to the speaker.
  • AudioFlinger receives the first instruction message sent by AudioPolicy, it can call the DMSDP Audio HAL 3701 corresponding to speaker 1 in the HAL, and send audio data 1 to speaker 1 through DMSDP Audio HAL3701, and the speaker 1Plays audio data 1 of MUSIC type.
  • AudioFlinger can parse, sample, encode, decode, encapsulate or decapsulate audio data 1 before sending audio data 1 to speaker 1 through DMSDP Audio HAL 3701, and send the processed audio data 1 to Speaker 1.
  • the speaker 1 can also perform processing operations such as parsing, sampling, encoding, decoding, encapsulating or decapsulating the audio data 1 before playing, and the embodiment of the present application does not do anything to this. limit.
  • the AudioPolicy determines that the first device plays the first audio data according to the device selection policy of the first slave device.
  • AudioPolicy instructs AudioFlinger to send the first audio data to the above-mentioned first device.
  • the first slave device is still used as an example of speaker 1, referring to the device selection strategy 1 of speaker 1 shown in Table 6, if the type of audio data 1 generated by the current audio APP is SYSTEM or NOTIFICATION, AudioPolicy can determine that speaker 1 is not allowed to play the audio data 1.
  • the SMS APP when the mobile phone is running the SMS APP, if the SMS APP receives a new SMS, the SMS APP can be used as the audio APP to input the generated SMS prompt tone (that is, audio data 2) to AudioFlinger through AudioTrack, and , the SMS APP can set the type of audio data 2 to NOTIFICATION in AudioTrack.
  • the AudioPolicy can determine that the speaker 1 is not allowed to play the audio data 2 of the NOTIFICATION type according to the device selection policy 1 shown in Table 6.
  • the AudioPolicy may further determine the audio output device of the audio data 2 in the device selection policy 1 shown in Table 6, that is, the first device that is allowed to play the NOTIFICATION type.
  • the audio output device for which audio data of the NOTIFICATION type is set is a mobile phone.
  • AudioPolicy can send a second instruction message to AudioFlinger, instructing AudioFlinger to send the audio data 2 from the SMS APP to the mobile phone, that is, the first device that plays the audio data 2 is the mobile phone.
  • AudioFlinger receives the second instruction message sent by AudioPolicy, it can call the Primary HAL corresponding to the speaker of the mobile phone in the HAL, and send the audio data 2 to the speaker of the mobile phone through the Primary HAL for playback.
  • the mobile phone when the mobile phone switches the audio function to the speaker, the mobile phone does not send all the audio data generated or received by itself to the speaker 1 (ie, the slave device) for playback.
  • the mobile phone can choose according to the device of the speaker 1.
  • the strategy sends one or more types of audio data suitable for playing on speaker 1 to speaker 1 for playback, and sends other audio data to other audio output devices for playback.
  • the mobile phone can accurately control the output flow of each audio data in combination with the device characteristics of the slave device when performing audio switching, and selectively switch the audio data to the corresponding audio output device for playback, so as to filter out some inappropriate audio data for the user. Audio data played on the current phone's slave device.
  • the AudioPolicy can also determine the first device that plays the audio data 2 according to a certain The selection strategy dynamically determines the audio output device of audio data 2 at this time. For example, AudioPolicy can determine the audio output device that is recently connected to the mobile phone except the speaker as the audio output device of audio data 2, that is, the first device that plays audio data 2 according to the principle of priority after access.
  • the audio output device of the mobile phone is the mobile phone itself from time T0, that is, the audio is played by the speaker of the mobile phone itself.
  • T1 T1>T0
  • the audio output device of the mobile phone at this time is updated to the Bluetooth headset.
  • T2 T2>T1
  • T3 T3>T2
  • AudioPolicy can select the audio output device with the highest priority other than speaker 1 as the audio output device that plays audio data 2, that is, select wired headphones to play audio data 2 . Furthermore, AudioPolicy can instruct AudioFlinger to send audio data 2 to wired headphones for playback.
  • those skilled in the art can also set a device selection strategy for the audio output device according to actual experience or actual application scenarios, which is not limited in this embodiment of the present application.
  • steps S3401-S3406 after the mobile phone as the master device establishes a network connection with the first slave device, it can dynamically select different types of audio data generated by the audio APP in the mobile phone according to the device selection strategy of the first slave device. Switch to the first slave device to play, so as to filter out some audio data that is not suitable for playing on the first slave device for the user, and provide the user with a better audio experience.
  • the mobile phone can also select this time according to the device selection strategy of the second slave device.
  • the audio data generated by the audio APP is switched to the second slave device for playback.
  • the mobile phone can switch the audio data to the second slave device for playback by performing the following steps S4101-S4106.
  • the mobile phone disconnects the network connection with the first slave device, and establishes a network connection with the second slave device by running the DV APP.
  • the user can also manually modify the slave device currently performing audio switching with the mobile phone on the mobile phone.
  • the mobile phone may display the control center 4201 in response to the user's operation of opening the control center.
  • the control center 4201 includes a switch button 4202 for the audio switch function.
  • the user wants to modify the slave device of the current mobile phone he can click the switch button 4202 to query one or more candidate devices that can currently be the slave device of the mobile phone.
  • the mobile phone can display one or more detected candidate devices in the control center 4201 .
  • the user can select the slave device (ie, the second slave device) to perform audio switching with the mobile phone in the control center 4201 .
  • the mobile phone detects that the user has enabled the screencasting function of the mobile phone, the mobile phone needs to switch the audio and images to other devices to play at the same time in the screencasting scenario, that is, the audio switching also needs to be performed in the screencasting scenario. Modify the slave device that performs audio switching with the mobile phone in response to the user's operation to turn on the screen projection function.
  • the application interface 4300 of the WeChat APP can be displayed.
  • the user can open a dialogue interface with a certain contact (eg, Sara or Mike), and listen to the voice sent by the user or the contact.
  • a certain contact eg, Sara or Mike
  • the user can open the control center 4301 of the mobile phone in the application interface 4300 .
  • a card 4302 can be set in the control center 4301, and the card 4302 is used to display one or more nearby candidate devices detected by the mobile phone that can perform screen projection.
  • the mobile phone can also identify the device currently performing screencasting with the mobile phone in the card 4302 by highlighting or other means. If it is detected that the user selects an electronic device (such as a TV) in the card 4302, it means that the user wishes to enable the screen projection function to project the image and audio generated by the mobile phone to the TV. At this time, the mobile phone can disconnect the network connection established with the speaker 1 (ie, the first slave device), and use the TV as the second slave device to establish a network connection with the TV.
  • an electronic device such as a TV
  • the DV APP in the mobile phone can obtain the audio capability parameters of the TV, and create the corresponding DMSDP Audio HAL in the HAL according to the audio capability parameters of the TV.
  • the mobile phone may update the DMSDP Audio HAL created for the speaker in step S3401 according to the audio capability parameters of the TV, so that the updated DMSDP Audio HAL matches the audio capability of the TV.
  • the mobile phone can transmit audio data to the TV through the updated DMSDP Audio HAL.
  • the mobile phone can send the display data in the mobile phone (for example, the application interface 4300 of the WeChat APP) to the TV for display according to the existing screen projection method, which is not limited in this embodiment of the present application.
  • the DV APP in the mobile phone delivers the device selection policy of the second slave device to AudioPolicy.
  • the DV APP can issue the device selection policy of the TV (that is, the device to the AudioPolicy). Choose strategy 2). For example, the DV APP can obtain the identification of the TV, thereby determining that the currently connected second slave device is a large-screen device. Furthermore, the DV APP can issue the device selection policy stored in advance for large-screen devices to AudioPolicy as the device selection policy 2 of the TV. Subsequently, the AudioPolicy may determine the specific audio output device of the audio data in the current mobile phone according to the device selection policy 2 of the TV.
  • the device selection strategy 2 of the TV can be as shown in Table 8. Different from the device selection strategy 1 shown in Table 6, the device selection strategy 2 of the TV can also set one or more application identifiers, such as The package name of the application. That is to say, in the device selection strategy 2, the mobile phone can also set the playback capabilities of different applications for different types of audio data. For example, for WeChat APP, TV allows WeChat APP to play MUSIC type and COMMUNICATION type audio data, but does not allow WeChat APP to play NOTIFICATION type and DTMF type audio data. For video APP, TV allows WeChat APP to play MUSIC type audio data, etc.
  • the specific application included in the device selection strategy 2 may be preset by the developer.
  • the mobile phone can obtain the device selection policy of the application in different audio output devices from the server, so that the mobile phone can dynamically update the information of each audio output device according to the application installed in the mobile phone.
  • the device selection policy which is not limited in this embodiment of the present application.
  • the mobile phone when the mobile phone is running the WeChat APP, the voice or media sound generated by the WeChat APP can be switched to the TV for playback, and the message prompt tones and key tones generated by the WeChat APP can be shunted to the mobile phone for playback, avoiding the noise generated by the WeChat APP.
  • the message prompt and key tones disturb the screencasting process of the phone on the TV.
  • the mobile phone can use the application as the granularity to output different types of audio data generated by an application to the corresponding audio output device for playback according to the device selection strategy, so that different audio output devices can be targeted to play specific applications. Specific types of audio data to improve the user's audio experience.
  • a device selection policy as shown in Table 9 may also be set in the AudioPolicy.
  • the AudioPolicy for different applications, audio output devices of different types of audio data are set for each application.
  • the Audio output device of the audio data may be a mobile phone, a speaker, a TV or an earphone.
  • the Audio output device of the audio data may be a mobile phone, a speaker or a TV.
  • the AudioPolicy can determine the audio output devices of various types of audio data generated by the running audio APP according to the device selection strategy shown in Table 9.
  • the user can also manually modify the device selection policy of the current slave device in the mobile phone.
  • a card 4502 for audio switching can be displayed in the control center 4501 , and a setting button 4503 for audio switching can be set in the card 4502 .
  • the DV APP can display the setting interface 4504 when the TV is the slave device. Similar to FIG. 38 , the switch button 4505 of the audio switching function can be set in the setting interface 4504 .
  • the user can set in the setting interface 4504 what types of audio data the TV can receive, or set what types of audio data the TV can receive when the mobile phone runs different applications.
  • the DV APP can update the device selection strategy 2 of the TV shown in Table 8 according to the user's selection in the setting interface 4504, so that the user can dynamically specify the type of audio data output in each audio output device.
  • the AudioPolicy determines whether the second slave device allows to play the second audio data from the audio APP according to the device selection policy of the second slave device.
  • AudioFlinger can receive audio data generated from different audio APPs.
  • AudioFlinger can request AudioPolicy to check whether the currently received audio data is allowed to be played on the TV.
  • the AudioPolicy can determine whether the current audio data is allowed to be played on the TV according to the device selection policy 2 of the TV.
  • AudioFlinger may receive multiple audio data from the same or different audio apps at the same time.
  • T1 the user opens the music APP on the mobile phone to start playing songs
  • T2 T2>T1
  • the user opens the voice message sent by the contact in the mobile phone's WeChat APP to start playing the voice.
  • T3-T4 T4>T3>T2
  • the key sound starts to be played when the user clicks a key using the keyboard in the WeChat APP.
  • AudioFlinger of the mobile phone can simultaneously receive the audio data A of the COMMUNICATION type and the audio data B of the DTMF type from the WeChat APP, and the audio data C of the MUSIC type from the music APP. Still as shown in FIG. 44 , AudioFlinger may request AudioPolicy to inquire whether audio data A, audio data B, and audio data C are allowed to be played on the TV. Furthermore, AudioPolicy can determine whether the current audio data A, audio data B and audio data C are allowed to be played on the TV according to the device selection policy 2 shown in Table 8.
  • the AudioPolicy instructs AudioFlinger to send the second audio data to the second slave device.
  • AudioPolicy can determine that the TV is allowed to play audio data A of COMMUNICATION type and audio data C of MUSIC type according to the device selection policy 2 shown in Table 8, but is not allowed to play DTMF type audio data A. Audio data B. Then, AudioPolicy can send a first instruction message to AudioFlinger, instructing AudioFlinger to send audio data A and audio data C to the speaker. Further, AudioFlinger can respond to this first instruction message, mix audio data A and audio data C two channels of audio data into audio data A+C, and send the mixed audio data A+C to the audio data A+C through DMSDP Audio HAL. television.
  • AudioFlinger can also not mix audio data A and audio data C, and send the unmixed audio data A and audio data C to the TV through the DMSDP Audio HAL, and the TV will play the video from the WeChat APP in the screen projection scene. Audio data A and audio data C from the music APP.
  • the AudioPolicy determines that the second device plays the second audio data according to the device selection policy of the second slave device.
  • AudioPolicy instructs AudioFlinger to send the second audio data to the above-mentioned second device.
  • AudioPolicy can determine that the TV does not allow to play DTMF audio data B according to the device selection policy 2 shown in Table 8. Then, the AudioPolicy can further determine the specific audio output device that is allowed to play the DTMF type in the device selection policy shown in Table 8, that is, the second device that plays the audio data B.
  • AudioPolicy may send a second instruction message to AudioFlinger, instructing AudioFlinger to send the currently generated audio data B to the mobile phone.
  • AudioFlinger responds to the second instruction message, it can call the Primary HAL corresponding to the speaker of the mobile phone in the HAL, and send the audio data B to the speaker of the mobile phone through the Primary HAL for playback.
  • steps S4101-S4106 after the mobile phone as the master device establishes a network connection with the second slave device, it can dynamically select different types of audio data generated by the audio APP in the mobile phone according to the device selection strategy of the second slave device. Switch to the second slave device to play, so as to filter out some audio data that is not suitable for playing on the second slave device for the user, and provide the user with a better audio experience.
  • multiple channels of audio data may be generated simultaneously in the main device (eg, the above-mentioned mobile phone).
  • the main device eg, the above-mentioned mobile phone.
  • the map APP can generate navigation voice in the navigation mode; at the same time, the mobile phone can also run the music APP to play songs.
  • the mobile phone can simultaneously play the navigation voice (ie, audio data 1) from the map APP and the song (ie, audio data 2) from the music APP.
  • the SMS APP of the mobile phone receives a new short message, the mobile phone also needs to play the prompt tone of the short message (ie, audio data 3).
  • the mobile phone can also play audio data 3 at the same time.
  • the mobile phone as the master device can send the generated audio data to one or more slave devices for playback, so as to realize the audio switching function between multiple devices. Then, when the mobile phone needs to output multi-channel audio data, the mobile phone can mix the multi-channel audio data and output it to the slave device for playback, but the multi-channel audio data after mixing will be distorted, resulting in Distortion also occurs when the mixed audio data is played back.
  • the audio output device (ie, the slave device) of the mobile phone may be a speaker.
  • the mobile phone can generate audio data 1 and audio data 2 at the same time during operation.
  • the mobile phone projects audio data 1 and audio data 2 to the speaker, it needs to mix audio data 1 and audio data 2 first, so that the audio data 1 and audio data 2 are mixed.
  • the audio signals are superimposed to obtain mixed audio data 3 .
  • the mobile phone can package the audio data 3 into data packets and send them to the speaker, and the speaker can play the corresponding audio after parsing the audio data 3 in each data packet.
  • the audio data 3 after mixing may not completely retain the audio characteristics of the audio data 1 and 2 before the mixing, for example, the loudness of audio data 1 or audio data 2,
  • the audio features such as frequency are changed in the audio data 3 after sound mixing, so that the audio data 3 is distorted. That is to say, the component of audio data 1 in audio data 3 may deviate from the audio data 1 before mixing, resulting in the audio characteristics of audio data 1 before mixing and the audio data 1 included in audio data 3 after mixing.
  • the audio features are different; similarly, the component of audio data 2 in audio data 3 may deviate from the audio data 2 before the mixing, resulting in the audio features of the audio data 2 before the mixing and the audio contained in the audio data 2 after the mixing.
  • the audio characteristics of the data 2 are different, so that the speaker appears distorted when playing the audio data 3, which affects the user's audio experience.
  • a sound mixing strategy may be preset in the main device (eg, a mobile phone), and the sound mixing strategy may be used to indicate whether different types of audio data are allowed to be mixed.
  • the mixing strategy shown in Table 1 users generally have higher requirements for the audio quality of music types, so it can be set in the mixing strategy in advance that music of the MUSIC type is not allowed to be mixed with other audio data, and Mixing with other audio data is allowed for NOTIFICATION type notification tones and DTMF type key tones.
  • the mobile phone can determine which audio data is based on the type of each channel of audio data and according to the mixing strategy shown in Table 1. No need to mix, which audio data needs to be mixed.
  • NOTIFICATION notification
  • DTMF Dual Tone Multi Frequency
  • MUSIC music not allowed ... ...
  • the speaker can be used as a slave device for audio switching.
  • the audio data 1 of the MUSIC type is generated. If there is only audio data of the audio data 1 at this time, the mobile phone can send the audio data 1 to the speaker for playback.
  • the mobile phone can also perform processing such as parsing, sampling, encoding, decoding, encapsulating or decapsulating the audio data 1, which is not limited in this embodiment of the present application.
  • the WeChat APP of the mobile phone receives a new short message, the WeChat APP can generate the audio data 2 of the NOTIFICATION type.
  • the mobile phone needs to send two channels of audio data from the WeChat APP and from the music APP to the speaker.
  • the mobile phone can determine that the audio data 1 of the MUSIC type is not allowed to be mixed with other audio data, so it is not necessary to mix the audio data 1 and the audio data 2, that is, the two The audio data of each channel needs to be transmitted to the speakers independently. Furthermore, as shown in FIG. 48 , the mobile phone can package the audio data 1 from the music APP (also referred to as a package) to obtain a first data package 4801 corresponding to the audio data 1 (the first data package 4801 may have multiple ), at the same time, the mobile phone can package the audio data 2 from the WeChat APP to obtain a second data package 4802 corresponding to the audio data 2 (there can be multiple second data packages 4802).
  • the music APP also referred to as a package
  • the mobile phone can package the audio data 2 from the WeChat APP to obtain a second data package 4802 corresponding to the audio data 2 (there can be multiple second data packages 4802).
  • the mobile phone can send the first data packet 4801 and the second data packet 4802 to the speaker, and the speaker can obtain the unmixed audio data 1 and audio data by parsing the received first data packet 4801 and second data packet 4802 2. That is to say, the mobile phone can send the audio data 1 and the audio data 2 to the speaker relatively independently without mixing the two audio data.
  • the audio data 1 and audio data 2 obtained by the speaker from the mobile phone have not been mixed, so the audio data 1 can more realistically reflect the audio characteristics of the songs in the music APP, and the audio data 2 can also be more realistic. reflects the audio characteristics of the notification sound of the SMS APP. That is to say, the audio data 1 and audio data 2 obtained by the speaker do not contain distortion caused by the audio mixing processing of the mobile phone. In this way, the distortion phenomenon generated by the speaker when playing the above-mentioned audio data 1 and audio data 2 is correspondingly reduced, thereby reducing the distortion of multi-channel audio data when playing across devices, and improving the audio output quality of the audio switching scene.
  • the mobile phone may also add feature information of the audio data 1 in the first data packet 4801, for example, the identifier of the audio data 1 is 01, and the type of the audio data 1 is MUSIC type, the volume level of audio data 1 is 5 and so on.
  • the above feature information can reflect the actual audio features of the audio data 1 .
  • the speaker parses the first data packet 4801, not only the unmixed audio data 1 can be obtained, but also the audio features of the audio data 1 can be obtained according to the feature information in the first data packet 4801. Subsequently, when playing the audio data 1, the speaker can restore the audio features of the audio data 1 more realistically according to the feature information of the audio data 1, and reduce the distortion phenomenon during the audio switching process.
  • the mobile phone can also add the feature information of the audio data 2 in the second data packet 4802, so that the speaker can not only obtain the unmixed audio data 2, but also can obtain the audio data 2 according to the second
  • the feature information in the data packet 4802 obtains the audio features of the audio data 2, so as to reduce the distortion phenomenon in the audio switching process.
  • the speaker plays the above-mentioned audio data 1 and audio data 2, it can also perform processing operations such as parsing, sampling, encoding, decoding, encapsulating or decapsulating the audio data 1 and audio data 2, which are not performed in this embodiment of the present application. any restrictions.
  • the DV APP can also issue a mixing strategy of different types of audio data to the AudioPolicy.
  • the DV APP can deliver the audio mixing policy shown in Table 10 to the AudioPolicy, where the audio mixing policy records whether audio mixing is allowed for each type of audio data.
  • AudioFlinger requests AudioPolicy to inquire which audio data in the current multi-channel audio data needs to be transmitted independently, and which audio data needs to be mixed before transmission.
  • AudioPolicy can query which audio data currently needs to be transmitted independently and which audio data needs to be mixed before transmission according to the mixing strategy shown in Table 10.
  • AudioFlinger can send a first request to AudioPolicy to request AudioPolicy to determine whether the three channels of audio data need to be mixed .
  • the AudioPolicy may query the mixing policy shown in Table 10 in response to the first request, thereby determining that the audio data C of the MUSIC type does not need to be mixed, while the audio data A of the NOTIFICATION type and the audio data B of the DTMF type need to be mixed.
  • AudioPolicy can output a mixing instruction to AudioFlinger, where the mixing instruction indicates that audio data A and audio data B are mixed into one channel of audio data, while audio data C is not mixed with audio data A and audio data B. AudioFlinger can respond to the above audio mixing instructions, mix audio data A and audio data B, and do not mix audio data C. In this way, AudioFlinger can finally output two channels of audio data, one is the mixed audio data A. +B, the other is unmixed audio data C.
  • AudioFlinger can call DMSDP Audio HAL to output audio data A+B and audio data C to the slave device for playback.
  • the master device can transmit the audio data C to the slave device independently, without mixing with other audio data, so that the audio data C received by the slave device C
  • Some audio features in the audio data C will not be lost due to mixing, avoiding audio distortion caused by mixing processing, thereby reducing the distortion of multi-channel audio data when playing across devices, and improving the audio in audio switching scenarios. output quality.
  • the master device can preset mixing strategies corresponding to various types of audio data. In this way, when multi-channel audio data needs to be output to the slave device, the master device can choose not to mix some audio data in the multi-channel audio data according to the mixing strategy, and transmit it to the slave device for playback independently, so as to avoid the Distortion of a certain type of audio data caused by mixing processing to improve the audio output quality of audio switching scenarios.
  • an audio control method provided by an embodiment of the present application includes the following steps:
  • the mobile phone establishes a network connection with the first slave device by running the DV APP.
  • the user can switch the audio output device in the mobile phone when the mobile phone outputs audio.
  • a switch button 5101 for audio switching can be displayed. If it is detected that the user clicks the above-mentioned switch button 5101, the mobile phone can search for one or more candidate devices nearby that can be used for audio switching by running the DV APP.
  • the DV APP can display candidate devices such as TVs, speakers, and headphones that are located on the same Wi-Fi network as the mobile phone in the menu 5102. The user can select one of these candidate devices as an audio output device when the mobile phone outputs audio subsequently, that is, a slave device of the mobile phone.
  • the user can also open the control center of the mobile phone, and switch the audio output device when the mobile phone outputs audio in the control center.
  • the mobile phone may display the control center 5201 .
  • a switch button 5202 for audio switching is provided in the control center 5201 . If it is detected that the user clicks the above switching button 5202, the mobile phone can also search for one or more candidate devices nearby that can be used for audio switching by running the DV APP. As shown in (b) of Figure 52, the DV APP can display the searched candidate devices such as TVs, speakers, and headphones that are located on the same Wi-Fi network as the mobile phone in the control center 5201. Likewise, the user can select one of these candidate devices as an audio output device when the mobile phone outputs audio subsequently, that is, a slave device of the mobile phone.
  • the DV APP can use the speaker as the slave device of the mobile phone and the speaker.
  • Establish a network connection may be a P2P connection based on TCP (transmission control protocol, transmission control protocol) or UDP (user datagram protocol, user datagram protocol), which is not limited in this embodiment of the present application.
  • the network connection established between the mobile phone and the slave device may specifically refer to a network connection of a service channel (ie, a service connection).
  • a service connection For example, before the user selects the speaker as the slave device of the mobile phone, the mobile phone may have established a connection with the speaker through the Wi-Fi network, and the connection at this time refers to the connection of the data channel (ie, the data connection).
  • the mobile phone and the speaker can establish a business connection on the basis of the established data connection.
  • the DV APP can obtain the audio capability parameter of the speaker based on the network connection, and the audio capability parameter can reflect the audio output function supported by the speaker.
  • the audio capability parameter may include a sampling rate supported by the speaker, the number of channels, a sound effect mode, a playback delay, and the like.
  • the DV APP can create the corresponding DMSDP Audio HAL in the HAL according to the audio capability parameters of the speaker.
  • the mobile phone can transmit audio data to the speaker through DMSDP Audio HAL, so as to switch the audio function in the mobile phone to the speaker.
  • the user may also select multiple slave devices for outputting audio from the phone.
  • the user can select the speaker and the TV as the slave devices of the mobile phone from the above candidate devices.
  • the DV APP can establish a network connection with the speaker and the TV respectively and obtain the corresponding audio capability parameters.
  • the DV APP can create a first DMSDP Audio HAL corresponding to the speaker in the HAL according to the audio capability parameters of the speaker, and the DV APP can create a second DMSDP Audio HAL corresponding to the TV in the HAL according to the audio capability parameters of the TV.
  • the mobile phone can send the corresponding first audio data to the speaker through the first DMSDP Audio HAL, and send the corresponding second audio data to the TV through the second DMSDP Audio HAL (the second audio data and the first audio data can be the same or different. ).
  • the DV APP in the mobile phone sends the audio mixing policy of the first slave device to AudioPolicy.
  • the mobile phone may pre-store sound mixing strategies of multiple audio output devices.
  • the mixing strategy of each audio output device is used to indicate the mixing requirements of this type of device for different types of audio data.
  • a mobile phone can pre-store sound mixing strategies for four types of audio output devices: speaker devices, large-screen devices, vehicle-mounted devices, and wearable devices.
  • the mobile phone has pre-stored sound mixing strategies for speaker devices and large-screen devices.
  • the sound mixing strategy the sound mixing strategy of whether to allow sound mixing when outputting each type of audio data to different types of audio output devices is set. It can be seen that, different from the sound mixing strategies shown in Table 10, the mobile phone can set corresponding sound mixing strategies for different types of audio output devices.
  • the mixing strategy of the speaker device it is not allowed to mix the audio data of the MUSIC type. That is to say, the audio data of MUSIC type needs to be transmitted to the speaker separately and not mixed with other audio data.
  • the sound mixing strategy of the speaker device it is allowed to mix the audio data of NOTIFICATION type and DTMF type with other audio data.
  • the sound mixing strategy of the large-screen device it is not allowed to mix the audio data of the MUSIC type and the NOTIFICATION type. That is to say, the audio data of the MUSIC type and the audio data of the NOTIFICATION type need to be transmitted to the TV separately without mixing with other audio data.
  • the DV APP can obtain the identity of speaker 1. Furthermore, the DV APP can identify the speaker 1 as a speaker device according to the identification of the speaker 1. Furthermore, as shown in Figure 53, the DV APP can send the pre-stored sound mixing strategy of the speaker device (ie, the sound mixing strategy 1) to AudioPolicy. AudioPolicy can associate the mixing strategy 1 issued by the DV APP with the speaker 1. At this time, the mixing strategy 1 can be bound to the speaker 1 as the mixing strategy of the speaker 1.
  • the user can also manually modify the mixing strategy 1 of the above speaker 1 through the DV APP.
  • the DV APP can display the setting interface 5401 of the audio switching function to the user.
  • the setting interface 5401 is provided with a switch button 5402 of the audio switching function. If it is detected that the user turns on the switch button 5402, it means that the user wants to turn on the audio switching function, and the mobile phone can allow the audio in the mobile phone to be switched to other audio output devices for playback. And, the user can further set the mixing strategy of the current audio output device in the setting interface 5401 .
  • the user may select, in the setting interface 5401, specific types of audio data that do not need to be mixed, and specific types of audio data that need to be mixed.
  • the user can click the option 5403 of “Add Others” in the setting interface 5401 .
  • the mobile phone can display more types of audio data in response to the user's operation of clicking option 5403, and the user can set whether to mix the audio data.
  • the DV APP can update the mixing policy 1 of the speaker 1 according to the user's selection in the setting interface 5401, and deliver the updated mixing policy 1 to AudioPolicy.
  • the AudioPolicy determines whether to mix different audio data generated by the audio APP according to the updated mixing policy 1.
  • the user can set or modify the audio type of the audio data that needs to be independently transmitted to each audio output device in the setting interface 5401 according to his own needs, that is, set a corresponding mixing strategy for each audio output device, so that various types of audio data It can be independently transmitted according to the user's settings or transmitted to the corresponding audio output device for playback after mixing.
  • the mobile phone can also save the mixing strategy set by the user for the speaker 1. Subsequently, when the mobile phone establishes a network connection with the speaker 1 again, the mobile phone can find the saved mixing strategy of the speaker 1 according to the identification of the speaker 1, and use the mixing strategy to determine whether to mix different audio data generated by the audio APP. sound.
  • the mobile phone may set by default that each type of audio output device except the mobile phone itself allows audio data of any type to be mixed. Then, after the mobile phone establishes a network connection with the first slave device (eg, speaker 1), the DV APP can send the audio mixing policy shown in Table 12 to AudioPolicy. In the mixing strategy shown in Table 13, any type of audio data sent by the mobile phone to the speaker 1 is allowed to be mixed. Subsequently, the mobile phone can update the sound mixing strategy of the speaker 1 shown in Table 12 according to the user's selection in the above-mentioned setting interface 1101, and deliver the updated sound mixing strategy of the sound box 1 to AudioPolicy.
  • the first slave device eg, speaker 1
  • the mobile phone can update the sound mixing strategy of the speaker 1 shown in Table 12 according to the user's selection in the above-mentioned setting interface 1101, and deliver the updated sound mixing strategy of the sound box 1 to AudioPolicy.
  • the AudioPolicy determines whether to mix different audio data generated by the audio APP according to the updated mixing strategy of the speaker 1.
  • the mobile phone can also set by default that each type of audio output device except the mobile phone itself is not allowed to mix any type of audio data. Subsequent users can also set the current mixing strategy of the slave device in the mobile phone according to their own needs. .
  • the above-mentioned sound mixing strategy may also be obtained by the mobile phone from the server, or, the above-mentioned sound mixing strategy may also be preset in the mobile phone by the developer, which is not limited in this embodiment of the present application.
  • the DV APP of the mobile phone may also issue the audio mixing policies of various audio output devices to AudioPolicy in advance.
  • the DV APP After the DV APP establishes a network connection with the first slave device (such as the speaker 1), the DV APP can indicate the identity of the speaker 1 to the AudioPolicy.
  • AudioPolicy can find the mixing strategy corresponding to the device type of speaker 1 in the mixing strategies of various audio output devices according to the identification of speaker 1, and determine the found mixing strategy as the mixing strategy of speaker 1 Strategy.
  • the audio mixing policy of each audio output device may also be stored in the AudioPolicy in advance, and there is no need for the DV APP to deliver the audio mixing policy of the audio output device to the AudioPolicy, which is not limited in this embodiment of the present application.
  • AudioFlinger sends the first audio data to the first slave device for playback.
  • step S5003 if the mobile phone generates audio data (which may be referred to as first audio data) when running the first audio APP (for example, the music APP), the first audio APP can call the audio player (eg AudioTrack), input the currently generated first audio data into an audio processor (eg AudioFlinger).
  • the music APP can set the type of audio data 1 in AudioTrack.
  • the audio APP can set the mode parameter corresponding to the audio data 1 to 01 in the AudioTrack to indicate that the type of the audio data 1 currently input to the AudioTrack is the audio data of the MUSIC type.
  • AudioFlinger After AudioFlinger receives the audio data (for example, audio data 1) from the first audio APP, it can identify the specific type of audio data 1 by reading the above-mentioned mode parameter in AudioTrack. Moreover, after AudioFlinger receives audio data 1, it can determine how many channels of audio data are received at this time, that is, the number of audio data that needs to be played on the slave device at the same time. If AudioFlinger only receives this channel of audio data at this time, no matter what type of audio data the audio data 1 is, it does not need to be mixed. Therefore, as shown in Figure 53, AudioFlinger can call the DMSDP Audio HAL corresponding to the speaker in the HAL, send audio data 1 to the speaker through the DMSDP Audio HAL, and the speaker will play the audio data 1.
  • AudioFlinger can call the DMSDP Audio HAL corresponding to the speaker in the HAL, send audio data 1 to the speaker through the DMSDP Audio HAL, and the speaker will play the audio data 1.
  • AudioPolicy can also set the corresponding audio policy according to the audio capability parameters of the speaker, and output the audio policy to AudioFlinger.
  • AudioPolicy can set whether to sample audio data 1, whether to add sound effects, etc. according to the audio capability parameter of the speaker.
  • AudioFlinger can perform corresponding processing on the audio data 1 according to the audio policy output by AudioPolicy. Then, AudioFlinger calls DMSDP Audio HAL to send audio data 1 to the speaker, which is the audio data processed by AudioFlinger according to the above audio strategy.
  • the AudioPolicy determines whether to mix the first audio data and the second audio data according to the mixing strategy of the first slave device.
  • the short message APP in the process of playing a song on the music APP (ie, the first audio application), if the short message APP receives a new short message, the short message APP can generate a NOTIFICATION type of Audio data 2 (ie, second audio data). Similar to the first audio data, the second audio APP can also call AudioTrack to input the currently generated second audio data into AudioFlinger.
  • AudioFlinger After AudioFlinger receives the audio data 2 from the SMS APP, it can query whether there is any other audio data that needs to be played on the slave device. For example, if AudioFlinger not only receives audio data 1 from the music APP, but also receives audio data 2 from the SMS APP at the same time, AudioFlinger can determine that audio data 1 and audio data 2 need to be on the current slave device (that is, the speaker) at the same time. play.
  • AudioFlinger can identify that the types of audio data 1 and audio data 2 are different by reading the mode parameters corresponding to audio data 1 and audio data 2 in AudioTrack. For example, AudioFlinger can determine that audio data 1 is audio data of MUSIC type, and audio data 2 is audio data of NOTIFICATION type. Since the audio data that currently needs to be played on the speakers are multiple channels of different types of audio data, AudioFlinger can send a query request to AudioPolicy, which can include the specific types of audio data 1 and audio data 2 to request AudioPolicy to determine Whether to mix audio data 1 and audio data 2.
  • the mobile phone can continue to perform the following steps S5005-S5006; if audio data 1 and audio data 2 need to be mixed, the mobile phone can continue to perform the following steps S5007 -S5009.
  • first audio application and second audio application may be the same application, or may be different applications.
  • WeChat APP when used as an audio APP, it can play both NOTIFICATION-type prompt sounds and MUSIC-type music, which is not limited in this embodiment of the present application.
  • the types of the first audio data and the second audio data are the same, it means that the audio characteristics of the first audio data and the second audio data are the same, and the effect of the distortion caused by the mixing on the first audio data and the second audio data is small.
  • the AudioPolicy can allow by default whether to mix the first audio data and the second audio data.
  • the AudioPolicy sends a first audio mixing instruction to AudioFlinger, where the first audio mixing instruction is used to instruct the independent transmission of the first audio data and the second audio data.
  • AudioPolicy can determine the audio data of the MUSIC type according to the types of audio data 1 and audio data 2 1 Mixing is not allowed, i.e. audio data 1 needs to be transmitted independently.
  • audio data 2 of NOTIFICATION type allows mixing with other audio data, since there is no other audio data that supports mixing except audio data 1 and audio data 2 at this time, AudioPolicy can determine that it is not necessary to mix audio data 1 and 2. Audio data 2 is mixed. That is, when one of audio data 1 and audio data 2 is not allowed to mix, AudioPolicy may determine that audio data 1 and audio data 2 do not need to be mixed.
  • AudioPolicy can send the first audio mixing instruction to AudioFlinger, and the first audio mixing instruction is used to indicate that audio data 1 and audio data 2 do not need to be mixed, that is, audio data 1 and audio data 2 need to be independently transmitted to speaker 1 , so as to ensure that the speaker 1 can restore the audio characteristics of the audio data 1 and the audio data 2 as much as possible according to the received audio data 1 and audio data 2 for playback.
  • the AudioFlinger in the mobile phone sends the first audio data and the second audio data to the first slave device respectively.
  • AudioFlinger After AudioFlinger receives the first mixing instruction sent by AudioPolicy, it can determine that the currently received audio data 1 and audio data 2 need to be independently transmitted to the speaker 1, then AudioFlinger does not need to follow the method in the prior art. Data 2 is mixed. Correspondingly, as shown in Figure 55, AudioFlinger can call the DMSDP Audio HAL in the HAL, send two channels of audio data (that is, audio data 1 and audio data 2) to the DMSDP Audio HAL, and then use the DMSDP Audio HAL to convert the audio data 1 and the audio data. Audio data 2 is sent to speaker 1. In this way, the audio data 1 and audio data 2 received by the speaker 1 are relatively independent two-channel audio data, and the speaker 1 can restore the audio data of the audio data 1 and the audio data 2 as much as possible when playing the audio data 1 and the audio data 2. feature.
  • AudioFlinger After AudioFlinger receives the above-mentioned first audio mixing instruction, it can package the audio data 1 and the audio data 2 respectively (also referred to as a package). Encapsulated into a data packet, the mobile phone can encapsulate every 2 frames of audio data in the audio data 2 into a data packet. As shown in FIG. 56 , in the process of packaging the audio data 1, an identifier of the audio data 1, such as 01, may be added to each data packet. Correspondingly, in the process of packaging the audio data 2, an identifier of the audio data 2, such as 02, may be added to each data packet.
  • AudioFlinger can store the packaged data packets in AudioFlinger's buffer 5601 in real time, and send the data packets in buffer 5601 to the DMSDP Audio HAL in real time.
  • DMSDP Audio HAL is a data packet of audio data 1 and audio data 2 obtained from the same buffer 5601
  • DMSDP Audio HAL can restore which data packets are audio data 1 data packets according to the identification in the data packet, Which packets are the packets of audio data 2.
  • multiple buffers can also be set in AudioFlinger, and each channel of audio data that needs to be transmitted to the slave device (eg, speaker 1) corresponds to one buffer.
  • AudioFlinger may pack the above-mentioned audio data 1 into several data packets and store them in the first buffer, and pack the above-mentioned audio data 2 into several data packets and store them in the second buffer.
  • AudioFlinger can add the identification for indicating specific audio data in the data packet, and also can not add the identification for indicating specific audio data in the data packet.
  • the data packet obtained by the DMSDP Audio HAL from the first buffer is the data packet of audio data 1
  • the data packet obtained by the DMSDP Audio HAL from the second buffer is the data packet of audio data 2.
  • the DMSDP Audio HAL After the DMSDP Audio HAL obtains each data packet carrying the identifier from the above buffer 5601, it can unpack each data packet, that is, decapsulate each data packet. In this way, DMSDP Audio HAL can restore two channels of unmixed audio data (that is, audio data 1 and audio data 2) according to the identification carried in each data packet. Furthermore, the DMSDP Audio HAL can send the audio data 1 and the audio data 2 to the speaker 1 relatively independently through the network connection established in step S5001, so that the speaker 1 can obtain the unmixed audio data 1 and audio data 2.
  • the DMSDP Audio HAL obtains each data packet carrying the identifier from the above buffer 5601, it can directly send the obtained data packet to the speaker 1, and the speaker 1 unpacks each received data packet, thereby Two channels of unmixed audio data (ie, audio data 1 and audio data 2) are restored according to the identifier carried in each data packet.
  • the processing complexity of the DMSDP Audio HAL in the mobile phone can be reduced, and the delay caused by the audio switching between the mobile phone and the speaker 1 can be reduced.
  • audio data 1 and audio data 2 need to be sent to two different audio output devices, for example, audio data 1 is sent to speaker 1 for playback, and audio data 2 is sent to TV 2 for playback. Then, after the DMSDP Audio HAL obtains each data packet carrying the logo from the above buffer 5601, it needs to unpack each data packet to restore the audio data of audio data 1 and audio data 2, and then respectively Audio data 1 is sent to speaker 1, and audio data 2 is sent to TV 2.
  • audio data 1 and audio data 2 are sent to speaker 1, since audio data 1 and audio data 2 have not been mixed, the audio features of audio data 1 and audio data 2 are preserved to the greatest extent, so that speaker 1 When playing audio data 1 and audio data 2, the audio features of audio data 1 and audio data 2 can also be restored to the greatest extent, thereby reducing the phenomenon of playback distortion in audio switching scenarios.
  • the user has set the volume of the audio data 1 of the MUSIC type to level 7, and the volume of the audio data 2 of the NOTIFICATION type has been set to level 4 in the mobile phone.
  • the volume level is larger, AudioFlinger will set the gain of the corresponding audio data to be larger, making the audio data louder during playback.
  • the gain of the audio data 1 received by the speaker 1 is still
  • the gain size of the audio data 2 also corresponds to the 4-level volume in the mobile phone.
  • the speaker 1 can directly play the audio data 1 and the audio data 2 according to the gain of the audio data 1 and the audio data 2 at the same time.
  • the speaker 1 can also enlarge or reduce the gain of the audio data 1 and the audio data 2 in proportion to the audio data 1 and the audio data 2 before playing. Either way, since the volume of the audio data 1 received by the speaker 1 is greater than the volume of the audio data 2, the volume of the audio data 1 finally played by the speaker 1 is still greater than the volume of the audio data 2, thereby restoring the audio data 1. and audio data 2's original volume characteristics on the mobile phone, to avoid the user feeling that the volume of a certain channel of audio data is too large or too low in the multi-channel audio data.
  • Audio data 1 and audio data 2 are not limited in this embodiment of the present application.
  • the AudioPolicy sends a second audio mixing instruction to AudioFlinger, where the second audio mixing instruction is used to instruct to mix the first audio data and the second audio data.
  • AudioPolicy can determine whether audio data 1 is allowed to be mixed according to the types of audio data 1 and audio data 2 and according to the mixing strategy shown in Table 11, and determine whether audio data 2 is allowed to be mixed. sound. If both audio data 1 and audio data 2 are allowed to mix, AudioPolicy may determine that audio data 1 and audio data 2 need to be mixed.
  • AudioPolicy can send a second audio mixing instruction to AudioFlinger, and the second audio mixing instruction is used to indicate that audio data 1 and audio data 2 need to be mixed, that is, audio data 1 and audio data 2 do not need to be independently transmitted to speaker 1 .
  • the AudioFlinger in the mobile phone mixes the first audio data and the second audio data into third audio data.
  • Audio data 1 and audio data 2 can be mixed.
  • AudioFlinger can uniformly sample audio data 1 and audio data 2 using the sampling rate of audio data 2 (ie, a smaller sampling rate).
  • AudioFlinger can adjust the increase size of audio data 1 and audio data 2 to the same value. Then, the mixed audio data 1 and audio data 2 are combined into one channel of audio data (ie, the third audio data).
  • the AudioFlinger in the mobile phone sends the third audio data to the first slave device.
  • AudioFlinger can send the mixed third audio data to speaker 1 through the DMSDP Audio HAL, and speaker 1 plays the mixed third audio data. Since some audio features of audio data 1 and audio data 2 in the third audio data are modified during sound mixing, a certain distortion phenomenon may occur when the speaker 1 plays the third audio data. However, since the user has set the audio data corresponding to the types of audio data 1 and audio data 2 to be allowed to mix in the mixing strategy corresponding to speaker 1, the distortion phenomenon that occurs when playing the third audio data is generally caused by the user's within the receiving range.
  • the audio data of audio data 1 and audio data 2 are used as an example to be mixed. It can be understood that when the AudioFlinger in the mobile phone receives three or more audio data channels Which audio data needs to be independently transmitted to the slave device and which audio data needs to be mixed before being transmitted to the slave device can be determined according to the method described in the foregoing embodiment, which is not limited in this embodiment of the present application.
  • the user can also manually modify the slave device currently performing audio switching with the mobile phone on the mobile phone.
  • the mobile phone is running the music APP
  • the mobile phone can display the control center 5901 in the application interface of the music APP.
  • the control center 5901 includes a switch button 5902 for the audio switch function.
  • the user wishes to modify the slave device of the current mobile phone, he or she may click the switch button 5902 to query one or more candidate devices that can currently be the slave device of the mobile phone. As shown in (b) of FIG.
  • the mobile phone can display one or more detected candidate devices in the control center 5902 .
  • the sound box in the control center 5902 has been marked as a selected state, that is, the sound box is playing audio from the mobile phone as a slave device (ie, the first slave device) of the mobile phone at this time. If the user needs to replace the slave device of the mobile phone, the user can re-select the slave device (ie, the second slave device) for audio switching in the control center 5902 .
  • the mobile phone can respond to the user's operation of selecting the car device in the control center 5902, disconnect the network connection established with the speaker 1, and establish a network connection with the car device. Similar to step S5001, after the mobile phone establishes a network connection with the vehicle, the audio capability parameters of the vehicle can be obtained through the DV APP, and a corresponding DMSDP Audio HAL can be created in the HAL according to the audio capability parameters of the vehicle. Alternatively, the mobile phone can update the DMSDP Audio HAL created for the speaker 1 in step S5001 according to the audio capability parameters of the car device, so that the updated DMSDP Audio HAL matches the audio capability of the car device.
  • the DV APP can obtain the identification of the vehicle to determine the current connection.
  • the second slave device is a vehicle-mounted device.
  • the DV APP can issue the pre-stored sound mixing strategy for in-vehicle devices to AudioPolicy as the sound mixing strategy 2 of the vehicle. Subsequently, the AudioPolicy may determine whether to mix the currently received audio data according to the audio mixing strategy 2 of the vehicle.
  • the sound mixing strategy 2 of the car and the machine can be as shown in Table 13. Different from the sound mixing strategy shown in Table 11, the sound mixing strategy 2 can also be set with one or more identifiers including applications, such as application.
  • the package name (Package Name). That is to say, in the audio mixing strategy 2, the mobile phone can also set the audio mixing capabilities of different applications for different types of audio data. For example, for the WeChat APP, the car does not allow to mix audio data of MUSIC type and COMMUNICATION type, but allows to mix audio data of NOTIFICATION type and DTMF type. For music apps, the car device does not allow mixing of MUSIC type audio data, etc.
  • the specific application included in the sound mixing strategy 2 may be preset by the developer.
  • the mobile phone can obtain the audio mixing strategy of the application in different audio output devices from the server, so that the mobile phone can dynamically update the audio output device of each audio output device according to the application installed in the mobile phone.
  • the sound mixing strategy is not limited in this embodiment of the present application.
  • the mobile phone when the mobile phone is running the WeChat APP, the MUSIC type and COMMUNICATION type audio data generated by the WeChat APP can be independently transmitted to the vehicle for playback, without mixing with other audio data received at the same time, thereby reducing the two The distortion rate of the audio data of the type when it is played on the car.
  • the mobile phone can use the application as the granularity to mix or not mix different types of audio generated by an application, so as to independently transmit the audio data with high sound quality requirements in an application to the slave device.
  • the original audio features of the audio data in the main device ie the mobile phone
  • the audio mixing policy shown in Table 14 may also be set in the AudioPolicy.
  • the audio mixing strategy sets device types that are not allowed to be mixed for different types of audio data in each application, that is, which types of audio output devices need to be independently transmitted when sending audio data. For example, when WeChat APP generates MUSIC type audio data, when the audio data needs to be played on audio output devices such as mobile phones, speakers, TVs or car devices, it is not allowed to mix the audio data with other audio data. . For another example, when the music APP generates the audio data of NOTIFICATION, the audio data can be mixed when played on any type of audio output device, that is, the device type for which mixing is not allowed is empty.
  • AudioPolicy can determine whether to mix various types of audio data generated by the running audio APP according to the mixing strategy shown in Table 14 and in combination with the device type of the current slave device.
  • audio output devices that allow sound mixing may also be set for different types of audio data in each application, which is not limited in this embodiment of the present application.
  • the user can also manually modify the current mixing strategy of the slave device in the mobile phone.
  • the WeChat APP can be opened to display the application interface 6100 of the WeChat APP. If it is detected that the user inputs an operation of opening the control center in the application interface 6100 , the mobile phone may display the control center 6101 in the application interface 6100 .
  • a card 6102 for audio switching is set in the control center 6101, and the card 6102 includes a setting button 6103 for audio switching. If it is detected that the user clicks the setting button 6103, as shown in (b) in FIG.
  • the DV APP can display the setting interface 6104 when the vehicle is used as a slave device. Similar to FIG. 54 , the switch button 6105 of the audio switching function can be set in the setting interface 6104 . After the user turns on the switch button 6105, the user can set in the setting interface 6104 what types of audio data the mobile phone allows to mix when the car is a slave device, or further set when the car is a slave device, the mobile phone allows certain types of audio data to be mixed Mix certain types of audio data in the app. Furthermore, the DV APP can update the vehicle sound mixing strategy 2 shown in Table 13 according to the user's selection in the setting interface 6104, so that the user can dynamically specify whether to perform sound mixing when each type of audio data is output to the slave device. .
  • AudioFlinger can request AudioPolicy to inquire whether the currently received audio data needs to be mixed. Furthermore, the AudioPolicy can determine whether to mix the current audio data according to the mixing strategy 2 issued by the DV APP.
  • the AudioFlinger of the mobile phone can simultaneously receive the NOTIFICATION type audio data A and DTMF type audio data B from the WeChat APP, and the MUSIC type audio data from the music APP at the same time. Audio data C.
  • AudioFlinger may request AudioPolicy to inquire whether audio data A, audio data B, and audio data C need to be mixed. Furthermore, AudioPolicy can determine that audio data A of the NOTIFICATION type and audio data B of the DTMF type can be mixed according to the mixing strategy 2 shown in Table 13, while the audio data C of the MUSIC type is not allowed to be mixed with other audio data. It is independently transmitted to the car machine to ensure the sound quality of the car machine when playing the MUSIC type audio data C.
  • AudioPolicy can send an instruction message to AudioFlinger, instructing AudioFlinger to mix audio data A and audio data B, but audio data C does not need to be mixed. Still as shown in Figure 60, AudioFlinger can respond to the instruction message, mix audio data A and audio data B into one channel of audio data (that is, audio data A+B), and output two channels of audio data, that is, the mixed audio. Data A+B and unmixed audio data C. Furthermore, AudioFlinger can call DMSDP Audio HAL to send the mixed audio data A+B and the unmixed audio data C to the car machine, and the car machine will play the above audio data A+B and audio data C.
  • the audio data C of the MUSIC type can be relatively independently transmitted to the slave device (that is, the car machine) without mixing processing, so that the audio data C received from the device can more truly reflect the original audio characteristics.
  • the audio distortion caused by the audio mixing process can reduce the distortion of multi-channel audio data when playing across devices, and improve the audio output quality of audio switching scenarios.
  • the audio data C can be packaged into data packets one by one. It is sent to the car machine in the form of a package.
  • the AudioFlinger in the mobile phone can package the audio data C according to the JSON (JavaScript Object Notation, Object Notation) protocol, and add the feature information of the audio data C to the data package.
  • JSON JavaScript Object Notation, Object Notation
  • the feature information may include the name of the application package to which the audio data C belongs, the playback type (eg game, movie, etc.), playback format (eg MP3, etc.), volume level, whether to mix, audio type (eg MUSIC type, etc.), Track information (such as the number of tracks, the serial number of the track, etc.).
  • the playback type eg game, movie, etc.
  • playback format eg MP3, etc.
  • volume level whether to mix
  • audio type eg MUSIC type, etc.
  • Track information such as the number of tracks, the serial number of the track, etc.
  • AudioFlinger can add feature information of corresponding audio data in the header file (head) of each data packet.
  • the data packets 1 and 2 encapsulated by AudioFlinger according to the JSON protocol can be as follows:
  • AudioFlinger can send the encapsulated data packets (for example, the above-mentioned data packets 1 and 2) to the DMSDP Audio HAL first, and the DMSDP Audio HAL decapsulates the above-mentioned data packets 1 and 2.
  • DMSDP Audio HAL can identify that data packet 1 is from the WeChat APP and data packet 2 is from the music APP by reading the characteristic information (such as the package name of the application) in data packet 1 and data packet 2, that is, data packet 1 and data packet 2 They belong to two channels of audio data. In this way, after the DMSDP Audio HAL unpacks each data packet sent by AudioFlinger, the corresponding unmixed two-channel audio data can be produced. Furthermore, the DMSDP Audio HAL can send these two audio data to the car machine for playback relatively independently.
  • the DMSDP Audio HAL after the DMSDP Audio HAL obtains the data packets that have been encapsulated by AudioFlinger, it can directly send the obtained data packets to the vehicle.
  • Each data packet received is unpacked by the car machine, so as to restore the corresponding unmixed two-channel audio data according to the feature information carried in each data packet.
  • the car machine can also select a corresponding playback mode according to the corresponding feature information to accurately restore the playback process of the two channels of audio data.
  • the car machine can use MP3 format to play the audio data corresponding to the above-mentioned data packet 1, and use the flac format to play the audio data corresponding to the above-mentioned data packet 2, so as to restore the audio data of the two channels when playing in the mobile phone as much as possible.
  • the audio characteristics can reduce the phenomenon of playback distortion in the audio switching scene.
  • the mobile phone switches all the audio data in the mobile phone to playback from the device (eg, a speaker) as an example. It can be understood that, in some embodiments, when AudioFlinger of the mobile phone receives multiple channels of audio data from different applications or the same application, AudioFlinger can also determine the audio of each channel of audio data in the multiple channels of audio data by interacting with AudioPolicy. output device.
  • the DV APP in the mobile phone can not only issue the above mixing strategy to AudioPolicy, but also issue the device selection strategy of the speaker to AudioPolicy , the device selection policy sets the type of audio data that the speaker is allowed to play and the type of audio data that the speaker is not allowed to play.
  • the speaker is allowed to play MUSIC type, NOTIFICATION type and RING type of audio data, but the speaker is not allowed to play the SYSTEM type and DTMF type of audio data.
  • the AudioFlinger of the mobile phone can simultaneously receive the NOTIFICATION type audio data A and DTMF type audio data B from the WeChat APP, and the MUSIC type audio from the music APP. data C. Furthermore, as shown in Figure 63, AudioFlinger can request AudioPolicy to query whether audio data A, audio data B, and audio data C are allowed to be played in the speaker, that is, the audio output device that negotiates audio data with AudioPolicy.
  • the AudioPolicy can determine, according to the above device selection policy, that the audio data A of the NOTIFICATION type and the audio data C of the MUSIC type can be played on the speaker, but the audio data B of the DTMF type is not allowed to be played on the speaker.
  • the AudioPolicy can also set an audio output device for the audio data B, for example, set the audio output device of the audio data B to be the mobile phone itself.
  • AudioPolicy can instruct AudioFlinger to output audio data A and audio data C to the speaker for playback, and output audio data B to the speaker of the mobile phone for playback.
  • AudioFlinger can determine that audio data A and audio data C need to be sent to speakers for playback according to the instruction of AudioPolicy. At this time, in order to ensure the audio quality of audio data A and audio data C played on the speaker, AudioFlinger can request AudioPolicy to inquire whether audio data A and audio data C need to be mixed, that is, to negotiate with AudioPolicy whether to mix audio data. . Furthermore, AudioPolicy can determine whether audio data A and audio data C need to be mixed according to the mixing strategy issued by the DV APP according to the method in the above-mentioned embodiment.
  • the mobile phone can perform the method described in steps S5005-5006, and send the audio data A and the audio data C to the speakers for playback relatively independently ( Not shown in Figure 63); if audio data A and audio data C need to be mixed, as shown in Figure 63, the mobile phone can perform the method as described in steps S5007-5009 to mix audio data A and audio data C One channel of audio data A+C obtained after mixing is sent to the speaker for playback.
  • AudioPolicy determines that the audio output device of audio data A and audio data C is a speaker according to the above device selection strategy, and the audio output device of audio data B is a mobile phone, since the speaker needs to play multiple audio data at the same time, AudioPolicy It can be further determined whether audio data A and audio data C need to be mixed according to the mixing strategy issued by the DV APP. Further, AudioPolicy can indicate to AudioFlinger that the audio output device of audio data A and audio data C is a speaker, and whether audio data A and audio data C need to be mixed, and indicate to AudioFlinger that the audio output device of audio data B is a mobile phone.
  • AudioFlinger can output audio data B to the speaker of the mobile phone through the Primary HAL for playback, and AudioFlinger can output the unmixed audio data A and audio data C (or the mixed audio data A+C through the DMSDP Audio HAL) ) to the speakers for playback.
  • the mobile phone when the mobile phone needs to switch the multi-channel audio data generated at the same time to the slave device for playback, the mobile phone can not only select the corresponding audio output device for different audio data according to the current device selection strategy of the slave device, but also can select the corresponding audio output device according to the current slave device selection strategy.
  • the mixing strategy of the device determines the audio data that needs to be independently transmitted in the multi-channel audio data played on the same audio output device, so as to avoid the distortion of a certain type of audio data caused by the mixing process, and improve the audio frequency of the audio switching scene. output quality.
  • the master device may be an electronic device with a split-screen display function (also referred to as a split-screen function).
  • the split-screen function means that when the main device displays on its own display screen, multiple windows can be created, and corresponding applications, software or programs can be executed and displayed in each window.
  • the user can trigger the mobile phone to enter the split-screen mode through a preset operation (such as long-pressing the screen, etc.).
  • a preset operation such as long-pressing the screen, etc.
  • the mobile phone in the split screen mode, can divide the display area in the display screen into a window 6401 and a window 6402 .
  • the status bar of the mobile phone may be displayed in the window 6401 or the window 6402, or, the status bar of the mobile phone may also be hidden in the split-screen mode, which is not limited in this embodiment of the present application.
  • Window 6401 and window 6402 can be used to run and display the corresponding application respectively, or, window 6401 and window 6402 can also run and display different tasks of the same application respectively, for example, window 6401 can display the chat with contact Amy in the WeChat APP At the same time, the window 6402 can display the chat interface with the contact Mike in the WeChat APP.
  • the mobile phone may also divide the display area into three or more windows, which is not limited in this embodiment of the present application.
  • the window 6401 can run the first video APP
  • the window 6402 can run the second video APP.
  • the first video APP can create one or more audio tasks when running, for example, audio task 1 for playing video A, and audio task 2 for playing a notification message.
  • the second video APP can also create one or more audio tasks when running.
  • each window displayed by the main device may be associated with an audio output device. That is, the audio data output by the audio task in each window can be played using the audio output device associated with that window.
  • the association relationship between the window and the audio output device may be set by the user. For example, if the user settings window A is associated with a wired headset. Then, when the audio task created by the application in the window A outputs the corresponding audio data, the mobile phone can send the audio data to the wired headset connected to the mobile phone for playback. In some embodiments, the mobile phone can also modify the association between the window and the audio output device.
  • the mobile phone can re-determine the audio output device associated with window A. For example, the mobile phone can determine the mobile phone as The audio output device associated with the window A, and then the mobile phone can send the audio data output in the window A to the speaker of the mobile phone for playback. Or, if the wired headset does not support playing the audio data in the current window A, for example, some wired headsets with lower configuration may not support playing the audio data in high-definition format, the mobile phone can re-determine the audio output device associated with the window A, And send the audio data to the associated audio output device for playback.
  • the mobile phone can also modify the association relationship between the window and the audio output device in response to the user's setting, which is not limited in this embodiment of the present application.
  • the mobile phone can display a first dialog 6501 in the window 6401 , and prompt the user to select an audio output device associated with the window 6401 in the first dialog 6501 .
  • the mobile phone may display in the first dialog 6501 an electronic device with an audio playback function that is in the same Wi-Fi network as the mobile phone or has established a connection with the mobile phone.
  • the user can select the audio output device associated with the window 6401 in the first dialog 6501 (ie, a slave device of the mobile phone).
  • the mobile phone can establish an association relationship between the window 6401 and the Bluetooth headset. Subsequently, the mobile phone can send the audio data output by the audio task in the window 6401 to the Bluetooth headset for playback.
  • the above-mentioned first dialog 6501 may be automatically displayed in the window 6401 after the mobile phone enters the split screen mode, or may be displayed in the window 6401 by the user triggering the mobile phone through a certain key or gesture after the mobile phone enters the split screen mode.
  • the mobile phone can also display a second dialog 6502 in the window 6402 , and prompt the user to select an audio output device associated with the window 6402 in the second dialog 6502 .
  • the mobile phone may display in the second dialog 6502 an electronic device with an audio playback function that is in the same Wi-Fi network as the mobile phone or has established a connection with the mobile phone. In this way, the user can select the audio output device associated with the window 6402 in the second dialog 6502 (ie, another slave device of the cell phone).
  • the mobile phone can establish an association between the window 6402 and the speaker. Subsequently, the mobile phone can send the audio data output by the audio task in the window 6402 to the speaker for playback.
  • the second dialog box 6502 may be automatically displayed in the window 6402 after the mobile phone enters the split screen mode, or may be displayed in the window 6402 by the user triggering the mobile phone through a certain key or gesture after the mobile phone enters the split screen mode.
  • the associated audio output device set by the user for window 6401 may be the same as the associated audio output device set by the user for window 6402, eg, the user selected Local in the first dialog 6501, and , the user also selects the local machine in the second dialog box 6502 .
  • the mobile phone can display a prompt message 6601, which is used to prompt the user to associate the window 6401 and the window 6402 to the same audio output device (ie, the mobile phone). Subsequently, the mobile phone can mix the audio data corresponding to the window 6401 and the audio data corresponding to the window 6402 and output it to the local speaker for playback.
  • the mobile phone may further provide the user with an entry for modifying the association relationship between different windows and different audio output devices. For example, as shown in (a) of FIG. 67 , the mobile phone may display the first switching button 6701 of the audio output device in the window 6401 , and the mobile phone may display the second switching button 6702 of the audio output device in the window 6402 . If it is detected that the user clicks the first switch button 6701, similar to FIG. 65, the mobile phone can display one or more electronic devices with audio playback function detected at this time in a dialog box 6703 for the user to select.
  • the mobile phone can respond to the user's Operation, modify the association relationship between the window 6401 and the Bluetooth headset to the association relationship between the window 6401 and the mobile phone.
  • the mobile phone can display one or more electronic devices with audio playback function detected at this time in the dialog 6704 for users to choose. If the user selects an electronic device other than a speaker, for example, the user selects a TV in the dialog box 6704, indicating that the user wants the audio data output by the audio task in the TV playback window 6402, the mobile phone can respond to the user's operation and display the window 6402 The relationship with the speaker is modified to the relationship between the window 6402 and the TV.
  • switch buttons eg, the first switch button 6701 and the second switch button 6702
  • those skilled in the art can also set other ways to modify the association between the window and the audio output device. For example, if it is detected that the user inputs a long press operation in the window 6402, the mobile phone can display the above-mentioned dialog 6704 so that the user can modify the audio output device corresponding to the window 6402, which is not limited in this embodiment of the present application.
  • the mobile phone can save the audio output device set by the user for each window, that is, save the association relationship between different windows and different audio output devices.
  • the mobile phone can send the audio data corresponding to the window to the corresponding audio output device for playback according to the saved relationship between the window and the audio output device.
  • the mobile phone can also obtain the association relationship between different windows and different audio output devices from the server.
  • the mobile phone can also automatically set the audio output device associated with the window according to the type of application or the type of audio data in different windows. For example, if the audio task created by the music APP in the window 6402 outputs MUSIC type audio data, the mobile phone can automatically send the MUSIC type audio data to the speaker for playback, which is not limited in this embodiment of the present application.
  • the main device eg, a mobile phone
  • the mobile phone can send the audio data output by the related audio tasks in each window to the corresponding audio output device for playback.
  • the multi-channel audio data concurrently generated by the main device will not interfere with each other, and the multi-channel audio data can be played to different users through different audio output devices, and each user can use the audio output device associated with the relevant window to listen to the corresponding Audio data will not be affected by audio data from other windows, thereby improving the user's audio experience.
  • FIG. 6 shows a schematic diagram of the architecture of the Android system in the mobile phone, wherein the Android system is provided with an audio architecture 601 that implements an audio function.
  • the Android system is further provided with a display architecture 6801 that implements a display function.
  • the display framework 6801 may include a window manager (WindowManager) and a display module.
  • the video APP can output a series of drawing instructions of the display data to be displayed to the window manager.
  • the drawing instruction may be an OpenGL instruction or the like.
  • the window manager can create a corresponding display module, and draw corresponding display data in the display module according to the drawing instruction issued by the video APP.
  • the window manager can query whether the current phone is in split-screen mode. If not in split-screen mode, the window manager can create a display module that provides display data to the display.
  • the window manager may draw the display data to be displayed by the video APP in the above-mentioned display module according to the received drawing instruction.
  • the window manager can send the display data in the above display module to the display screen for display through the Display HAL. That is to say, in the non-split screen mode, the mobile phone can use the entire display area in the display screen as a window to display the display data of the video APP.
  • the window manager can create multiple display modules, each of which corresponds to a window in the display. For example, as shown in FIG. 68, in the split-screen mode, the mobile phone can divide the display area in the display screen into two windows by default. Then, if the user input is detected to enable the split-screen mode, the window manager can create Display module 1 corresponding to window 1 and display module 2 corresponding to window 2.
  • the display module 1 can be understood as a virtual storage space for storing the display data to be displayed in the window 1; similarly, the display module 2 can also be understood as a virtual storage space for storing the display data to be displayed in the window 2 data.
  • the window manager can draw the corresponding display data 1 in the display module 1 according to the drawing instruction. Subsequently, the window manager may send the display data 1 in the above-mentioned display module 1 to the window 1 in the display screen through the Display HAL for display.
  • an application such as a music APP
  • the window manager can draw the corresponding display data 2 in the display module 2 according to the drawing instruction, and send the display data 2 in the display module 2 to the window 2 in the display screen for display through the Display HAL. In this way, in the split-screen mode, the mobile phone can display the display data of the relevant application in each window with a granularity of windows.
  • Display HAL can periodically obtain the corresponding 2 channels of display data from display module 1 and display module 2, combine these 2 channels of display data into one channel of display data corresponding to the entire display screen, and combine the display data of this channel sent to the display for display.
  • the user may input a preset split-screen operation to the mobile phone (ie, the main device) to trigger the mobile phone to enter the split-screen mode.
  • the mobile phone ie, the main device
  • the mobile phone can enter the split-screen mode in response to this operation.
  • the mobile phone can automatically divide the display screen into two windows, namely the first window 6901 and the second window 6902.
  • the first window 6901 can be used to continue running the WeChat APP
  • the second window 6902 can be used to display the desktop of the mobile phone.
  • the user can use various functions provided by the mobile phone in the first window 6901 , and can also use various functions provided by the mobile phone in the second window 6902 .
  • the WeChat APP can send an instruction message to the window manager to instruct the window manager to enter the split-screen mode. .
  • the window manager can respond to the instruction message to create a display module 1 corresponding to the first window 6901 and a display module 2 corresponding to the second window 6902.
  • the display module 1 and the display module 2 can pass through different display ID distinction.
  • the display module 1 is used to provide corresponding display data to the first window 6901
  • the display module 2 is used to provide corresponding display data to the second window 6902 .
  • the window manager can receive the drawing instruction from the WeChat APP, and draw the display corresponding to the WeChat APP in the display module 1 according to the drawing instruction data. Moreover, the window manager may draw the display data 2 of the desktop in the display module 2 by default. Subsequently, the Display HAL in the HAL can combine the display data 1 in the display module 1 and the display data 2 in the display module 2 into the display data 3 of the entire display screen, and send the display data 3 to the display screen of the mobile phone to make the display screen The display interface shown in (b) of FIG. 69 is displayed.
  • the mobile phone can also run the WeChat APP in the second window 6902 and the desktop in the first window 6901 .
  • the mobile phone can also run other applications by default in the window other than the WeChat APP, which is not limited in this embodiment of the present application.
  • the Android system currently has an Audio Focus preemption mechanism, and only one application can hold the audio focus at a time.
  • the application that gets the audio focus has the permission to play the audio.
  • application 1 can call the requestAudioFocus() interface to obtain the audio focus, and the application 1 (which may be referred to as an audio focus application) that obtains the audio focus can start to execute the audio task and play corresponding audio data.
  • application 1 can call awayAudioFocus() to release the above-mentioned audio focus (also called out of focus), and stop playing the corresponding audio data.
  • application 1 when application 1 holds the audio focus, if application 2 calls the requestAudioFocus() interface to apply for the above-mentioned audio focus, then application 1 can also release the above-mentioned audio focus, so that application 2 acquires this application 2 and becomes the current audio-focus application .
  • the mobile phone can set an audio focus (Audio Focus) for each window in the split-screen mode.
  • the above-mentioned first window 6901 may correspond to audio focus 1
  • the above-mentioned second window 6902 may correspond to audio focus 2.
  • the audio focus application that has acquired audio focus 1 in the first window 6901 can start to perform related audio tasks
  • the audio focus application that has acquired audio focus 2 in the second window 6902 can start to perform related audio tasks, so that each Audio tasks between windows will not interfere with each other.
  • audio data output by audio tasks in different windows can also be distributed to different audio output devices for playback, so that audio data between windows will not interfere with each other.
  • the window manager can be used to manage the acquisition and release process of the audio focus 1 in the first window 6901 and the acquisition and release process of the audio focus 62 in the second window 902 .
  • the window manager can create and maintain the correspondence between each window and the audio-focused application.
  • the ID of the display module 1 corresponds to the package name of the WeChat APP, that is, the audio focus application in the first window 6901 is the WeChat APP, and the WeChat APP currently holds the audio focus 1 of the first window 6901; display
  • the ID of the module 2 corresponds to the package name of the desktop, that is, the audio focus application in the second window 6902 is the desktop, and the desktop currently holds the audio focus 2 in the second window 6902 .
  • the video APP can call the requestAudioFocus() interface to apply to the window manager to obtain the audio of the second window 6902 Focus 2.
  • the window manager can modify the application package name corresponding to the ID of the display module 2 in Table 15 to the video APP package name, so that the desktop in the second window 6902 releases the audio focus 2, and simultaneously makes the second window 6902 The video app in get audio focus 2.
  • the window manager can determine the specific application corresponding to each current window by recording the audio focus application corresponding to each display module.
  • multiple applications may also run in one window.
  • foreground applications and background applications can be set in each window at the granularity of the window.
  • the WeChat APP can be run in the foreground of the first window 6901
  • the music APP can be run in the background of the first window 6901.
  • a video APP can be run in the foreground of the second window 6902
  • a sports APP can be run in the background of the second window 6902.
  • the applications corresponding to the display module 1 include the WeChat APP and the music APP
  • the applications corresponding to the display module 2 include the video APP and the sports APP.
  • Display ID The package name of the foreground application and/or background application ID of display module 1 Package name of WeChat APP, package name of Music APP ID of display module 2 Package name of video APP, package name of sports APP
  • the corresponding relationship between the display module and the application shown in Table 15 or Table 16 may be referred to as the application information of each window, and the window manager may be used to record and maintain the application information of each window, so that the mobile phone Specific applications running in each window can be determined according to the application information.
  • the window manager can also set the corresponding audio output device for each window with the window as the granularity.
  • the mobile phone may be connected to one or more audio output devices, that is, there may be one or more slave devices of the mobile phone.
  • a mobile phone can establish a Bluetooth connection with a Bluetooth headset, and the mobile phone can also establish a network connection with a speaker and a TV through a Wi-Fi network.
  • the mobile phone's own speaker can also be used as an audio output device to play audio.
  • the slave device can be registered in the audio policy module, for example, register the slave device's ID, device name, device model or device type, etc. Then, the audio manager of the mobile phone can inquire about the specific audio output devices currently available to the mobile phone in the audio strategy module.
  • the audio manager can query the audio strategy module for an available one of the current mobile phone. or multiple audio output devices, and notify the window manager of the queried audio output devices. Furthermore, as shown in FIG.
  • the window manager can display a first dialog 7101 in the first window 6901 running the WeChat APP, and the first dialog 7101 includes one or more audio output devices currently available on the mobile phone; and, The window manager can display a second dialog 7102 in the second window 6902 running the video APP, and the second dialog 7102 also includes one or more audio output devices currently available on the mobile phone. In this way, the user can select the audio output device associated with the first window 6901 in the first dialog 7101, and the user can select the audio output device associated with the second window 6902 in the second dialog 7102.
  • the window manager can create The association between the display module 1 and the Bluetooth headset, that is, the first window 6901 is associated with the Bluetooth headset; if it is detected that the user selects a speaker in the second dialog 7102, it means that the user wants the audio data output by the audio task in the second window 6902 If it is played by the speaker, as shown in Table 17, the window manager can establish an association relationship between the display module 2 and the speaker, that is, the second window 6902 is associated with the speaker. In this way, as shown in Table 17, the window manager can establish and maintain the correspondence between different windows and different audio output devices in the split-screen mode.
  • the window manager may further set the type of audio data allowed to be played by the corresponding audio output device.
  • the types of audio data can be divided into: ALARM (alarm), MUSIC (music), RING (ringtone), SYSTEM (system), NOTIFICATION (notification), DTMF ( Dual-tone multi-frequency), COMMUNICATION (communication) and VOICE_CALL (call) and other types.
  • the window manager may set the audio output device associated with the first window 6901 to a Bluetooth headset, and the window manager may set the Bluetooth headset to allow the playback of MUSIC (music) type and NOTIFICATION (notification) type
  • the audio data is not allowed to play RING (ringtone) type audio data.
  • MUSIC (music) type or NOTIFICATION (notification) type audio data is generated in the first window 6901
  • the audio data can be output to the Bluetooth headset for playback.
  • the window manager can also set the audio output device associated with the first window 6901 by default to allow all types of audio data to be played, which is not limited in this embodiment of the present application.
  • the window manager may only set the type of audio data that the audio output device is allowed to play in Table 18, and other types of audio data are the audio data that the audio output device is not allowed to play; In Table 18, only the types of audio data that are not allowed to be played by the audio output device are set. At this time, other types of audio data are the audio data that are allowed to be played by the audio output device.
  • the user can also manually modify the audio output device associated with each window, as well as the types of audio data that the audio output device allows or does not allow to play.
  • the mobile phone may display a first setting button 7201 in the first window 6901 .
  • the first setting button 7201 may be a floating button. If it is detected that the user clicks the first setting button 7201, as shown in (b) of FIG. 72, the mobile phone may display the first setting menu 7202. In the first setting menu 7202, the user can reset the audio output device associated with the first window 6901. And, in the first setting menu 7202, the user can also set the type of audio data that the audio output device associated with the current window allows or does not allow to play.
  • the mobile phone can also display the second setting button 7301 in the second window 6902 . If it is detected that the user clicks the second setting button 7301, as shown in (b) of FIG. 73, the mobile phone may display the second setting menu 7302. In the second settings menu 7302, the user can reset the audio output device associated with the second window 6902. And, in the second setting menu 7302, the user can also set the type of audio data that the audio output device associated with the current window allows or does not allow to play.
  • the window manager may update the correspondence between different windows, audio output devices, and audio data types allowed or not allowed in the table 18 according to the user's selection in the first setting menu 7202 or the second setting menu 7302.
  • the user can set the audio output device of each window and the specific audio data output on the audio output device according to his own needs, so that the audio data in each window can be distributed by the mobile phone to the corresponding device according to the user's settings. playback on the audio output device.
  • the window manager may further set the volume of the corresponding types of audio data in each window when playing.
  • the audio output device corresponding to the display module 1 ie, the first window 6901
  • the audio output device corresponding to the display module 1 is a Bluetooth headset, which allows playing audio data of MUSIC (music) type and NOTIFICATION (notification) type.
  • the volume level when playing audio data of the MUSIC (music) type is level 15, and the volume level when playing the audio data of the NOTIFICATION (notification) type is level 10.
  • the audio output device corresponding to the display module 2 ie, the second window 6902 ) is a speaker, and the speaker allows playing audio data of MUSIC (music) type, RING (ringtone) type and NOTIFICATION (notification) type.
  • the volume level when playing the MUSIC (music) type audio data is 12
  • the volume level when playing the RING (ringtone) type audio data is 8
  • the volume level when playing the NOTIFICATION (notification) type audio data is
  • the user can manually modify the volume of the corresponding types of audio data in each window when playing.
  • the WeChat APP when the mobile phone runs the WeChat APP in the first window 6901, if it receives a new message sent by the contact Sara, the WeChat APP can generate a notification tone of NOTIFICATION type.
  • the user can trigger the mobile phone to display the volume adjustment bar 7401 in the first window 6901 through a preset gesture. In this way, the user can adjust the volume of the notification sound in the first window 6901 by adjusting the position of the slider on the volume adjustment bar 7401.
  • the window manager can modify the volume level of the audio data of the NOTIFICATION type corresponding to the display module 1 in Table 19 according to the position of the slider on the volume adjustment bar 7401.
  • the user can also trigger the window manager to modify the MUSIC (music) corresponding to the display module 1 through the volume adjustment bar 7401 in the first window 6901.
  • the volume level of the type of audio data when there is no audio task being played in the first window 6901, if it is detected that the user adjusts the position of the slider in the volume adjustment bar 7401, the window manager can modify a certain type corresponding to the display module 1 by default (for example, MUSIC type) volume level of the audio data.
  • the window manager may also modify the volume level of a certain type of audio data corresponding to the display module 1 by default.
  • the volume adjustment bar 7402 can also be displayed in the second window 6902 . Since the audio data generated when the video APP runs is MUSIC (music) audio data, if the mobile phone detects that the user adjusts the slider on the volume adjustment bar 7402, the window manager can adjust the slider on the volume adjustment bar 7402 according to the The volume level of the audio data of the MUSIC (music) type corresponding to the display module 2 in the position modification table 19.
  • MUSIC music
  • the user can also trigger the window manager to modify the RING (ringtone) corresponding to the display module 2 through the volume adjustment bar 7402 in the second window 6902.
  • the volume level of the type of audio data If the audio data of the NOTIFICATION (notification) type is being played in the second window 6902, the user can also trigger the window manager to modify the NOTIFICATION (notification) type corresponding to the display module 2 through the volume adjustment bar 7402 in the second window 6902. The volume level of the audio data.
  • the window manager can modify a certain type corresponding to the display module 2 by default (for example, the MUSIC type ) of the audio data volume level.
  • the window manager may also modify the volume level of a certain type of audio data corresponding to the display module 2 by default.
  • the mobile phone can also set the option of modifying the volume of various types of audio data in the above-mentioned first setting menu 7202 or second setting menu 7302, so that the user can manually set various types of audio data to be played on different windows and different audio output devices.
  • the volume at the time is not limited in this embodiment of the present application.
  • the specific audio configuration content including the association relationship between different windows and different audio output devices shown in Tables 17 to 19 may be referred to as audio configuration information of each window.
  • the audio configuration information of the first window 6901 includes the associated audio output device, and may further include the type of audio data that is allowed and/or not allowed to be played by the audio output device, and the audio data that is allowed to be played. volume level, etc.
  • the window manager can establish and maintain application information of each window (for example, the correspondence between different display modules and corresponding applications shown in Table 15 or Table 16), and the window manager can Audio configuration information for each window (eg, the audio configuration information shown in any of Tables 17 to 19) may be established and maintained.
  • the mobile phone can manage the audio data corresponding to each window with the window as the granularity according to the application information and audio configuration information of the above-mentioned windows, so that the audio data in each window can be The audio data output by the task will not interfere with each other.
  • the window manager in the split-screen mode, can send the application information and audio configuration information of the above-mentioned respective windows to the audio manager, for example, to the audio policy module of the audio manager (for example, to the audio policy module of the audio manager). AudioPolicy). Moreover, when the window manager detects that the application information or audio configuration information of a window has changed, the window manager can dynamically update the application information or audio configuration information of the window, and update the latest application information and audio configuration information of each window. Information is sent to AudioPolicy.
  • the audio focus application in the first window 6901 as the WeChat APP and the audio focus application in the second window 6902 as the video APP, if it is detected that the user clicks the play button of the video APP in the second window 6902, the video APP on the one hand
  • An audio task 1 that plays audio data in a video can be created, and a display task 1 that plays display data in a video can be created on the other hand.
  • the video APP can send the relevant drawing instructions (dotted arrows from the video APP in Figure 75) to the window manager, because the window manager has already created the display module 2
  • the corresponding relationship between the display module 2 and the second window 6902 is established. Therefore, after the window manager receives the drawing instruction issued by the video APP in the second window 6902, it can be downloaded in the corresponding display module 2 according to the video APP.
  • the sent drawing instruction draws the display data 1 of the video APP.
  • the video APP can create a corresponding audio player 1 (for example, AudioTrack 1), and send the audio data 1 to be played by the video APP to AudioTrack 1.
  • AudioTrack 1 can send the audio data 1 from the video APP to an audio processor (such as AudioFlinger), and the AudioFlinger will sample the audio data 1, add sound effects and other processing.
  • AudioFlinger after AudioFlinger receives audio data 1, it can send a query request to AudioPolicy to request AudioPolicy to query the specific audio output device of audio data 1.
  • a video APP when creating AudioTrack 1, a video APP can associate AudioTrack 1 with the video APP, for example, establish a correspondence between AudioTrack 1 and the package name of the video APP.
  • AudioFlinger receives audio data 1, it can determine that the received audio data 1 is video data from the video APP according to the above-mentioned corresponding relationship.
  • AudioFlinger can carry the package name of the video APP in the above query request and send it to AudioPolicy.
  • AudioPolicy After AudioPolicy receives the query request sent by AudioFlinger, it can query which window the video APP is running in according to the package name of the video APP in the query request. For example, as shown in Table 15, if the package name of the video APP corresponds to the ID of the display module 2, it means that the video APP is the audio focus application currently running in the second window 6902, that is, the video APP holds the audio focus application in the second window 6902. Audio focus 2, with playback rights to play audio data. Furthermore, the AudioPolicy can determine the audio output device corresponding to the display module 2 according to the audio configuration information of each window delivered by the window manager.
  • the AudioTrack 1 created by the video APP may also be associated with the process ID of the video APP.
  • multiple processes may be created, that is, the video APP can correspond to multiple process IDs, and the audio tasks created in each process can correspond to the corresponding AudioTrack.
  • the window manager can send the window, the audio focus application, and the corresponding relationship between different process IDs in the audio focus application to AudioPolicy.
  • AudioPolicy can also determine that audio data 1 is audio data from a video APP according to the process ID associated with AudioTrack 1. Further, the AudioPolicy can query the specific window in which the video APP is running according to the above method, that is, the display module corresponding to the video APP.
  • AudioPolicy can determine the audio corresponding to the display module 2 according to the audio configuration information shown in Table 17.
  • the output device is a speaker.
  • AudioPolicy can send an instruction message to AudioFlinger, where the instruction message is used to instruct AudioFlinger to send the processed audio data 1 to the speaker for playback through the DMSDP Audio HAL.
  • the query request sent by AudioFlinger to AudioPolicy may also carry the type identifier of audio data 1, for example, audio data 1 is MUSIC (music) audio data.
  • AudioPolicy determines that audio data 1 corresponds to display module 2
  • AudioPolicy can determine that the audio output device corresponding to display module 2 is a speaker according to the audio configuration information shown in Table 18.
  • the AudioPolicy can determine that the speaker is allowed to play MUSIC (music) type audio data according to the audio configuration information shown in Table 18, that is, the speaker is allowed to play the above-mentioned audio data 1.
  • AudioPolicy can send an instruction message to AudioFlinger, where the instruction message is used to instruct AudioFlinger to send the processed audio data 1 to the speaker for playback through the DMSDP Audio HAL.
  • AudioPolicy may re-determine the audio output device of audio data 1. For example, AudioPolicy can play audio data 1 by default using the speaker of this unit as the audio output device. Alternatively, the AudioPolicy can use the audio output device recently connected to the mobile phone except the speaker as the audio output device of the audio data 1. Of course, the AudioPolicy can also determine that the audio output device of the audio data 1 is empty, that is, no audio output device is used to play the audio data 1, which is not limited in this embodiment of the present application.
  • AudioPolicy determines that the audio data 1 from the video APP corresponds to the display module 2 according to the audio configuration information shown in Table 19.
  • the audio output device is a speaker.
  • the AudioPolicy can determine that the speaker is allowed to play audio data of the MUSIC (music) type according to the audio configuration information shown in Table 19, and the volume level during playback is 12.
  • AudioPolicy can send an instruction message to AudioFlinger, which can not only instruct AudioFlinger to send the processed audio data 1 to the speaker to play through the DMSDP Audio HAL, but also be used to indicate that the volume level of the audio data 1 is 12. In this way, in response to the instruction message, AudioFlinger can amplify or reduce the gain of the audio signal in the audio data 1 according to the 12-level volume level, and send the output audio data 1 to the speaker for playback through the DMSDP Audio HAL.
  • a scenario where multiple audio tasks in multiple windows are played concurrently may occur in the split-screen mode. For example, as shown in FIG. 76, while the video APP in the second window 6902 creates the above-mentioned audio task 1 and plays the video, if the user clicks the voice message 7601 in the WeChat APP in the first window 6901, the WeChat APP on the one hand An audio task 2 that plays the voice message 7601 can be created, and a display task 2 that displays the application interface in the WeChat APP can be created on the other hand.
  • the WeChat APP can send the relevant drawing instructions (the dotted arrow from the WeChat APP in Figure 75) to the window manager. Since the window manager has established the corresponding relationship between the display module 1 and the first window 6901 when the display module 1 is created, after the window manager receives the drawing instruction issued by the WeChat APP in the first window 6901, the window The manager can draw the display data 2 corresponding to the application interface of the WeChat APP in the corresponding display module 1 according to the drawing instruction issued by the WeChat APP.
  • the Display HAL in the HAL can periodically obtain corresponding display data from the display module 1 and the display module 2 according to a certain frame rate. Take Display HAL to obtain the above display data 2 from display module 1, and obtain the above display data 1 from display module 2 as an example,
  • Display HAL can synthesize display data 1 and display data 2 into display data 3 corresponding to the display screen of the mobile phone. Further, the Display HAL can send the display data 3 to the display screen of the mobile phone for display, so that the display screen can display the first window 6901 and the second window 6902 as shown in FIG. 76 .

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
US18/013,904 US20230297324A1 (en) 2020-07-02 2021-07-01 Audio Control Method, System, and Electronic Device
EP21833204.7A EP4167580A4 (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
CN202010700459.8 2020-07-20
CN202010701720 2020-07-20
CN202010701720.6 2020-07-20
CN202010700459 2020-07-20
CN202010718939 2020-07-23
CN202010718939.7 2020-07-23
CN202010774729 2020-08-04
CN202010774729.X 2020-08-04
CN202010847900 2020-08-21
CN202010847900.5 2020-08-21
CN202011058010.2 2020-09-29
CN202011058010 2020-09-29
CN202011149031.5 2020-10-23
CN202011149031 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
EP4167580A4 (en) 2023-11-29
EP4167580A1 (en) 2023-04-19
US20230297324A1 (en) 2023-09-21

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
CN112398855B (zh) 应用内容跨设备流转方法与装置、电子设备
AU2013211541B2 (en) Mobile apparatus and control method thereof
KR20110054609A (ko) 블루투스 디바이스의 원격 제어 방법 및 장치
WO2022143883A1 (zh) 一种拍摄方法、系统及电子设备
US11870941B2 (en) Audio processing method and electronic device
WO2022135527A1 (zh) 一种视频录制方法及电子设备
US20170195817A1 (en) Simultaneous Binaural Presentation of Multiple Audio Streams
JP2022546542A (ja) 通話方法、通話装置、通話システム、サーバ及びコンピュータプログラム
CN114697527A (zh) 一种拍摄方法、系统及电子设备
WO2022156721A1 (zh) 一种拍摄方法及电子设备
CN115167802A (zh) 一种音频切换播放方法及电子设备
EP4152756A1 (en) Device recommendation method and electronic device
WO2022002218A1 (zh) 一种音频控制方法、系统及电子设备
WO2023185589A1 (zh) 音量控制方法及电子设备
US20240214512A1 (en) Systems and methods for wireless real-time multi-channel audio and video integration
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