Methods, devices, and storage media for adjusting audio algorithm parameters

Abstract

This application discloses a method, device, and storage medium for adjusting audio algorithm parameters, relating to the field of audio algorithm adjustment technology. The method includes: acquiring test audio output by the audio device under test based on an audio test topology, wherein the audio test topology comprises multiple nodes, each node corresponding to an audio processing unit; when at least one audio metric of the test audio is outside a preset acceptable range, determining whether each audio processing unit is in an optimal parameter state based on the parameter sensitivity detection results of each audio processing unit; if so, updating the topology of the audio test topology until all audio metrics in the test audio of the updated audio test topology are within the preset acceptable range. This avoids meaningless parameter iteration in topologies with structural defects, improving the effectiveness of audio algorithm debugging.

Description

Technical Field

[0001] This application relates to the field of audio algorithm adjustment technology, and in particular to methods, devices and storage media for adjusting audio algorithm parameters. Background Technology

[0002] The current audio algorithm debugging process relies heavily on engineers' experience. Engineers manually adjust parameters such as filter coefficients and gain thresholds based on subjective listening experience or limited objective indicators.

[0003] In automated audio algorithm tuning methods, neural network models are typically used to predict correction coefficients to dynamically adjust audio parameters. However, current tuning methods essentially search for optimal parameters within a fixed topology. When the algorithm structure itself is not suited to a specific application scenario, parameter fine-tuning cannot improve overall performance. This single optimization path is insufficient to overcome the performance bottlenecks of the original architecture.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, device and storage medium for adjusting audio algorithm parameters, aiming to solve the technical problem of meaningless parameter iteration in topologies with structural defects.

[0006] To achieve the above objectives, this application proposes a method for adjusting audio algorithm parameters, the method comprising: Acquire test audio output by the audio device under test based on an audio test topology, wherein the audio test topology contains multiple nodes, each node corresponding to an audio processing unit; When at least one audio metric of the test audio is outside the preset acceptable range, based on the parameter sensitivity detection results of each audio processing unit, it is determined whether each audio processing unit is in the optimal parameter state. If so, update the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset acceptable range.

[0007] In one embodiment, the step of updating the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset acceptable range includes: Determine the evaluation results of the structural adaptability of each audio processing unit in the audio test topology; Based on the evaluation results, a target audio processing unit is determined, which includes a newly added audio processing unit and / or a processing unit to be adjusted in the audio test topology. The target audio processing unit updates the topology of the audio test topology until all audio indicators of the test audio in the updated audio test topology are within the preset acceptable range.

[0008] In one embodiment, when the target audio processing unit is the processing unit to be adjusted in the audio test topology, the step of determining the target audio processing unit based on the evaluation result includes: Based on the evaluation results, the processing unit that constitutes the performance bottleneck in the audio test topology is identified as the unit to be adjusted. The step of updating the topology in the audio test topology according to the target audio processing unit includes: Disconnect the processing unit to be adjusted from other processing units in the audio test topology, and / or adjust the signal connection relationship between the processing unit to be adjusted and adjacent nodes.

[0009] In one embodiment, when the target audio processing unit is the newly added audio processing unit and the processing unit to be adjusted in the audio test topology, the step of determining the target audio processing unit based on the evaluation result includes: Based on the evaluation results, target audio parameters that are outside the preset qualified area are determined; Obtain at least one of the newly added audio processing units associated with the target audio parameters; Identify the processing unit to be adjusted that is incompatible with the newly added audio processing unit; The step of updating the topology in the audio test topology according to the target audio processing unit includes: Replace the processing unit to be adjusted with the newly added audio processing unit.

[0010] In one embodiment, when the target audio processing unit is the newly added audio processing unit, the step of updating the topology in the audio test topology according to the target audio processing unit includes: Determine the topology connection structure corresponding to the newly added audio processing unit; Based on the aforementioned topology connection structure and the newly added audio processing unit, a target topology is generated, and the audio test topology is replaced with the target topology.

[0011] In one embodiment, the preset compliance range includes a first range and a second range, which overlap. Before the step of determining whether each audio processing unit is in an optimal parameter state based on the parameter sensitivity detection results of each audio processing unit when at least one audio indicator of the test audio is outside the preset compliance range, the method for adjusting the audio algorithm parameters further includes: Determine whether all audio metrics of the test audio are outside the first interval and the second interval; If so, then at least one audio indicator of the test audio is determined to be outside the preset acceptable range.

[0012] In one embodiment, before the step of acquiring the test audio output by the audio device under test based on the audio test topology, the method for adjusting the audio algorithm parameters further includes: In response to the access command of the audio device under test, determine the device information of the audio device under test; Output the test topology information of the audio device under test based on the device information; In response to the configuration instructions of the test topology information, the audio test topology for audio testing of the audio device under test is determined.

[0013] In one embodiment, after the step of acquiring the test audio output by the audio device under test based on an audio test topology, wherein the audio test topology includes multiple nodes, each node corresponding to an audio processing unit, the method for adjusting the audio algorithm parameters further includes: When all audio metrics of the test audio are within the preset acceptable range, update the historical debugging record of the audio device under test. The historical debugging record includes at least one of the following: iterative configuration snapshots, test results, convergence trajectories, and the iterative audio test topology.

[0014] In addition, to achieve the above objectives, this application also proposes an audio algorithm parameter adjustment device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the audio algorithm parameter adjustment method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the audio algorithm parameter adjustment method as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: By acquiring test audio output from the audio device under test based on an audio test topology containing multiple nodes corresponding to audio processing units, when at least one audio metric of the test audio falls outside the preset acceptable range, the system does not directly modify the topology or blindly search for parameters. Instead, it first determines whether each audio processing unit is in its optimal parameter state based on the parameter sensitivity detection results of each unit. Only when it is confirmed that the parameters of all audio processing units have reached their optimal state but still cannot meet the acceptable requirements, is the topology configuration of the audio test topology updated, until all audio metrics in the test audio of the updated audio test topology are within the preset acceptable range. Based on this, it breaks the limitation of a single optimization path that only searches for optimal parameters within a fixed topology structure. It can automatically switch to topology optimization mode when parameter fine-tuning cannot overcome the performance bottleneck of the original architecture, avoiding meaningless parameter iteration in topologies with structural defects. It specifically addresses the problem of algorithm structure not being suitable for specific application scenarios, thereby effectively breaking through the performance limit of the original architecture, improving the comprehensiveness of audio algorithm debugging and the final audio processing effect. Attached Figure Description

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

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the first embodiment of the method for adjusting audio algorithm parameters in this application; Figure 2 This is a schematic diagram of the audio test topology for the audio algorithm parameter adjustment method of this application; Figure 3 This is a schematic diagram of another audio test topology for the method of adjusting audio algorithm parameters in this application; Figure 4 This is a simplified flowchart illustrating the method for adjusting the audio algorithm parameters in this application. Figure 5 This is a schematic diagram of the system architecture for the audio algorithm parameter adjustment method of this application; Figure 6 This is a schematic diagram of the device structure of the hardware operating environment involved in the audio algorithm parameter adjustment method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] The current audio algorithm debugging process relies heavily on engineers' experience. Engineers manually adjust parameters such as filter coefficients and gain thresholds based on subjective listening experience or limited objective indicators.

[0023] In automated audio algorithm tuning methods, neural network models are typically used to predict correction coefficients to dynamically adjust audio parameters. However, current tuning methods essentially search for optimal parameters within a fixed topology. When the algorithm structure itself is not suited to a specific application scenario, parameter fine-tuning cannot improve overall performance. This single optimization path is insufficient to overcome the performance bottlenecks of the original architecture.

[0024] Based on this, this application provides a solution that, when at least one audio metric of the test audio is outside the preset acceptable range, does not directly modify the topology or blindly search for parameters. Instead, it first determines whether each audio processing unit is in the optimal parameter state based on the parameter sensitivity detection results of each audio processing unit. Only when it is confirmed that the parameters of all audio processing units have reached the optimal state but still cannot meet the acceptable requirements, does it update the topology configuration of the audio test topology. This continues until all audio metrics in the test audio of the updated audio test topology are within the preset acceptable range. This breaks the limitation of a single optimization path that only searches for the optimal parameters within a fixed topology. It can automatically switch to topology optimization mode when parameter fine-tuning cannot break through the performance bottleneck of the original architecture. This avoids meaningless parameter iteration in topologies with structural defects, specifically solving the problem that the algorithm structure is not suitable for specific application scenarios. This effectively breaks through the performance limit of the original architecture, improves the comprehensiveness of audio algorithm debugging and the final audio processing effect.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or audio algorithm parameter adjustment device capable of performing the above functions. The following description uses an audio algorithm parameter adjustment device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a method for adjusting audio algorithm parameters, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the method for adjusting audio algorithm parameters according to this application.

[0028] In this embodiment, the method for adjusting the audio algorithm parameters includes steps S10 to S30: Step S10: Obtain the test audio output by the audio device under test based on the audio test topology.

[0029] The audio test topology comprises multiple nodes, each corresponding to an audio processing unit. In essence, an audio test topology is a logical structure for audio signal processing formed by connecting multiple audio processing units according to a specific signal flow direction. It is typically a directed acyclic graph (DAG) used to define the complete processing path of the audio signal from input to output. Each node in the audio test topology uniquely maps to an independent audio processing function module. An audio processing unit is a software module or hardware circuit that implements a specific audio signal processing function, including but not limited to acoustic echo cancellation (AEC), noise suppression (ANS), automatic gain control (AGC), equalizer (EQ), dynamic range compressor (Limiter), sound effect renderer, and filtering unit.

[0030] In this embodiment, after the audio device under test (DUT) is connected and an initial audio test topology is configured for it, a standardized test signal can be input to the DUT, and its output signal processed based on the current audio test topology can be collected as the test audio. Specifically, the audio test device generates a preset standard sinusoidal sweep signal that covers the entire audible frequency range of 20Hz-20kHz with a constant amplitude. The generated standard sinusoidal sweep signal is then sent to the audio input interface of the DUT, triggering the DUT to load the current audio test topology and process the input signal. The audio test device acquires the signal output from the audio output interface of the DUT using a high-precision audio acquisition card and stores the acquired digital signal as a test audio file.

[0031] For example, the audio test topology of the audio device under test is as follows: Figure 1 As shown, the audio testing equipment generates a 16-bit, 48kHz sampling rate sinusoidal sweep signal. During the processing of the signal through the TWS voice headset with the topology of "audio input → high-pass filter → noise suppression → gain control → audio output", the signal sequentially passes through the high-pass filter to filter out DC components and low-frequency interference, the noise suppression unit to eliminate background noise, and the gain control unit to adjust the output volume before being output. The audio testing equipment collects this output signal and uses it as the test audio.

[0032] Optionally, real audio samples from real-world scenarios can be loaded from the test sample library to process the real audio samples using the audio device under test, facilitating subsequent signal comparison.

[0033] This embodiment obtains accurate test audio to provide data support for subsequent audio index detection and parameter status judgment.

[0034] Step S20: When at least one audio metric of the test audio is outside the preset acceptable range, based on the parameter sensitivity detection results of each audio processing unit, determine whether each audio processing unit is in the optimal parameter state.

[0035] Audio metrics are objective parameters used to quantify and evaluate audio signal quality. These metrics typically include total harmonic distortion (THD), signal-to-noise ratio (SNR), frequency response deviation, and speech intelligibility. Preset compliance ranges refer to the acceptable value ranges for various audio metrics pre-defined according to product design requirements. Parameter sensitivity testing is the process of analyzing the impact of changes in audio processing unit parameters on the final output audio metrics, used to quantify the contribution of each parameter to overall performance. Optimal parameter state refers to the state where, under the premise that the current audio test topology remains unchanged, all adjustable parameters of all audio processing units have been adjusted to achieve the best possible audio metrics.

[0036] In this embodiment, parameter sensitivity detection can be performed using a preset algorithm, such as a gradient backpropagation algorithm or a local network search algorithm.

[0037] As an optional implementation method, when performing parameter sensitivity detection and optimal judgment based on gradient backpropagation, parameter sensitivity is evaluated by calculating the gradient value of the audio index relative to the parameters of each audio processing unit, and then it is determined whether the optimal parameter state has been reached. The magnitude of the gradient value directly reflects the degree of influence of parameter changes on the audio index. When the gradient values ​​of all parameters approach zero, it indicates that the parameters have reached a local optimum.

[0038] Specifically, the audio testing equipment performs index detection on the test audio, calculating values ​​for various audio indicators such as total harmonic distortion (THD), signal-to-noise ratio (SNR), and frequency response deviation. The calculated results are compared with preset acceptable ranges to determine if at least one indicator exceeds the acceptable range. If at least one indicator fails to meet the standard, the audio testing equipment uses the currently failing indicator as the objective function and calculates the gradient value of each adjustable parameter of each audio processing unit using a backpropagation algorithm. The larger the absolute value of the gradient, the higher the sensitivity of that parameter to the target indicator. Finally, the gradient values ​​of all parameters are compared with preset convergence thresholds. If the absolute value of the gradient values ​​of all parameters is less than the convergence threshold, it is determined that each audio processing unit is in an optimal parameter state; otherwise, it is determined that the optimal parameter state has not been reached.

[0039] For example, if the total harmonic distortion (THD) of the test audio is detected to be 1.2%, which exceeds the preset acceptable range of ≤0.5%, the gradient of the gain parameter of the gain unit, the gradient of the cutoff frequency parameter of the filter unit, and the gradient of the noise reduction intensity parameter of the noise reduction unit are calculated with THD as the objective function. All of these are less than the preset convergence threshold of 0.01. Therefore, it is determined that all audio processing units are in the optimal parameter state.

[0040] As an alternative implementation, parameter sensitivity detection and optimal determination based on local grid search involves performing a grid search within a small range near the current parameter to evaluate the improvement effect of parameter adjustment on audio metrics, and then determining whether the optimal parameter state has been reached. Specifically, if no parameter value that significantly improves the audio metrics can be found within the neighborhood of the current parameter, it indicates that the current parameter is close to optimal.

[0041] Specifically, the audio testing equipment performs index detection on the acquired test audio, obtaining the index values ​​of various audio indicators. After comparing these values ​​with preset acceptable ranges, it confirms the existence of non-compliant indicators. Next, a local search range is determined for each adjustable parameter of each audio processing unit. This range is centered on the current parameter value and extends upwards and downwards by preset proportions. Based on the set search range, all possible parameter combinations are generated according to a fixed step size. Each parameter combination is sequentially loaded into the audio device under test, the corresponding output audio is acquired, and the index value is calculated. The index values ​​corresponding to all parameter combinations are compared. If the difference between the optimal index value and the index value corresponding to the current parameter is less than a preset improvement threshold, then each audio processing unit is determined to be in an optimal parameter state; otherwise, it is determined that the optimal parameter state has not been reached.

[0042] For example, the audio testing device detects that the signal-to-noise ratio of the test audio is 58dB, which is lower than the preset acceptable range of ≥65dB. Then, it sets a local search range of ±5% for each parameter with a step size of 1%, generates all parameter combinations and tests them, and obtains the optimal signal-to-noise ratio of 58.3dB. The difference from the current value is 0.3dB, which is less than the preset improvement threshold of 1dB. Therefore, it is determined that all audio processing units are in the optimal parameter state.

[0043] This embodiment uses parameter sensitivity detection to determine that the performance bottleneck of the current audio test topology is caused by improper parameter settings. This allows for the subsequent topology adjustment process to be initiated when the parameters are improperly set. In other words, the topology update process is only initiated when it is confirmed that parameter optimization can no longer further improve performance, thus avoiding the situation where blindly modifying the topology structure would destroy the original reasonable structure.

[0044] Step S30: If yes, update the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset acceptable range.

[0045] The topology includes information on the node composition of the audio test topology, the internal parameters of the nodes, and the connection relationships between the nodes.

[0046] In this embodiment, when updating the audio test topology, both local and overall structural adjustments can be made. Local structural adjustments modify individual nodes or node connections without changing the overall architecture of the audio test topology. Overall topology replacement refers to replacing the current audio test topology entirely with a completely different topology.

[0047] When updating the topology of an audio test topology, it is necessary to first identify the audio processing units that need adjustment, and then adjust those units. During this process, a structural adaptability assessment can be performed on each audio processing unit in the audio test topology. This assessment evaluates its ability to support substandard audio metrics within the current topology and determines whether the unit has inherent problems that cannot be resolved through parameter adjustments, such as insufficient performance limits, incomplete functional coverage, or structural design flaws. The evaluation results are used to quantify the contribution of each audio processing unit to the current performance bottleneck, providing a precise basis for subsequent topology updates. Therefore, as an optional implementation, a structural adaptability assessment can be performed on the audio processing units in the audio test topology first, and the topology can be updated based on the assessment results.

[0048] In addition, the location and type of topological defects that cause the indicators to fail to meet the standards can be located by using parameter sensitivity test results and audio index deviation characteristics, and then corresponding structural adjustment schemes can be generated.

[0049] Therefore, as an alternative implementation, the location and type of topological defect causing the substandard performance can be identified based on the parameter sensitivity test results and audio index deviation characteristics. For example, if the high-frequency response deviation is too large and the filter unit parameters are already optimal, it is determined to be a structural defect due to insufficient filter unit order. Then, a corresponding local structural adjustment scheme is generated based on the defect type. For example, for the defect of insufficient filter unit order, an adjustment scheme is generated to replace the second-order IIR filter with a fourth-order IIR filter. The audio test topology is then updated according to the adjustment scheme. Finally, steps S10 and S20 are re-executed, and the audio index corresponding to the updated topology is checked. If all indexes meet the standards, the debugging ends; otherwise, local structural adjustments continue or the entire topology is replaced.

[0050] For example, the audio test equipment determined that the excessive frequency response deviation in the high-frequency band was due to the insufficient order of the second-order IIR filter unit. An adjustment scheme was generated to replace the second-order IIR filter with a fourth-order IIR filter. After updating the topology configuration, the solution was sent to the audio device under test. The retest showed that the frequency response deviation in the high-frequency band was ±0.5dB, which was within the preset ±1dB acceptable range. The debugging was then completed.

[0051] As an alternative implementation, a complete topology replacement can be performed based on a candidate template library. Specifically, according to the current test type and the type of substandard audio metric, suitable alternative topologies are selected from a preset candidate template library. These alternative topologies are then sorted by priority from high to low. Finally, the sorted alternative topologies are loaded sequentially onto the audio device under test, and steps S10 and S20 are re-executed. When all audio metrics fall within the preset acceptable range after loading a particular alternative topology, the debugging process ends, and the topology is saved as the optimal topology configuration. Different test types and substandard audio types are typically associated with different complete alternative topologies. If no complete alternative topology exists, local structural adjustments are made.

[0052] For example, please refer to Figure 2 and Figure 3 , Figure 2 The audio test topology shown can only output one channel of audio with basic noise reduction in a multi-person conference scenario. It cannot simultaneously meet the noise reduction requirements of remote calls and the speech enhancement requirements of local recordings. After parameter optimization, the main output speech clarity is only 82%, failing to meet the ≥90% compliance requirement. At this point, based on the current test type and the type of audio metric failing to meet the standard, a complete topology switching process is triggered. The audio test equipment loads from the template library... Figure 3 The new test topology shown maps the original input to a common input, the original output to audio output 1 (for remote calls), and adds audio output 2 for local recording. The 80Hz high-pass filter parameters in the original topology are adapted to the 80Hz low-pass filter parameters in the new topology, and the original 20dB noise reduction intensity parameters are adapted to the base noise reduction intensity of the adaptive noise reduction unit. After the switch, the test results show that the noise reduction depth of audio output 1 is 32dB and the speech intelligibility is 93%, while the speech enhancement gain of audio output 2 is 6dB and the intelligibility is 95%. All indicators meet the preset target range, and the topology switch is complete.

[0053] Optionally, when the audio processing unit is not in an optimal parameter state, the parameters of the audio test topology can be adjusted.

[0054] This embodiment provides a method for adjusting audio algorithm parameters. By employing a layered debugging logic that verifies parameter optimality before updating the topology, it effectively addresses the shortcomings of a single optimization path that only searches for parameters within a fixed topology. This avoids meaningless parameter iterations in topologies with structural defects, reducing computational resource consumption and debugging time. Furthermore, when parameter fine-tuning fails to overcome the performance bottleneck of the original architecture, it automatically switches to a topology optimization mode, specifically addressing the problem of algorithm structures being unsuitable for specific application scenarios. This effectively breaks through the performance limits of the original architecture, improving the comprehensiveness of audio algorithm debugging and the final audio processing effect.

[0055] Based on the first embodiment of this application, in the second embodiment of this application, the same or similar content as the first embodiment can be referred to the above description, and will not be repeated hereafter. On this basis, a structural adaptability evaluation is performed on the audio processing units in the audio test topology to obtain the evaluation results. When updating the topology structure of the audio test topology based on the evaluation results, it is necessary to first determine the target audio processing unit based on the evaluation results, and then update the topology structure of the audio test topology through the target audio processing unit. Therefore, step S30 also includes steps S31 to S33: Step S31: Determine the evaluation results of the structural adaptability of each audio processing unit in the audio test topology.

[0056] In this embodiment, the audio testing equipment uses substandard audio metrics as the core objective of structural adaptability evaluation. Based on the architectural parameters and technical specifications of each audio processing unit, it calculates the theoretical optimal performance value that the unit can achieve under ideal parameter configuration. Finally, the theoretical optimal performance value of each unit is compared with the target metric requirements to generate the structural adaptability evaluation results for each unit. These evaluation results are divided into three levels: "fully adapted," "partially adapted," and "completely unsuitable."

[0057] For example, targeting Figure 2 The high-pass filter → noise suppression → gain control topology shown is used in audio testing equipment to determine that the non-compliant metric is the noise reduction depth in outdoor scenarios. The theoretical maximum noise reduction depth of the current single-channel noise suppression unit is calculated to be 25dB, while the target requirement is 30dB. Therefore, the evaluation result is "completely unsuitable" for the noise suppression unit, and "completely suitable" for the high-pass filter and gain control unit.

[0058] Step S32: Based on the evaluation results, determine the target audio processing unit; Step S33: Update the topology in the audio test topology according to the target audio processing unit until all audio indicators of the test audio of the updated audio test topology are within the preset acceptable range.

[0059] The target audio processing unit includes newly added audio processing units and / or processing units in the audio test topology that need adjustment. The target audio processing unit is a set of audio processing units that need modification or supplementation, determined based on the structural adaptability assessment results. Processing units to be adjusted are existing audio processing units in the current topology that have structural defects and need to be replaced or have their internal structure modified. Newly added audio processing units are those missing from the current topology that need to be added to cover the missing functions. Therefore, when determining the target audio processing unit, the evaluation results can be used to identify the processing units that constitute performance bottlenecks in the audio test topology and require adjustment. For example, based on the evaluation results, all audio processing units with evaluation levels of "partially compatible" and "completely incompatible" can be screened, and at least one of these units can be selected as the processing unit to be adjusted. When adjusting the topology for the processing unit to be adjusted, the connection between the processing unit to be adjusted and other processing units in the audio test topology can be disconnected, and / or the signal connection relationship between the processing unit to be adjusted and its adjacent nodes can be updated. Disconnecting the connection indicates that the processing unit will not participate in subsequent audio processing in the current audio test topology.

[0060] For example, targeting Figure 2 The high-pass filter → noise suppression → gain control topology shown, after structural adaptability evaluation, revealed that the gain control unit was located after the noise suppression unit. This caused instability in the signal amplitude processed by the noise suppression unit, reducing the noise reduction effect and creating a performance bottleneck. Therefore, the optimal adjustment scheme was determined to be to move the gain control unit after the noise suppression unit, disconnect the gain control unit from the audio output port, and disconnect the noise suppression unit from the gain control unit. The gain control unit was then reconnected between the high-pass filter and the noise suppression unit, forming a new connection relationship of high-pass filter → gain control → noise suppression → audio output. Retesting showed that the noise reduction depth increased from 22dB to 28dB, meeting the preset requirement of ≥25dB. The adjustment was then complete.

[0061] Furthermore, when determining the target audio processing unit, target audio parameters outside the preset qualified area can be identified based on the evaluation results. Then, at least one newly added audio processing unit associated with the target audio parameters is obtained, and processing units that are incompatible with the newly added audio processing unit are identified for adjustment. These adjusted processing units can then be replaced with the newly added audio processing unit, or the newly added audio processing unit can be added to the audio test topology. The preset qualified area is a range of qualified values ​​for the structural adaptability evaluation indicators of each audio processing unit and the overall topology in the audio test topology, pre-defined according to system design requirements, hardware resource limitations, and test scenario requirements.

[0062] Specifically, the audio testing equipment extracts the target audio parameters that cause the indicators to fail to meet the standards based on the evaluation results. It then selects new audio processing units from a pre-set audio processing unit library that can effectively improve these parameters. Next, it analyzes the functional compatibility and resource consumption of the new units with all existing processing units to determine if there are any incompatible processing units that need adjustment. If there are units with completely overlapping functions or logically mutually exclusive relationships, they are marked as incompatible units and replaced first. If no incompatible units exist, the addition method is used.

[0063] For example, based on Figure 2 The topology shown was evaluated, and the target audio parameter was found to be the noise reduction depth for outdoor scenes. The theoretical maximum noise reduction depth of the existing single-channel noise suppression unit is only 25dB, which cannot meet the ≥30dB compliance requirement. A dual-channel adaptive noise suppression unit was selected from the unit library as a new unit. Analysis revealed that its function completely overlapped with the original single-channel noise suppression unit, making them incompatible units. Therefore, the connection between the original single-channel noise suppression unit and the high-pass filter and gain control unit was disconnected, and the dual-channel adaptive noise suppression unit was connected to its original position. Retesting yielded a noise reduction depth of 33dB, meeting the compliance requirement, and the replacement was completed. In addition, the evaluation revealed that the target audio parameter is the echo intensity in a conference scene. The existing topology lacks echo cancellation functionality, causing the echo index to exceed the compliance range. At this point, an acoustic echo cancellation unit was selected from the unit library as a new unit. Analysis revealed that it had no incompatible relationship with any existing units. The optimal connection position was determined to be between the noise suppression unit and the gain control unit. The echo cancellation unit was then connected to this position, forming a new topology of high-pass filter → noise suppression → echo cancellation → gain control → audio output. The new topology was retested and the echo suppression ratio was found to be 45dB, which meets the preset requirement of ≥40dB.

[0064] Furthermore, when the target audio processing unit is simply a newly added audio processing unit, the topology connection structure corresponding to the newly added audio processing unit can be determined first. Then, based on the topology connection structure and the newly added audio processing unit, a target topology is generated, and the audio test topology is replaced with the target topology. Specifically, according to the technical specifications and functional characteristics of the newly added audio processing unit, its corresponding topology connection structure requirements are extracted, including the required number of input ports, the number of output ports, the signal branching method, and the functional dependencies with other units. Then, based on the core processing units retained in the original topology and combined with the connection structure requirements of the newly added unit, multiple candidate target topologies are automatically generated through a topology generation algorithm. Finally, the newly generated target topology is loaded and the parameters of all units are initialized. Steps S10 and S20 are re-executed to detect audio indicators. If the indicators meet the standards, the replacement is completed; if they still do not meet the standards, the generation parameters of the target topology are optimized.

[0065] This embodiment provides a method for adjusting audio algorithm parameters. By conducting a structural adaptability assessment, it determines whether there are fundamental defects in the current audio test topology. If there are fundamental defects, it initiates a switching path, selects a suitable audio processing unit for replacement, or selects a more suitable alternative structure from the candidate template for replacement, thereby improving the intelligence level of audio algorithm debugging and the rationality of the final topology structure.

[0066] Based on the first embodiment of this application, in the third embodiment of this application, the same or similar content as the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, the preset compliance range includes a first range and a second range, which overlap. The first range refers to the general basic performance compliance range that audio products must meet, i.e., objective compliance requirements, which are preset parameters. The second range refers to a specific performance compliance range customized for a specific application scenario, usually a user-defined parameter. Therefore, before step S20, it is necessary to determine whether all audio indicators of the test audio are outside the first and second ranges; if so, it is determined that at least one audio indicator of the test audio is outside the preset compliance range.

[0067] In this embodiment, an audio metric is deemed unqualified only when it fails to meet both the requirements of the first and second intervals. This avoids misjudging cases that only slightly deviate from the scene requirements but still meet the basic standards as unqualified, thus reducing unnecessary debugging processes.

[0068] During the judgment process, the audio testing equipment performs index detection on the test audio to obtain the specific values ​​of each audio index. Then, the value of each index is compared with the first interval and the second interval to determine whether the index is simultaneously outside the first interval and outside the second interval.

[0069] For example, in a TWS earphone topology test scenario, the pre-configured first interval (general basic standard) is: total harmonic distortion ≤1%, signal-to-noise ratio ≥60dB, and noise reduction depth ≥20dB; the user-defined second interval (outdoor scenario-specific standard) is: total harmonic distortion ≤0.5%, signal-to-noise ratio ≥65dB, and noise reduction depth ≥30dB; the intersection of the two intervals is the region where total harmonic distortion ≤0.5%, signal-to-noise ratio ≥65dB, and noise reduction depth ≥30dB. The audio testing equipment detected that the total harmonic distortion of the test audio was 0.8%, the signal-to-noise ratio was 62dB, and the noise reduction depth was 22dB; after comparison, it was found that the total harmonic distortion was within the first interval but outside the second interval, the signal-to-noise ratio was within the first interval but outside the second interval, and the noise reduction depth was within the first interval but outside the second interval, none of which were simultaneously outside both intervals, therefore it was determined that the non-compliance conditions were not triggered.

[0070] This embodiment uses an audio index pass / fail judgment logic based on the intersection of two intervals to solve the problem that a single pass / fail interval cannot take into account both general performance and scenario performance. It can flexibly adapt to different application scenarios and different levels of strictness in debugging requirements, avoid over-debugging due to slight deviations in non-critical indicators, reduce computing resource consumption and debugging time, and ensure specific performance requirements in specific scenarios.

[0071] Based on the first embodiment of this application, in the fourth embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Furthermore, before step S10, steps S01 to S03 are also included: Step S01: In response to the access command of the audio device under test, determine the device information of the audio device under test.

[0072] An access command is a handshake signal sent by the audio device under test (DUT) to establish a physical or wireless connection with the audio test equipment. It is used to notify the test equipment that a new device has connected. Device information refers to a set of parameters that uniquely identify the hardware capabilities and software configuration of the DUT, including device model, hardware version, firmware version, list of supported audio processing units, maximum number of topology nodes, and available computing resources.

[0073] In this embodiment, the audio testing device monitors the level changes of all its wired interfaces in real time. When a device is detected to be connected, it automatically sends a device information query command to the device under test (DUT). Upon receiving the query command, the DUT reads pre-stored information such as device model, hardware version, firmware version, supported audio processing unit types, and parameter ranges from its local storage, packages it, and sends it to the audio testing device via a wired link. Finally, the audio testing device parses the received data packet, extracts and stores key device information, and completes device identification and capability assessment.

[0074] In addition, it can connect to the audio device under test and transmit device information wirelessly via Bluetooth, Wi-Fi, and other methods.

[0075] Step S02: Output the test topology information of the audio device under test based on the device information.

[0076] The test topology information is a collection of all audio processing topologies that the device can support, selected from a preset topology library based on the capability information of the audio device under test. Each topology information includes topology ID, topology name, node composition, signal flow direction, applicable scenarios, historical debugging success rate, etc.

[0077] In this embodiment, the audio testing device queries a locally stored device model-topology mapping library based on the acquired device model. It then extracts detailed information about all audio testing topologies supported by that device model from the mapping library, including topology ID, node composition, and applicable scenarios. Finally, the extracted topology information is categorized and sorted according to applicable scenarios and output to the user interface for selection.

[0078] For example, the audio testing device queries the local model-topology mapping library based on the TWS earphone model and extracts the three topologies supported by that model: Topology ID1 (graph1 basic topology: high-pass filter → noise suppression → gain control, applicable scenario: general calls), Topology ID2 (enhanced noise reduction topology: high-pass filter → dual-stage noise suppression → gain control, applicable scenario: outdoor calls), and Topology ID3 (music mode topology: equalizer → gain control, applicable scenario: music playback). Finally, the three topology information are displayed on the testing device's screen in order of priority for general scenarios.

[0079] Step S03: In response to the configuration command for the test topology information, determine the audio test topology for the audio device under test for audio testing.

[0080] Configuration commands refer to the commands that users input through the interactive interface of the audio testing equipment to select or confirm the test topology, including topology selection commands, topology confirmation commands, and custom topology modification commands.

[0081] In this embodiment, the audio testing device displays all available topology information on the interactive interface, with each topology accompanied by an explanation of its applicable scenarios. The user selects the corresponding topology option based on the application scenario of the current debugging task, or customizes the topology configuration. Finally, after receiving the user's selection command, the audio testing device generates a topology configuration confirmation prompt. After the user clicks "confirm," the topology is confirmed as the final audio testing topology for this debugging session.

[0082] Optionally, the system can automatically recommend the most suitable topology based on the application scenario of the current debugging task and the device's historical debugging data. Specifically, the audio testing device acquires the application scenario information of the current debugging task (such as general calls, outdoor calls, conferences, etc.), then combines the available topology information with the device's historical debugging success rate data in the corresponding scenario to calculate the suitability score for each topology. Finally, the topology with the highest suitability score is selected as the recommended topology and displayed on the interactive interface. After the user clicks "confirm," this topology is confirmed as the final audio testing topology.

[0083] In this embodiment, after responding to the access command of the audio device under test, the initial audio test topology corresponding to the device is obtained through the device information of the device, thereby improving the automation efficiency of audio algorithm parameter adjustment.

[0084] Based on the first embodiment of this application, in the fifth embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, after step S10, step S40 is also included: Step S40: When all audio indicators of the test audio are within the preset acceptable range, update the historical debugging record of the audio device under test.

[0085] The historical debugging record includes at least one of the following: configuration snapshots of the iteration, test results, convergence trajectory, and the audio test topology after the iteration.

[0086] In this embodiment, when all audio metrics of the test audio are within the preset acceptable range, it indicates that the audio device under test meets the test requirements. At this point, key data from this debugging process is extracted, including the device's unique identifier, the start and end times of the debugging, the final audio test topology (node ​​composition and connection relationships), the optimal parameter configurations of all audio processing units, the final values ​​of each audio metric, the comprehensive test score, the number of parameter optimizations performed during the debugging process, and the number of topology updates performed. Next, the local historical record database is queried to check if there are any historical records with the same device and topology. If no identical records exist, the data from this debugging process is added as a new entry to the historical record database; if identical records exist, only the fields showing changes, such as parameter configuration, metric values, and test scores, are updated to complete the incremental update.

[0087] Optionally, when the algorithm within the audio processing unit is improved without adjusting the topology, the algorithm or suggestions that need to be improved can be output, and then re-detected in response to the improvement operation triggered by the user.

[0088] For example, to help understand the implementation flow of the audio algorithm parameter adjustment method obtained by combining this embodiment with the first embodiment described above, please refer to... Figure 4 , Figure 4 A simplified flowchart illustrating a method for adjusting audio algorithm parameters is provided, specifically: The fully automated audio algorithm debugging process begins with loading the initial audio processing topology and default parameters of the audio device under test. First, it performs a comprehensive subjective and objective metric assessment. If the comprehensive score reaches the preset passing threshold, the optimal topology and parameter configuration are saved, and the process ends. If it fails to meet the threshold, it checks if there is room for parameter adjustment in the current topology. If so, it prioritizes adjusting the parameters that have the greatest impact on the failing metrics. If not, it indicates that the parameters have reached their theoretical optimality, and the performance bottleneck stems from the topology itself. It then determines whether the problem can be solved by adjusting the internal topology. If so, a locally optimized new topology is generated based on the defect location. If not, it indicates a fundamental architectural defect, and the core processing algorithm that needs updating is located and algorithm-level improvements are completed. After all parameter adjustments, topology generation, or algorithm improvements are completed, the process enters a retest phase, returning to the subjective and objective metric assessment node. This layered and progressive optimization and verification process is repeated until the comprehensive metrics meet the threshold, at which point the configuration is saved, and the entire debugging process ends.

[0089] Further, please refer to Figure 5 , Figure 5 A schematic diagram of the overall architecture for audio parameter adjustment is provided. This architecture consists of five core functional modules: a modular algorithm component library, a DAG-type graph audio topology builder, an AI parameter tuning engine, a test data closed-loop feedback system, and a debugging knowledge base storage module. Each layer is loosely coupled through standardized interfaces, forming a complete automated debugging loop. The modular component library contains a series of standardized audio processing units, each encapsulating independent functional logic and a set of adjustable parameters. Typical components include, but are not limited to: acoustic echo cancellation (AEC), noise suppression (ANS), automatic gain control (AGC), equalizer (EQ), dynamic range compressor (Limiter), and sound effect renderer. All components adhere to a unified input / output interface protocol, supporting plug-and-play integration. The graph builder allows users (manually selecting the connection direction) to connect multiple components according to the signal flow direction to form a directed acyclic graph (DAG) structure, defining a complete audio processing flow. The graph supports various topologies, including linear serial structures, branched selection paths, and composite structures with nested subgraphs. The system maintains a set of preset candidate graph templates, covering typical configurations for common use cases, such as call noise reduction mode, music playback enhancement mode, and voice wake-up low-power mode.

[0090] The AI ​​parameter tuning engine, acting as the system's decision-making hub, receives multi-dimensional feedback data from the testing instruments, including subjective MOS scores (ratings given by users) and objective audio quality metrics (such as THD+N, SNR, and frequency response flatness). The AI ​​engine incorporates a multi-objective optimization model, employing Bayesian optimization or particle swarm optimization (PSO) algorithms to jointly search for the optimal solution in both the parameter and structure spaces. The core decision logic of the AI ​​engine includes: first, determining whether the current test results meet the preset standards; if not, further analyzing the sources of performance deviation. The system performs diagnostics through two parallel paths: First, perform parameter sensitivity testing to identify the highly sensitive components that have the greatest impact on key indicators and their parameters to be adjusted. Second, conduct a structural adaptability assessment to determine whether there are any fundamental defects in the current graph topology.

[0091] If the primary issue is determined to be improper parameter settings, the "fine-tuning" path is triggered, generating a new parameter combination and sending it to the target Component. If the existing Graph is determined to be insufficient, the "switching" path is initiated, selecting a more suitable alternative structure from candidate templates for replacement. This dual-path decision-making mechanism ensures that the system can be finely adjusted and macroscopically restructured, forming a hierarchical optimization strategy.

[0092] The test data closed-loop system consists of a test server, audio playback / recording equipment, and analysis software. It is responsible for executing automated test tasks and sending the results back to the AI ​​engine. The test process covers various typical usage scenarios, including different signal-to-noise ratio conditions, multi-speaker aliasing environments, and vibration interference during movement. The knowledge base storage module persistently stores historical debugging records, including configuration snapshots for each iteration, corresponding test results, convergence trajectories, and the final adopted optimal solution. The knowledge base uses a key-value pair index structure, supporting efficient retrieval by hardware platform, acoustic environment, usage scenario, and other dimensions. Subsequent projects can obtain initial configuration suggestions by querying similar cases, enabling effective reuse of debugging experience.

[0093] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the method of adjusting the audio algorithm parameters of this application. Any simple transformations based on this technical concept are within the protection scope of this application.

[0094] This application provides an audio algorithm parameter adjustment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the audio algorithm parameter adjustment method in the first embodiment described above.

[0095] The following is for reference. Figure 6 It shows a schematic diagram of the structure of an audio algorithm parameter adjustment device suitable for implementing the embodiments of this application. Figure 6 The audio algorithm parameter adjustment device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0096] like Figure 6 As shown, the audio algorithm parameter adjustment device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the audio algorithm parameter adjustment device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the audio algorithm parameter adjustment device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows audio algorithm parameter adjustment devices with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0097] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0098] The audio algorithm parameter adjustment device provided in this application, employing the audio algorithm parameter adjustment method in the above embodiments, can solve the technical problem of meaningless parameter iteration in topologies with structural defects. Compared with the prior art, the beneficial effects of the audio algorithm parameter adjustment device provided in this application are the same as those of the audio algorithm parameter adjustment method provided in the above embodiments, and other technical features in this audio algorithm parameter adjustment device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0099] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0100] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0101] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the audio algorithm parameter adjustment method in the above embodiments.

[0102] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (EPROM, or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0103] The aforementioned computer-readable storage medium may be included in the audio algorithm parameter adjustment device; or it may exist independently and not be assembled into the audio algorithm parameter adjustment device.

[0104] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the audio algorithm parameter adjustment device, cause the audio algorithm parameter adjustment device to: acquire test audio output by the audio device under test based on the audio test topology, wherein the audio test topology contains multiple nodes, each node corresponding to an audio processing unit; When at least one audio metric of the test audio is outside the preset acceptable range, based on the parameter sensitivity detection results of each audio processing unit, it is determined whether each audio processing unit is in the optimal parameter state. If so, update the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset acceptable range.

[0105] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0108] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described audio algorithm parameter adjustment method, which can solve the technical problem of meaningless parameter iteration in topologies with structural defects. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the audio algorithm parameter adjustment method provided in the above embodiments, and will not be repeated here.

[0109] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for adjusting audio algorithm parameters, characterized in that, The methods for adjusting the audio algorithm parameters include: Acquire test audio output by the audio device under test based on an audio test topology, wherein the audio test topology contains multiple nodes, each node corresponding to an audio processing unit; When at least one audio metric of the test audio is outside the preset acceptable range, based on the parameter sensitivity detection results of each audio processing unit, it is determined whether each audio processing unit is in the optimal parameter state. If so, update the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset acceptable range.

2. The method for adjusting audio algorithm parameters as described in claim 1, characterized in that, The step of updating the topology of the audio test topology until all audio indicators in the test audio of the updated audio test topology are within the preset compliance range includes: Determine the evaluation results of the structural adaptability of each audio processing unit in the audio test topology; Based on the evaluation results, a target audio processing unit is determined, which includes a newly added audio processing unit and / or a processing unit to be adjusted in the audio test topology. The target audio processing unit updates the topology of the audio test topology until all audio indicators of the test audio in the updated audio test topology are within the preset acceptable range.

3. The method for adjusting audio algorithm parameters as described in claim 2, characterized in that, When the target audio processing unit is the processing unit to be adjusted in the audio test topology, the step of determining the target audio processing unit based on the evaluation result includes: Based on the evaluation results, the processing unit that constitutes the performance bottleneck in the audio test topology is identified as the unit to be adjusted. The step of updating the topology in the audio test topology according to the target audio processing unit includes: Disconnect the processing unit to be adjusted from other processing units in the audio test topology, and / or adjust the signal connection relationship between the processing unit to be adjusted and adjacent nodes.

4. The method for adjusting audio algorithm parameters as described in claim 2, characterized in that, When the target audio processing unit is the newly added audio processing unit and the processing unit to be adjusted in the audio test topology, the step of determining the target audio processing unit based on the evaluation results includes: Based on the evaluation results, target audio parameters that are outside the preset qualified area are determined; Obtain at least one of the newly added audio processing units associated with the target audio parameters; Identify the processing unit to be adjusted that is incompatible with the newly added audio processing unit; The step of updating the topology in the audio test topology according to the target audio processing unit includes: Replace the processing unit to be adjusted with the newly added audio processing unit.

5. The method for adjusting audio algorithm parameters as described in claim 2, characterized in that, When the target audio processing unit is the newly added audio processing unit, the step of updating the topology structure in the audio test topology according to the target audio processing unit includes: Determine the topology connection structure corresponding to the newly added audio processing unit; Based on the aforementioned topology connection structure and the newly added audio processing unit, a target topology is generated, and the audio test topology is replaced with the target topology.

6. The method for adjusting audio algorithm parameters as described in claim 1, characterized in that, The preset target range includes a first range and a second range, which overlap. Before the step of determining whether each audio processing unit is in its optimal parameter state based on the parameter sensitivity detection results of each audio processing unit when at least one audio indicator of the test audio is outside the preset target range, the method for adjusting the audio algorithm parameters further includes: Determine whether all audio metrics of the test audio are outside the first interval and the second interval; If so, then at least one audio indicator of the test audio is determined to be outside the preset acceptable range.

7. The method for adjusting audio algorithm parameters as described in claim 1, characterized in that, Before the step of acquiring the test audio output by the audio device under test based on the audio test topology, the method for adjusting the audio algorithm parameters further includes: In response to the access command of the audio device under test, determine the device information of the audio device under test; Output the test topology information of the audio device under test based on the device information; In response to the configuration instructions of the test topology information, the audio test topology for audio testing of the audio device under test is determined.

8. The method for adjusting audio algorithm parameters as described in claim 1, characterized in that, Following the step of acquiring the test audio output by the audio device under test based on the audio test topology, wherein the audio test topology contains multiple nodes, each node corresponding to an audio processing unit, the method for adjusting the audio algorithm parameters further includes: When all audio metrics of the test audio are within the preset acceptable range, update the historical debugging record of the audio device under test. The historical debugging record includes at least one of the following: iterative configuration snapshots, test results, convergence trajectories, and the iterative audio test topology.

9. A device for adjusting audio algorithm parameters, characterized in that, The audio algorithm parameter adjustment device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the audio algorithm parameter adjustment method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the method for adjusting audio algorithm parameters as described in any one of claims 1 to 8.

Images