Audio processing method and device

Abstract

The embodiment of the invention provides an audio processing method and device, and relates to the technical field of terminals. The method comprises the following steps: a first electronic device creates a first player in response to a request for creating the first player; the first electronic equipment binds the first player with a first thread, wherein the first thread corresponds to the first audio type; the first electronic device creates the second player in response to the request for creating the second player; and the first electronic equipment binds the second player with a second thread, wherein the second thread corresponds to the second audio type. It can be understood that the first electronic device can achieve shunting for different audio types by creating different lines for different audio types and creating different players for different audio types. The audio types are classified, so that the audio data under different audio types can be played in different playing forms, and the playing flexibility of the audio data is improved.

Description

Technical Field

[0001] This application relates to the technical field of terminals, and in particular, to an audio processing method and apparatus. Background Art

[0002] With the rapid development of electronic technology, various electronic technologies have gradually been applied to vehicles, making vehicles more and more intelligent, and various types of interaction methods have gradually been integrated into vehicles. For example, before driving a vehicle, a user can interconnect an electronic device and a car machine. After the connection is successfully established, the user can view content such as navigation or music provided by the electronic device on the car machine screen; alternatively, some car machines can also download audio applications (applications, APPs) or navigation APPs based on their own devices to present content such as navigation or music, and enjoy a safer and more convenient in-vehicle experience during driving.

[0003] However, the playback form of audio data by the car machine is relatively single, which affects the user experience. Summary of the Invention

[0004] Embodiments of this application provide an audio processing method and apparatus. An electronic device can set different audio types for audio data from different applications and different audio types, and a car machine can set different playback methods according to the audio types to improve the flexibility of audio data playback.

[0005] In a first aspect, embodiments of this application provide an audio processing method. The method includes: a first electronic device receives a device connection event of a second electronic device, creates a first thread, and creates a second thread; the first electronic device receives a first operation on a first application; after receiving the first operation, the first electronic device receives a request to create a first player, and the request to create the first player carries: a first media type and an identifier of the first application; the first electronic device creates a first player in response to the request to create the first player; the first electronic device binds the first player to the first thread, and the first thread corresponds to a first audio type; the first electronic device receives a second operation on a second application; after receiving the second operation, the first electronic device receives a request to create a second player, and the request to create the second player carries: the first media type and an identifier of the second application; the first electronic device creates a second player in response to the request to create the second player; the first electronic device binds the second player to the second thread, and the second thread corresponds to a second audio type.

[0006] The first electronic device may be the electronic device (such as a mobile phone) described in the embodiments of this application, and the second electronic device may be the car machine described in the embodiments of this application.

[0007] The first thread may be the playback thread 1 described in the embodiments of the present application. The first application may be the media application described in the embodiments of the present application. The first operation may be the operation of playing music audio data in the media application. The first player may be the audio player 1 described in the embodiments of the present application. The first media type may be the media type described in the embodiments of the present application. The identifier of the first application may be the package name of the media application or the UID of the media application. The first audio type may be the music shunt type described in the embodiments of the present application.

[0008] The second thread may be the playback thread 2 described in the embodiments of the present application. The second application may be the navigation application described in the embodiments of the present application. The second operation may be the operation of playing navigation audio data in the navigation application. The second player may be the audio player 2 described in the embodiments of the present application. The identifier of the second application may be the package name of the navigation application or the UID of the navigation application. The second audio type may be the navigation shunt type described in the embodiments of the present application.

[0009] It can be understood that the first electronic device can achieve the shunt of different audio types by creating different threads for different audio types and creating different players. The classification of audio types enables the audio data under different audio types to be played in different playback forms, so as to improve the flexibility of audio data playback.

[0010] In a possible implementation manner, before the first electronic device binds the first player to the first thread, the method further includes: the first electronic device determines that the first application corresponds to the first audio type according to the correspondence relationship between the first media type, the identifier of the first application, and the first audio type; before the first electronic device binds the second player to the second thread, the method further includes: the first electronic device determines that the second application corresponds to the second audio type according to the correspondence relationship between the first media type, the identifier of the second application, and the second audio type.

[0011] Based on this, the electronic device can distinguish the audio data from different applications and with the same media type through the correspondence relationship between the media type, the identifier of the application, and the audio type, refine the existing media type, and make the classified audio types more in line with the playback habits of the electronic device. For example, subsequently, the first electronic device or the second electronic device can determine different playback forms based on the first audio type and the second audio type.

[0012] For example, when the first media type is a media type and the identifier of the first application is the identifier of a media application, the first audio type can be a music shunt type. Or, when the first media type is a media type and the identifier of the first application is the identifier of a navigation application, the second audio type can be a navigation shunt type. The first electronic device differentiates audio data under different applications by refining the classification of the media type.

[0013] In a possible implementation, during the process of creating the first thread, the first electronic device creates a first buffer and a second buffer; during the process of creating the first player, the first electronic device creates a third buffer.

[0014] The first buffer can be buffer1 described in the embodiments of the present application, the second buffer can be buffer2 described in the embodiments of the present application, and the third buffer can be buffer3 described in the embodiments of the present application.

[0015] The first buffer is used to receive audio data from the third buffer; the second buffer is used to receive audio data from the first buffer; the third buffer is used to receive audio data from the first application.

[0016] Before playing the audio data, the first electronic device can create three pre - created buffers so that there will be no stuttering phenomenon when playing the audio data.

[0017] In a possible implementation, after the first player is successfully created, the first electronic device receives first audio data from the first application and caches the first audio data in the third buffer; the first electronic device caches the first audio data in the third buffer into the first buffer; the first electronic device caches the first audio data in the first buffer into the second buffer.

[0018] The first electronic device can establish an audio path through the three pre - created buffers. So that the audio data can be transferred to the appropriate place through the above three buffers, ensuring that the audio data can be transmitted according to the pre - set audio path.

[0019] In the embodiments of the present application, before playing different types of audio data, three buffers corresponding to any type can be created, so that the audio data of any audio type can be transmitted according to the three created buffers, realizing the shunt of audio data.

[0020] In a possible implementation, creating a first buffer includes: determining a first storage space of the first buffer, and creating the first buffer that meets the first storage space, where the first storage space is determined based on one or more of the following: the maximum data format, the maximum number of channels, the maximum sampling rate, a preset frame length, or a preset buffer multiple; creating a second buffer includes: determining a second storage space of the second buffer, and creating the second buffer that meets the second storage space, where the second storage space is determined based on one or more of the following: the data format of the first audio path, the sampling rate of the first audio path, the number of channels supported by the first audio path, or a preset frame length; creating a third buffer includes: determining a third storage space of the third buffer, and creating the third buffer that meets the third storage space, where the third storage space is determined based on one or more of the following: the first data format, the first number of channels, the first sampling rate, a preset frame length, or a preset buffer multiple.

[0021] It can be understood that the maximum data format, the maximum number of channels, and the maximum sampling rate can be preset. Since the first buffer can be used to cache audio data copied from a media application, and the first electronic device cannot determine in advance the data size of the audio data copied by the media application, in order to ensure that the first buffer can cache audio data of any data size, the first electronic device can determine the first buffer that can cache more data based on the maximum data format, the maximum number of channels, and the maximum sampling rate.

[0022] The first electronic device can set the size of the storage area and create the storage area according to the size of the storage area, so that the audio data can be transmitted in a sufficient storage area to ensure the stability of data transmission.

[0023] In a possible implementation, before the first electronic device receives a device connection event of the second electronic device, the method further includes: the first electronic device loads a configuration file in response to an operation of starting the first electronic device; the first electronic device obtains a first configuration parameter in the configuration file, where the first configuration parameter corresponds to a first audio type, and the first configuration parameter includes one or more of the following: the name of the first audio path corresponding to the first audio type, the data format of the first audio path, the correspondence between the first audio path and the second electronic device, the sampling rate of the first audio path, or the number of channels supported by the first audio path.

[0024] The first audio path can be the music audio path described in the embodiments of the present application. The first configuration parameter can be the configuration parameter corresponding to the music audio path.

[0025] The first electronic device can obtain the first configuration parameter by parsing the configuration file and configure the subsequent first audio path based on the first configuration parameter. The creation process of the first audio path may include creating the first thread and creating the first player as described above.

[0026] In a possible implementation, the first electronic device includes an audio policy module and an audio engine module. When the first electronic device receives a device connection event from the second electronic device and creates the first thread, the process includes: the audio policy module receives the device connection event; in response to receiving the device connection event, the audio policy module sends a request to create the first playback thread to the audio engine module; in response to the request to create the first playback thread, the audio engine module creates the first playback thread.

[0027] In this way, the audio policy module can complete the creation of the first thread when receiving the device connection event. In this way, when playing audio data subsequently, the audio data can be transmitted based on the first thread, ensuring the stability of audio data transmission.

[0028] In a possible implementation, the first electronic device further includes a DMSDP audio processing module. When the first electronic device creates the first buffer and creates the second buffer, the process includes: the audio engine module creates the first buffer; the audio engine module sends a message for creating an audio path to the DMSDP audio processing module; in response to receiving the message for creating an audio path, the DMSDP audio processing module creates the second buffer.

[0029] In this way, the first electronic device can make the audio data flow from the audio engine module to the DMSDP audio processing module by creating buffers in different modules, ensuring that the audio data can be transmitted according to the preset audio path.

[0030] In a possible implementation, when the first electronic device responds to the request to create the first player and creates the first player, the process includes: the audio engine module receives the request to create the first player; in response to receiving the request to create the first player, the audio engine module sends a message for selecting an audio type to the audio policy module; in response to receiving the message for selecting an audio type, the audio policy module determines the first audio type and the first thread; the audio policy module notifies the audio engine module to create the first player in the first thread; the audio engine module creates the first player.

[0031] In this way, the audio policy module can pre-determine the audio type corresponding to the current application and media type. When the audio engine module creates the first player, it can create a player belonging to the first audio type, and this first player can be used to transmit audio data of the first audio type, thus achieving the diversion of audio data.

[0032] In a possible implementation, the first electronic device further includes: a smart travel application. The audio policy module determines the first audio type, including: in response to receiving a message for selecting an audio type, the audio policy module sends the message for selecting an audio type to the audio service module; in response to receiving the message for selecting an audio type, the audio service module obtains the first audio type from the smart travel application; the smart travel application includes the correspondence between the first media type, the identifier of the first application, and the first audio type; the audio service module sends the first audio type to the audio policy module; the audio policy module determines the first audio type.

[0033] In the embodiments of the present application, a first correspondence is described. The first correspondence may include the correspondence between the first media type, the identifier of the first application, and the first audio type.

[0034] The first correspondence can be pre-set in the smart travel application, and when the audio service module determines that an audio type needs to be selected, the first audio type can be determined through the first correspondence.

[0035] It can be understood that the setting of the first correspondence can meet the user's need to divert media types of different applications. For example, the first correspondence can be used to distinguish the media types in the navigation application and the media application, so that the first electronic device or the second electronic device can play navigation audio data or music audio data in different playback forms.

[0036] In a possible implementation, the first electronic device creates a third buffer, including: the audio engine module creates the third buffer; the first electronic device receives the first audio data from the first application and caches the first audio data in the third buffer, including: the audio engine module receives the first audio data from the first application and caches the first audio data in the third buffer; the first electronic device caches the first audio data in the third buffer into the first buffer, including: the audio engine module caches the first audio data in the third buffer into the first buffer; the first electronic device caches the first audio data in the first buffer into the second buffer, including: the audio engine module sends the first audio data in the first buffer to the DMSDP audio processing module, and the DMSDP audio processing module caches the first audio data in the first buffer into the second buffer.

[0037] The first electronic device can create buffer areas in different modules, enabling the audio engine module to receive first audio data from the first application, and the first audio data can flow from the audio engine module to the DMSDP audio processing module. This ensures that the audio data can be transmitted according to a pre-set audio path.

[0038] In a possible implementation, the method further includes: the first electronic device sending the first audio data and the first audio type to the second electronic device, where the first audio data corresponds to the first audio type; the first electronic device sending the second audio data and the second audio type to the second electronic device, where the second audio data corresponds to the second audio type.

[0039] The first electronic device can send the audio data and the audio type to the second electronic device, enabling the second electronic device to determine different playback forms based on the audio type. The different playback forms may include: controlling different speakers to play audio data of different audio types, or playing audio data of different audio types at different volumes, etc., which are not limited in the embodiments of the present application.

[0040] In a possible implementation, the method further includes: the first electronic device receiving a device disconnection event from the second electronic device and destroying the first thread and the second thread.

[0041] The first electronic device can destroy the first thread and the second thread in a timely manner when detecting a device disconnection event, reducing the memory space occupied by the first thread and the second thread.

[0042] In a second aspect, an embodiment of the present application provides an audio processing method, the method including: the second electronic device receiving the first audio data and the first audio type from the first electronic device, where the first audio data corresponds to the first audio type; the second electronic device playing the first audio data through the first speaker, where the first speaker corresponds to the first audio type; the second electronic device receiving the second audio data and the second audio type from the first electronic device, where the second audio data corresponds to the second audio type; the second electronic device playing the second audio data through the second speaker, where the second speaker corresponds to the second audio type, and the first speaker is different from the second speaker.

[0043] This enables the second electronic device to determine different playback forms based on the audio type, improving the flexibility of audio data playback.

[0044] In a possible implementation, the method further includes: when the second electronic device receives the first audio data and the second audio data simultaneously, the second electronic device plays the second audio data, and the priority corresponding to the second audio type is higher than the priority corresponding to the first audio type.

[0045] Enable the second electronic device to determine to preferentially play the audio data of the high-priority audio type according to the priority of the audio type, avoiding the conflict caused by playing multiple audio data in the same speaker.

[0046] In a fourth aspect, an embodiment of the present application provides an audio processing device. The audio processing device may be the first electronic device, or a chip or a chip system within the first electronic device. Alternatively, the audio processing device may be the second electronic device, or a chip or a chip system within the second electronic device. The audio processing device may include a communication unit and a processing unit.

[0047] In a fifth aspect, an embodiment of the present application provides an electronic device, including a processor and a memory. The memory is used to store code instructions, and the processor is used to run the code instructions to execute the method described by the first electronic device in the first aspect or any possible implementation manner of the first aspect, or execute the method described by the second electronic device in the second aspect or any possible implementation manner of the second aspect.

[0048] In a sixth aspect, an embodiment of the present application provides a computer-readable storage medium. A computer program or instruction is stored in the computer-readable storage medium. When the computer program or instruction runs on an electronic device, the electronic device is enabled to execute the method described by the first electronic device in the first aspect or any possible implementation manner of the first aspect, or execute the method described by the second electronic device in the second aspect or any possible implementation manner of the second aspect.

[0049] In a seventh aspect, an embodiment of the present application provides a computer program product including a computer program. When the computer program runs on an electronic device, the electronic device is enabled to execute the method described by the first electronic device in the first aspect or any possible implementation manner of the first aspect, or execute the method described by the second electronic device in the second aspect or any possible implementation manner of the second aspect.

[0050] In an eighth aspect, the present application provides a chip or a chip system. The chip or the chip system includes at least one processor and a communication interface. The communication interface and the at least one processor are interconnected by a line. The at least one processor is used to run a computer program or instruction to execute the method described in the first aspect or any possible implementation manner of the first aspect. Among them, the communication interface in the chip may be an input / output interface, a pin, a circuit, etc.

[0051] In a possible implementation, the chip or the chip system described above in the present application further includes at least one memory, and instructions are stored in the at least one memory. The memory may be a storage unit inside the chip, such as a register, a cache, etc., or a storage unit of the chip (such as a read-only memory, a random access memory, etc.).

[0052] It should be understood that the technical solutions of the third to eighth aspects of this application correspond to those of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation manners are similar and will not be elaborated herein. Description of the Drawings

[0053] Figure 1 A schematic diagram of a scenario provided by an embodiment of this application;

[0054] Figure 2 A schematic diagram of the distribution of speakers in a vehicle-mounted computer provided by an embodiment of this application;

[0055] Figure 3 A schematic diagram of the hardware structure of an electronic device provided by an embodiment of this application;

[0056] Figure 4 A schematic diagram of the software structure of an electronic device provided by an embodiment of this application;

[0057] Figure 5 A schematic diagram of the module interaction of an audio processing method provided by an embodiment of this application;

[0058] Figure 6 A schematic diagram of the process of playing music audio data based on a music audio path provided by an embodiment of this application;

[0059] Figure 7 A schematic diagram of the process of playing navigation audio data based on a navigation audio path provided by an embodiment of this application;

[0060] Figure 8 A schematic diagram of the process of playing ringtone audio data based on other audio paths provided by an embodiment of this application;

[0061] Figure 9 A schematic diagram of the steps of releasing an audio path provided by an embodiment of this application;

[0062] Figure 10 A schematic diagram of the interface for setting speakers provided by an embodiment of this application;

[0063] Figure 11 Another schematic diagram of the interface for setting speakers provided by an embodiment of this application;

[0064] Figure 12 A schematic diagram of the flow of an audio processing method provided by an embodiment of this application;

[0065] Figure 13 Another schematic diagram of the hardware structure of an electronic device provided by an embodiment of this application. Detailed Embodiments

[0066] For the convenience of clearly describing the technical solutions of the embodiments of the present application, in the embodiments of the present application, terms such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and roles. For example, the first value and the second value are only used to distinguish different values, and their order is not limited. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and the terms "first" and "second" do not necessarily limit being different.

[0067] It should be noted that in the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present relevant concepts in a specific manner.

[0068] In the present application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the associated objects before and after are in an "or" relationship. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (item) or plural items (items). For example, at least one (item) of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0069] Exemplarily, Figure 1 is a schematic diagram of a scenario provided for an embodiment of the present application. In Figure 1 the corresponding embodiment, taking the electronic device as a mobile phone as an example for illustration, this example does not limit the embodiments of the present application.

[0070] As Figure 1 shown, this scenario may include: a display screen of an electronic device and a car machine, and the electronic device establishes a communication connection with the car machine.

[0071] When the electronic device detects that the user opens the playback interface of a certain media application, it may display an audio playback interface as shown in Figure 1 a in. The audio playback interface may display: the song name of audio 100, the singer information of audio 100, the song cover of audio 100, the playback progress of audio 100, a playback button 101, a button for viewing the previous song, and a button for viewing the next song, etc.

[0072] When the electronic device is connected to the in-vehicle unit, the in-vehicle unit can display the interface shown in b of Figure 1 when it detects that the user opens the mobile-vehicle interconnection application from the in-vehicle unit. The corresponding interface of the mobile-vehicle interconnection application can be displayed in this interface. For example, window 106 and window 107 can be displayed in this interface.

[0073] In window 106, the following can be displayed: the icon 102 of the navigation application, the icon 103 of the SMS application of the mobile-vehicle interconnection application, the icon 104 of the phone application, and the function icon 105 for opening more functions, etc.

[0074] In window 107, one or more of the following can be displayed: window 108 corresponding to the navigation application, the control 109 for opening the navigation route home or the navigation route to the company, the weather information 110, and the audio playback information 111.

[0075] In the window 108 corresponding to the navigation application, the following can be displayed: the map, and the information such as the identifier indicating the location of the electronic device; in the weather information 110, the following can be displayed: 27°, XX City, sunny, good air quality, 32° / 22°, etc.; in the audio playback information 111, the following can be displayed: the song name of the audio 100, the singer information, the play button 112, the button for viewing the previous song, and the button for viewing the next song, etc.

[0076] The mobile-vehicle interconnection application can be understood as an electronic device-vehicle intelligent interconnection product. The mobile-vehicle interconnection application can enable users to enjoy convenient and safe Internet ecological application services in the vehicle. For example, users can access applications such as navigation, SMS, music, and phone in the electronic device through the mobile-vehicle interconnection application.

[0077] In a possible implementation, in response to the user's trigger operation on the icon 102, the in-vehicle unit can display the interface shown in c of Figure 1 In this interface, the specific content in the navigation application can be displayed in window 107, such as the map.

[0078] Exemplarily, in response to the user's operation on the play button 101 in the interface shown in a of Figure 1 , the mobile phone can send an instruction to play the audio to the in-vehicle unit, and then the in-vehicle unit can control the speaker on the in-vehicle unit to play the audio data (or simply referred to as music) in the audio playback application. Or, in response to the user's operation on the play button 112 in the interface shown in b of Figure 1 , the in-vehicle unit can send an instruction to request playing the audio to the mobile phone. When the mobile phone agrees to play the audio data, it can send the instruction to play the audio and the music to the in-vehicle unit, and the in-vehicle unit can control the speaker on the in-vehicle unit to play the music.

[0079] Exemplarily, in response to the user setting a navigation route in the electronic device and triggering the operation of starting navigation, the mobile phone can send an instruction to play audio data to the in-vehicle device, and the in-vehicle device can control the speaker on the in-vehicle device to play the audio data in the navigation (or simply referred to as navigation sound). Alternatively, in response to the user setting a navigation route in the in-vehicle device and triggering the operation of starting navigation, the in-vehicle device can send an instruction to request audio playback to the mobile phone. When the mobile phone agrees to play the audio data, it can send the instruction to play the audio and the navigation sound to the in-vehicle device. After receiving the instruction to play the audio and the navigation sound, the in-vehicle device can control the speaker on the in-vehicle device to play the navigation sound.

[0080] Exemplarily, Figure 2 This is a schematic diagram of the distribution of speakers in an in-vehicle device provided in an embodiment of the present application. As Figure 2 shown, the in-vehicle device may include one or more of the following speakers, for example: the driver's speaker 1 located around the driver's seat, the co-driver's speaker 1 located around the co-driver's seat, the rear row speaker 1 located around the rear row seat 1, the rear row speaker 2 located around the rear row seat 2, or the rear row speaker 3 located around the rear row seat 3, etc.

[0081] It can be understood that in the embodiments of the present application, the number of rows of seats in the in-vehicle device, the number of seats in any row, and the number of speakers around the seats are not specifically limited. For example, the in-vehicle device may include three rows of seats, any row of seats may include 2 or 3 seats, and around any seat may include: 2 or 3 speakers, etc.

[0082] When the in-vehicle device controls the above speakers to play music and navigation sound simultaneously, the driver's speaker 1 can play music and navigation sound simultaneously. For the driver in the vehicle, the music played by the driver's speaker 1 may interfere with the simultaneously played navigation sound, making it impossible for the driver to accurately hear the navigation. The rear row speaker 3 can play music and navigation sound simultaneously. For the passenger sitting in the rear row seat 3 in the in-vehicle device, the navigation sound played by the rear row speaker 3 may also interfere with the simultaneously played music, making it impossible for the passenger to immerse themselves in the music. Therefore, the playback form of audio data in the in-vehicle device is relatively single.

[0083] In view of this, an embodiment of the present application provides an audio processing method. An electronic device can set a navigation diversion type for audio data from a navigation application and of a media audio type, and set a music diversion type for audio data from a media application and of a media audio type. Furthermore, the in-vehicle computer can control different speakers to play audio corresponding to different diversion types according to the corresponding relationship between the diversion type and the speakers. For example, it can control the driver's seat speaker 1 to play the audio data under the navigation diversion type, or control one or more of the co-driver's seat speaker 1, the rear row speaker 1, the rear row speaker 2, and the rear row speaker 3 to play the audio data under the music diversion type, so as to achieve flexible playback of the audio data and improve the user's auditory experience.

[0084] In a possible implementation manner, the in-vehicle computer may also not control the playback of music or navigation sound, etc. through the above-mentioned mobile phone-vehicle interconnection application (such as Figure 1 the scenario shown). For example, when the electronic device is connected to the in-vehicle computer, the in-vehicle computer may also control the playback of music or navigation sound based on other applications or other control interfaces. The embodiments of the present application do not limit this.

[0085] It can be understood that the above-mentioned electronic device may also be referred to as a terminal, (terminal), user equipment (UE), mobile station (MS), mobile terminal (MT), etc. The electronic device can be a mobile phone with a touch screen, a smart TV, a wearable device, a tablet computer (Pad), a computer with wireless transceiver function, a virtual reality (VR) electronic device, an augmented reality (AR) electronic device, and so on. The embodiments of the present application do not limit the specific technologies and specific device forms adopted by the electronic device.

[0086] It can be understood that an audio processing method provided by an embodiment of the present application may not be limited to the scenario where the electronic device is connected to the in-vehicle computer, and may also be applied to an electronic device with multiple speakers other than the in-vehicle computer. The embodiments of the present application do not limit this.

[0087] In order to better understand the embodiments of the present application, the structure of the electronic device in the embodiments of the present application will be introduced below. Exemplarily, Figure 3 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.

[0088] The electronic device may include a processor 110, an internal memory 121, a universal serial bus (USB) interface 130, an antenna 2, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, a display screen 194, etc.

[0089] The sensor module 180 may include sensors such as a touch sensor. The touch sensor may be disposed on the display screen 194, and the touch sensor and the display screen 194 form a touch screen. The touch sensor is used to receive a triggering operation of the user on the touch screen.

[0090] It can be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than those illustrated, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0091] The processor 110 may include one or more processing units. Among them, different processing units may be independent devices or integrated in one or more processors. A memory may also be provided in the processor 110 for storing instructions and data. For example, the processor 110 is used to store the instructions and data related to an audio processing method provided in the embodiments of the present application.

[0092] The USB interface 130 is an interface that conforms to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, etc. The USB interface 130 can be used to implement data transmission between the electronic device and a peripheral device. For example, the USB interface 130 can implement a wired connection between the vehicle head unit and the electronic device in the embodiments of the present application.

[0093] The wireless communication module 160 can provide functions such as wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), or Bluetooth (BT) applied to the electronic device.

[0094] For example, the wireless communication module 160 can implement wireless connections such as a WIFI connection or a Bluetooth connection between the vehicle head unit and the electronic device, and implement data transmission between the vehicle head unit and the electronic device based on the WIFI connection or the Bluetooth connection. The specific connection manner between the devices in the embodiments of the present application is not limited.

[0095] The electronic device realizes the display function through the GPU, the display screen 194, and the application processor, etc. The GPU is a microprocessor for image processing, and is connected to the display screen 194 and the application processor.

[0096] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. For example, the display screen 194 can realize the display of the interface shown in a of Figure 1 , or the display screen 194 can also realize the playback setting of the speaker in the in-vehicle unit (see Figures 10 - 11 the corresponding embodiment), etc., which is not limited in the embodiments of the present application.

[0097] The software system of the electronic device can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture, etc., which will not be elaborated here.

[0098] Exemplarily, Figure 4 is a schematic diagram of the software structure of an electronic device provided by an embodiment of the present application.

[0099] As Figure 4 shown, the layered architecture divides the software into several layers, and each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the android system is divided into multiple layers, from top to bottom are the application layer, the application framework layer, the hardware abstraction layer (HAL), and the kernel layer, etc., which is not limited in the embodiments of the present application.

[0100] The application layer may include a series of application packages. The application layer may include one or more of the following: media applications, navigation applications, intelligent travel applications (or called intelligent vehicle connection applications), or telephone applications, etc. The media application is an application that allows playing audio data. For example, the media application may include: an audio playback application, and / or a video playback application, etc., which is not limited in the embodiments of the present application.

[0101] The media application or the navigation application can realize the generation of audio data. For example, the media application can generate music audio data, the navigation application can generate navigation audio data, and the telephone application can be used to generate ringtone audio data (or simply called ringtone).

[0102] The intelligent travel application is used to realize notifying the audio service module to register a callback interface (or unregister the callback interface) based on the in-vehicle unit connection (or in-vehicle unit disconnection) situation, and notifying the audio service module of the device connection event (or device disconnection event).

[0103] The application framework layer provides application programming interfaces (APIs) and programming frameworks for the applications in the application layer. The application framework layer includes some predefined interfaces. The application framework layer may include one or more of the following: an audio policy module, an audio engine module, and an audio service module.

[0104] The audio policy module is used to load and store configuration parameters according to a configuration file, and is also used to configure different audio channels according to the configuration parameters. Any audio channel can correspond to a shunt type. For the specific content in the configuration file and configuration parameters, refer to the description of S501, which will not be elaborated here.

[0105] The audio engine module is used to create a playback thread according to the instructions sent by the audio policy module, and is also used to send instructions for creating an audio channel to the audio processing module of the distributed mobile sensing development platform (DMSDP).

[0106] The audio service module is used to send a message for selecting a shunt type to the intelligent travel application based on a callback function.

[0107] In possible implementation manners, the application framework layer may also include one or more of the following: a display composition system, a window manager, a content provider, a resource manager, a view system, or a notification manager, etc. ( Figure 4 not shown in the figure), which is not limited in the embodiments of the present application.

[0108] The purpose of the hardware abstraction layer is to abstract the hardware, which can provide a unified interface for querying hardware devices for the upper-layer applications, or can also provide data storage services for the upper-layer applications. The hardware abstraction layer may include one or more of the following: the DMSDP audio processing module.

[0109] The DMSDP audio processing module is used to implement the creation (or release) of an audio channel and the transmission of audio data based on the audio channel. For example, the DMSDP audio processing module can transmit audio data to the in-vehicle unit based on the audio channel.

[0110] In possible implementation manners, the hardware abstraction layer may also include: a hardware editor ( Figure 4 not shown in the figure), and the hardware editor mainly provides hardware support for the display compositor and supports functions such as layer composition and display.

[0111] The kernel layer is the layer between hardware and software. The kernel layer is used to drive the hardware to make it work. The kernel layer may include one or more of the following: camera driver, display driver, sensor driver, etc.

[0112] Among possible line-of-sight modes, an electronic device may include a hardware layer, and the hardware layer may include one or more of the following: a camera, a liquid crystal display (LCD), a graphics processing unit (GPU), or a central processing unit (CPU), etc. ( Figure 4 not shown in the figure).

[0113] In the embodiments of the present application, the software layer involved in the software architecture, the modules included in the layer, and the functions of the modules are not specifically defined.

[0114] The following uses specific embodiments to elaborate in detail on the technical solutions of the present application and how the technical solutions of the present application solve the above technical problems. These several specific embodiments can be implemented independently or in combination with each other. For the same or similar concepts or processes, they may not be repeated in some embodiments.

[0115] Exemplarily, Figure 5 is a schematic diagram of module interaction for an audio processing method provided by an embodiment of the present application. In Figure 5 the corresponding embodiment, the audio processing method involves an electronic device and a vehicle head unit. The electronic device may include: an audio policy module, an audio engine module, an audio service module, a DMSDP audio processing module, and a smart travel application.

[0116] As Figure 5 shown, S501-S502 may be a schematic process of the electronic device loading a configuration file in response to the user's power-on operation. S503-S513 may be a schematic process of the electronic device creating a playback thread and creating an audio path in response to the establishment of a connection between the vehicle head unit and the electronic device. Specifically, the audio processing method may include the following steps:

[0117] S501. In response to the user's power-on operation, the audio policy module loads the configuration file.

[0118] The electronic device may use the configuration file to implement parameter configuration for the audio path, and the configuration file may be pre-set in the memory.

[0119] The configuration file may include one or more of the following configuration parameters: the name of the audio path (mixport name), the splitting type corresponding to the audio path name, or the routing relationship between the virtual audio device and the audio path, the data format (format) of the audio path, the sampling rate (sampling rates) of the audio path, or the number of channels supported by the audio path (channelmasks), etc.

[0120] The number of channels supported by the audio path can generally be 2, and the 2 channels can generally be the left channel and the right channel.

[0121] The audio path name may include: the music audio path (or called virtual output music), the navigation audio path (or called virtual output navigation), and other audio paths (or called virtual output other).

[0122] The music audio path may correspond to the music splitting type, the navigation audio path corresponds to the navigation splitting type, and other audio paths correspond to other splitting types other than the music splitting type and the navigation splitting type. The splitting type can be understood as a type of audio.

[0123] The routing relationship between the virtual audio device and the audio path may include the path conditions corresponding to any virtual audio device supported by the electronic device. For example, for a certain virtual audio device, such as a car stereo, the routing relationship between the car stereo and the audio path may include: the car stereo - music audio path, the car stereo - navigation audio path, the car stereo - other audio paths, etc.

[0124] Among them, the virtual audio device can be understood as a device name of the electronic device for the recognized playback device, and the virtual audio device can be: a speaker, or an electronic device carrying a speaker, etc. For example, in the scenario where the car stereo provided in the embodiment of the present application establishes a connection with the electronic device, the car stereo can be used as a virtual audio device in the electronic device.

[0125] It can be understood that in the embodiment of the present application, the number of audio paths in the configuration file, the splitting type, and the number in the routing relationship between the virtual audio device and the audio path are not specifically limited.

[0126] Exemplarily, the configuration file may include: the routing relationship between the virtual audio device and the audio path, such as deviceport_sources = virtual output music, virtual output navigation, virtual output other. Herein, deviceport_sources may refer to the virtual audio device.

[0127] The configuration parameters for virtual output music may include one or more of the following: mixport name = virtual output music, format = 16_bit, sampling rates = 48000, channel masks = stereo.

[0128] Herein, stereo may be understood as stereo sound, corresponding to 2 channels. The shunt type may be reflected from mixport name. For example, when mixport name = virtual output music, the shunt type may be the music shunt type music.

[0129] The configuration parameters for virtual output navigation may include one or more of the following: mixport name = virtual output music, format = 16_bit, sampling rates = 48000, channel masks = stereo. When mixport name = virtual output navigation, the shunt type may be the navigation shunt type navigation.

[0130] The configuration parameters for virtual output other may include one or more of the following: mixport name = virtual output music, format = 16_bit, sampling rates = 48000, channel masks = stereo. When mixport name = virtual output other, the shunt type may be the other shunt type other.

[0131] It can be understood that the configuration parameters provided in the embodiments of the present application are only used as an example and do not constitute a limitation to the embodiments of the present application.

[0132] Exemplarily, in response to the user's power-on operation, the Linux kernel starts, and the kernel can notify the audio policy module and other module devices to start up through init(), and the audio policy module loads the configuration file by triggering audioserver(). Among them, the configuration file may include the configuration information of the operating system and the configuration information of the application required when the electronic device starts, and the configuration file may include the configuration file.

[0133] S502: The audio policy module parses the configuration file and saves the configuration parameters in the configuration file.

[0134] The audio policy module can parse the configuration parameters in the configuration file and save the configuration parameters in the audio policy module. The content of the configuration parameters can refer to the description in S501, which will not be repeated here.

[0135] S503: In response to the user's operation of connecting the vehicle computer and the electronic device, the smart travel application registers a callback function with the audio service module.

[0136] The callback function is used to obtain the audio diversion type from the smart travel application during the audio data playback process.

[0137] Exemplarily, in response to the user's operation of connecting the vehicle computer and the electronic device, the smart travel application creates a callback function and registers the callback function with the audio service module, and then the audio service module can execute the steps shown in S504 to save the callback function.

[0138] The electronic device and the vehicle computer can be connected by wired means, for example, the electronic device and the vehicle computer establish a communication connection through a universal serial bus (USB). Alternatively, the electronic device and the vehicle computer can also be connected by wireless means, for example, the electronic device and the vehicle computer establish a communication connection through Bluetooth, WIFI, connecting to the same cloud account, or trust ring, etc., which is not limited in the embodiments of the present application.

[0139] It can be understood that when a connection is established between the electronic device and the vehicle computer, the vehicle computer can subsequently control the audio playback through the mobile phone-vehicle computer interconnection application, or the vehicle computer can also control the audio playback through the trust ring.

[0140] Among them, the trust ring is a technical solution based on the identity authentication system to achieve cross-system multi-device trusted interconnection and enable the flow and sharing of services between devices. In the scenario of establishing device connection based on the trust ring, the electronic device that logs in to the device account can use a personal identification number (PIN) (or PIN code) or other verification code to achieve device authentication between the electronic device and the vehicle computer.

[0141] For example, taking the authentication of the trust ring based on the PIN code as an example for illustration. The electronic device can send the PIN code to the in-vehicle device through means such as broadcasting, and then display a prompt box for inputting the PIN code for verification. When the in-vehicle device receives the PIN code, it displays the PIN code and returns a response message to the electronic device indicating that the PIN code has been received. In response to the user's operation of inputting the PIN code on the electronic device, the electronic device and the in-vehicle device can complete device authentication. In this scenario, the electronic device can display the interface corresponding to the trust ring, and the icon of the in-vehicle device can be displayed in this interface.

[0142] After the device authentication is successful, the in-vehicle device and the electronic device can be within the same trust ring. When the electronic device logging in to the device account approaches the in-vehicle device again, the electronic device and the in-vehicle device can automatically establish a networking connection based on the trust ring and implement communication under the trust ring.

[0143] It can be understood that the embodiments of the present application do not specifically limit the scenario of establishing a communication connection between the electronic device and the in-vehicle device.

[0144] In a possible implementation manner, after responding to the user's operation of connecting the in-vehicle device and the electronic device, the in-vehicle device can send the attribute information of the speaker to the intelligent travel application, and then the intelligent travel application can display an interface as Figure 10 shown. Among them, the attribute information of the speaker may include one or more of the following: the position of the speaker, or the number of speakers, etc.

[0145] S504. The audio service module saves the callback function.

[0146] S505. The intelligent travel application sends a device connection event to the audio service module.

[0147] Exemplarily, the intelligent travel application can send a device connection event to the audio service module through a specific interface. This specific interface can be startVirtualAudio.

[0148] Exemplarily, after responding to the user's operation of connecting the in-vehicle device and the electronic device, the electronic device can execute the steps shown in S503 and S505 simultaneously, or can also execute the steps shown in S503 and S505 successively. The embodiments of the present application do not specifically limit this.

[0149] S506. The audio service module sends a device connection event to the audio policy module.

[0150] The device connection event carries a device type identifier.

[0151] The device type identifier may include: DMSDP identifier, etc. When the electronic device detects the DMSDP identifier, the electronic device can virtualize the speakers of the device corresponding to the DMSDP identifier, such as the speakers of other devices like a car stereo, into the local speakers of the electronic device, and then use the virtualized local speakers of the electronic device for audio playback. Among them, other devices may be devices other than the local device, such as a smart watch with a speaker, a tablet with a speaker, or a smart bracelet with a speaker, etc., and this is not limited in the embodiments of the present application.

[0152] In possible implementation manners, the device connection event may also carry: device identifier, etc. When the electronic device detects the device identifier, the electronic device can identify the specific device connected to the local device based on the device identifier.

[0153] The device connection event is used to indicate that the virtual audio device establishes a connection with the electronic device.

[0154] After the audio policy module receives the device connection event, the audio policy module can create a playback thread and an audio path for each audio path through the audio engine module and the DMSDP audio processing module according to the number of audio paths in the configuration parameters. In this way, subsequently, when the virtual audio device plays audio data, it can perform shunt management on the audio data under different audio paths.

[0155] Exemplarily, the audio policy module can select the configuration parameters by calling openoutputwithprofileanddevice(), and determine that audio paths under three shunt types can be created.

[0156] For example, the audio paths set in the configuration parameters include: music audio path, navigation audio path, and other audio paths. Therefore, the electronic device can create the music audio path and playback thread 1, create the navigation audio path and playback thread 2, and create the other audio path and playback thread 3. Among them, the embodiments of the present application do not limit the creation sequence of the three audio paths. The number of created audio paths is not limited.

[0157] The process of creating the music audio path and playback thread 1 can refer to the steps shown in S507 - S514.

[0158] S507. The audio policy module notifies the audio engine module to create playback thread 1.

[0159] The playback thread can create an audio player.

[0160] S508. The audio engine module creates playback thread 1 and creates buffer 1.

[0161] During the process of creating playback thread 1, the audio engine module can determine the size of buffer1 based on the maximum data format, the maximum number of channels, and the maximum sampling rate, and then create buffer1. Buffer1 is used to cache the music audio data copied in audio player 1. The size of the buffer can also be referred to as the storage space of the buffer.

[0162] It can be understood that the maximum data format, the maximum number of channels, and the maximum sampling rate can be preset. Since buffer1 can be used to cache the audio data copied from the media application, and the audio engine module cannot determine in advance the data size when the media application copies the audio data, in order to ensure that buffer1 can cache the audio data of any data size, the audio engine module can determine buffer1 that can cache more data based on the maximum data format, the maximum number of channels, and the maximum sampling rate.

[0163] For example, taking the maximum data format of 32bit, the maximum number of channels of 12, and the maximum sampling rate of 196000Hz as an example, the size of buffer1 is illustrated as follows:

[0164] The size of buffer1 = 32 × 12 × 196000 × preset frame length × preset cache multiple

[0165] Among them, in the calculation of buffer1, the preset frame length can be 0.02 seconds, and 0.02 seconds can be understood as 20 milliseconds; the preset cache multiple can be a value such as 2 or 3, and this application embodiment does not limit this.

[0166] It can be understood that in order to avoid the stuttering situation caused by untimely audio data transmission, the electronic device can set the cache multiple to a value such as 2 or 3, so as to store several buffer data more, to alleviate the possible stuttering situation.

[0167] In a possible implementation manner, the preset cache multiple may not be included in the calculation formula of buffer1.

[0168] Exemplarily, openoutputwithprofileanddevice() can carry: profile->getname and iohandle. Among them, the electronic device can determine the audio path allowed to be processed by the playback thread through profile->getname, and can associate the thread identifier (such as the thread number) of the playback thread through iohandle. Further, the audio engine module can create this playback thread 1 through the openoutput() instruction.

[0169] It can be understood that the electronic device can also create playback thread 2 and create playback thread 3 based on openoutput(), which will not be elaborated hereinafter.

[0170] S509. The audio engine module notifies the DMSDP audio processing module to create a music audio path.

[0171] Creating a music audio path can be understood as creating a path for transmitting music audio data between the audio engine module and the DMSDP audio processing module.

[0172] For example, after the audio engine module creates buffer1, the audio engine module notifies the DMSDP audio processing module to create a music audio path (or it can be understood as sending a message for creating a music audio path to the DMSDP audio processing module), so that the DMSDP audio processing module creates buffer2. Among them, since both buffer1 and buffer2 are created in the same playback thread 1, there is a corresponding relationship between buffer1 and buffer2.

[0173] It can be understood that after the music audio path is created, the subsequent media application can copy audio data to buffer1 of the audio engine module every 20 milliseconds at equal intervals, and the audio engine module can copy audio data to buffer2 of the DMSDP audio processing module every 20 milliseconds at equal intervals, to achieve the transmission of audio data from the media application to the DMSDP audio processing module (see the descriptions in S612 - S613).

[0174] S510. The DMSDP audio processing module creates buffer2.

[0175] In response to the message for creating a music audio path, the DMSDP audio processing module can calculate the size of buffer2 by using the configuration parameters related to the music audio path, and create buffer2. Buffer2 is used to cache the music audio data copied by the audio engine module.

[0176] For example, taking the data format of the music audio path as 16bit, the number of channels supported by the music audio path as 2, and the sampling rate of the music audio path as 48000 as an example, the size of buffer2 is illustrated as follows:

[0177] The size of buffer2 = 16 × 2 × 48000 × preset frame length

[0178] Among them, the preset frame length can be the same as or different from that described above. In a possible implementation, after the buffer2 is created in the DMSDP audio processing module, a message indicating the completion of the creation of the music audio path can be sent to the audio engine module, and then the audio engine module can determine that the playback thread 1 is created.

[0179] S511. The audio policy module sends the configuration parameters of the music audio path to the audio engine module.

[0180] The configuration parameters of the music audio path may include one or more of the following: mixport name = virtualoutput music, format = 16_bit, sampling rates = 48000, channel masks = stereo, shunt type = music.

[0181] S512. The audio engine module sends the configuration parameters of the music audio path to the DMSDP audio processing module.

[0182] In a possible implementation, the electronic device may send the configuration information of the music audio path to the vehicle head unit based on the steps shown in S512 - S513, and the vehicle head unit may then transmit audio data based on the configuration information of the music audio path. Alternatively, the vehicle head unit may also pre - set the configuration information of the audio path locally, and this application embodiment does not limit this.

[0183] S513. The DMSDP audio processing module sends the configuration parameters of the music audio path to the vehicle head unit.

[0184] S514. The vehicle head unit returns a response message to the DMSDP audio processing module.

[0185] For example, the vehicle head unit may set the configuration parameters after receiving the configuration parameters of the music audio path, and return a response message to the DMSDP audio processing module after the parameter setting is completed.

[0186] The process of creating the navigation audio path and the playback thread 2 can refer to the steps shown in S515 - S522.

[0187] S515. The audio policy module notifies the audio engine module to create the playback thread 2.

[0188] During the process of creating the playback thread 2, the audio engine module can determine the size of buffer4 based on the maximum data format, the maximum number of channels, and the maximum sampling rate, and then create buffer4. Buffer4 is used to cache the navigation audio data copied from the audio player 2. The calculation method of buffer4 can be similar to that of buffer1, and will not be elaborated here.

[0189] S516. The audio engine module creates a playback thread 2 and creates a buffer 4.

[0190] S517. The audio engine module notifies the DMSDP audio processing module to create a navigation audio path.

[0191] Creating a navigation audio path can be understood as creating a path for transmitting navigation audio data between the audio engine module and the DMSDP audio processing module.

[0192] For example, after the audio engine module creates buffer 4, the audio engine module notifies the DMSDP audio processing module to create a navigation audio path (or it can be understood as sending a message for creating a navigation audio path to the DMSDP audio processing module), so that the DMSDP audio processing module creates buffer 5. Among them, since both buffer 4 and buffer 5 are created in the same playback thread 2, there is a corresponding relationship between buffer 4 and buffer 5.

[0193] It can be understood that after the navigation audio path is created, the subsequent navigation application can copy audio data to buffer 4 of the audio engine module every 20 milliseconds at equal intervals, and the audio engine module can copy audio data to buffer 5 of the DMSDP audio processing module every 20 milliseconds at equal intervals, realizing the transmission of navigation audio data from the navigation application to the DMSDP audio processing module (see the description in S712 - S713).

[0194] S518. The DMSDP audio processing module creates a buffer 5.

[0195] In response to the message for creating a navigation audio path, the DMSDP audio processing module can calculate the size of buffer 5 by using the configuration parameters related to the navigation audio path and create buffer 5. Buffer 5 is used to cache the navigation audio data copied by the audio engine module. The calculation method of buffer 5 can be similar to that of buffer 2, which will not be elaborated here.

[0196] In a possible implementation, after the DMSDP audio processing module creates buffer 5, it can send a message to the audio engine module indicating that the creation of the navigation audio path is completed. Then, the audio engine module can determine that the playback thread 2 is created.

[0197] S519. The audio policy module sends the configuration parameters of the navigation audio path to the audio engine module.

[0198] The configuration parameters of the navigation audio path may include one or more of the following: mixport name = virtualoutput navigation, format = 16_bit, sampling rates = 48000, channel masks = stereo, splitting type = navigation.

[0199] S520. The audio engine module sends the configuration parameters of the navigation audio path to the DMSDP audio processing module.

[0200] S521. The DMSDP audio processing module sends the configuration parameters of the navigation audio path to the vehicle head unit.

[0201] S522. The vehicle head unit returns a response message to the DMSDP audio processing module.

[0202] For example, the vehicle head unit can set the configuration parameters after receiving the configuration parameters of the navigation audio path, and return a response message to the DMSDP audio processing module after the parameter setting is completed.

[0203] The process of creating other audio paths and the playback thread 3 can refer to the steps shown in S523 - S530.

[0204] Among them, other audio paths can be other paths except for the music audio path and the navigation audio path.

[0205] S523. The audio policy module notifies the audio engine module to create the playback thread 3.

[0206] S524. The audio engine module creates the playback thread 3 and creates buffer 7.

[0207] During the process of creating the playback thread 3, the audio engine module can determine the size of buffer 7 based on the maximum data format, the maximum number of channels, and the maximum sampling rate, and then create buffer 7. Buffer 7 is used to buffer the audio data copied by other applications (such as the phone application). The calculation method of buffer 7 can be similar to that of buffer 1, which will not be elaborated here.

[0208] S525. The audio engine module notifies the DMSDP audio processing module to create other audio paths.

[0209] Creating other audio paths can be understood as creating a path for transmitting other audio data between the audio engine module and the DMSDP audio processing module.

[0210] For example, after the audio engine module creates buffer7, the audio engine module notifies the DMSDP audio processing module to create other audio paths (or it can be understood as sending a message for creating other audio paths to the DMSDP audio processing module), so that the DMSDP audio processing module creates buffer8. Since both buffer7 and buffer8 are created in the same playback thread 3, there is a corresponding relationship between buffer7 and buffer8.

[0211] It can be understood that after the creation of other audio paths is completed, subsequent other applications (such as the phone application) can copy audio data to buffer4 of the audio engine module every 20 milliseconds at equal intervals, and the audio engine module can copy audio data to buffer5 of the DMSDP audio processing module every 20 milliseconds at equal intervals, realizing the transmission of audio data from the phone application to the DMSDP audio processing module (see the descriptions in S812 - S813).

[0212] S526. The DMSDP audio processing module creates buffer8.

[0213] In response to the message for creating other audio paths, the DMSDP audio processing module can calculate the size of buffer8 by using the configuration parameters related to other audio paths and create buffer8. Buffer8 is used to cache the audio data copied from the audio engine module. The calculation method of buffer8 can be similar to that of buffer2 and will not be elaborated here.

[0214] In a possible implementation, after the DMSDP audio processing module creates buffer8, it can send a message indicating the completion of the creation of other audio paths to the audio engine module. Then, the audio engine module can determine that the playback thread 3 is created successfully.

[0215] S527. The audio policy module sends the configuration parameters of other audio paths to the audio engine module.

[0216] The configuration parameters of other audio paths can include one or more of the following: mixport name = virtualoutput other, format = 16_bit, sampling rates = 48000, channel masks = stereo, shunt type = other.

[0217] S528. The audio engine module sends the configuration parameters of other audio paths to the DMSDP audio processing module.

[0218] S529. The DMSDP audio processing module sends the configuration parameters of other audio channels to the in-vehicle unit.

[0219] S530. The in-vehicle unit returns a response message to the DMSDP audio processing module.

[0220] For example, the in-vehicle unit can set the configuration parameters after receiving the configuration parameters of other audio channels, and return a response message to the DMSDP audio processing module after the parameter setting is completed.

[0221] It can be understood that the steps shown in S507 - S530 can be regarded as the initialization of the audio channel. After initializing the audio channel, the electronic device can play music audio data based on Figure 6 the corresponding embodiment, or play navigation audio data based on Figure 7 the corresponding embodiment, or play ringtone data based on Figure 8 the corresponding embodiment, so as to speed up the audio data playback process.

[0222] In a possible implementation manner, the electronic device may not create all the audio channels supported by the electronic device first (or it can be understood as not executing S507 - S530). When the electronic device detects that the user plays music audio data, it creates the required music audio channel based on the steps shown in S507 - S514, or when the electronic device detects that the user plays navigation audio data, it creates the required navigation audio channel based on S515 - S522, or when the electronic device detects that the user plays ringtone audio data, it creates the required other audio channel based on S523 - S530, so as to reduce memory occupation. The embodiments of the present application do not limit this.

[0223] It can be understood that the electronic device can complete the creation of the audio channel and the playback thread based on Figure 5 the corresponding embodiment, so that the subsequent electronic device can transmit and play audio data through the playback thread and the audio channel.

[0224] In Figure 5 the corresponding embodiment where the music audio channel, the navigation audio channel, and other audio channels are created, the electronic device can play music audio data using the music audio channel based on Figure 6 the corresponding embodiment, the electronic device can also play navigation audio data using the navigation audio channel based on Figure 7 the corresponding embodiment, or the electronic device can also play other audio data using other audio channels based on Figure 8 the corresponding embodiment. Among them, other audio data can be audio data other than music audio data and navigation audio data. For example, other audio data can be ringtone audio data, or prompt tone audio data, etc.

[0225] Exemplarily, Figure 6 FIG. is a schematic diagram of a process for playing music audio data based on a music audio path provided by an embodiment of the present application. In Figure 6 the corresponding embodiment, taking the application for playing audio data as a media application and the audio data played by the media application as music audio data as an example for illustration, this example does not limit the embodiments of the present application.

[0226] S601. In response to the user's operation of playing music audio data in the media application, the media application notifies the audio engine module to create an audio player 1.

[0227] The audio player 1 (or referred to as player1) is used to write music audio data into buffer1 in the audio engine module.

[0228] The user's operation of playing music audio data in the media application may be: the user's triggering operation on the play button 101 in the electronic device interface shown in a of Figure 1 . In response to the user's operation of playing music audio data in the media application, it may be in response to the user's triggering operation on the play button 101 in the electronic device interface shown in a of Figure 1 .

[0229] Alternatively, the user's operation of playing music audio data in the media application may be: the user's triggering operation on the play button 112 in the in-vehicle device interface shown in b of Figure 1 . When the in-vehicle device detects the user's triggering operation on the play button 112 in the in-vehicle device interface shown in b of Figure 1 , the in-vehicle device may send a message for playing audio data to the electronic device. In response to the user's operation of playing music audio data in the media application, it may be in response to receiving the message for playing music audio data sent by the in-vehicle device.

[0230] Alternatively, the user's operation of playing music audio data in the media application may be: an operation such as a voice operation for playing audio, which is not limited in the embodiments of the present application.

[0231] Exemplarily, in response to the user's operation of playing audio in the media application, the media application may send a message for creating an audio player 1 to the audio engine module.

[0232] The message for creating the audio player 1 may include one or more of the following: the package name of the media application (or the UID of the media application), the audio type of the music audio data, the first data format, the first number of channels, or the first sampling rate. The first data format, the first number of channels, and the first sampling rate may be audio transmission parameters supported by the media application.

[0233] The audio type of the music audio data can be the audio type for the electronic device to distinguish the audio data in the application. For example, the audio type can include one of the following: media type, call type, ringtone type, text to speech (TTS) type, or notification type, etc.

[0234] For example, after opening the navigation application, the user can wake up the human-computer interaction function in the navigation application through a wake-up word (such as Hello, XX Navigation). In response to the wake-up word, the navigation application can generate human-computer interaction audio data (such as Hello, may I help you?).

[0235] It can be understood that the audio data in different applications can correspond to different audio types. For example, the human-computer interaction audio data in the navigation application can be the TTS type in the audio type, the navigation audio data in the navigation application can be the media type in the audio type, and the audio data in the music application can be the media type.

[0236] To meet the user needs in scenarios such as mobile phone-vehicle interconnection, an audio processing method provided in an embodiment of the present application can implement dividing the media type into a navigation diversion type and a music diversion type, and setting other audio types except the media type in the audio type as other types. Through the reclassification of the audio type, the divided audio type can better meet the user's usage needs.

[0237] The media application can notify the audio engine module to create an audio player by calling the new AudioTrack() instruction. The new AudioTrack() instruction can carry stream_music, sampleRate, channelConfig, and audioFormat. Among them, stream_music can be understood as the audio type of the music audio data, sampleRate can correspond to the first sampling rate, channelConfig can correspond to the first number of channels, and audioFormat can correspond to the first data format.

[0238] It can be understood that the new AudioTrack() may not carry the package name (or UID of the media application) of the media application. In this scenario, when receiving the new AudioTrack(), the audio engine module can obtain the caller through the attributionSource, and the caller can be the package name (or UID of the media application) of the media application (see the description in S610).

[0239] In a possible implementation, in S701, the electronic device may also notify the audio engine module to create an audio player 2 based on the new AudioTrack() instruction, and the parameter values carried in this instruction may be different from those in S601; in S801, the electronic device may also notify the audio engine module to create an audio player 3 based on the new AudioTrack() instruction, and the parameter values carried in this instruction may be different from those in S601. Details will not be elaborated hereinafter.

[0240] S602. The audio engine module sends a message for selecting a shunting type to the audio policy module.

[0241] The message for selecting a shunting type carries the package name of the media application (or the UID of the media application) and the audio type of the music audio data.

[0242] In one implementation, the electronic device may determine the shunting type through the Smart Travel APP based on the steps shown in S603 - S608 (see the description in Figure 6 ).

[0243] In another implementation, the electronic device may also determine the shunting type in the audio policy module. For example, in response to S602, the audio policy module may determine the shunting type according to the first correspondence. In this scenario, the electronic device may not need to execute the steps shown in S603 - S607.

[0244] S603. The audio policy module sends a message for selecting a shunting type to the audio service module.

[0245] S604. The audio service module notifies to call the callback function to send a message for selecting a shunting type to the Smart Travel application.

[0246] It can be understood that since the audio service module has completed the saving of the callback function in the step shown in S504, the audio service module can send a message for selecting a shunting type to the Smart Travel application by calling the callback function, and thus obtain the shunting type corresponding to the music audio path from the Smart Travel application.

[0247] S605. The Smart Travel application determines the music shunting type according to the package name of the media application and the audio type of the music audio data.

[0248] The package name of the media application (or the UID of the media application) and the audio type of the music audio data can both be carried in the step of S601 and passed to the Smart Travel application through S602 - S605.

[0249] In one implementation, the intelligent travel application can pre-configure a first correspondence relationship among the application package name, the audio type of the audio data, and the shunt type, so that the intelligent travel application can obtain the shunt type related to the package name of the media application and the audio type of the music audio data from the first correspondence relationship.

[0250] For example, taking the correspondence relationship among the application package name, the audio type of the audio data, and the shunt type included in the first correspondence relationship as an example for illustration, the correspondence relationship among the UID of the application, the audio type of the audio data, and the shunt type is similar and will not be elaborated here.

[0251] The first correspondence relationship can be as shown in Table 2.

[0252] Table 2 Schematic table of the first correspondence relationship

[0253]

[0254]

[0255] The number of data in the first correspondence relationship may not be limited to the description in Table 2. The intelligent travel application can determine the music shunt type corresponding to the package name of the media application and the media type of the music audio data based on the first correspondence relationship as shown in Table 2.

[0256] S606. The intelligent travel application returns the music shunt type to the audio service module.

[0257] S607. The audio service module returns the music shunt type to the audio policy module.

[0258] In a possible implementation, the audio policy module selects a playback device. In the embodiment of the present application, the playback device can be a car radio. For example, the electronic device can determine the playback device after detecting the establishment of a connection with the car radio, or can also confirm that the playback device is the car radio in response to the user's operation of playing audio in the media application.

[0259] S608. The audio policy module selects the corresponding playback thread 1 according to the music shunt type.

[0260] It can be understood that since the audio policy module has completed the creation of the playback thread 1 based on the steps shown in S507 - S508, and generated the correspondence relationship between the music shunt type and the playback thread 1 after the creation of the playback thread 1 is completed. Therefore, the audio policy module can select the corresponding playback thread 1 according to the music shunt type.

[0261] S609. The audio policy module calls the corresponding playback thread 1 in the audio engine module to create an audio player 1.

[0262] The audio player 1 can be used to implement subsequent playback of music audio data.

[0263] S610. The audio engine module creates the audio player 1 and creates the buffer 3.

[0264] During the process of the audio player 1, the audio engine module can determine the size of the buffer 3 based on parameters such as the first data format, the first number of channels, and the first sampling rate, and create the buffer 3 in the audio player 1. The buffer 3 can implement caching of music audio data in the media application.

[0265] For example, taking the first data format as 16 bit, the first number of channels as 2, and the first sampling rate as 36000 Hz as an example, the size of the buffer 3 is illustrated as follows:

[0266] Size of buffer 3 = 16 × 2 × 36000 × preset frame length × preset cache multiple

[0267] It can be understood that since both the buffer 3 and the buffer 1 can be created by the audio engine module in the playback thread 1, there is a corresponding relationship between the buffer 3 and the buffer 1.

[0268] In a possible implementation manner, the calculation formula of the buffer 3 may not have the preset cache multiple either, and the embodiments of the present application do not limit this.

[0269] Exemplarily, the audio engine module can create an audio player by calling the createTrack_l() instruction. In the createTrack_l(), the audio engine module can determine the identifier of the application through attributionSource, such as the package name of the media application (or the UID of the media application).

[0270] In a possible implementation manner, in S710, the audio engine module can create the audio player 2 by calling the createTrack_l(), and the package name of the navigation application (or the UID of the navigation application) can be carried in the createTrack_l(); in S810, the audio engine module can create the audio player 3 by calling the createTrack_l(), and the package name of the phone application (or the UID of the phone application) can be carried in the createTrack_l(), which will not be elaborated hereinafter.

[0271] S611. The audio engine module notifies the media application of the message that the audio player 1 is successfully created.

[0272] The message that the audio player 1 is successfully created can carry the identifier of the audio player 1.

[0273] S612. The media application copies the music audio data to buffer3 in the audio engine module at equal intervals of every 20 milliseconds.

[0274] Exemplarily, when buffer3 is created, the media application can copy the music audio data to buffer3 in the audio player 1 at equal intervals of every 20 milliseconds.

[0275] Among them, the audio engine module can start playback thread 1 by calling the startoutput() instruction. The portId can be carried in startoutput(), and the portId can be understood as the identifier of the audio player. For example, in S612, the portId can be understood as the identifier of audio player 1.

[0276] In a possible implementation, in S712, the audio engine module can also start playback thread 2 by calling the startoutput() instruction, and the identifier of audio player 2 can be carried in startoutput(); in S812, the audio engine module can also start playback thread 3 by calling the startoutput() instruction, and the identifier of audio player 3 can be carried in startoutput().

[0277] S613. The audio engine module can copy the music audio data in buffer3 to buffer1 at equal intervals of every 20 milliseconds.

[0278] S614. The audio engine module copies the music audio data in buffer1 to buffer2 in the DMSDP audio processing module at equal intervals of every 20 milliseconds.

[0279] In this way, when buffer1, buffer2, and buffer3 are all created, the audio engine module can implement the transmission of music audio data from the media application to the DMSDP audio processing module based on S611 - S612.

[0280] S615. The DMSDP audio processing module sends packet 1 containing music audio data and the music splitting type to the in - vehicle computer.

[0281] This packet 1 may include: a packet header, a data payload, and a trailer.

[0282] The packet header contains the control information of packet 1. For example, the packet header may include: the sender (or source address) of packet 1, the receiver (or destination address) of packet 1, the type of packet 1, the length of packet 1, and the music splitting type.

[0283] The data payload is the actual data part carried by the data packet, which can be different types of data such as text, images, audio, video, etc. For example, the data payload can include music audio data.

[0284] The packet tail usually contains some additional check information for detecting whether errors or losses occur during data transmission.

[0285] Exemplarily, when the DMSDP audio processing module receives music audio data, it can set the music diversion type in the packet header of Packet 1 and set the music audio data in the data payload, and then send Packet 1 containing the music audio data and the music diversion type to the in-vehicle unit.

[0286] S616. The in-vehicle unit parses Packet 1 and determines Speaker 1 for playing the music audio data according to the music diversion type.

[0287] Exemplarily, a second correspondence between the diversion type and the speaker can be preset in the in-vehicle unit, so that the in-vehicle unit can determine Speaker 1 corresponding to the music diversion type according to the second correspondence.

[0288] The second correspondence can be as shown in Table 3.

[0289] Table 3 Schematic table of the second correspondence

[0290]

[0291] The number of data in the second correspondence is not limited to the description in Table 3. The in-vehicle unit can determine Speaker 1 corresponding to the music diversion type based on the second correspondence as shown in Table 3.

[0292] Among them, as shown in Table 3, Speaker 1 described hereinafter can include one or more of the following: co-pilot Speaker 1, rear row Speaker 1, rear row Speaker 2, or rear row Speaker 3, etc. Speaker 2 described hereinafter can include: driver's seat Speaker 1, etc. Speaker 3 described hereinafter can include one or more of the following: driver's seat Speaker 1, co-pilot Speaker 1, rear row Speaker 1, rear row Speaker 2, or rear row Speaker 3, etc.

[0293] S617. The in-vehicle unit instructs Speaker 1 to play the music audio data.

[0294] It can be understood that since the second correspondence can be set in the in-vehicle unit, the in-vehicle unit can control Speaker 1 for playing the music audio data and instruct Speaker 1 to play the music audio data, referring to the steps shown in S614 - S615.

[0295] In a possible implementation, a second correspondence relationship may also be set in the electronic device, enabling the electronic device to specify a speaker for playing audio data. For example, in response to S614, the DMSDP audio processing module may send music audio data and the music shunt type to the intelligent travel APP. The intelligent travel APP determines speaker 1 in the vehicle head unit for playing the music audio data according to the second correspondence relationship, and then returns a target data packet containing the identifier of speaker 1 and the music audio data to the vehicle head unit. Subsequently, the vehicle head unit can parse the target data packet and control the playback of the music audio data on speaker 1.

[0296] Among them, the second correspondence relationship may be pre-set by the electronic device based on Figure 8 the corresponding embodiments, which are not limited in this embodiment of the present application.

[0297] In a possible implementation, when volume control is allowed in the intelligent travel APP, the intelligent travel APP can also send the volumes of different speakers to the vehicle head unit through the target data packet, enabling the vehicle head unit to achieve precise control of the volumes of different speakers.

[0298] Based on this, this embodiment of the present application can implement playing music audio data of the music shunt type using the music audio path and playback thread 1. Subsequently, the vehicle head unit can instruct the corresponding speaker 1 to play the music audio data according to the second correspondence relationship, achieving precise classification of the audio data and enabling the playback form of the music audio data to meet the user's usage requirements.

[0299] Exemplarily, Figure 7 FIG. is a schematic diagram of a process for playing navigation audio data based on a navigation audio path provided by an embodiment of the present application. In Figure 7 the corresponding embodiment, taking the application for playing audio data as a navigation application and the audio data played by the navigation application as navigation audio data as an example for illustration, this example does not limit the embodiments of the present application. Among them, the navigation audio data may also be referred to as navigation sound, etc.

[0300] S701. In response to the user's operation of playing navigation audio data in the navigation application, the navigation application notifies the audio engine module to create audio player 2.

[0301] Audio player 2 (or referred to as player2) is used to write navigation audio data to buffer4 in the audio engine module.

[0302] The user's operation of playing navigation audio data in the navigation application may be: the user's operation of setting a navigation route and starting navigation in the electronic device interface. The response to the user's operation of playing navigation audio data in the navigation application may be the response to the user's operation of setting a navigation route and triggering the start of navigation in the interface of the navigation application.

[0303] Alternatively, the operation of the user to play navigation audio data in the navigation application may be: the operation of the user to set a navigation route in the in-vehicle device and start navigation. Among them, when the in-vehicle device detects the operation of the user to set a navigation route in the in-vehicle device and start navigation, the in-vehicle device may send a message for playing navigation audio data to the electronic device. Responding to the operation of the user to play navigation audio data in the navigation application may be responding to the operation of the user to set a navigation route in the interface of the navigation application and trigger the start of navigation.

[0304] Alternatively, the operation of the user to play navigation audio data in the navigation application may also be: operations such as voice operations for starting navigation, etc., which are not limited in the embodiments of the present application.

[0305] Exemplarily, in response to the operation of the user to play navigation audio data in the navigation application, the navigation application may send a message for creating Audio Player 2 to the audio engine module.

[0306] The message for creating Audio Player 2 may include one or more of the following: the package name of the navigation application (or the UID of the navigation application), the audio type of the navigation audio data, the second data format, the second number of channels, or the second sampling rate. Among them, the second data format, the second number of channels, and the second sampling rate may be audio transmission parameters supported by the navigation application.

[0307] S702. The audio engine module sends a message for selecting a shunt type to the audio policy module.

[0308] The message for selecting a shunt type carries: the package name of the navigation application (or the UID of the navigation application) and the audio type of the navigation audio data.

[0309] S703. The audio policy module sends a message for selecting a shunt type to the audio service module.

[0310] S704. The audio service module notifies the call of the callback function to send a message for selecting a shunt type to the intelligent travel application.

[0311] S705. The intelligent travel application determines the navigation shunt type according to the package name of the navigation application and the audio type of the navigation audio data.

[0312] Among them, the intelligent travel application may determine the navigation shunt type based on the description in the first correspondence relationship. The first correspondence relationship may refer to the description in S605 and will not be elaborated here.

[0313] S706. The intelligent travel application returns the navigation shunt type to the audio service module.

[0314] S707. The audio service module returns the navigation diversion type to the audio policy module.

[0315] S708. The audio policy module selects the corresponding playback thread 2 according to the navigation diversion type.

[0316] It can be understood that since the audio policy module has completed the creation of the playback thread 2 based on the steps shown in S515 - S516, and generated the corresponding relationship between the navigation diversion type and the playback thread 2 after the creation of the playback thread 2 is completed. Therefore, the audio policy module can select the corresponding playback thread 2 according to the navigation diversion type.

[0317] S709. The audio policy module calls the corresponding playback thread 2 in the audio engine module to create the audio player 2.

[0318] The audio player 2 can be used to implement the subsequent playback of the navigation audio data.

[0319] S710. The audio engine module creates the audio player 2 and creates buffer6.

[0320] During the process of the audio player 2, the audio engine module can determine the size of buffer6 based on parameters such as the second data format, the second number of channels, and the second sampling rate, and create buffer6 in the audio player 2. Buffer6 can implement the caching of the navigation audio data in the navigation application. The calculation method of buffer6 can be similar to that of buffer3, which will not be elaborated here.

[0321] S711. The audio engine module notifies the navigation application of the message that the audio player 2 is successfully created.

[0322] The message that the audio player 2 is successfully created can carry the identifier of the audio player 2.

[0323] S712. The navigation application copies the navigation audio data to buffer6 in the audio engine module at equal intervals of every 20 milliseconds.

[0324] Exemplarily, when buffer6 is created, the navigation application can copy the navigation audio data to buffer6 in the audio player 2 at equal intervals of every 20 milliseconds.

[0325] S713. The audio engine module can copy the navigation audio data in buffer6 to buffer4 at equal intervals of every 20 milliseconds.

[0326] S714. The audio engine module can copy the navigation audio data in buffer4 to buffer5 in the DMSDP audio processing module at equal intervals of every 20 milliseconds.

[0327] In this way, when buffers 4, 5, and 6 are all created, the audio engine module can transfer the navigation audio data from the navigation application to the DMSDP audio processing module based on S711 - S712.

[0328] S715. The DMSDP audio processing module sends packet 2 containing the navigation audio data and the navigation diversion type to the in - vehicle unit.

[0329] Packet 2 may include: a packet header, a data payload, and a trailer.

[0330] The packet header contains the control information of packet 2. For example, the packet header may include: the sender (or source address) of packet 2, the receiver (or destination address) of packet 2, the type of packet 2, the length of packet 2, and the navigation diversion type.

[0331] The data payload may include the navigation audio data.

[0332] The trailer usually contains some additional check information for detecting whether errors or losses occur during data transmission.

[0333] S716. The in - vehicle unit parses packet 2 and determines speaker 2 for playing the navigation audio data according to the navigation diversion type.

[0334] Exemplarily, the in - vehicle unit can determine speaker 2 for playing the navigation audio data according to the second corresponding relationship, and the second corresponding relationship can be referred to the description in S616 and will not be elaborated here.

[0335] S717. The in - vehicle unit instructs speaker 2 to play the navigation audio data.

[0336] It can be understood that since the second corresponding relationship can be set in the in - vehicle unit, the in - vehicle unit can control speaker 2 for playing the navigation audio data and instruct speaker 2 to play the navigation audio data, referring to the steps shown in S714 - S715.

[0337] Based on this, the embodiments of the present application can implement playing the navigation audio data under the navigation diversion type by using the navigation audio path and playing thread 2. Furthermore, the in - vehicle unit can instruct the corresponding speaker 2 to play the navigation audio data according to the second corresponding relationship, realizing the precise classification of the audio data, so that the playing form of the navigation audio data can meet the user's usage requirements.

[0338] Exemplarily, Figure 8 is a schematic diagram of the process of playing the ringtone audio data based on other audio paths provided by the embodiments of the present application. Figure 8In a corresponding embodiment, an example is given where the application for playing audio data is called a phone application, and the audio data played by the phone application is ringtone audio data (or referred to as a ringtone). This example does not limit the embodiments of the present application.

[0339] The audio data played by the phone application may also include: a prompt tone or other audio data, etc., which is not limited in the embodiments of the present application.

[0340] S801. When the phone application plays ringtone audio data, the phone application notifies the audio engine module to create an audio player 3.

[0341] The audio player 3 (or referred to as player3) is used to write ringtone audio data into buffer7 in the audio engine module.

[0342] The message for creating the audio player 3 may include one or more of the following: the package name of the phone application (or the UID of the phone application), the audio type of the ringtone audio data, the third data format, the third number of channels, or the third sampling rate. Among them, the third data format, the third number of channels, and the third sampling rate may be audio transmission parameters supported by the phone application.

[0343] S802. The audio engine module sends a message for selecting a shunt type to the audio policy module.

[0344] The message for selecting a shunt type carries the package name of the phone application (or the UID of the phone application), and the audio type of the ringtone audio data. The audio type of the ringtone audio data may be a ringtone type.

[0345] S803. The audio policy module sends a message for selecting a shunt type to the audio service module.

[0346] S804. The audio service module notifies the calling callback function to send a message for selecting a shunt type to the intelligent travel application.

[0347] S805. The intelligent travel application determines other shunt types according to the package name of the phone application and the audio type of the ringtone audio data.

[0348] Among them, the intelligent travel application may determine other shunt types based on the description in the first correspondence relationship. The first correspondence relationship can be referred to the description in S605 and will not be elaborated here.

[0349] S806. The intelligent travel application returns other shunt types to the audio service module.

[0350] S807. The audio service module returns other shunt types to the audio policy module.

[0351] S808. The audio policy module selects the corresponding playback thread 3 according to other shunt types.

[0352] It can be understood that since the audio policy module has completed the creation of the playback thread 3 based on the steps shown in S523 - S524, and generated the corresponding relationship between other shunt types and the playback thread 3 after the creation of the playback thread 3 is completed. Therefore, the audio policy module can select the corresponding playback thread 3 according to other shunt types.

[0353] S809. The audio policy module calls the corresponding playback thread 3 in the audio engine module to create the audio player 3.

[0354] The audio player 3 can be used to implement the subsequent playback of the ringtone audio data.

[0355] S810. The audio engine module creates the audio player 3 and creates buffer 9.

[0356] During the process of the audio player 3, the audio engine module can determine the size of buffer 9 based on parameters such as the third data format, the third number of channels, and the third sampling rate, and create buffer 9 in the audio player 3. Buffer 9 can implement the caching of the ringtone audio data in the phone application. The calculation method of buffer 9 can be similar to that of buffer 3, which will not be elaborated here.

[0357] S811. The audio engine module notifies the phone application of the message that the audio player 3 is successfully created.

[0358] The message that the audio player 3 is successfully created can carry the identifier of the audio player 3.

[0359] S812. The phone application copies the ringtone audio data to buffer 9 in the audio engine module at equal intervals of every 20 milliseconds.

[0360] Exemplarily, when buffer 9 is created, the phone application can copy the ringtone audio data to buffer 9 in the audio player 3 once every 20 milliseconds at equal intervals.

[0361] S813. The audio engine module can copy the ringtone audio data in buffer 9 to buffer 7 at equal intervals of every 20 milliseconds.

[0362] S814. The audio engine module can copy the ringtone audio data in buffer 7 to buffer 8 in the DMSDP audio processing module at equal intervals of every 20 milliseconds.

[0363] In this way, when buffers 7, 8, and 9 are all created, the audio engine module can implement the transmission of ringtone audio data from the phone application to the DMSDP audio processing module based on S811 - S812.

[0364] S815. The DMSDP audio processing module sends packet 3 containing ringtone audio data and other shunt types to the in - vehicle unit.

[0365] Packet 3 can include: a packet header, a data payload, and a packet trailer.

[0366] The packet header contains the control information of packet 3. For example, the packet header can include: the sender (or source address) of packet 3, the receiver (or destination address) of packet 3, the type of packet 3, the length of packet 3, and other shunt types.

[0367] The data payload can include ringtone audio data.

[0368] The packet trailer usually contains some additional check information for detecting whether errors or losses occur during data transmission.

[0369] Exemplarily, when the DMSDP audio processing module receives the ringtone audio data, it can play the ringtone audio data through audio player 3, set other shunt types in the packet header of packet 3, and then send packet 3 containing ringtone audio data and other shunt types to the in - vehicle unit.

[0370] S816. The in - vehicle unit parses packet 3 and determines speaker 3 for playing the ringtone audio data according to other shunt types.

[0371] Exemplarily, the in - vehicle unit can determine speaker 3 for playing the ringtone audio data according to the second corresponding relationship. The description of the second corresponding relationship can be referred to in S616 and will not be elaborated here.

[0372] S817. The in - vehicle unit instructs speaker 3 to play the ringtone audio data.

[0373] It can be understood that since the second corresponding relationship can be set in the in - vehicle unit, the in - vehicle unit can control speaker 3 for playing the ringtone audio data and instruct speaker 3 to play the ringtone audio data. Refer to the steps shown in S814 - S815.

[0374] Based on this, the embodiments of the present application can realize playing the ringtone audio data under other shunt types by using other audio channels and the playback thread 3. Furthermore, the vehicle-mounted device can instruct the corresponding speaker 3 to play the ringtone audio data according to the second corresponding relationship, achieving precise classification of the audio data, so that the playback form of the ringtone audio data can meet the user's usage requirements.

[0375] It can be understood that in the audio processing method provided by the embodiments of the present application, when the electronic device shunts the audio data, the vehicle-mounted device can also control the volume of the audio data under different shunt types. For example, a volume setting interface can be provided in the vehicle-mounted device, and different shunt types and corresponding volume setting buttons can be displayed in the volume setting interface.

[0376] Alternatively, the vehicle-mounted device can set the priorities of the audio data under different shunt types. When the vehicle-mounted device receives the audio data under multiple shunt types, it determines to play the audio data under the shunt type with a high playback priority based on the priorities. For example, a priority setting interface can be provided in the vehicle-mounted device, and different shunt types and corresponding priority setting buttons can be displayed in the priority setting interface.

[0377] Alternatively, when the electronic device shunts the audio data, the vehicle-mounted device can also perform one or more of the following controls: the vehicle-mounted device controls the speakers under different shunt types, controls the audio volume under different shunt types, or controls the playback of the audio data under the shunt type with a higher playback priority.

[0378] When the electronic device shunts the audio data, the embodiments of the present application do not limit the setting methods of the vehicle-mounted device under different shunt types.

[0379] In Figures 5 - 8 the corresponding embodiments, Figure 9 a schematic diagram of the steps for releasing an audio channel is provided for the embodiments of the present application. As Figure 9 shown, the process of releasing the audio channel can include the following steps:

[0380] S901. In response to the user's operation of disconnecting the connection between the vehicle-mounted device and the electronic device, the intelligent travel application cancels the callback function from the audio service module.

[0381] Exemplarily, in response to the user's operation of disconnecting the connection between the vehicle-mounted device and the electronic device, the intelligent travel application cancels the callback function from the audio service module. Furthermore, the audio service module can execute the step of deleting the callback function shown in S902.

[0382] The operation of disconnecting the connection between the in-vehicle unit and the electronic device can correspond to the operation of connecting the in-vehicle unit and the electronic device. For example, in a scenario where the electronic device and the in-vehicle unit establish a communication connection via USB, the operation of disconnecting the connection between the in-vehicle unit and the electronic device can be the operation of disconnecting one end of the USB from the electronic device or the in-vehicle unit; when the electronic device and the in-vehicle unit establish a communication connection via Bluetooth, the operation of disconnecting the connection between the in-vehicle unit and the electronic device can be: the operation of the electronic device turning off Bluetooth, the operation of the in-vehicle unit turning off Bluetooth, or the distance between the electronic device and the in-vehicle unit exceeding a certain preset distance such that the Bluetooth between the electronic device and the in-vehicle unit is disconnected, etc., and the embodiments of the present application do not limit this.

[0383] S902. The audio service module deletes the callback function.

[0384] S903. The intelligent travel application sends a device disconnection event to the audio service module.

[0385] The device disconnection event is used to indicate that the electronic device is disconnected from the in-vehicle unit.

[0386] S904. The audio service module sends the device disconnection event to the audio policy module.

[0387] After the audio policy module receives the device disconnection event, the audio policy module can perform the steps of destroying playback thread 1 and releasing the music audio path, destroying playback thread 2 and releasing the navigation audio path, and destroying playback thread 3 and releasing the other audio path according to the 3 created audio paths. Among them, the embodiments of the present application do not limit the release order of the three audio paths.

[0388] The process of destroying playback thread 1 and releasing the music audio path can refer to the steps shown in S905 - S908.

[0389] S905. The audio policy module notifies the audio engine module to destroy playback thread 1.

[0390] S906. The audio engine module destroys playback thread 1 and releases buffer1 and buffer3.

[0391] During the process of destroying playback thread 1, the audio engine module can release buffer1 and buffer3.

[0392] S907. The audio engine module notifies the DMSDP audio processing module to release the music audio path.

[0393] S908. The DMSDP audio processing module releases the music audio path and releases buffer2.

[0394] Since the DMSDP audio processing module has created buffer2 in S510, the DMSDP audio processing module can release buffer2.

[0395] The process of destroying playback thread 2 and releasing the navigation audio path can be seen in the steps shown in S909 - S912.

[0396] S909. The audio policy module notifies the audio engine module to destroy playback thread 2.

[0397] S910. The audio engine module destroys playback thread 2, and releases buffer4 and buffer6.

[0398] During the process of destroying playback thread 2, the audio engine module can release buffer4 and buffer6.

[0399] S911. The audio engine module notifies the DMSDP audio processing module to release the navigation audio path.

[0400] S912. The DMSDP audio processing module releases the navigation audio path, and releases buffer5.

[0401] Since the DMSDP audio processing module has created buffer5 in S518, the DMSDP audio processing module can release buffer5 during the process of determining to release the navigation audio path.

[0402] The process of destroying playback thread 3 and releasing other audio paths can be seen in the steps shown in S913 - S916.

[0403] S913. The audio policy module notifies the audio engine module to destroy playback thread 3.

[0404] S914. The audio engine module destroys playback thread 3, and releases buffer7 and buffer9.

[0405] During the process of destroying playback thread 1, the audio engine module can release buffer7 and buffer9.

[0406] S915. The audio engine module notifies the DMSDP audio processing module to release other audio paths.

[0407] S916. The DMSDP audio processing module releases other audio paths, and releases buffer8.

[0408] Since the DMSDP audio processing module has created buffer8 in S526, the DMSDP audio processing module can release buffer8 during the process of determining to release the audio path.

[0409] It can be understood that when the electronic device is disconnected from the vehicle head unit, it can determine to destroy the created audio path and the playback thread to achieve the purpose of reducing the device power consumption.

[0410] In a possible implementation, after S503 responds to the user's operation of connecting the vehicle head unit to the electronic device, the intelligent travel application can obtain the attribute information of the speaker from the vehicle head unit and display, based on the attribute information of the speaker, as Figure 10 the interface shown.

[0411] It can be understood that the second corresponding relationship can also be set by the user. Or, the preset second corresponding relationship can support the user to make custom modifications. Or, the electronic device can preferentially adopt the second corresponding relationship set by the user. In this case, the preset second corresponding relationship of the electronic device is temporarily ineffective.

[0412] Figure 10 This is a schematic diagram of an interface for setting a speaker provided by an embodiment of the present application.

[0413] In response to the user's operation of opening the intelligent travel from Settings - More Connections, the electronic device displays the interface as shown in Figure 10 a in the figure. This interface can be an intelligent travel settings interface, and one or more of the following can be displayed in this interface: a button 1001 for managing the mobile phone - vehicle head unit interconnection application, a button for connecting to the vehicle, and text information in the intelligent travel settings interface.

[0414] In response to the triggering operation on the button 1001, the electronic device displays the interface as shown in Figure 10 b in the figure. Buttons for connecting to the vehicle system, buttons for application management, buttons for setting automatic connection management, setting buttons, buttons for viewing supported vehicle models, and a button 1002 for setting audio playback can be displayed in this interface.

[0415] In response to the triggering operation on the button 1002, the electronic device displays the interface as shown in Figure 10 c in the figure. Information such as at least one speaker in the vehicle head unit, the position of the speaker, the on / off status of the speaker, and the volume of the speaker can be displayed in this interface. For example, information about the driver's seat speaker 1 can be displayed in the interface, such as: the driver's seat speaker 1 is on, and the volume of the driver's seat speaker 1 can be 40% of the maximum volume, etc. Similarly, information about the passenger seat speaker 1, the rear row speaker 1, the rear row speaker 2, and the rear row speaker 3 can also be displayed in the interface.

[0416] It can be understood that the electronic device can support the user to control the speaker for playing audio data and the volume of the speaker in the intelligent travel APP, so as to improve the user's listening experience.

[0417] The intelligent travel APP can also control the speaker for playing music audio data. The intelligent travel APP can select the speaker to be controlled under the current traffic diversion type. In this scenario, the intelligent travel APP does not need to pre-configure the second corresponding relationship, and can be based on the user's Figure 10 selection on the interface shown in c in, and flexibly set the speaker playback situation.

[0418] In a possible implementation, the electronic device can also provide multiple audio modes for the user to select, such as Figure 11 the interface shown in, Figure 11 which is another schematic diagram of the interface for setting the speaker provided by the embodiment of the present application.

[0419] In response to the user's triggering operation on the button 1002 shown in b in Figure 10 , the electronic device displays the interface shown in Figure 11 . Multiple audio playback modes provided by the intelligent travel APP can be displayed in this interface. For example, the playback modes can include one or more of the following: immersive mode, children's mode, driver's mode, intelligent mode, or sleep mode, etc.

[0420] In the immersive mode, the electronic device controls all the speakers in the car radio to be turned on; in the children's mode, the electronic device turns down the volume of all the rear speakers; in the driver's mode, the electronic device turns on the driver's speaker and turns off the speakers in other positions; in the intelligent mode, the electronic device automatically turns on the speakers where there are people based on the riding situation; in the sleep mode, the electronic device turns off all the speakers in the car radio.

[0421] The intelligent travel APP can screen the audio playback modes adapted to the traffic diversion type. For example, when the target traffic diversion type is the navigation traffic diversion type, the electronic device can provide the immersive mode and the driver's mode for the user to select; when the target traffic diversion type is the music traffic diversion type, the electronic device can provide the immersive mode, children's mode, driver's mode, intelligent mode, and sleep mode for the user to select. Through the user's selection of the audio playback mode, more flexible control of the speakers in the car radio by the electronic device is achieved.

[0422] Based on the above Figures 5 - 9 corresponding embodiment, for a clearer description of the description in the embodiment of the present application, Figure 12 a flowchart of an audio processing method provided by the embodiment of the present application is shown. As Figure 12 shown, the audio processing method can include the following steps:

[0423] S1201. The first electronic device receives a device connection event of the second electronic device, creates a first thread, and creates a second thread.

[0424] The first electronic device can be the electronic device (such as a mobile phone) described in the embodiments of the present application, and the second electronic device can be the vehicle-mounted device described in the embodiments of the present application.

[0425] For the meaning of the device connection event, refer to the description in S505 and will not be elaborated here.

[0426] The first thread can be the playback thread 1 described in the embodiments of the present application, and the second thread can be the playback thread 2 described in the embodiments of the present application.

[0427] S1202. The first electronic device receives a first operation on the first application.

[0428] The first application can be the media application described in the embodiments of the present application.

[0429] The first operation can be an operation for the user to play music audio data in the media application. Refer to the description in S601.

[0430] S1203. After receiving the first operation, the first electronic device receives a request to create a first player.

[0431] The first player can be the audio player 1 described in the embodiments of the present application.

[0432] The request to create the first player can be the request to create the audio player 1 described in S601.

[0433] The request to create the first player carries: the first media type and the identifier of the first application. For example, the first media type can be the media type described in the embodiments of the present application. The identifier of the first application can be the package name of the media application or the UID of the media application.

[0434] S1204. The first electronic device responds to the request to create the first player and creates the first player.

[0435] S1205. The first electronic device binds the first player to the first thread.

[0436] The first thread corresponds to the first audio type, and the first audio type can be the music shunt type described in the embodiments of the present application.

[0437] S1206. The first electronic device receives a second operation on the second application.

[0438] The second application can be the navigation application described in the embodiments of the present application.

[0439] The second operation may be an operation of playing navigation audio data in a navigation application. Refer to the description in S701.

[0440] S1207. After receiving the second operation, the first electronic device receives a request to create a second player.

[0441] The second player may be the audio player 2 described in the embodiments of the present application.

[0442] The request to create a second player may be the request to create the audio player 2 described in S701.

[0443] The request to create a second player carries: a first media type and an identifier of a second application. For example, the identifier of the second application may be the package name of the navigation application or the UID of the navigation application.

[0444] S1208. In response to the request to create a second player, the first electronic device creates a second player.

[0445] S1209. The first electronic device binds the second player to a second thread, and the second thread corresponds to a second audio type.

[0446] The second audio type may be the navigation shunt type described in the embodiments of the present application.

[0447] Based on this, the first electronic device can achieve shunting for different audio types by creating different threads and different players for different audio types. The classification of audio types enables audio data under different audio types to be played in different playback forms, so as to improve the flexibility of audio data playback.

[0448] It should be understood that the sequential relationship between the steps described in the embodiments of the present application is only an example and does not constitute a limitation on the embodiments of the present application.

[0449] It should be noted that the module names involved in the embodiments of the present application can all be defined as other names, as long as the functions of each module can be achieved, and no specific limitation is imposed on the module names.

[0450] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data that have been authorized by the user or fully authorized by all parties. And the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0451] Figure 13This is a schematic diagram of the hardware structure of another electronic device provided by an embodiment of the present application.

[0452] The electronic device includes a processor 1301 - 1304 and at least one communication interface ( Figure 13 Exemplarily, the communication interface 1303 is taken as an example for illustration).

[0453] The processor 1301 can be a general - purpose central processing unit (CPU), a microprocessor, an application - specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application solution.

[0454] The communication line 1304 may include a circuit for transmitting information between the above - mentioned components.

[0455] The communication interface 1303, using any device such as a transceiver, is used to communicate with other devices or communication networks, such as Ethernet, wireless local area networks (WLAN), etc.

[0456] Possibly, the electronic device may further include a memory 1302.

[0457] The memory 1302 can be a read - only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read - only memory (EEPROM), a compact disc read - only memory (CD - ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu - ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but not limited thereto. The memory can exist independently and be connected to the processor through the communication line 1304. The memory can also be integrated with the processor.

[0458] Among them, the memory 1302 is used to store computer-executable instructions for executing the solution of this application, and is controlled by the processor 1301 for execution. The processor 1301 is used to execute the computer-executable instructions stored in the memory 1302, so as to implement the method provided in the embodiments of this application.

[0459] Possibly, the computer-executable instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not make specific limitations on this.

[0460] In a specific implementation, as an embodiment, the processor 13 may include one or more CPUs, such as Figure 13 CPU0 and CPU1 in

[0461] In a specific implementation, as an embodiment, the electronic device may include multiple processors, such as Figure 13 the processor 1301 and the processor 1305 in

[0462] The broadcast processing method provided by the embodiments of this application can be applied to an electronic device with communication functions. The electronic device includes a terminal device, and the specific device form of the terminal device and the like can refer to the above relevant description, which will not be elaborated here.

[0463] The embodiments of this application provide a terminal device, which includes: a processor and a memory; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, so that the terminal device executes the above method.

[0464] The embodiments of this application provide a chip. The chip includes a processor, and the processor is used to call a computer program in the memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those of the above relevant embodiments, which will not be elaborated here.

[0465] The embodiments of the present application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the above-mentioned method is implemented. The method described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over a computer-readable medium as one or more instructions or codes. The computer-readable medium can include a computer storage medium and a communication medium, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0466] In a possible implementation, the computer-readable medium may include RAM, ROM, a compact disc read-only memory (CD-ROM), or other optical disc storage, a magnetic disk storage, or other magnetic storage devices, or any other medium targeted to carry or store the required program code in the form of instructions or data structures and accessible by a computer. Moreover, any connection is properly termed a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. As used herein, disk and optical disc include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks usually reproduce data magnetically, while optical discs utilize lasers to optically reproduce data. The above combinations should also be included within the scope of the computer-readable medium.

[0467] The embodiments of the present application provide a computer program product. The computer program product includes a computer program. When the computer program is run, the computer is caused to execute the above-mentioned method.

[0468] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowcharts and / or block diagrams, and the combination of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable devices to generate a machine, such that the instructions executed by the processing unit of the computer or other programmable data processing devices generate means for implementing the processes Figure 1One process or multiple processes and / or boxes Figure 1 A device for the functions specified in one box or multiple boxes.

[0469] In the above specific embodiments, the purpose, technical solution and beneficial effects of the present invention have been further described in detail. It should be understood that the above are only specific embodiments of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention shall be included in the protection scope of the present invention.

Claims

1. An audio processing method, characterized in that, The method includes: The first electronic device receives a device connection event of the second electronic device, creates a first thread, and creates a second thread; The first electronic device receives a first operation on a first application; After receiving the first operation, the first electronic device receives a request to create a first player, and the request to create the first player carries: a first media type and an identifier of the first application; The first electronic device creates the first player in response to the request to create the first player; The first electronic device binds the first player to the first thread, and the first thread corresponds to a first audio type; The first electronic device receives a second operation on a second application; After receiving the second operation, the first electronic device receives a request to create a second player, and the request to create the second player carries: the first media type and an identifier of the second application; The first electronic device creates the second player in response to the request to create the second player; The first electronic device binds the second player to the second thread, and the second thread corresponds to a second audio type.

2. The method according to claim 1, wherein Before the first electronic device binds the first player to the first thread, the method further includes: the first electronic device determines that the first application corresponds to the first audio type according to a correspondence relationship among the first media type, the identifier of the first application, and the first audio type; Before the first electronic device binds the second player to the second thread, the method further includes: the first electronic device determines that the second application corresponds to the second audio type according to a correspondence relationship among the first media type, the identifier of the second application, and the second audio type.

3. The method according to claim 1 or 2, characterized in that, The method further includes: During the process of creating the first thread, the first electronic device creates a first buffer and creates a second buffer; During the process of creating the first player, the first electronic device creates a third buffer.

4. The method according to claim 3, characterized in that, The method further includes: After the first player is successfully created, the first electronic device receives first audio data from the first application and caches the first audio data in the third buffer; The first electronic device caches the first audio data in the third buffer into the first buffer; The first electronic device caches the first audio data in the first buffer into the second buffer.

5. The method according to claim 3 or 4, wherein Creating the first buffer includes: determining a first storage space of the first buffer, and creating the first buffer that meets the first storage space, where the first storage space is determined based on one or more of the following: maximum data format, maximum number of channels, maximum sampling rate, preset frame length, or preset buffer multiple; The creating of the second buffer includes: determining a second storage space of the second buffer, and creating the second buffer that meets the second storage space, where the second storage space is determined based on one or more of the following: the data format of the first audio path, the sampling rate of the first audio path, the number of channels supported by the first audio path, or the preset frame length; The creating of the third buffer includes: determining a third storage space of the third buffer, and creating the third buffer that meets the third storage space, where the third storage space is determined based on one or more of the following: the first data format, the first number of channels, the first sampling rate, the preset frame length, or the preset buffer multiple.

6. The method according to claim 5, wherein Before the first electronic device receives a device connection event from the second electronic device, the method further includes: The first electronic device loads a configuration file in response to an operation of starting the first electronic device; The first electronic device obtains a first configuration parameter in the configuration file, where the first configuration parameter corresponds to the first audio type, and the first configuration parameter includes one or more of the following: the name of the first audio path corresponding to the first audio type, the data format of the first audio path, the correspondence between the first audio path and the second electronic device, the sampling rate of the first audio path, or the number of channels supported by the first audio path.

7. The method according to any one of claims 3 to 6, characterized in that, The first electronic device includes: an audio policy module and an audio engine module. When the first electronic device receives a device connection event from the second electronic device and creates a first thread, it includes: The audio policy module receives the device connection event; In response to receiving the device connection event, the audio policy module sends a request to create a first playback thread to the audio engine module; In response to the request to create a first playback thread, the audio engine module creates the first playback thread.

8. The method according to claim 7, characterized in that, The first electronic device further includes: a DMSDP audio processing module. When the first electronic device creates a first buffer and a second buffer, it includes: The audio engine module creates the first buffer; The audio engine module sends a message for creating an audio path to the DMSDP audio processing module; In response to receiving the message for creating an audio path, the DMSDP audio processing module creates the second buffer.

9. The method according to claim 8, wherein When the first electronic device responds to the request to create a first player and creates the first player, it includes: The audio engine module receives the request to create a first player; In response to receiving the request to create a first player, the audio engine module sends a message for selecting an audio type to the audio policy module; In response to receiving the message for selecting an audio type, the audio policy module determines a first audio type and the first thread; The audio policy module notifies the audio engine module to create the first player in the first thread; The audio engine module creates the first player.

10. The method according to claim 9, wherein The first electronic device further includes: a smart travel application, and the audio policy module determines a first audio type, including: In response to receiving the message for selecting an audio type, the audio policy module sends the message for selecting an audio type to the audio service module; In response to receiving the message for selecting an audio type, the audio service module obtains the first audio type from the smart travel application; the smart travel application includes: the correspondence between the first media type, the identifier of the first application, and the first audio type; The audio service module sends the first audio type to the audio policy module; The audio policy module determines the first audio type.

11. The method according to any one of claims 8-10, wherein The first electronic device creates a third buffer area, including: the audio engine module creates the third buffer area; The first electronic device receives first audio data from the first application and caches the first audio data in the third buffer area, including: the audio engine module receives first audio data from the first application and caches the first audio data in the third buffer area; The first electronic device caches the first audio data in the third buffer area into the first buffer area, including: the audio engine module caches the first audio data in the third buffer area into the first buffer area; The first electronic device caches the first audio data in the first buffer area into the second buffer area, including: the audio engine module sends the first audio data in the first buffer area to the DMSDP audio processing module, and the DMSDP audio processing module caches the first audio data in the first buffer area into the second buffer area.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: The first electronic device sends the first audio data and the first audio type to the second electronic device, and the first audio data corresponds to the first audio type; The first electronic device sends the second audio data and the second audio type to the second electronic device, and the second audio data corresponds to the second audio type.

13. The method according to any one of claims 1-12, characterized in that, The method further includes: The first electronic device receives the device disconnection event of the second electronic device and destroys the first thread and the second thread.

14. An audio processing method, characterized in that, The method includes: The second electronic device receives the first audio data and the first audio type of the first electronic device, and the first audio data corresponds to the first audio type; The second electronic device plays the first audio data through the first speaker, and the first speaker corresponds to the first audio type; The second electronic device receives the second audio data and the second audio type of the first electronic device, and the second audio data corresponds to the second audio type; The second electronic device plays the second audio data through the second speaker, and the second speaker corresponds to the second audio type, and the first speaker is different from the second speaker.

15. The method according to claim 14, characterized in that, The method further includes: When the second electronic device receives the first audio data and the second audio data simultaneously, the second electronic device plays the second audio data, and the priority corresponding to the second audio type is higher than the priority corresponding to the first audio type.

16. An electronic device, characterized in that, The electronic device includes: one or more processors and a memory; The memory is coupled to the one or more processors. The memory is used to store computer program code, and the computer program code includes computer instructions. The one or more processors call the computer instructions to cause the electronic device to execute the method of the first electronic device according to any one of claims 1-13, or to cause the electronic device to execute the method of the second electronic device according to any one of claims 14-15.

17. A chip system, which is applied to an electronic device. The chip system includes one or more processors, and the processors are used to call computer instructions to cause the electronic device to execute the method of the first electronic device according to any one of claims 1-13, or to cause the electronic device to execute the method of the second electronic device according to any one of claims 14-15.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions. When the computer instructions run on an electronic device, they cause the electronic device to execute the method of the first electronic device according to any one of claims 1-13, or to cause the electronic device to execute the method of the second electronic device according to any one of claims 14-15.

19. A computer program product, characterized in that, The computer program product includes computer program code. When the computer program code runs on an electronic device, it causes the electronic device to execute the method of the first electronic device according to any one of claims 1-13, or to cause the electronic device to execute the method of the second electronic device according to any one of claims 14-15.

Images