Audio parameter processing method and device, electronic equipment and storage medium

Abstract

The invention relates to an audio parameter processing method and device, electronic equipment and a storage medium. The audio parameter processing method comprises: in response to obtaining a first audio parameter sent based on a first process, determining a key value pair corresponding to the first audio parameter, the key value pair being used for representing a parameter type of the first audio parameter, the parameter type representing whether the first audio parameter needs to be authenticated and whether the first audio parameter needs to be self-recovered; and in response to determining that the first process has the right to issue the first audio parameter based on the key value pair and the first audio parameter needs to be self-recovered, issuing the first audio parameter to a target application based on a parameter set corresponding to the first process. Through the method provided by the embodiment of the invention, the possibility of wrong sending of the parameters caused by the change of the target application identifier can be reduced, so that the audio parameter sending process is more stable.

Description

Technical Field

[0001] This disclosure relates to the field of information processing, and in particular to audio parameter processing methods, apparatus, electronic devices, and storage media. Background Technology

[0002] In related technologies, to ensure that a terminal can send correct parameters to its applications, the terminal typically performs authentication based on the identifier of the parameter recipient before or during parameter transmission. For example, by identifying the parameter recipient's identifier, if the parameter recipient is determined to be an audio playback application, then that parameter recipient is deemed not authorized to receive audio system-related parameters. Conversely, by identifying the parameter recipient's identifier, if the parameter recipient is determined to be an audio system, then that parameter recipient is deemed authorized to receive audio system-related parameters. Summary of the Invention

[0003] To overcome the problems existing in related technologies, this disclosure provides an audio parameter processing method, apparatus, electronic device, and storage medium.

[0004] According to a first aspect of the present disclosure, an audio parameter processing method is provided, comprising: in response to obtaining a first audio parameter sent based on a first process, determining a key-value pair corresponding to the first audio parameter, wherein the key-value pair is used to characterize the parameter type of the first audio parameter, and the parameter type indicates whether the first audio parameter needs authentication and whether it needs self-recovery; in response to determining based on the key-value pair that the first process has the right to send the first audio parameter and that the first audio parameter needs self-recovery, sending the first audio parameter to a target application based on a parameter set corresponding to the first process.

[0005] In one implementation, the first audio parameter, based on the value of the key-value pair, indicates whether a target function of the target application is enabled or disabled. Before sending the first audio parameter to the target application, the method further includes: if the first audio parameter is a parameter used to indicate that the target function is enabled, and the key of the key-value pair corresponding to the second audio parameter is different from the key of the key-value pair corresponding to the first audio parameter, then the audio parameter is added to the parameter set; if the first audio parameter is a parameter used to indicate that the target function is disabled, and there exists a key of the key-value pair corresponding to the second audio parameter that is the same as the key of the key-value pair corresponding to the first audio parameter, then the second audio parameter with the same key is deleted from the parameter set; wherein, the second audio parameter is an audio parameter that has been stored in the parameter set and sent to the target application based on the first process.

[0006] In one implementation, the first audio parameter is a parameter used to indicate that the target function is enabled, and sending the first audio parameter to the target application includes: if there is no key-value pair of the second audio parameter that is the same as the key-value pair of the first audio parameter in the parameter set corresponding to the second process, then sending the first audio parameter to the target application; wherein, the second process is the preceding process of the first process.

[0007] In one implementation, the first audio parameter is a parameter used to indicate that the target function is turned off, and sending the first audio parameter to the target application includes: if the key-value pair of the second audio parameter in the parameter set corresponding to the second process is the same as the key-value pair of the first audio parameter, then sending the first audio parameter to the target application; wherein, the second process is the preceding process of the first process.

[0008] In one implementation, when the first process exits abnormally and the first audio parameter is a parameter used to instruct the target application to close, sending the first audio parameter to the target application includes: if there exists a key-value pair of the second audio parameter in the parameter set corresponding to the second process where the key is the same as the key of the key-value pair of the first audio parameter, and the value of the key-value pair of the second audio parameter is different from the value of the key-value pair of the first audio parameter, then the first audio parameter is sent to the target application; wherein the second process is the preceding process of the first process.

[0009] In one implementation, determining that the process has the right to send the audio parameters based on the key-value pair includes: in response to the key-value pair indicating that the audio parameters are parameter types that a specified process is allowed to send, and the process belongs to the specified process, determining that the process has the right to send the audio parameters.

[0010] In one implementation, sending the first audio parameter to the target application includes: determining a route for sending the first audio parameter based on the key of the key-value pair, wherein there is a correspondence between the key of the key-value pair and the route of the first audio parameter; and sending the first audio parameter to the target application based on the route.

[0011] According to a second aspect of the present disclosure, an audio parameter processing apparatus is provided, comprising: a processing unit, configured to, upon obtaining a first audio parameter sent based on a first process, determine a key-value pair corresponding to the first audio parameter, wherein the key-value pair is used to characterize the parameter type of the first audio parameter, and the parameter type indicates whether the first audio parameter requires authentication and whether it requires self-recovery; and a sending unit, configured to, based on a parameter set corresponding to the first process, send the first audio parameter to a target application if, based on the key-value pair, it is determined that the first process has the right to send the first audio parameter and the first audio parameter requires self-recovery.

[0012] In one implementation, where the first audio parameter, based on the value of the key-value pair, indicates whether a target function of the target application is enabled or disabled, the processing unit is further configured to: add the audio parameter to the parameter set when the first audio parameter is a parameter indicating that the target function is enabled, and the key of the key-value pair corresponding to the second audio parameter is different from the key of the key-value pair corresponding to the first audio parameter; and delete the second audio parameter with the same key from the parameter set when the first audio parameter is a parameter indicating that the target function is disabled, and there exists a key of the key-value pair corresponding to the second audio parameter that is the same as the key of the key-value pair corresponding to the first audio parameter; wherein the second audio parameter is an audio parameter that has been stored in the parameter set and sent to the target application based on the first process.

[0013] In one implementation, when the first audio parameter is a parameter used to indicate that the target function is enabled, the sending unit sends the first audio parameter to the target application in the following manner: if there is no key-value pair of the second audio parameter that is the same as the key-value pair of the first audio parameter in the parameter set corresponding to the second process, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0014] In one implementation, when the first audio parameter is a parameter used to indicate that the target function is turned off, the sending unit sends the first audio parameter to the target application in the following manner: if the key-value pair of the second audio parameter in the parameter set corresponding to the second process is the same as the key-value pair of the first audio parameter, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0015] In one implementation, if the first process exits abnormally and the first audio parameter is a parameter used to indicate that the target application is closed, the sending unit sends the first audio parameter to the target application in the following manner: if there exists a key-value pair of the second audio parameter in the parameter set corresponding to the second process where the key is the same as the key of the key-value pair of the first audio parameter, and the value of the key-value pair of the second audio parameter is different from the value of the key-value pair of the first audio parameter, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0016] In one implementation, the sending unit determines that the process is authorized to send the audio parameters based on the key-value pair in the following manner: if the key-value pair indicates that the audio parameter is a parameter type that a specified process is allowed to send, and the process belongs to the specified process, then the process is authorized to send the audio parameters.

[0017] In one implementation, the sending unit sends the first audio parameter to the target application in the following manner: determining the route for sending the first audio parameter based on the key of the key-value pair, wherein there is a correspondence between the key of the key-value pair and the route of the first audio parameter; and sending the first audio parameter to the target application based on the route.

[0018] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to: execute the audio parameter processing method described in the first aspect or any embodiment of the first aspect.

[0019] According to a fourth aspect of the present disclosure, a storage medium is provided, the storage medium storing instructions that, when executed by a processor, enable the processor to perform the audio parameter processing method described in the first aspect or any embodiment of the first aspect.

[0020] The technical solutions provided by the embodiments of this disclosure can include the following beneficial effects: Since key-value pairs can be used to characterize the parameter type of the first audio parameter, the parameter type of the first audio parameter can be determined through the key-value pairs corresponding to the first audio parameter. Furthermore, when it is determined that the first process has the right to send the first audio parameter and that the first audio parameter is a parameter requiring self-recovery, the audio parameter is sent to the target application, realizing management based on the parameter category dimension during the sending process of the first audio parameter. Compared with the related technology of sending parameters based on the identifier of the parameter receiving object, the possibility of incorrect parameter sending due to changes in the target application identifier can be reduced, thereby making the first audio parameter sending process more stable.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0023] Figure 1 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment.

[0024] Figure 2 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment.

[0025] Figure 3 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment.

[0026] Figure 4 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment.

[0027] Figure 5 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment.

[0028] Figure 6 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment.

[0029] Figure 7 This is a block diagram of a parameter processing apparatus according to an exemplary embodiment.

[0030] Figure 8 This is a block diagram illustrating an apparatus for audio parameter processing according to an exemplary embodiment.

[0031] Figure 9 This is a block diagram illustrating an apparatus for audio parameter processing according to an exemplary embodiment. Detailed Implementation

[0032] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure.

[0033] To ensure applications on a terminal function correctly, the terminal typically sends parameters to these applications to perform appropriate actions, such as self-recovery of certain parameters. However, the parameters sent to the application usually need to meet certain permission requirements. For example, with an audio playback application, the terminal is configured with many parameters related to it, but some of these parameters belong to the terminal system or its audio playback system, and the audio playback application does not have permission to use them. Therefore, when the terminal sends parameters to the audio playback application, it should avoid sending such parameters.

[0034] In related technologies, to ensure that a terminal can send correct parameters to its applications, the terminal typically performs authentication based on the identifier of the parameter recipient before or during parameter transmission. For example, by identifying the parameter recipient's identifier, if the parameter recipient is determined to be an audio playback application, then that parameter recipient is deemed not authorized to receive audio system-related parameters. Conversely, by identifying the parameter recipient's identifier, if the parameter recipient is determined to be an audio system, then that parameter recipient is deemed authorized to receive audio system-related parameters.

[0035] However, if the terminal system malfunctions and the identifiers of the parameter recipients (such as the identifiers of the audio system and the audio application) change, the above authentication method will cause the parameter transmission to fail to meet the corresponding permission requirements.

[0036] Based on this, the present disclosure proposes a parameter sending method to solve the above-mentioned technical problems.

[0037] In this embodiment of the disclosure, the parameters configured on the terminal are identified according to their parameter characteristics (such as permission characteristics, usage characteristics, etc.), and the parameters are sent by identifying the identifier corresponding to the parameter characteristics during the parameter sending process.

[0038] For ease of understanding, the following embodiments will be illustrated using a scenario where the terminal sends parameters to an audio playback application as an example. It should be noted that the parameter sending method described in this disclosure is also applicable to other parameter sending scenarios.

[0039] Figure 1 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment, such as... Figure 1 As shown, the audio parameter processing method used in the terminal includes the following steps.

[0040] In step S11, in response to obtaining the first audio parameter sent based on the first process, the key-value pair corresponding to the first audio parameter is determined, wherein the key-value pair is used to characterize the parameter type of the first audio parameter, and the parameter type indicates whether the first audio parameter needs authentication and whether it needs self-recovery.

[0041] In step S12, in response to determining that the first process is authorized to send the first audio parameter based on the key-value pair, and that the first audio parameter needs to be self-recovered, the first audio parameter is sent to the target application based on the parameter set corresponding to the first process.

[0042] In this embodiment, since key-value pairs can be used to characterize the parameter type of the first audio parameter, the parameter type of the first audio parameter can be determined through the key-value pair corresponding to the first audio parameter. Furthermore, when it is determined that the first process has the right to send the first audio parameter and that the first audio parameter is a parameter requiring self-recovery, the audio parameter is sent to the target application, achieving management based on the parameter category dimension during the first audio parameter sending process. Compared to sending parameters based on the identifier of the parameter receiving object in related technologies, this reduces the possibility of incorrect parameter sending due to changes in the target application identifier, thereby making the first audio parameter sending process more stable.

[0043] Understandably, for an audio system, for example, the terminal's audio scheduler (audioflinger) could obtain the first audio parameters from the first process.

[0044] It is understandable that the first process can be understood as the thread that receives the first audio parameters and sends them to the target application. This thread may carry multiple first audio parameters to be sent to the target application. Therefore, when the first thread sends the audio parameters required by the target application, it can send one or more audio parameters required by the target application to the target application in the form of a parameter set (including, for example, a parameter list, a message queue, or a parameter configuration file).

[0045] It should also be noted that the parameter features corresponding to the first audio parameter can be relationships established based on relevant rules during parameter configuration. For example, a relationship may be established between a certain first audio parameter and a certain parameter feature based on user needs, or a relationship may be established between a certain first audio parameter and a certain parameter feature based on the function of a certain first audio parameter, or a relationship may be established between a certain first audio parameter and a certain parameter feature based on the routing characteristics of a certain first audio parameter, etc. It can be understood that the parameter features corresponding to the first audio parameter can be one (or one type) of parameter features for each first audio parameter, or multiple (or various types) of parameter features for each first audio parameter.

[0046] For example, based on user needs, it can be determined whether the first audio parameter requires authentication. For instance, if a first audio parameter can be directly sent to the target application, then that type of parameter is considered an audio parameter that does not require authentication. If, before being directly sent to the target application, it is necessary to determine whether the target application or the process sending the first audio parameter has the right to access it, then that type of parameter is considered an audio parameter that requires authentication.

[0047] For example, based on user needs, it can be determined whether the first audio parameter is an audio parameter that requires self-recovery. For instance, during the audio parameter configuration phase, developers can determine which audio parameters can be considered as audio parameters requiring self-recovery based on the relationship between the audio parameters and the target application.

[0048] Of course, when the first audio parameter can correspond to multiple parameter features, the above two examples can also be combined. For example, the types corresponding to the first audio parameter are: requiring authentication and requiring self-recovery; requiring authentication and not requiring self-recovery; not requiring authentication but requiring self-recovery; and not requiring authentication and not requiring self-recovery.

[0049] As for key-value pairs, they can be set during the parameter configuration stage, and different key-value pairs can represent different parameter types. For example, setting the key of a key-value pair as (keya) indicates that the first audio parameter type requires authentication and self-recovery, while setting the key of a key-value pair as (keyb) indicates that the first audio parameter type does not require authentication and requires self-recovery, and so on.

[0050] Based on this, the type of the first audio parameter can be determined by identifying the key-value pair corresponding to it. Furthermore, based on the determined type, it can be determined whether to send the first audio parameter to the target application.

[0051] For example, if the first audio parameter is determined to be a parameter requiring authentication and self-recovery, and after authentication, and if the authentication result indicates that the first process has the right to issue the first audio parameter, then based on the first process and its corresponding parameter set, the first audio parameter is issued to the target application.

[0052] Whether the first process has the right to issue the first audio parameters can be determined in the following ways:

[0053] In some embodiments, in response to the key-value pair indicating that the audio parameter is a parameter type that a specified process is allowed to send, and the process belongs to the specified process, it is determined that the process has the right to send the audio parameter.

[0054] Understandably, the permissions for a process to send parameters can be designed using key-value pairs during the parameterization configuration phase. For example, process A can be configured to have permissions to send parameters with keys (keya), (keyb), and (keyc), but not to send parameters of other types. If the first audio parameter sent by process A is one or more of types (keya), (keyb), and (keyc), then process A is considered to have the right to send the first audio parameter.

[0055] Based on this, key-value pairs can be used to determine whether the first process has permission to send the first audio parameter, thereby reducing the likelihood of the first process sending the first audio parameter to the target application without permission. This makes the parameter delivery process more stable.

[0056] It is known that this is based on the terminal audio architecture design. During the audio parameter distribution process, the audio parameters are usually sent to the Audio Policy Service, which interacts with the Audio Scheduler Service and the Audio Hardware Abstraction Layer Service (audio-hal-service) according to a predetermined decision-making strategy.

[0057] However, in practical applications, it can be found that some audio parameters can be directly sent to the audio hardware abstraction layer service without the need for scheduling by the audio decision layer service (e.g., in related technologies, they are scheduled to the audio hardware abstraction layer service via the audio decision layer service). Therefore, different sending paths can be configured for parameters during the parameter configuration process using key-value pairs, thereby saving parameter sending time.

[0058] Figure 2 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment, the method comprising the following steps.

[0059] In step S21, the route for sending the first audio parameter is determined based on the key of the key-value pair, wherein there is a correspondence between the key of the key-value pair and the route of the first audio parameter.

[0060] In step S22, the first audio parameters are sent to the target application based on the route.

[0061] In this embodiment of the disclosure, the corresponding route is determined by using the key of the key-value pair as the first audio parameter, and the first audio parameter is sent based on the determined route. This reduces the workload of parameter processing in the audio decision layer service, thereby reducing the time required to send the audio parameter.

[0062] For example, in a key-value pair, key (keya) represents the parameter type that is sent to the audio decision layer service via a corresponding route, and key (keyb) represents the parameter type that is sent to the audio hardware abstraction layer service via a corresponding route. Based on this, when the key-value pair corresponding to the first audio parameter is obtained, the route corresponding to the first audio parameter can be determined, and then the audio scheduler can reference the first audio parameter to the target based on the route corresponding to the first audio parameter.

[0063] Based on this, the permissions and paths corresponding to the first audio parameter can be determined through the key-value pairs corresponding to the first audio parameter.

[0064] In some scenarios, the same type of audio parameter may correspond to different parameter processing methods. For example, different values ​​corresponding to the first type of parameter can indicate whether certain functions are enabled or disabled. For instance, in related technologies, writing "0" to a certain bit of the volume parameter in code indicates that the volume adjustment function is disabled, or writing "1" to a certain bit of the volume parameter in code indicates that the volume adjustment function is enabled, and so on.

[0065] Based on this, in some embodiments, the target function of the target application can be enabled or disabled by using the first audio parameter based on the value of the key-value pair.

[0066] For example, different values ​​in key-value pairs can be used to indicate whether a certain function of the target application is enabled or disabled. For instance, the first audio parameter in a key-value pair (keya-valuea) indicates that the first audio parameter is of type requiring authentication and self-recovery, and this first audio parameter is used to indicate that function A of the target application is enabled. Similarly, the first audio parameter in a key-value pair (keya-valueb) indicates that the first audio parameter is of type requiring authentication and self-recovery, and this first audio parameter is used to indicate that function A of the target application is disabled.

[0067] In this situation, to reduce the waste of resources caused by the same parameters being sent repeatedly, and to prevent the possibility of conflicting parameters leading to a chaotic sending process, it is necessary to perform the following steps before sending parameters: Figure 3 The method shown writes the first audio parameter into the parameter set corresponding to the first thread in the following manner.

[0068] Figure 3 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment. Figure 3 As shown, the method includes the following steps.

[0069] In step S31, the content indicated by the first audio parameter is determined.

[0070] In step S32, if the first audio parameter is a parameter used to indicate that the target function is turned on, and the key of the key-value pair corresponding to the second audio parameter is different from the key of the key-value pair corresponding to the first audio parameter, then the audio parameter is added to the parameter set.

[0071] In step S33, if the first audio parameter is a parameter used to indicate that the target function is turned off, and there exists a second audio parameter whose key is the same as the key of the first audio parameter's key-value pair, then the second audio parameter with the same key is deleted from the parameter set.

[0072] The second audio parameter is an audio parameter that has been stored in the parameter set and sent to the target application based on the first process.

[0073] In this embodiment, the content indicated by the first audio parameter is determined. The processing method corresponding to the first audio parameter is determined based on the indicated content and the relationship between the key-value pairs of the second audio parameter stored in the parameter set and the key-value pairs of the first audio parameter. If the parameter set corresponding to the first process does not store a parameter of the same type as the first audio parameter, the first audio parameter is written into the parameter set. If there is a conflict in the indicated content, the earlier indicated content can be deleted to avoid confusion in the parameter distribution process caused by conflicting parameter content.

[0074] Understandably, the parameter set of the first process records the parameters used to send to the target application. If the first audio parameter is not recorded, it needs to be written to the parameter set. Determining whether the first audio parameter is recorded in the parameter set can be done, for example, by examining the key-value pairs corresponding to the second audio parameter recorded in the parameter set. If the key of the second audio parameter's key-value pair is different from the key of the first audio parameter's key-value pair, it is assumed that the first audio parameter has not been recorded in the parameter set.

[0075] It is also understandable that, since the content indicated by the first audio parameter is different, in order to save the resource consumption corresponding to parameter distribution, the audio parameter that can indicate the target function of the target application to be enabled can be written into the parameter set, and the target function of the target application can be indicated to be disabled by not writing the audio parameter.

[0076] For example, if the first audio parameter indicates that the target function of the target application should be disabled, and it is determined in the parameter set of the first thread that there exists a key-value pair of a second audio parameter with the same key as the key-value pair of the first audio parameter (i.e., a parameter of the same type as the first audio parameter is considered to have been recorded in the parameter set), but the value of the key-value pair of the second audio parameter is different from the value of the key-value pair of the first audio parameter (i.e., the second audio parameter indicates that the target function of the target application should be enabled), then since the first audio parameter is obtained after the second audio parameter, it can be assumed that the user's latest request is to disable the target function of the target application. Therefore, in this case, by checking the second audio parameter in the parameter set, the value of the second audio parameter can be avoided during the process of disabling the target function, thus preventing the disabling of the target function from failing.

[0077] It should be noted that, Figure 3 The description of the relevant embodiments can be combined with the other first audio parameter delivery processes in the embodiments of this disclosure.

[0078] It is understood from the above embodiments that the first audio parameter may correspond to different functions during the sending process. In this case, in order to ensure that the parameter can be sent effectively, it can be determined whether the first thread should continue to send the first audio parameter by combining the parameter sending situation of the second thread before the first thread.

[0079] When the first audio parameter is a parameter used to indicate that the target function is enabled. For example, it can be done through... Figure 4 The parameter processing method shown determines how the first audio parameter is sent. Figure 4 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment, the method comprising the following steps.

[0080] In step S41, the parameter set corresponding to the second process is determined.

[0081] In step S42, if there is no key-value pair of the second audio parameter that is the same as the key-value pair of the first audio parameter in the parameter set corresponding to the second process, then the first audio parameter is sent to the target application.

[0082] The second process is the preceding process of the first process.

[0083] It should be noted that the second process and the first process can correspond to the same target application, or they can correspond to different target applications.

[0084] In this embodiment, since the sending of processes follows a sequential logic, and the second process is the preceding sending process of the first process, if the second process does not carry the first audio parameter and send it to the target application, then the first audio parameter can be sent to the target application.

[0085] It is understandable that if the second process has already carried the first audio parameters and sent them to the target application, the first audio parameters may not need to be sent in order to avoid wasting resources by sending the same parameters repeatedly.

[0086] For example, in some embodiments, if there is a key-value pair of the second audio parameter in the parameter set corresponding to the second process that is the same as the key-value pair of the first audio parameter, then the first audio parameter is not sent to the target application.

[0087] For example, taking the first audio parameter as (keya-valuea), the parameter sets corresponding to the second process (there may be multiple second processes) are traversed, and it is determined whether there is an audio parameter with the key-value pair (keya-valuea) in the parameter set corresponding to the second process. If the number of second processes with the audio parameter with the key-value pair (keya-valuea) in the parameter set is greater than or equal to 1, it is considered that the second process has already sent the first audio parameter, and the first process does not need to send the first audio parameter again. If the number of second processes with the audio parameter with the key-value pair (keya-valuea) in the parameter set is 0, it is considered that the second process has not sent the first audio parameter, and the first process needs to send the first audio parameter.

[0088] Based on this, key-value pairs can be used to determine how to send the first audio parameter when the first audio parameter is a parameter used to indicate that the target function is enabled.

[0089] When the first audio parameter is a parameter used to indicate that the target function is off. For example, it can be done through... Figure 5 The parameter processing method shown determines how the first audio parameter is sent. Figure 5 This is a flowchart illustrating a first audio parameter processing method according to an exemplary embodiment, the method comprising the following steps.

[0090] In step S51, the parameter set corresponding to the second process is determined.

[0091] In step S52, if the key-value pair of the second audio parameter in the parameter set corresponding to the second process is the same as the key-value pair of the first audio parameter, then the first audio parameter is sent to the target application.

[0092] In this embodiment, the key-value pairs of the second audio parameters in the parameter set corresponding to the second process are the same as the key-value pairs of the first audio parameters, indicating that the second process also needs to send audio parameters to instruct the target function to be turned off. Based on this, it is possible to avoid some target applications that need to enable the target function from being abnormally closed due to the impact of the first audio parameter being sent, thereby affecting the user experience.

[0093] It is understandable that, if the first audio parameter is used to indicate that the target function is disabled, and there are key-value pairs in the parameter set of the preceding process that have the same key-value pair as the first audio parameter, then it can be assumed that the preceding process also needs to disable the target function. Therefore, issuing the first audio parameter to indicate that the target function is disabled will not affect other processes.

[0094] Understandably, in order to avoid the impact of disabling certain target functions on other processes (e.g., other processes do not want to disable them), if there are multiple second processes, then all the parameter sets corresponding to the second processes need to contain key-value pairs of the second audio parameters that are the same as the key-value pairs of the first audio parameters.

[0095] In some embodiments, if there is a key-value pair of the second audio parameter in the parameter set corresponding to the second process that is different from the key-value pair of the first audio parameter, then the first audio parameter is not sent to the target application.

[0096] Based on this, key-value pairs can be used to determine how to send the first audio parameter when the first audio parameter is a parameter used to indicate that the target function is enabled.

[0097] The above embodiments describe the audio parameter delivery process when the first process can successfully deliver the first audio parameter. If an exception occurs during the parameter delivery process (e.g., abnormal exit), the first audio parameter can be delivered in the following manner, for example.

[0098] In some embodiments, when the first process exits abnormally and the first audio parameter is a parameter used to instruct the target application to close, sending the first audio parameter to the target application includes: if there exists a key-value pair of the second audio parameter in the parameter set corresponding to the second process where the key is the same as the key of the key-value pair of the first audio parameter, and the value of the key-value pair of the second audio parameter is different from the value of the key-value pair of the first audio parameter, then sending the first audio parameter to the target application, wherein the second process is the preceding process of the first process.

[0099] It is understood that, in this embodiment of the disclosure, the system determines whether a second audio parameter of the same type as the first audio parameter but indicating a different function has already been issued in the parameter set corresponding to the second process. If such a second audio parameter exists, then the first audio parameter needs to be issued.

[0100] For example, a second process sends a second audio parameter of the same type as the first audio parameter, indicating that the target function is enabled. If a subsequent first process wants to send a first audio parameter to disable the target function, but the first process has exited abnormally, the parameter might not have been successfully sent. Therefore, if it is determined that the preceding process did not send the parameter to disable the target application, the first audio parameter needs to be resent to disable the target function.

[0101] For ease of understanding, this disclosure will combine Figure 6 The above audio parameter processing methods are explained in detail.

[0102] Figure 6 This is a flowchart illustrating an audio parameter processing method according to an exemplary embodiment. For example... Figure 6 As shown, Figure 6 An audio parameter processing flow is shown, including the following steps:

[0103] 1) Process A sends parameters p = {keya = valuea} to the audio scheduler.

[0104] 2) At the audio scheduler, authenticate the parameters based on keya. If the parameter is only allowed to be sent to certain users or process names, proceed to step 3); otherwise, proceed to step 4.

[0105] 3) Determine whether process A has the authority to send parameter p based on the process name and user ID. If it has the authority, proceed to step 4).

[0106] 4) Determine whether parameter p needs to support self-recovery based on keya. If so, store the parameter.

[0107] 5) Check if the parameters need to be issued. If so, proceed to step 6.

[0108] 6) The parameter routing mechanism determines whether parameter p is sent to the audio decision layer service based on keya. If it is, it is sent to the audio decision layer service; otherwise, it is sent to the audio hardware abstraction layer service.

[0109] In some embodiments, for stored parameters, for example: if keya = valuea, then search for keya in the parameter list issued by process A; if not found, then insert keya = valuea into the list.

[0110] If keya = valueb, then search for keya in the parameter list issued by process A. If found, remove keya = valuea from the list. When value = valuea, it means that a certain function is "enabled" and when value = valueb, it means that a certain function is "disabled".

[0111] In some embodiments, for the verification parameter, for example: if keya = valuea, then calculate the number c of processes that have issued keya = valuea according to the storage parameter; if c > 1, then it is not necessary to issue the parameter keya = valuea; if c <= 1, then it is necessary to issue the parameter keya = valuea.

[0112] If keya = valueb, then the number c of processes that have been issued keya = valuea is calculated based on the storage parameters. If c > 0, then the parameter keya = valueb does not need to be issued. If c <= 0, then the parameter keya = valueb needs to be issued. When value = valuea, it means that a certain function is "enabled" and when value = valueb, it means that a certain function is "disabled".

[0113] In some embodiments, for self-recovery parameters, process A sends parameter p = {keya = valuea} during runtime and should send parameter p' = {keya = valueb} upon exit. However, when process A exits abnormally, it cannot send parameter p'. The steps for self-recovery parameter p' are as follows: find the parameter p that the process has already sent in the stored parameters; construct and send parameter p'.

[0114] It is understandable that for parameter query, please refer to the relevant descriptions in the above embodiments, and for constructing parameter p′, please refer to the relevant embodiments for parameter storage.

[0115] Based on this, the embodiments of this disclosure can authenticate the delivery of parameters by combining user identifier and process name; support multiple processes to "enable" or "disable" a function by delivering parameters; avoid duplicate or erroneous delivery of parameters by storing parameters; reduce parameter delivery time by parameter routing; and ensure normal operation of the audio system by self-recovering parameters.

[0116] Based on the same concept, this disclosure also provides an audio parameter processing apparatus.

[0117] It is understood that the audio parameter processing apparatus provided in this disclosure includes hardware structures and / or software modules corresponding to each function in order to achieve the above-mentioned functions. In conjunction with the units and algorithm steps of the various examples disclosed in this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of this disclosure.

[0118] Figure 7 This is a block diagram illustrating a parameter processing apparatus according to an exemplary embodiment. (Refer to...) Figure 7 The device 100 includes a processing unit 101 and a sending unit 102.

[0119] The processing unit 101 is used to determine the key-value pair corresponding to the first audio parameter when the first audio parameter sent based on the first process is obtained. The key-value pair is used to characterize the parameter type of the first audio parameter. The parameter type indicates whether the first audio parameter needs authentication and whether it needs self-recovery.

[0120] The sending unit 102 is used to send the first audio parameter to the target application based on the parameter set corresponding to the first process, when it is determined that the first process has the right to send the first audio parameter based on the key-value pair, and the first audio parameter needs to be self-recovered.

[0121] In some embodiments, where the first audio parameter indicates whether a target function of the target application is enabled or disabled based on the value of a key-value pair, the processing unit 101 is further configured to: add the audio parameter to the parameter set if the first audio parameter is a parameter indicating that the target function is enabled, and the key of the key-value pair corresponding to the second audio parameter is different from the key of the key-value pair corresponding to the first audio parameter; and delete the second audio parameter with the same key from the parameter set if the first audio parameter is a parameter indicating that the target function is disabled, and there exists a key of the key-value pair corresponding to the second audio parameter that is the same as the key of the key-value pair corresponding to the first audio parameter; wherein the second audio parameter is an audio parameter that has been stored in the parameter set and sent to the target application based on the first process.

[0122] In some embodiments, when the first audio parameter is a parameter used to indicate that a target function is enabled, the sending unit 102 sends the first audio parameter to the target application in the following manner: if there is no key-value pair of the second audio parameter that is the same as the key-value pair of the first audio parameter in the parameter set corresponding to the second process, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0123] In some embodiments, when the first audio parameter is a parameter used to indicate that a target function is turned off, the sending unit 102 sends the first audio parameter to the target application in the following manner: if the key-value pair of the second audio parameter in the parameter set corresponding to the second process is the same as the key-value pair of the first audio parameter, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0124] In some embodiments, when the first process exits abnormally and the first audio parameter is a parameter used to indicate that the target application is closed, the sending unit 102 sends the first audio parameter to the target application in the following manner: if there exists a key-value pair of the second audio parameter in the parameter set corresponding to the second process where the key is the same as the key of the key-value pair of the first audio parameter, and the value of the key-value pair of the second audio parameter is different from the value of the key-value pair of the first audio parameter, the first audio parameter is sent to the target application; wherein, the second process is the preceding process of the first process.

[0125] In some embodiments, the sending unit 102 determines the process's right to send audio parameters based on key-value pairs in the following manner: when the key-value pair indicates that the audio parameter is a parameter type that a specified process is allowed to send, and the process belongs to the specified process, it is determined that the process has the right to send audio parameters.

[0126] In some embodiments, the sending unit 102 sends the first audio parameter to the target application in the following manner: determining the route for sending the first audio parameter based on the key of the key-value pair, wherein there is a correspondence between the key of the key-value pair and the route of the first audio parameter; and sending the first audio parameter to the target application based on the route.

[0127] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0128] Figure 8 This is a block diagram illustrating an apparatus 200 for audio parameter processing according to an exemplary embodiment. The apparatus 200 can be provided as a terminal. For example, the apparatus 200 can be a mobile phone, computer, digital broadcasting terminal, messaging device, game console, tablet device, medical device, fitness device, personal digital assistant, etc.

[0129] Reference Figure 8 The device 200 may include one or more of the following components: processing component 202, memory 204, power component 206, multimedia component 208, audio component 210, input / output (I / O) interface 212, sensor component 214, and communication component 216.

[0130] Processing component 202 typically controls the overall operation of device 200, such as operations associated with display, telephone calls, data communication, camera operation, and recording. Processing component 202 may include one or more processors 220 to execute instructions to perform all or part of the steps of the methods described above. Furthermore, processing component 202 may include one or more modules to facilitate interaction between processing component 202 and other components. For example, processing component 202 may include a multimedia module to facilitate interaction between multimedia component 208 and processing component 202.

[0131] Memory 204 is configured to store various types of data to support the operation of device 200. Examples of such data include instructions for any application or method operating on device 200, contact data, phonebook data, messages, pictures, videos, etc. Memory 204 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0132] The power supply component 206 provides power to the various components of the device 200. The power supply component 206 may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device 200.

[0133] Multimedia component 208 includes a screen that provides an output interface between the device 200 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 208 includes a front-facing camera and / or a rear-facing camera. When the device 200 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0134] Audio component 210 is configured to output and / or input audio signals. For example, audio component 210 includes a microphone (MIC) configured to receive external audio signals when device 200 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 204 or transmitted via communication component 216. In some embodiments, audio component 210 also includes a speaker for outputting audio signals.

[0135] I / O interface 212 provides an interface between processing component 202 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0136] Sensor assembly 214 includes one or more sensors for providing status assessments of various aspects of device 200. For example, sensor assembly 214 may detect the on / off state of device 200, the relative positioning of components such as the display and keypad of device 200, changes in the position of device 200 or a component of device 200, the presence or absence of user contact with device 200, the orientation or acceleration / deceleration of device 200, and temperature changes of device 200. Sensor assembly 214 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 214 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 214 may also include an accelerometer, a gyroscope, a magnetometer, a pressure sensor, or a temperature sensor.

[0137] Communication component 216 is configured to facilitate wired or wireless communication between device 200 and other devices. Device 200 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 216 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 216 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0138] In an exemplary embodiment, the apparatus 200 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0139] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 204 including instructions, which can be executed by a processor 220 of the device 200 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0140] Figure 9 This is a block diagram illustrating an apparatus 300 for audio parameter processing according to an exemplary embodiment. For example, apparatus 300 may be provided as a server. (Refer to...) Figure 9 The device 300 includes a processing component 322, which further includes one or more processors, and memory resources represented by memory 332 for storing instructions, such as application programs, that can be executed by the processing component 322. The application programs stored in memory 332 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 322 is configured to execute instructions to perform the aforementioned cell selection method.

[0141] Device 300 may also include a power supply component 326 configured to perform power management of device 300, a wired or wireless network interface 350 configured to connect device 300 to a network, and an input / output (I / O) interface 358. Device 300 may operate on an operating system stored in memory 332, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.

[0142] It is understood that in this disclosure, "multiple" refers to two or more, and other quantifiers are similar. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. The singular forms "a," "the," and "the" are also intended to include the plural forms unless the context clearly indicates otherwise.

[0143] It is further understood that the terms "first," "second," etc., are used to describe various types of information, but this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another, and do not indicate a specific order or degree of importance. In fact, the expressions "first," "second," etc., are completely interchangeable. For example, without departing from the scope of this disclosure, first information can also be referred to as second information, and similarly, second information can also be referred to as first information.

[0144] It is further understood that the terms “center,” “longitudinal,” “lateral,” “front,” “rear,” “up,” “down,” “left,” “right,” “vertical,” “horizontal,” “top,” “bottom,” “inner,” and “outer,” etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this embodiment and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation.

[0145] It can be further understood that, unless otherwise specified, "connection" includes both direct connections where no other components exist between the two parties and indirect connections where other components exist between them.

[0146] It is further understood that although operations are described in a specific order in the accompanying drawings in the embodiments of this disclosure, this should not be construed as requiring these operations to be performed in the specific order or serial order shown, or requiring all of the shown operations to be performed to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous.

[0147] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein.

Claims

1. An audio parameter processing method, characterized in that, include: In response to obtaining the first audio parameter sent based on the first process, a key-value pair corresponding to the first audio parameter is determined, wherein the key-value pair is used to characterize the parameter type of the first audio parameter, and the parameter type indicates whether the first audio parameter needs authentication and whether it needs self-recovery; In response to determining, based on the key-value pair, that the first process is authorized to send the first audio parameter, and that the first audio parameter needs to be self-recovering, the first audio parameter is sent to the target application based on the parameter set corresponding to the first process.

2. The method according to claim 1, characterized in that, The first audio parameter, based on the value of the key-value pair, indicates whether a target function of the target application is enabled or disabled. Before sending the first audio parameter to the target application, the method further includes: If the first audio parameter is a parameter used to indicate that the target function is enabled, and the key of the key-value pair corresponding to the second audio parameter is different from the key of the key-value pair corresponding to the first audio parameter, then the audio parameter is added to the parameter set. If the first audio parameter is a parameter used to indicate that the target function is turned off, and there exists a second audio parameter whose key is the same as the key of the first audio parameter's key-value pair, then the second audio parameter with the same key is deleted from the parameter set. The second audio parameter is an audio parameter that has been stored in the parameter set and sent to the target application based on the first process.

3. The method according to claim 1 or 2, characterized in that, The first audio parameter is a parameter used to indicate that the target function is enabled. Sending the first audio parameter to the target application includes: If there is no key-value pair of the second audio parameter that is the same as the key-value pair of the first audio parameter in the parameter set corresponding to the second process, then the first audio parameter is sent to the target application. The second process is the preceding process of the first process.

4. The method according to claim 1 or 2, characterized in that, The first audio parameter is a parameter used to indicate that the target function is turned off. Sending the first audio parameter to the target application includes: If the key-value pair of the second audio parameter in the parameter set corresponding to the second process is the same as the key-value pair of the first audio parameter, then the first audio parameter is sent to the target application. The second process is the preceding process of the first process.

5. The method according to claim 1 or 2, characterized in that, If the first process exits abnormally, and the first audio parameter is a parameter used to instruct the target application to close, sending the first audio parameter to the target application includes: If there exists a key-value pair of the second audio parameter in the parameter set corresponding to the second process, where the key is the same as the key of the first audio parameter key-value pair, and the value of the second audio parameter key-value pair is different from the value of the first audio parameter key-value pair, then the first audio parameter is sent to the target application. The second process is the preceding process of the first process.

6. The method according to claim 1, characterized in that, The step of determining that the process is authorized to issue the audio parameters based on the key-value pair includes: In response to the key-value pair indicating that the audio parameter is a parameter type that a specified process is allowed to send, and that the process belongs to the specified process, it is determined that the process has the right to send the audio parameter.

7. The method according to claim 1 or 2, characterized in that, Sending the first audio parameter to the target application includes: Based on the key of the key-value pair, the route for sending the first audio parameter is determined, wherein there is a correspondence between the key of the key-value pair and the route of the first audio parameter; The first audio parameter is sent to the target application based on the route.

8. An audio parameter processing device, characterized in that, include: The processing unit is configured to determine the key-value pair corresponding to the first audio parameter when the first audio parameter sent based on the first process is obtained, wherein the key-value pair is used to characterize the parameter type of the first audio parameter, and the parameter type indicates whether the first audio parameter needs authentication and whether it needs self-recovery; The sending unit is configured to send the first audio parameter to the target application based on the parameter set corresponding to the first process, provided that the first process is authorized to send the first audio parameter based on the key-value pair and the first audio parameter needs to be self-recovering.

9. An electronic device, characterized in that, include: processor: Memory used to store processor-executable instructions; The processor is configured to execute the audio parameter processing method according to any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium stores instructions that, when executed by a processor, enable the processor to perform the audio parameter processing method according to any one of claims 1 to 7.

Images