CN116974508A

CN116974508A - Audio focus control method and device

Info

Publication number: CN116974508A
Application number: CN202310810150.8A
Authority: CN
Inventors: 郑樱樟; 殷红文
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-06-30
Filing date: 2023-06-30
Publication date: 2023-10-31
Anticipated expiration: 2043-06-30
Also published as: CN116974508B

Abstract

The embodiment of the application provides an audio focus control method and device, wherein the method comprises the following steps: if the control unit receives an audio focus acquisition request initiated by the first service, determining whether the first service is allowed to acquire the audio focus according to a second service in the holder linked list, wherein the second service is the service holding the audio focus. If the service is allowed, the first service is added to the preemption linked list, and an audio focus release instruction is sent to the second service. After the second service informs that the audio focus has been released, the second service is deleted from the holder linked list and an audio focus grant instruction is sent to the first service. The first traffic is added to the holder linked list and deleted from the preemption linked list. According to the technical scheme, the orderly management of the audio focus can be effectively ensured by maintaining the holder linked list and the preemption linked list.

Description

Audio focus control method and device

Technical Field

The application relates to the technical field of terminals, in particular to an audio focus control method and device.

Background

In the terminal device, there are often scenes where a plurality of services all need to play audio, and in order to ensure that a plurality of services can orderly play audio, audio focuses need to be managed.

Generally, in a single-core architecture, a service that needs to play audio can directly preempt the audio focus to play audio. However, in the multi-core architecture, the chip responsible for controlling the service logic and the chip responsible for controlling the audio hardware first need to interact, so that the audio hardware can control which service audio data is specifically played, and therefore, some time delay exists from the initiation of the audio playing request by the service to the playing of the audio data by the audio hardware.

Therefore, in the multi-core architecture, if the service that needs to play the audio directly preempts the audio focus, the situation that the audio of the previous service is still playing, but the audio focus is already obtained by the latter service may occur, so that the management of the audio focus may be confused.

Disclosure of Invention

The embodiment of the application provides an audio focus control method and device, which are applied to the technical field of terminals.

In a first aspect, an embodiment of the present application provides an audio focus control method. The method comprises the following steps:

if the control unit receives an audio focus acquisition request initiated by a first service, determining whether the first service is allowed to acquire an audio focus according to a second service in a holder linked list, wherein the second service is the service holding the audio focus;

If the first service is allowed, adding the first service to a preemption linked list, and sending an audio focus release instruction to the second service;

deleting the second service from the holder linked list after the second service informs that the audio focus has been released, and sending an audio focus grant instruction to the first service;

adding the first traffic to the holder linked list and deleting the first traffic from the preemption linked list.

In this embodiment, when the first service needs to acquire the audio focus, if it is determined that the first service is allowed to acquire, the first service is first recorded in the preemption linked list, and then the audio focus is granted to the first service when it is determined that the second service currently holding the audio focus has released the audio focus, so that the situation that the first service holds the audio focus but the audio data of the second service is actually played can be avoided, and ordered management of the audio focus is effectively ensured.

In some implementations, the terminal device further includes a second chip for controlling audio hardware, where the second chip includes a driving unit of the audio hardware;

After the audio focus release instruction is sent to the second service, the method further includes:

the second service sends a play stopping instruction to the driving unit;

the driving unit responds to the play stopping instruction and controls the audio hardware to stop playing;

and the driving unit sends feedback information to the second service, wherein the feedback information is used for indicating that the audio hardware stops playing.

In this embodiment, when the second service is to release the audio focus, the second service instructs the driving unit to stop playing the audio of the second service, after the second service receives the feedback information sent by the driving unit and determines that the driving unit has stopped playing, the second service notifies the control unit that the second service has released the audio focus, and then the control unit deletes the second service from the holder linked list, thereby effectively ensuring the information accuracy and validity of the audio focus released by the second service.

In some implementations, the deleting the second service from the holder linked list after the second service informs that the audio focus has been released includes:

the second service responds to the feedback information and sends notification information to the control unit, wherein the notification information is used for notifying that the second service releases the audio focus;

The control unit deletes the second service from the holder linked list in response to the notification information.

In some implementations, after the sending the audio focus grant instruction to the first service, the method further includes:

the first service sends an audio playing instruction to the driving unit;

the driving unit requests the audio data of the first service according to the audio playing instruction and controls the audio hardware to play the audio data of the first service.

In the embodiment, the holder linked list and the preemption linked list are correspondingly updated, so that the correctness of the recorded state in the linked list and the orderly management of the audio focus can be effectively ensured.

In some implementations, adding the first traffic to a preemption linked list includes:

adding the first service to the preemption linked list according to the priority of the first service and the priority of the stored service in the preemption linked list;

wherein, each business in the preemption linked list is ordered according to the order of priority from big to small.

In some implementations, the bottommost end of the holder linked list records free traffic;

The adding the first traffic to the holder linked list and deleting the first traffic from the preemption linked list comprises:

adding each service in the preemption linked list to the header of the holder linked list in the sequence kept in the preemption linked list;

and deleting each service in the preemption linked list.

In some implementations, recoverable identifiers are added to the preemption linked list and the holder linked list for the service that can be recovered and played;

if the second service is a service which can resume playing and the service exists in the preemption linked list, maintaining the second service in the holder linked list after the second service informs that the audio focus is released.

In some implementations, the determining whether to allow the first service to acquire the audio focus according to the second service in the holder linked list includes:

acquiring a preset matrix, wherein the preset matrix comprises a processing strategy for the audio focus between a holding service holding the audio focus and a request service requesting to hold the audio focus, and the processing strategy comprises at least one of the following steps: rejecting the request service to obtain an audio focus, allowing the request service to obtain an audio focus and the hold service to release an audio focus, and allowing the request service and the hold service to share an audio focus;

Searching a target processing strategy for the audio focus between the first service and the second service in the preset matrix, and determining whether the first service is allowed to acquire the audio focus according to the target processing strategy.

In the embodiment, whether the corresponding service is allowed to occupy the audio focus or not is simply and efficiently determined through the preset matrix, complex maintenance operation is not required to be performed on each service, the preset matrix is directly updated when the service is newly added subsequently, adjustment is not required to be performed on each service, and therefore the management complexity of the audio focus can be effectively reduced.

In some implementations, a mixing container is also maintained in the control unit;

the method further comprises the steps of:

if the target processing strategy is that the first service and the second service share an audio focus, judging whether the service exists in the audio mixing container;

if yes, rejecting the first service to acquire an audio focus;

if not, adding the first service to the mixing container, granting an instruction to the audio focus of the first service, and sending an audio adjustment instruction to the second service.

In some implementations, after the sending the audio adjustment instruction to the second service, the method further includes:

the second service sends a sound mixing starting instruction to the driving unit;

and the driving unit adjusts the playing parameters of the audio hardware for playing the audio data of the second service according to the audio mixing starting instruction.

In some implementations, the method further comprises:

after the first service releases the audio focus, deleting the first service from the mixing container, and sending a mixing ending instruction to the second service;

the second service sends a command for canceling the mixing to the driving unit;

and the driving unit restores the playing parameters of the audio hardware for playing the audio data of the second service according to the audio mixing canceling instruction.

In the embodiment, the audio mixing processing of multiple services can be effectively realized in the dual-core system through the mixing container.

In a second aspect, an embodiment of the present application provides an audio focus control apparatus. The device comprises:

the processing module is used for determining whether the first service is allowed to acquire the audio focus or not according to a second service in the holder linked list if the control unit receives the audio focus acquisition request initiated by the first service, wherein the second service is the service holding the audio focus;

The processing module is further configured to add the first service to a preemption linked list and send an audio focus release instruction to the second service if the first service is allowed;

the processing module is further configured to delete the second service from the holder linked list after the second service informs that the audio focus has been released;

the sending module is used for sending an audio focus grant instruction to the first service;

the processing module is further configured to add the first service to the holder linked list and delete the first service from the preemption linked list.

the sending module is further configured to:

after the audio focus release instruction is sent to the second service, the second service sends a play stopping instruction to the driving unit;

the processing module is further configured to: the driving unit responds to the play stopping instruction and controls the audio hardware to stop playing;

the sending module is further configured to: and the driving unit sends feedback information to the second service, wherein the feedback information is used for indicating that the audio hardware stops playing.

In some implementations, the processing module is specifically configured to:

In some implementations, the sending module is further configured to:

after the audio focus grant instruction is sent to the first service, the first service sends an audio playing instruction to the driving unit;

the processing module is further configured to: the driving unit requests the audio data of the first service according to the audio playing instruction and controls the audio hardware to play the audio data of the first service.

In some implementations, the processing module is specifically configured to:

the processing module is specifically configured to:

and deleting each service in the preemption linked list.

In some implementations, the processing module is specifically configured to:

the processing module is further configured to:

if yes, rejecting the first service to acquire an audio focus;

In some implementations, the sending module is further to:

after the audio adjustment instruction is sent to the second service, the second service sends an instruction for starting mixing to the driving unit;

the processing module is further configured to: and the driving unit adjusts the playing parameters of the audio hardware for playing the audio data of the second service according to the audio mixing starting instruction.

In some implementations, the processing module is further to:

In a third aspect, an embodiment of the present application provides a terminal device, which may also be referred to as a terminal (terminal), a User Equipment (UE), a Mobile Station (MS), a Mobile Terminal (MT), or the like. The terminal device may be a mobile phone, a smart television, a wearable device, a tablet (Pad), a computer with wireless transceiving function, a Virtual Reality (VR) terminal device, an augmented reality (augmented reality, AR) terminal device, a wireless terminal in industrial control (industrial control), a wireless terminal in unmanned driving (self-driving), a wireless terminal in teleoperation (remote medical surgery), a wireless terminal in smart grid (smart grid), a wireless terminal in transportation safety (transportation safety), a wireless terminal in smart city (smart city), a wireless terminal in smart home (smart home), or the like.

The terminal device includes: comprising the following steps: a processor and a memory; the memory stores computer-executable instructions; the processor executes computer-executable instructions stored in the memory to cause the terminal device to perform a method as in the first aspect.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing a computer program. The computer program, when executed by a processor, implements a method as in the first aspect.

In a fifth aspect, embodiments of the present application provide a computer program product comprising a computer program which, when run, causes a computer to perform the method as in the first aspect.

In a sixth aspect, an embodiment of the present application provides a chip comprising a processor for invoking a computer program in a memory to perform a method according to the first aspect.

It should be understood that the second to sixth aspects of the present application correspond to the technical solutions of the first aspect of the present application, and the advantages obtained by each aspect and the corresponding possible embodiments are similar, and are not repeated.

Drawings

Fig. 1 is a schematic diagram of an audio focus occupation manner according to an embodiment of the present application;

Fig. 2 is a schematic diagram of a scenario in which audio is played by multiple services according to an embodiment of the present application;

fig. 3 is a schematic diagram of a second scenario of multi-service audio playback provided in an embodiment of the present application;

fig. 4 is a schematic software architecture diagram of a terminal device according to an embodiment of the present application;

fig. 5 is a flowchart of an audio focus control method according to an embodiment of the present application;

FIG. 6 is an interactive flowchart of an audio focus control method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a preset matrix according to an embodiment of the present application;

FIG. 8 is a second interactive flowchart of a method for controlling an audio focus according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a change in a linked list according to an embodiment of the present application;

fig. 10 is an interaction flow chart III of an audio focus control method according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of an audio focus control device according to an embodiment of the present application;

fig. 12 is a schematic hardware structure of a terminal device according to an embodiment of the present application.

Detailed Description

For purposes of clarity in describing the embodiments of the present application, the words "exemplary" or "such as" are used herein to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a alone, a and B together, and B alone, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a, b, c, a-b, a-c, b-c, or a-b-c, wherein a, b, c may be single or plural.

The "at … …" in the embodiment of the present application may be an instant when a certain situation occurs, or may be a period of time after a certain situation occurs, which is not particularly limited. In addition, the display interface provided by the embodiment of the application is only used as an example, and the display interface can also comprise more or less contents.

In order to better understand the technical scheme of the application, the related technology related to the application is further described in detail.

With the continuous development of terminal equipment technology, in order to meet various demands of users, a plurality of application programs are usually installed in a terminal equipment, and one application program may include a plurality of services, for example, in the application program of a call, a service of an incoming ring tone may be included, and a call service may also be included, where one service may be understood as a function that can be provided by one application program.

Services in the terminal device may need to play audio, for example, an incoming ring tone service needs to play an incoming ring tone, for example, a call service needs to play call content, for example, a music playing service needs to play a music file, for example, a timer needs to play a prompt tone, and so on.

In addition, a plurality of services often exist in the terminal equipment and a scene of playing audio is needed at the same time, so that in order to ensure that the plurality of services can orderly play audio, the management of audio playing can be performed through an audio focus.

Where audio focus is the concept introduced by the operating system to manage the audio hardware for enabling the business (application) to use control of the audio hardware in the time dimension. Generally, a service applies for an audio focus, and after the audio focus is applied successfully, the audio can be played normally. After the audio playing of the service is completed, the audio focus is released, so that other audio can be successfully applied to the audio focus when the audio needs to be played.

The occupation mode of the audio focus may include an exclusive audio focus and a shared audio focus, where the exclusive audio focus refers to that a single service uses audio hardware to perform audio playing, the shared audio focus refers to that two or more services use audio hardware to perform audio playing at the same time, and when a plurality of services play audio at the same time, audio data of the plurality of services are mixed in the audio hardware.

For example, it can be understood with reference to fig. 1, and fig. 1 is a schematic diagram of an occupation manner of an audio focus according to an embodiment of the present application.

As shown in fig. 1, for example, the music service starts playing music at time t1, when the music service is in exclusive audio focus.

Assuming that the timer service determines that the time expires at time t2, thereby playing the alert tone, then the timer service and the music service share the audio focus during the period of time t 2-t 3. The prompting tone playing of the timer service is completed by the time t3, and the music service resumes the exclusive audio focus.

It is further assumed that the call service needs to play the call audio at the time t3, where the call service can only monopolize the audio focus, so that the call service monopolizes the focus in the time period from t4 to t 5. The call audio playing of the call service is completed by the time t5, and the music service resumes the exclusive audio.

Currently, there is a single-core architecture, that is, there is only one chip in the terminal device, and there is also a multi-core architecture, that is, there are multiple chips in the terminal device.

In the single-core architecture, if a certain low-priority service currently occupies an audio focus for audio playing, and at the moment, a high-priority service also needs to play audio, the high-priority service can directly occupy the audio focus, and after the high-priority service occupies the audio focus, audio hardware can be directly used for audio playing.

However, in the multi-core architecture, the chip responsible for controlling the service logic and the chip responsible for controlling the audio hardware are usually two separate chips, and when controlling which service audio data is specifically played by the audio hardware, interaction needs to be performed between the two chips, so that some time delay exists from the initiation of the service audio playing request to the playing of the audio data by the audio hardware.

Specifically, in the multi-core architecture, all audio playing services relate to interaction between dual cores, dual-machine communication relates to bilateral data transmission and respective task scheduling processing, all audio control instructions are sent from a chip responsible for controlling service logic to a chip responsible for controlling audio hardware to execute response and report a state, the time difference is also changed due to the change of the current running condition of the system, and the busy task response time is longer.

The technical problems described herein are described below with reference to two scenes, fig. 2 is a schematic diagram of a first scene of multi-service audio playback provided by an embodiment of the present application, and fig. 3 is a schematic diagram of a second scene of multi-service audio playback provided by an embodiment of the present application.

Taking the terminal device as a wearable device as an example, referring to fig. 1, assume that before time t1, a timer is playing a prompt tone, an incoming call is made while the timer is ringing, and at time t1, the incoming call ringtone preempts the audio focus of the timer to play the incoming call ringtone. And then the user selects to answer the call, and the call preempts the audio focus of the timer at the time t2 so as to play the call voice.

And referring to fig. 2, it is assumed that a timer is playing music before time t1, incoming calls are made during the music playing process, and incoming call ringtones occupy the audio focus of the music at time t1 to play incoming call ringtones. And then the user selects to answer the call, and the call preempts the audio focus of the timer at the time t2 so as to play the call voice.

And, regardless of whether the music is played in the foreground or in the background, the music should automatically resume its hold audio focus after the incoming call is completed. Referring to fig. 2, at time t3, the call introduction, the music resumes to hold the audio focus, and the music resumes to play automatically.

The distinction between the single-core architecture and the multi-core architecture is described below with respect to the two application scenarios described above.

Taking fig. 1 as an example, in the single-core architecture, when the timer is holding the audio focus to play the alert tone, the incoming ring needs to play the ring audio, and because the service priority of the incoming ring is higher than that of the timer, the incoming ring can directly occupy the audio focus. And because of the single-core architecture, after the incoming ring signal seizes the audio focus, the incoming ring signal can be directly played through the audio hardware.

However, in the multi-core architecture, if a scheme of directly preempting the audio focus by the service that needs to play the audio is still adopted, the following situations may occur: when the timer is holding the audio focus to play the prompt tone, the incoming ring tone needs to play the ring tone, and the incoming ring tone directly preempts the audio focus because the service priority of the incoming ring tone is higher than that of the timer. After the timer loses the audio focus, the chip controlling the service logic needs to inform the chip controlling the audio hardware to stop playing the prompting tone of the timer service, but because of the existence of the transmission delay, when the audio hardware has not stopped playing the prompting tone, the incoming call bell has already obtained the audio focus.

After the incoming call bell gets the audio focus, the incoming call interface shown in fig. 1 can be rendered, so that the wearable device displays the incoming call interface, but meanwhile, the wearable device plays the prompt tone of the timer, so that the management of the audio focus is disordered, and the interface of the terminal device and the played audio cannot be matched.

Aiming at the technical problems introduced above, the application provides the following technical conception: by maintaining a holder linked list and a preemption linked list in a control unit for managing the audio focus, the service currently holding the audio focus and the service waiting for acquiring the audio focus are maintained, and then the next service is allowed to hold the audio focus after the previous service releases the audio focus, so that the orderly management of the audio focus in the multi-core architecture can be ensured.

First, a specific software architecture of a terminal device with a multi-core architecture will be described with reference to fig. 4, and fig. 4 is a schematic diagram of the software architecture of the terminal device according to an embodiment of the present application.

As shown in fig. 4, a first chip, a second chip and a third chip may be disposed in the terminal device in the present application, where, for example, the first chip is responsible for the master control and sensor hub of the terminal device, the second chip is responsible for bluetooth and audio of the terminal device, and the third chip is responsible for communication services of the terminal device.

In the technical scheme of the application, the first chip is specifically used for processing business logic, and the second chip is specifically used for controlling audio hardware.

Referring to fig. 4, a third party application and a system application may be further deployed in the first chip, and the system application may further include a UI layer and a service layer, where the UI layer is used to implement processing of an application interface, and the service layer is used to implement processing of a specific service of the application. It will be appreciated that in practice third party applications are similar, also including UIs as well as services.

And an audio service (audio service) is also disposed in the first chip, and a control unit of an audio focus may be included in the audio service, and the control unit is specifically used for processing data related to the audio focus.

And a driving unit and audio hardware are deployed in the second chip, and the driving unit is used for carrying out data interaction with the related software unit in the first chip so as to control the audio playing of the audio hardware.

In the actual implementation process, the specific model of each chip described above can be determined according to the actual requirement, and the number of the chips actually contained in the terminal device and the service for which each chip is responsible can also be selected and determined according to the actual requirement, so long as the chip for which the service is responsible and the chip for which the audio hardware is responsible are two independent chips, the technical scheme of the application can be applied.

When dual-core communication is used to implement audio control, the dual-core communication generally includes an audio playing process and an audio stopping process, and interactions between the modules in the two processes are described below.

In the audio playing flow, a user can trigger audio playing on a UI interface of an application program, and then an audio playing instruction at the UI level is transmitted to an audio service. The audio service unit may send configuration parameters to a driving unit (may also be referred to as an audio task) in the second chip, where the configuration parameters may include at least one of the following: format, number of channels, bit depth, sampling rate. And then the driving unit carries out parameter configuration on the audio hardware according to the received configuration parameters, and the audio hardware plays the audio data according to the configured parameters.

The drive unit may then request audio data for the service from the audio service or the drive unit may also request audio data directly from the service. The audio service may then parse the data and send the parsed audio data to the drive unit.

For example, the audio service may send a bitmap (bitmap) to the driving unit every two data packets, and the driving unit verifies whether packet loss occurs according to the bitmap, and if packet loss occurs, the audio service re-requests the audio service for audio data, and then the audio service re-parses the data and occurs.

After the audio service receives the audio data, the audio data is sent to the audio hardware for playing, so that the audio playing flow is realized.

And in the audio stop playing process, the user can trigger the audio stop playing at the UI interface of the application program, and then the stop playing instruction at the UI layer is transmitted to the audio service. The audio service unit can send a play stopping instruction to the driving unit in the second chip, and the driving unit controls the audio hardware to stop playing.

And the driving unit can also send feedback information of stopping completion to the audio service, and then call back the UI processing to realize corresponding interface rendering.

On the basis of the above description, the audio focus control method provided by the application is described below with reference to specific embodiments. First, referring to fig. 5, fig. 5 is a flowchart of an audio focus control method according to an embodiment of the present application.

As shown in fig. 5, the method includes:

s501, if the control unit receives an audio focus acquisition request initiated by a first service, determining whether to allow the first service to acquire an audio focus according to a second service in the holder linked list, wherein the second service is the service holding the audio focus.

When it can be determined based on the above-described software architecture, a control unit of an audio focus is disposed in the first chip, and in this embodiment, a holder linked list and a preemption linked list are maintained in the control unit. The service which is currently holding the audio focus and/or the service which needs to restore the audio focus later is recorded in the holder linked list, and the service which waits for acquiring the audio focus is recorded in the preemption linked list.

Illustratively, the records in the two tables of the holder chain table and the preemption chain table are identifiers of the services, and for convenience of description, the contents of the following text description are the services in the holder chain table and the services in the preemption chain table, but it should be understood that the specific meaning is the services recorded in the holder chain table and the services recorded in the preemption chain table.

Assuming that the first service needs to play audio, the first service may initiate an audio focus acquisition request to the control unit, and after receiving the audio focus acquisition request of the first service, the control unit may first determine that the second service in the holder linked list is holding the audio focus at the current time.

In one possible implementation, the service in the header in the bearer linked list is the service that is holding the audio focus at the current time, so the service in the header may be determined as the second service.

And then determining whether the first service is allowed to acquire the audio focus according to the second service. For example, if the priority of the first service is greater than that of the second service, the first service is allowed to acquire the audio focus, and if the priority of the first service is less than that of the second service, the first service is not allowed to acquire the focus.

If the control unit determines that the first service is not allowed to acquire the audio focus, the flow may be ended directly, or rejection information may be sent to the first service to inform the first service of rejecting its audio focus acquisition request.

In this embodiment, the first service may also be understood as a high priority service, and the second service may also be understood as a low priority service.

S502, if the first service is allowed, adding the first service to a preemption linked list, and sending an audio focus release instruction to the second service.

If the control unit determines that the first service is allowed to acquire the audio focus, in this embodiment, the first service is not directly allowed to acquire the audio focus, but is added to the preemption linked list first.

And the control unit may further send an audio focus release instruction to the second service to instruct the second service to release the audio focus, and in a possible implementation manner, the control unit may send the audio focus release instruction to the second service in a callback manner.

In the actual implementation process, the execution sequence of adding the first service to the preemption linked list and sending the audio focus release instruction to the second service may be selected according to actual requirements, which is not limited in this embodiment.

S503, deleting the second service from the holder linked list after the second service informs that the audio focus is released, and sending an audio focus grant instruction to the first service.

The second service performs a correlation process to release the audio focus after receiving the audio focus release instruction, and informs the control unit that the audio focus has been released after the second service releases the audio focus. In one possible implementation, the second service, in case it is confirmed that the audio hardware has stopped playing the audio data of the second service, confirms that the audio focus has been released, thereby informing the control unit that it has released the audio focus.

After confirming that the second service has released the audio focus, the control unit may delete the second service from the holder linked list, and then send an audio focus grant instruction to the first service, where the audio focus grant instruction is used to inform that the first service is granted with audio focus.

After receiving the audio focus grant instruction, the first service can interact with the second chip, so that audio data of the first service can be played by using audio hardware.

S504, adding the first service to the holder linked list, and deleting the first service from the preemption linked list.

The control unit sends an audio focus grant instruction to the first service, which indicates that the first service has acquired audio focus, and then the control unit needs to record the first service to acquire audio focus, so that the first service is added to the holder linked list, and the first service needs to be deleted from the preemption linked list.

For example, the control unit may determine whether there is traffic in the preemption linked list each time after deleting traffic from the bearer linked list, that is, whether there is traffic waiting to preempt the audio focus. If so, the trigger control unit sends an audio focus grant instruction to the first service, adds the first service to the holder linked list, and deletes the first service from the preemption linked list.

The audio focus control method provided by the embodiment of the application comprises the following steps: if the control unit receives an audio focus acquisition request initiated by the first service, determining whether the first service is allowed to acquire the audio focus according to a second service in the holder linked list, wherein the second service is the service holding the audio focus. If the service is allowed, the first service is added to the preemption linked list, and an audio focus release instruction is sent to the second service. After the second service informs that the audio focus has been released, the second service is deleted from the holder linked list and an audio focus grant instruction is sent to the first service. The first traffic is added to the holder linked list and deleted from the preemption linked list. When the first service needs to acquire the audio focus, if the first service is determined to be allowed to acquire, the first service is firstly recorded in the preemption linked list, then the audio focus is granted to the first service under the condition that the second service currently holding the audio focus is determined to release the audio focus, so that the situation that the first service holds the audio focus but the audio data of the second service is actually played can be avoided, then the first service is deleted from the preemption linked list and recorded in the preemption linked list, and the orderly management of the audio focus can be effectively ensured by maintaining the preemption linked list and the preemption linked list.

Based on the above description, the audio focus control method provided by the present application will be described in further detail with reference to fig. 6 to 7 in combination with the angle of interaction between the software units. Fig. 6 is an interactive flowchart of an audio focus control method according to an embodiment of the present application, and fig. 7 is a schematic diagram of a preset matrix according to an embodiment of the present application.

As shown in fig. 6, the method includes:

s601, a first service sends an audio focus acquisition request to a control unit.

When the first service needs to play audio, an audio focus acquisition request is sent to the control unit first.

S602, the control unit adds the first service to the preemption linked list.

After receiving an audio focus acquisition request initiated by a first service, the control unit first determines whether to allow the first service to acquire the audio focus according to the service in the holder linked list, which is holding the audio focus.

Illustratively, the service that is holding audio focus is actually the service that is located at the head of the holder linked list, referring to the linked list case illustrated in fig. 6 (a), where the second service is located at the head of the holder linked list, which is the service that is holding audio focus.

In one implementation, the preemption authority relationship of the service to the rest of the services may be maintained separately in each service, e.g., maintaining preemption authority relationships with service 2, service 3, service 4 in service 1, maintaining preemption authority relationships with service 1, service 3, service 4 in service 2, etc.

When each service is in the preemption of the audio focus, judging what service is currently in the preemption of the audio focus, determining whether the service has the authority of preempting the audio focus according to the preemption authority relation maintained by each service, and when the preemption authority is determined to be in the preemption authority, releasing the audio focus of the preempted service and updating the corresponding service UI.

However, in such an implementation, each new service needs to be newly added in the software architecture, a logic judgment between the new service and all the original services is maintained, and the modification of the preemption authority also involves the cooperation and the modification of all the services, that is, the code needs to be modified for all the services in the original system to supplement the preemption authority relationship between the new service and the new service, so that the implementation can cause a complicated and complex processing flow.

In the technical scheme of the application, a preset matrix can be set, wherein the preset matrix comprises a processing strategy for the audio focus between a holding service holding the audio focus and a request service requesting to hold the audio focus, and the processing strategy comprises at least one of the following steps: rejecting request service to obtain audio focus, allowing request service to obtain audio focus and holding service to release audio focus, allowing request service and holding service to share audio focus;

as can be understood from fig. 7, the preset matrix is assumed to have 5 services, i.e. idle service and service 1 to service 4, where each service may be a holding service or a request service, so that the preset matrix includes any service as a request service and a processing policy when the request service requests to acquire an audio focus when any service is a holding service.

In fig. 7, R (Reject) indicates that the request service is refused to acquire the audio focus (i.e., the audio focus holding the service cannot be preempted), E (Exclusive) indicates that the request service is allowed to acquire the audio focus and the hold service is released (i.e., the audio focus holding the service can be preempted), and C (current) indicates that the request service and the hold service are allowed to share the audio focus, specifically, the request service can acquire the audio focus while the hold service also holds the audio focus (i.e., can hold the focus and mix at the same time).

As described in connection with a specific example of fig. 7, for example, when service 2 is currently holding an audio focus and service 3 requests to acquire an audio focus, then service 2 is the holding service, service 3 is the requesting service, and the processing policy corresponding to fig. 7 is E, that is, the requesting service is allowed to acquire an audio focus and the holding service releases an audio focus, that is, the audio focus of service 2 may be preempted by service 3.

Referring again to fig. 7, for example, service 3 is currently holding an audio focus, and service 4 requests to acquire an audio focus, then service 3 is the holding service, service 4 is the requesting service, and the processing policy corresponding to fig. 7 is R, i.e., the requesting service is denied to acquire an audio focus, that is, the audio focus of service 3 can be preempted by service 4.

When determining whether to allow the first service to acquire the audio focus, searching a target processing strategy for the audio focus between the first service and the second service in the preset matrix, specifically, when the first service is used as a request service and the second service is used as a holding service, the target processing strategy for the audio focus between the first service and the second service can be searched, and then determining whether to allow the first service to acquire the audio focus according to the target processing strategy.

It should be noted that, in this embodiment, when the target processing policy is E described above, it may be confirmed that the first service is allowed to acquire the audio focus. When the target processing strategy is C described above, there are additional processing methods, which are described in detail below.

Therefore, in this embodiment, whether to allow the corresponding service to occupy the audio focus can be simply and efficiently determined through the preset matrix, without complex maintenance operations for each service, and when the service is newly added subsequently, the preset matrix is directly updated, and without adjustment for each service, so that the management complexity of the audio focus can be effectively reduced.

And in one implementation manner, in order to ensure that when any service initiates an audio focus acquisition request, whether the service is allowed to acquire the audio focus can be effectively confirmed, an idle service can be always recorded at the bottommost end of the bearer linked list, the bottommost end can be understood as the table tail of the bearer linked list, the idle service never goes out of the linked list, and the idle service is the service with the lowest priority. Referring to the link list cases illustrated in (a) to (d) of fig. 6, the free traffic is always recorded in the holder link list.

Referring to the preset matrix illustrated in fig. 7, when an idle service is used as a request service, any one service is used as a hold service, and the idle service cannot obtain an audio focus. On the contrary, when the idle service is used as the holding service, any one service is used as the request service, and the audio focus can be obtained.

That is, by setting the resident idle service in the bearer linked list, it can be ensured that the processing strategy for the requested service can be determined based on the preset matrix under the condition that no actual service holds the audio focus, so that the completeness of the scheme can be effectively ensured. For example, when only the idle service exists in the bearer linked list, the system is idle, so if the control unit receives the audio focus acquisition request sent by the first service, the first service may be directly added to the bearer linked list, so that the first service directly obtains the audio focus.

That is, when the idle service is the only service in the bearer linked list, because the idle service is not an actually processed service and no audio is played, the idle service can indicate that the system is in an idle state, so that the first service can directly obtain an audio focus, and various interactive operations introduced above are not needed, thereby effectively improving the audio playing efficiency of the first service.

And it should be further noted that, the preset matrix described in this embodiment is not the only implementation manner, and in the actual implementation process, the preset matrix is not limited to the data format of the matrix, and virtually any possible data format may be used to record the processing policy between any two services described above.

The determination process of the control unit is not illustrated in fig. 6, and after the control unit determines that the first service is allowed to acquire the audio focus, the control unit may add the first service to the preemption linked list. Referring to the linked list case illustrated in fig. 6 (b), a first service is added to the preemption linked list.

And S603, the control unit sends an audio focus release instruction to the second service.

After determining that the first service is allowed to acquire the audio focus, the control unit needs the second service to release the audio focus, so the control unit sends an audio focus release instruction to the second service.

S604, the second service sends a play stopping instruction to the driving unit.

After the second service receives the audio focus release instruction, the second service confirms that the audio focus is to be released, and correspondingly, the second service needs to inform the second chip to stop playing the audio data of the second service so as to ensure the orderly use of audio hardware.

Therefore, the second service sends a play stopping instruction to the driving unit, and the play stopping instruction is used for informing the driving unit that the audio of the second service needs to be stopped.

The second service may directly send a play stopping instruction to the driving unit, or the second service may also send a play stopping instruction to the audio service, and then the audio service sends the play stopping instruction to the driving unit.

And S605, the driving unit responds to the play stopping instruction to control the audio hardware to stop playing.

And S606, the driving unit sends feedback information to the second service.

And the driving unit can send feedback information to the second service under the condition that the audio hardware is confirmed to stop playing, wherein the feedback information is used for indicating that the audio hardware stops playing.

S607, the second service sends notification information to the control unit.

After receiving the feedback information sent by the driving unit, the second service can confirm that the audio hardware has stopped playing, so that the second service can send notification information to the control unit in response to the feedback information, wherein the notification information is used for notifying the control unit that the second service has released the audio focus.

S608, the control unit deletes the second service from the holder linked list.

After receiving the notification, the control unit may confirm that the second service has released the audio focus, so that the control unit may delete the second service from the holder linked list.

Referring to the linked list case illustrated in fig. 6 (c), the second service is deleted in the holder linked list.

S609, the control unit sends an audio focus grant instruction to the first service.

S610, the control unit adds the first service to the holder linked list and deletes the first service from the preemption linked list.

Referring to the linked list case illustrated in fig. 6 (d), a first service is added to the header of the holder linked list, and the first service is deleted from the preemption linked list.

S611, the first service sends an audio playing instruction to the driving unit.

After the first service obtains the audio focus, an audio playing instruction may be sent to the driving unit to instruct the driving unit to play the audio data of the first service.

The first service may send the audio play instruction directly to the drive unit, or the first service may also send the audio play instruction to the audio service, which then sends the audio play instruction to the drive unit.

The execution sequence of S610 and S611 may be determined according to actual requirements.

S612, the driving unit controls the audio hardware to play the audio data of the first service.

The driving unit can then control the audio hardware to play the audio data of the first service. For example, the driving unit may request the audio data of the first service from the audio service in the first chip, and then the audio service sends the audio data of the first service to the driving unit, and the driving unit controls the audio hardware to play.

In this embodiment, after the first service obtains the audio focus, the UI interface of the first service is rendered, so that when the UI interface of the first service is displayed, the terminal device plays the audio data of the first service, thereby avoiding occurrence of abnormal audio play.

In the audio focus control method provided by the embodiment of the application, whether the first service is allowed to acquire the audio focus is determined through the preset matrix, so that the management complexity of the audio focus can be effectively reduced. After the control unit determines that the first service is allowed to preempt the audio focus and sends an audio focus release instruction to the second service, the second service instructs the driving unit to stop playing the audio of the second service, after the second service receives feedback information sent by the driving unit and determines that the driving unit has stopped playing, the second service informs the control unit that the second service has released the audio focus, so that the information accuracy and the effectiveness of the audio focus released by the second service can be effectively ensured. And then the control unit grants the first service audio focus, and correspondingly updates the holder linked list and the preemption linked list, so that the correctness of the recorded state in the linked list and the orderly management of the audio focus can be effectively ensured.

As to the application scenario described in fig. 3, it can be understood that, for a service such as a music service that can resume playing, after an audio focus is occupied by a certain service and then released by the service, it should be ensured that the music service can automatically resume holding the audio focus. The following describes a scheme for automatically recovering audio focus in a dual-core system with reference to fig. 8 to 8, taking a first service as a call service and a second service as a music service as an example.

Fig. 8 is an interaction flow chart II of an audio focus control method according to an embodiment of the present application.

As shown in fig. 8, the method includes:

s801, the call service sends an audio focus acquisition request to the control unit.

S802, the control unit adds the call service to the preemption linked list.

S803, the control unit sends an audio focus release instruction to the music service.

S804, the music service sends a play stopping instruction to the driving unit.

S805, the driving unit responds to the play stopping instruction to control the audio hardware to stop playing.

S806, the driving unit sends feedback information to the music service.

S807, the music service transmits notification information to the control unit.

The implementation of S801 to S807 is similar to the implementation of S601 to S607 described above, and will not be repeated here.

S808, the control unit maintains the music service in the holder linked list.

The difference is that after the second service sends the notification information to the control unit, the control unit determines whether the second service is a service that can resume playing, and determines whether there is a service in the preemption linked list. If the second service is a service which can be played back again and the service exists in the preemption linked list, the current situation is that the service needs to preempt the audio focus of the second service, and after the audio playing of the service which preempts the audio focus is finished, the audio playing of the second service needs to be restored.

Thus in this embodiment, the control unit maintains the music service in the holder's linked list after the music service has been notified that the audio focus has been released.

Illustratively, the control unit may not perform this specific action of "maintaining," step 808 is merely to illustrate that maintaining the music service in the holder's linked list is not deleted, which may be a step that need not be performed.

In this embodiment, a recoverable identifier is added to the service that can be played back for recovery, whether in the preemption linked list or the bearer linked list, and in fig. 8, the recoverable identifier is added to the music service, and in the actual implementation process, the recoverable identifier may be a field.

S809, the control unit sends an audio focus grant instruction to the call service.

S810, the control unit adds the call service to the holder linked list and deletes the first service from the preemption linked list.

The implementation of S809 and S810 is similar to the implementation of S609 and S610 described above, and will not be repeated here.

S811, after the incoming call is hung up, the call service sends an audio focus release request to the control unit.

The audio focus release request is a call service active request to release the audio focus, because the audio playing requirement of the call service is finished.

S812, the control unit deletes the call service from the holder linked list.

In fig. 8, the relevant steps of the call service interacting with the drive unit to request playing of audio content and to request stopping of playing of audio content are saved, which are implemented similarly to the above description and are therefore not shown in detail.

S813, the control unit sends an audio focus grant instruction to the music service.

After the call service is deleted from the holder linked list, the music service is located at the top of the stack in the holder linked list, and the control unit determines that the music service carries the recoverable mark, so that the control unit can directly send an audio focus grant instruction to the application service.

In view of the current situation, because the call service has already sent the audio focus release request, the call service necessarily has no audio data to be played, that is, the situation that the audio focus is not preempted currently, so the control unit directly sends the audio focus grant instruction to the application service at this time, the problem of audio hardware confusion introduced above does not occur, and the situation can be understood that the audio service is taken as the service to be recovered, and the audio focus is automatically obtained.

S814, the music service sends an audio playing instruction to the driving unit.

S815, the driving unit controls the audio hardware to play the audio data of the music service.

In this embodiment, by setting the recoverable identifier for the service that can be recovered and after the second service informs that the audio focus has been released, the control unit determines that the second service is a service that can be recovered, and when there is a service in the preemption linked list, the control unit keeps the second service in the holder linked list, so that the first service that preempting the audio focus can directly recover to hold the audio focus after actively releasing the audio focus, thereby effectively realizing that the recoverable service in the dual-core system is terminated by interrupting the audio play by the service with high priority, and the recoverable service can automatically recover the audio play.

On the basis of the above description, it should also be noted that there may be a plurality of services waiting for preempting the audio focus, so when a service is added to the preemption linked list, the addition may be performed according to the priority of the service.

Illustratively, when adding the first service to the preemption linked list, the following may be used:

adding the first service to the preemption linked list according to the priority of the first service and the priority of the stored service in the preemption linked list; wherein, each service in the preemption linked list is ordered according to the order of the priority from big to small, the ordering refers to the ordering from the head to the tail, that is, the higher the priority is, the closer to the head, the lower the priority is, the closer to the tail.

It can be understood that the addition of elements in the form of the linked list is very flexible, and the addition of elements can be performed at any position until the pointer needs to be modified, so that the linked list maintenance holder and the preemption are adopted in the embodiment, and the flexibility of data maintenance can be effectively ensured.

In one possible implementation, only the first traffic may be operated upon both when the first traffic is added to the holder linked list and when the first traffic is deleted from the preemption linked list.

Alternatively, when the first service is added to the holder linked list, each service in the preemption linked list may be added to the header of the holder linked list in its entirety in the order kept in the preemption linked list.

It can be understood with reference to fig. 9, and fig. 9 is a schematic diagram of a change of a linked list according to an embodiment of the present application.

As shown in fig. 9, assume that the timer service and the idle service are initially included in the holding linked list, and the preemption linked list is empty.

Then, assuming that the music service is to preempt the audio focus and after the control unit confirms the permission, the control unit adds the music service to the preemption linked list.

Then, if the control unit confirms permission after checking, the control unit adds the ring tone service to the list of the preemptiors, wherein the ring tone service has higher priority than the music service, so that the ring tone service is located at the header.

After the related process of releasing the audio focus by the timer service is finished, the control unit deletes the timer service from the holder linked list, and maintains the incoming call ring service and the music service in the preemption linked list, the incoming call ring is in the up and the music service is in the down order, and adds the whole to the header of the holder linked list, thereby obtaining the final holder linked list in fig. 9, wherein the three services are in sequence from the header to the tail: ring tone service, music service, idle service.

It can be understood that, because the writing operation of the linked list is flexible, the two services of bell sound and music can be written into the holder linked list in sequence by simply modifying the pointer, and correspondingly, the subsequent incoming bell sound service with higher priority first obtains the audio focus, and then the music service with higher priority obtains the audio focus.

And when deleting the first service from the preemption linked list, each service in the preemption linked list can be deleted directly. Optionally, after the modification pointer of the above-described holder linked list implements element writing, the element pointer in the preemption linked list is actually changed, so that service deletion in the preemption linked list is implemented correspondingly.

In this embodiment, a plurality of services in the preemption linked list are directly written into the holder linked list at one time, and there is an advantage that each service waiting for the audio focus can be directly written into the holder linked list through one operation, so that the subsequent operation of repeatedly writing and deleting the linked list is avoided, and system resources can be effectively saved. After each service waiting for the audio focus is written into the holder linked list, if the former service finishes audio playing to release the audio focus, the latter service can automatically acquire the audio focus, thereby effectively shortening the time for acquiring the audio focus for the latter service.

On the basis of the description of the foregoing embodiment, it should also be noted that, in the foregoing description, the target processing policy is determined for the first service and the second service, and if the target processing policy indicates that the first service and the second service may share the audio focus, the audio mixing operation may be performed for the audio of the first service and the audio of the second service. Next, referring to fig. 10, a description will be given of a mixing process of service audio, and fig. 10 is an interaction flow chart III of an audio focus control method according to an embodiment of the present application.

As shown in fig. 10, the method includes:

s1001, the first service sends an audio focus acquisition request to the control unit.

S1002, the control unit adds the first service to the mixing container.

After the control unit receives the audio focus acquisition request sent by the first service, a target processing strategy is determined according to the first service and the second service. In this embodiment, a mixing container is also maintained in the control unit, in which a service for mixing with a service that is holding an audio focus is recorded.

The control unit may therefore add the first service to the mixing container if the target processing policy indicates that the first service and the second service may share the audio focus.

In one possible implementation manner, in order to ensure the effect of playing audio by the terminal device, it may be configured to support audio mixing processing of only two services, so when determining that the target processing policy is that the first service and the second service share the audio focus, it may be further determined whether there is a service in the mixing container.

If so, it indicates that there is currently one service in the mixing process, so that the first service can be refused to acquire the audio focus.

If not, it means that no service is currently being mixed, so the first service can be added to the mixing container. Referring to (b) of fig. 10, the first service is recorded in the mixing container.

S1003, the control unit sends an audio adjustment instruction to the second service.

The audio adjustment instruction is used for informing the second service that the second service is to perform audio mixing processing currently, so that the second service needs to perform audio playing adjustment.

S1004, the control unit sends an audio focus grant instruction to the first service.

And the first service and the second service share the audio focus, and the first service is actually obtained the audio focus, so the control unit sends an audio focus grant instruction to the first service.

The execution sequence of S1003 and S1004 may be selected and set according to the actual requirement, which is not limited in this embodiment.

S1005, the second service sends a mixing instruction to the driving unit.

The mixing instruction is used for informing the driving unit that the driving unit needs to mix with other services at present. Alternatively, the second service may also send an instruction to the drive unit to decrease the volume.

S1006, the first service sends an audio playing instruction to the driving unit.

The execution sequence of S1005 and S1006 may be selected and set according to the actual requirement, which is not limited in this embodiment.

S1007, the driving unit responds to the audio mixing instruction to adjust the playing parameters of the audio data of the second service played by the audio hardware.

After receiving the audio mixing instruction sent by the second service, the driving unit can adjust the playing parameters of the audio hardware for playing the audio data of the second service, for example, the volume of the audio data of the second service can be reduced, so that the audio mixing processing with the first service is realized, and the specific audio mixing strategy can be selected and set according to the actual requirement.

S1008, the driving unit responds to the audio playing instruction and controls the audio hardware to play the audio data of the first service.

And the driving unit can also control the audio hardware to play the audio data of the first service after receiving the audio playing instruction sent by the first service. The audio parameters used for playing the audio data of the first service may be default parameters or parameters after mixing and tuning.

Therefore, the effect of the current realization is that the audio hardware plays the audio data of the first service and the audio data of the second service at the same time, and then the playing parameters of the audio hardware are adjusted to a certain extent, thereby realizing the mixed audio playing of the two services at the hardware level.

S1009, the first service sends a play stop instruction to the driving unit.

After the first service ends, the first service may send a play stop instruction to the drive unit.

S1010, the driving unit responds to the play stopping instruction to control the audio hardware to stop playing the audio data of the first service.

S1011, the driving unit sends feedback information to the first service.

The driving unit controls the audio hardware to stop playing the audio data of the first service according to the playing stopping instruction sent by the first service, and sends feedback information to the first service so as to inform the first service that the playing of the audio data of the first service is stopped.

S1012, the first service sends notification information to the control unit.

S1013, the control unit deletes the first service from the mixing container.

Similar to the above description, the notification information is used to inform the control unit that the first service has released the audio focus, so that the control unit may delete the first service from the mixing container after receiving the notification information sent by the first service. Referring to (c) of fig. 10, the first service is deleted in the mixing container.

S1014, the control unit sends a mixing ending instruction to the second service.

S1015, the second service sends a command for canceling the mixing to the driving unit.

The mixing ending instruction is used for informing the second service that the mixing processing is ended. Therefore, after the second service receives the mixing end instruction, it can confirm that the mixing is to be ended, and thus the drive unit is required to send a cancel mixing instruction. Or the second service may also send an instruction for volume restoration to the drive unit.

S1016, the driving unit responds to the audio mixing canceling instruction and restores the playing parameters of the audio data of the second service played by the audio hardware.

After receiving the instruction for canceling the mixing, the driving unit can restore the playing parameters of the audio data of the second service played by the audio hardware, thereby realizing the end of mixing at the hardware level.

According to the audio focus control method provided by the embodiment of the application, the mixing container is arranged, so that the mixing processing of two services can be effectively realized in a dual-core system, and the orderly control of the audio focus can be effectively ensured in the process.

Two special cases in the mixing scenario are described below, assuming a first service in the mixing container and a second service in the holder linked list.

Case 1: if the second service sends an audio focus release request to the control unit in the process of mixing the first service and the second service, the control unit deletes the second service from the holder linked list, adds the first service to the holder linked list, and also needs to delete the first service from the mixing container so that the first service becomes the service currently holding the audio focus in the holder linked list.

The first service and the related interactions between the second service and the driving unit are similar to those described above, and will not be described here again.

Case 2: if the control unit receives the audio focus acquisition request initiated by the third service again in the process of mixing the first service and the second service, then, similar to the description above, the control unit needs to determine the processing policy of the third service according to the first service and the second service. For example, the processing policy may be determined according to the first service and the third service, and the processing policy may be determined according to the second service and the third service, and then the final processing policy for the third service may be determined by combining the two processing policies.

If the processing policy of the third service relative to the first service is to refuse the third service to acquire the audio focus, or if the processing policy of the third service relative to the second service is to refuse the third service to acquire the audio focus, it may be determined that the processing policy of the third service is to refuse the third service to acquire the audio focus.

If the processing policy of the third service relative to the first service is to allow the third service to share the audio focus, or if the processing policy of the third service relative to the second service is to allow the third service to share the audio focus, the above description describes that only two services can share the audio focus at the same time, so it can be determined that the processing policy of the third service is to reject the third service to acquire the audio focus.

If the processing policy of the third service relative to the first service is to allow the third service to acquire the audio focus and the first service releases the audio focus, or if the processing policy of the third service relative to the second service is to allow the third service to acquire the audio focus and the second service releases the audio focus, the processing policy of the third service may be determined to allow the third service to acquire the audio focus and both the first service and the second service release the audio focus.

In this case, therefore, the control unit needs to delete the first service from the mixing container, delete the second service from the holder linked list, and then add the third service to the holder linked list, and the specific interaction content among the specific service, the control module and the driving module is similar to that described in the above embodiment, which will be referred to the description of the above embodiment and will not be repeated here.

The audio focus control method according to the embodiment of the present application has been described above, and the device for executing the audio focus control method according to the embodiment of the present application is described below. It will be appreciated by those skilled in the art that the methods and apparatus may be combined and referred to, and that the related apparatus provided by the embodiments of the present application may perform the steps in the method for sorting a linked list described above.

Fig. 11 is a schematic structural diagram of an audio focus control device according to an embodiment of the present application. As shown in fig. 11, the apparatus 110 includes: a processing module 1101, a transmitting module 1102;

the processing module 1101 is configured to determine whether to allow the first service to acquire the audio focus according to a second service in the bearer linked list if the control unit receives an audio focus acquisition request initiated by the first service, where the second service is a service that is holding the audio focus;

The processing module 1101 is further configured to add the first service to a preemption linked list and send an audio focus release instruction to the second service if allowed;

the processing module 1101 is further configured to delete the second service from the holder linked list after the second service informs that the audio focus has been released;

a sending module 1102, configured to send an audio focus grant instruction to the first service;

the processing module 1101 is further configured to add the first service to the holder linked list and delete the first service from the preemption linked list.

the sending module 1102 is further configured to:

the processing module 1101 is further configured to: the driving unit responds to the play stopping instruction and controls the audio hardware to stop playing;

the sending module 1102 is further configured to: and the driving unit sends feedback information to the second service, wherein the feedback information is used for indicating that the audio hardware stops playing.

In some implementations, the processing module 1101 is specifically configured to:

In some implementations, the sending module 1102 is further configured to:

the processing module 1101 is further configured to: the driving unit requests the audio data of the first service according to the audio playing instruction and controls the audio hardware to play the audio data of the first service.

the processing module 1101 is specifically configured to:

and deleting each service in the preemption linked list.

the processing module 1101 is further configured to:

if yes, rejecting the first service to acquire an audio focus;

In some implementations, the sending module 1102 is further configured to:

the processing module 1101 is further configured to: and the driving unit adjusts the playing parameters of the audio hardware for playing the audio data of the second service according to the audio mixing starting instruction.

In some implementations, the processing module 1101 is further to:

The audio focus control method provided by the embodiment of the application can be applied to electronic equipment with a communication function. The electronic device includes a terminal device, and specific device forms and the like of the terminal device may refer to the above related descriptions, which are not repeated herein.

An embodiment of the present application provides a terminal device, and fig. 12 is a schematic hardware structure of the terminal device provided by the embodiment of the present application. As shown in fig. 12, the terminal device 120 includes: comprising the following steps: a processor 1201 and a memory 1202; memory 1202 stores computer-executable instructions; processor 1201 executes computer-executable instructions stored in memory 1202 to cause terminal apparatus 120 to perform the method described above. When the memory 1202 is provided separately, the terminal device further comprises a bus 1203 for connecting said memory 1202 and the processor 1201.

The embodiment of the application provides a chip. The chip comprises a processor for invoking a computer program in a memory to perform the technical solutions in the above embodiments. The principle and technical effects of the present application are similar to those of the above-described related embodiments, and will not be described in detail herein.

The embodiment of the application also provides a computer readable storage medium. The computer-readable storage medium stores a computer program. The computer program realizes the above method when being executed by a processor. The methods described in the above embodiments may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer readable media can include computer storage media and communication media and can include any medium that can transfer a computer program from one place to another. The storage media may be any target media that is accessible by a computer.

In one possible implementation, the computer readable medium may include RAM, ROM, compact disk-read only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium targeted for carrying or storing the desired program code in the form of instructions or data structures and accessible by a computer. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (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 medium. Disk and disc, as used herein, includes optical disc, laser disc, optical disc, digital versatile disc (Digital Versatile Disc, DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Embodiments of the present application provide a computer program product comprising a computer program which, when executed, causes a computer to perform the above-described method. Embodiments of the present application are described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processing unit of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The foregoing detailed description of the application has been presented for purposes of illustration and description, and it should be understood that the foregoing is by way of illustration and description only, and is not intended to limit the scope of the application.

Claims

1. The audio focus control method is characterized by being applied to terminal equipment, wherein the terminal equipment comprises a first chip for processing business logic, and a control unit of the audio focus in the first chip maintains a holder linked list and a preemption linked list;

the method comprises the following steps:

2. The method according to claim 1, wherein the terminal device further comprises a second chip for controlling audio hardware, the second chip comprising a driving unit of the audio hardware;

the second service sends a play stopping instruction to the driving unit;

3. The method of claim 2, wherein said deleting the second service from the holder linked list after the second service informs that the audio focus has been released comprises:

4. A method according to claim 2 or 3, wherein after said sending an audio focus grant instruction to said first service, said method further comprises:

the first service sends an audio playing instruction to the driving unit;

5. The method of any of claims 1-4, wherein adding the first traffic to a preemption linked list comprises:

6. The method of claim 5, wherein the lowest end of the bearer linked list has idle traffic recorded;

and deleting each service in the preemption linked list.

7. The method of claim 6, wherein a recoverable mark is added to both the preemption linked list and the bearer linked list for recoverable played services;

8. The method of any of claims 1-7, wherein determining whether to allow the first service to acquire audio focus based on the second service in the holder linked list comprises:

9. The method of claim 8, wherein a mixing container is also maintained in the control unit;

the method further comprises the steps of:

if yes, rejecting the first service to acquire an audio focus;

10. The method of claim 9, wherein after the sending the audio adjustment instruction to the second service, the method further comprises:

11. The method according to claim 9 or 10, characterized in that the method further comprises:

12. An audio focus control apparatus, comprising:

13. A terminal device, comprising: a processor and a memory;

the memory stores computer-executable instructions;

the processor executing computer-executable instructions stored in the memory to cause the terminal device to perform the method of any one of claims 1-11.

14. A computer readable storage medium storing a computer program, which when executed by a processor implements the method according to any one of claims 1-11.

15. A computer program product comprising a computer program which, when run, causes a computer to perform the method of any of claims 1-11.