Dynamic audio buffer management method and system and medium

Abstract

The invention relates to the technical field of software, and discloses a dynamic audio buffer management method and system and a medium. The method comprises the following steps: presetting a white list library of a plurality of application scenes, and matching a package name of a current foreground running application with the white list library to determine a current application scene; acquiring system performance state parameters in real time, wherein the parameters comprise at least one of a CPU occupancy rate, a memory occupancy rate and a temperature control and frequency limiting state; generating a buffer adjustment variable according to a statistical result of the audio lagging times; inputting the current application scene, the system performance state parameter and the buffer area adjustment variable into a preset strategy model, and outputting a buffer area gear value; and dynamically adjusting the size of a buffer area of an audio driving layer according to the gear value so as to adapt to the performance change of the system. According to the invention, the problem of lagging or delay caused by a fixed buffer area can be solved.

Description

Technical Field

[0001] The technical field of the present invention belongs to software technology, and in particular relates to a dynamic audio buffer management method, system and medium. Background Art

[0002] In the audio playback scenario of smart devices, the management of audio buffers is crucial to real-time performance and stability. In current mainstream operating systems (such as Android), common audio channels (such as fast, direct, and deep buffers) usually use fixed DMA buffer (Direct Memory Access buffer) configurations. For example, the fast channel is used for low-latency scenarios (such as notification sounds, game background sounds), and its DMA buffer is smaller; the deep buffer channel is used for scenarios such as music playback that do not require high latency, and has a larger buffer. The DMA buffer size of these channels is determined by the product of the fixed PERIOD_SIZE (amount of data transferred in a single DMA) and PERIOD_COUNT (the buffer is divided into multiple periodic blocks for continuous transmission, which represents the number of buffer periodic blocks). However, this fixed configuration has significant drawbacks:

[0003] 1. Dynamic changes in system performance lead to freezes or delays

[0004] When the system is under high load (such as high CPU usage, insufficient memory, or thermal control frequency limiting), fixed small buffers (such as the fast path) may not be replenished in time, causing the audio driver layer buffer to underrun, resulting in noise or lag. Conversely, if the buffer is set too large (such as the deep buffer path), although it can reduce lag, it will introduce higher audio latency, affecting the user experience in real-time interactive scenarios (such as gaming and live streaming).

[0005] 2. Insufficient scene adaptation capabilities

[0006] Traditional solutions fail to consider the diverse audio performance requirements of different application scenarios. For example, gaming scenarios require low latency but are more tolerant of occasional minor stuttering; music playback, on the other hand, requires lower latency but extremely high continuity, avoiding stuttering. The fixed buffer configuration in traditional solutions makes it impossible to dynamically adjust the buffer strategy for different scenarios, resulting in an imbalance between performance and user experience.

[0007] 3. Lack of multi-dimensional parameter collaborative decision-making mechanism

[0008] Existing technologies typically rely on a single parameter (such as CPU utilization) for simple adjustments, while ignoring the combined effects of memory utilization, thermal control status, and audio freezes. For example, in high-temperature environments, even if CPU utilization is within the specified range, thermal throttling may result in a decrease in data processing capacity. In this case, relying solely on CPU utilization cannot effectively predict buffer requirements.

[0009] Therefore, to address the above problems, there is an urgent need for an audio buffer management method that can combine application scenario classification, multi-dimensional system performance parameters and real-time audio jamming feedback to achieve intelligent adaptation of the buffer size, reduce jamming while reducing latency, and improve user experience. Summary of the Invention

[0010] The present invention aims to provide a dynamic audio buffer management method, system and medium, aiming to solve the problem of jamming or delay caused by a fixed buffer.

[0011] To achieve the above object, in a first aspect of the present invention, a dynamic audio buffer management method is provided, comprising the following steps:

[0012] Preset a whitelist library for multiple application scenarios, and match the package name of the currently running application in the foreground with the whitelist library to determine the current application scenario;

[0013] Real-time acquisition of system performance status parameters, including at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status;

[0014] Generate buffer adjustment variables based on the statistical results of the number of audio freezes;

[0015] Input the current application scenario, system performance status parameters and buffer adjustment variables into a preset strategy model, and output a buffer gear value;

[0016] The buffer size of the audio driver layer is dynamically adjusted according to the gear value to adapt to changes in system performance.

[0017] Preferably, in the dynamic audio buffer management method, the application scenarios include:

[0018] Scenario 1: Games or live streaming applications; Scenario 2: Music or video players; Scenario 3: Social media apps; Scenario 4: System prompts or notifications;

[0019] Each scenario corresponds to a different whitelist classification strategy.

[0020] Preferably, in the dynamic audio buffer management method, the method for obtaining the temperature control and frequency limiting state includes:

[0021] Read the real-time temperature data of the CPU temperature node;

[0022] Compare the frequency limit threshold defined in the temperature control configuration file to determine whether temperature control frequency limit is triggered.

[0023] Preferably, in the dynamic audio buffer management method, the CPU occupancy rate is obtained by reading system node information to obtain the total CPU running time and idle time, and calculating the difference between the total CPU running time and idle time based on the ratio of the difference between the total CPU running time and idle time.

[0024] The memory occupancy rate is obtained by obtaining the total memory size and the free memory size through a system interface, and is calculated based on the ratio of the difference between the total memory size and the free memory size.

[0025] Preferably, in the dynamic audio buffer management method, the input of the strategy model includes the following multi-dimensional parameters:

[0026] The classification label of the current application scenario; the real-time value of the system performance status parameter; the calculation result of the buffer adjustment variable;

[0027] The output of the policy model is a preset buffer gear value, and the gear value corresponds one-to-one to different buffer size configuration strategies.

[0028] Preferably, in the dynamic audio buffer management method, the gear setting rules for each scenario in the strategy model are:

[0029] In the scenario 1, if the system performance status is high load, gear 2 is used; if it is low load, the default gear is maintained;

[0030] In the scenario 2, if the system performance state is low load, gear 3 is used; if it is high load, gear 4 is used;

[0031] In the scenarios 3 and 4, if the system performance state is high load, gear 3 and gear 2 are used respectively;

[0032] The definitions of high load and low load are as follows:

[0033] The high load requires the system performance state to meet at least one of the following conditions: the CPU occupancy rate is higher than a preset first threshold; the memory occupancy rate is higher than a preset second threshold; the temperature control and frequency limiting state is a trigger state;

[0034] The low load requires the system performance state to meet all of the following conditions: the CPU occupancy rate is lower than the first threshold; the memory occupancy rate is lower than the second threshold; the temperature control and frequency limiting state is not triggered.

[0035] Preferably, in the dynamic audio buffer management method, the process of dynamically adjusting the buffer size of the audio driver layer according to the gear value includes:

[0036] Passing the gear value to the audio driver layer through the audio hardware abstraction layer;

[0037] The audio driver layer modifies a DMA buffer parameter according to the gear value, where the DMA buffer parameter includes at least one of a single DMA transfer data volume and a buffer cycle number.

[0038] Preferably, in the dynamic audio buffer management method, the method further comprises:

[0039] When the system performance status returns to the baseline threshold, the default buffer size corresponding to each scenario is automatically reset.

[0040] In a second aspect of the present invention, a dynamic audio buffer management system is further provided, comprising the following modules:

[0041] A scenario recognition module is used to preset a whitelist library of multiple application scenarios and match the package name of the currently running application with the whitelist library to determine the current application scenario;

[0042] A performance monitoring module is used to obtain system performance status parameters in real time, including at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status;

[0043] The jam statistics module is used to generate buffer adjustment variables based on the number of buffer underruns reported by the audio driver layer or the jam event records monitored by the system;

[0044] A dynamic adjustment strategy module is pre-installed with a strategy model, receives the current application scenario output by the scenario recognition module, the system performance status parameters obtained by the performance monitoring module, and the buffer adjustment variable generated by the jam statistics module, and outputs the corresponding buffer gear value;

[0045] a buffer configuration module, configured to dynamically adjust DMA buffer parameters of the audio driver layer according to the gear value, including modifying at least one of a single DMA transfer data amount and a buffer cycle number to dynamically adjust the buffer size;

[0046] and a recovery control module for automatically resetting the default buffer parameters corresponding to each scenario when the system performance status recovers to the baseline threshold.

[0047] In a third aspect of the present invention, a computer-readable storage medium is further provided, wherein program instructions are stored in the computer-readable storage medium. When the program instructions are executed, the dynamic audio buffer management method described in the first aspect is implemented.

[0048] Compared with the prior art, the present invention has at least the following technical effects:

[0049] This dynamic audio buffer management method addresses the issues of audio lag or delay caused by a fixed buffer by creating a whitelist of application scenarios, monitoring system performance and audio freezes in real time, and dynamically adjusting the audio buffer size based on a policy model. Furthermore, this method can adapt to different system load scenarios, optimize audio transmission quality, and significantly improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 A flowchart of a method for dynamic audio buffer management according to an embodiment of the present invention;

[0051] Figure 2 This is a flow chart of an algorithm for updating a buffer zone in one embodiment of the present invention;

[0052] Figure 3 FIG. 4 is a logic flow chart of a dynamic audio buffer management method according to an embodiment of the present invention. DETAILED DESCRIPTION

[0053] The following describes a dynamic audio buffer management method, system, and medium of the present invention in more detail with reference to schematic diagrams. These diagrams illustrate preferred embodiments of the present invention. It should be understood that those skilled in the art may modify the present invention described herein while still achieving the beneficial effects of the present invention. Therefore, the following description should be understood as generally understood by those skilled in the art and is not intended to limit the present invention.

[0054] For the sake of clarity, not all features of actual embodiments are described. In the following description, well-known functions and structures are not described in detail because they would obscure the present invention with unnecessary detail. It should be understood that in the development of any actual embodiment, numerous implementation details must be made to achieve the developer's specific goals, such as adapting from one embodiment to another to accommodate system or business constraints. Furthermore, it should be understood that such development work may be complex and time-consuming, but is nevertheless a routine undertaking for those skilled in the art.

[0055] The following paragraphs describe the present invention in more detail by way of example with reference to the accompanying drawings. The advantages and features of the present invention will become more apparent from the following description. It should be noted that the drawings are greatly simplified and not to exact scale, and are provided solely for the purpose of assisting in the description of the embodiments of the present invention.

[0056] Example 1

[0057] As mentioned in the background, if the audio path uses a fixed DMA buffer, it may not be able to adapt to changes in system performance in some scenarios. For example, in the fast path, if the current system performance is relatively poor, data transmission is not timely, and the DMA buffer is relatively small, the underlying data will be played out faster and not replenished in time. At this time, empty data will be played, and the empty data will be interspersed with normal data, which will cause the human ear to hear noise, which greatly affects the user experience.

[0058] In view of this, if Figure 1 and Figure 3 As shown, an embodiment of the present invention provides a dynamic audio buffer management method, comprising the following steps:

[0059] S1: Preset a whitelist library for multiple application scenarios, and match the package name of the current foreground running application with the whitelist library to determine the current application scenario;

[0060] S2: acquiring system performance status parameters in real time, wherein the parameters include at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status;

[0061] S3: Generate a buffer adjustment variable based on the statistical results of the number of audio freezes;

[0062] S4: Input the current application scenario, system performance status parameters and buffer adjustment variables into a preset strategy model, and output a buffer gear value;

[0063] S5: Dynamically adjust the buffer size of the audio driver layer according to the gear value to adapt to changes in system performance.

[0064] For step S1, Table 1 below shows a comparison of DMA buffer sizes for some common audio paths, illustrating the fixed configuration differences between fast, deep buffer, and direct paths.

[0065] Table 1

[0066]

[0067]

[0068] In this embodiment, based on the single-frame delay time and DMA buffer size of different audio channels in Table 1 above, application scenarios can be pre-defined into four categories, and a whitelist library can be created for each category. Specifically, the application scenarios include Scenario 1, Scenario 2, Scenario 3, and Scenario 4, each corresponding to a different whitelist classification strategy. Scenario 1 defines a whitelist for gaming or live streaming applications; Scenario 2 defines a whitelist for music players or video players; Scenario 3 defines a whitelist for social media apps; and Scenario 4 defines a whitelist for system prompts and notification sounds.

[0069] In addition, the whitelist library includes application package names corresponding to specific scenarios. For example, the package name list corresponding to scenario 1 (games or live streaming applications) includes mainstream games and live streaming applications; the package name list corresponding to scenario 2 (music or video players) includes Spotify, YouTube, etc.; the package name list corresponding to scenario 3 (social software) includes WeChat, WhatsApp, etc.; the package name list corresponding to scenario 4 (system prompts or notification sounds) includes system ringtones, message notification sounds, etc.

[0070] The package name of the current foreground application is obtained through system interfaces (such as ActivityManager.getRunningTasks()) and compared against the whitelist to determine the current application scenario. If a match is found, the current application scenario is determined; if not, it is classified as a general scenario (using the default buffer strategy).

[0071] In step S2 of this embodiment, three system performance status parameters, namely, CPU occupancy, memory occupancy, and temperature control and frequency limiting status, need to be acquired in real time.

[0072] The CPU usage is calculated by reading the / proc / stat information on the system node to obtain the total CPU running time (total_time) and idle time (idle_time), and then calculating the difference between the two as a percentage of the total time. The formula is as follows:

[0073] CPU usage = (total_time - free_time) ÷ total_time × 100%, calculate the current CPU load in real time.

[0074] The memory usage is calculated by calling the system interface (such as ActivityManager.MemoryInfo) to obtain the total memory size (total_mem) and the free memory size (free_mem), and then calculating the difference between the two as a percentage of the total memory size. The formula is as follows:

[0075] Memory usage = (total_mem - free_mem) ÷ total_mem × 100%.

[0076] In addition, the method for acquiring the temperature control and frequency limiting state includes: reading the real-time temperature data of the CPU temperature node; comparing the frequency limiting threshold defined in the temperature control configuration file to determine whether the temperature control and frequency limiting is triggered.

[0077] Specifically, the thermal control and frequency limiting state is determined by reading the real-time temperature value of the CPU temperature node (such as / sys / class / thermal / thermal_zone0 / temp) and comparing it with the frequency limiting threshold (such as 80°C) defined in the thermal control configuration file (such as / vendor / ect / thermal-engine.conf). If the temperature exceeds the threshold and the system triggers frequency reduction, thermal control is triggered and the "thermal control and frequency limiting state is activated."

[0078] Further, for step S3, in the dynamic audio buffer management method, a buffer adjustment variable is generated according to the statistical result of the number of audio freezes, such as Figure 2 The buffer adjustment variables include variable 1 (xrun_count), variable 2 (Bufincrease), variable 3 (framesReady), and variable 4 (framesDesired). The specific steps are as follows:

[0079] First, initialize the variables. In the AudioFlinger service, set the variable xrun_count to record the number of audio freezes in the system, with an initial value of 0. Set the variable Bufincrease to record whether the buffer needs to be updated, with an initial value of 0 (0 means no increase, 1 means an increase, and 2 means further increase). At the same time, the system has a known variable framesReady to represent the frames prepared at each time, and a variable framesDesired to represent the desired frames.

[0080] Next, determine if there is audio lag. Entering the judgment process, compare framesReady and framesDesired. If framesReady is less than framesDesired, it indicates that the application is not writing data in a timely manner and the system is experiencing lag. In this case, the value of xrun_count is incremented by 1. If framesReady is greater than or equal to framesDesired, the xrun_count increment operation is not performed.

[0081] Finally, the buffer adjustment variable is determined based on the number of jams. The value of xrun_count is judged. If xrun_count is less than 3 and the xrun_count plus 1 operation has been performed due to jams before (that is, there is jamming), Bufincrease is set to 1, indicating that the buffer needs to be increased; if xrun_count is greater than or equal to 3, it means that the jam is more serious, and Bufincrease is set to 2, indicating that the buffer needs to be further increased; if xrun_count is always less than 3 and there is no jam (framesReady is greater than or equal to framesDesired), Bufincrease is set to 0, indicating that the buffer does not need to be increased, and xrun_count is reset to 0, and the jam count is restarted. The final generated Bufincrease variable is the buffer adjustment variable, which will be input into the preset strategy model for subsequent determination of the buffer gear value and adjustment of the buffer size.

[0082] In step S4, the information determined in steps S1-S3 is input into a pre-set policy model. The policy model's inputs include the following multi-dimensional parameters: the classification label of the current application scenario; the real-time values ​​of system performance status parameters; and the calculated results of buffer adjustment variables. The policy model's output is a preset buffer level value, which corresponds to different buffer size configuration strategies. Table 2 below is a policy level table, which specifies the level selection rules for each scenario under different system states.

[0083] Table 2

[0084] Strategy gear DMA buffer size Latency Stuttering rate 1 480 Low Sometimes happens 2 1920 middle Less common 3 3840 high It's hard to happen 4 7680 Very high Extremely unlikely to happen

[0085] It should be noted that the strategy model of the present invention performs logical operations on input parameters based on preset algorithmic rules, and its internal decision-making logic can achieve dynamic parameter calibration through machine learning or heuristic optimization mechanisms. It should be clarified that the specific strategy rules demonstrated in this embodiment are merely illustrative schemes for algorithmic implementation. In actual deployment, multi-dimensional parameter tuning can be performed based on performance monitoring data, including but not limited to scenario weight coefficient adjustment, dynamic threshold calibration, and gear mapping optimization.

[0086] Furthermore, the gear setting rules for each scenario in the strategy model are as follows: in scenario 1, if the system performance status is high load, gear 2 is adopted; if it is low load, the default gear is maintained; in scenario 2, if the system performance status is low load, gear 3 is adopted; if it is high load, gear 4 is adopted; in scenarios 3 and 4, if the system performance status is high load, gear 3 and gear 2 are adopted respectively.

[0087] The definitions of high load and low load are as follows: High load requires the system performance state to meet at least one of the following conditions: CPU occupancy is higher than a preset first threshold (such as 80%); memory occupancy is higher than a preset second threshold (such as 80%); and the temperature control and frequency limiting state is triggered. Low load requires the system performance state to meet all of the following conditions: CPU occupancy is lower than the first threshold; memory occupancy is lower than the second threshold; and the temperature control and frequency limiting state is not triggered.

[0088] Specifically, Table 3 is a system performance status definition table, which lists some high / low load judgment conditions and thresholds.

[0089] Table 3

[0090]

[0091] State 1 is defined as follows: CPU usage > 80%, memory usage > 80%, thermal control frequency limiting is triggered, and Bufincrease is 0. State 2 is defined as follows: CPU usage > 80%, memory usage > 80%, thermal control frequency limiting is triggered, and Bufincrease is 1. State 3 is defined as follows: CPU usage > 80%, memory usage > 80%, thermal control frequency limiting is triggered, and Bufincrease is 2. State 4 is defined as follows: CPU usage < 80%, memory usage < 80%, thermal control frequency limiting is not triggered, and Bufincrease is 0.

[0092] In this embodiment, the gear setting rules for each scenario in the strategy model may be as follows: In scenario 1, if the system state is state 2 or state 3, gear 2 is output; if the system state is state 1, the default strategy is maintained unchanged. In scenario 2, if the system state is state 1, gear 3 is output; if the system state is state 2 or state 3, gear 4 is output. In scenario 3, when the system state is state 2 or state 3, gear 3 is output. In scenario 4, when the system state is state 2 or state 3, gear 2 is output. When the system state is state 4, the default buffer size originally set for each scenario is restored, and no gear adjustment is performed (equivalent to maintaining the buffer gear under the default strategy). Finally, the strategy model outputs corresponding buffer gear values ​​according to different input combinations.

[0093] For step S5, the process of dynamically adjusting the buffer size of the audio driver layer according to the gear value includes: passing the gear value to the audio driver layer through the audio hardware abstraction layer; the audio driver layer modifies the DMA buffer parameters according to the gear value, and the DMA buffer parameters include at least one of the amount of data transferred in a single DMA (PERIOD_SIZE) and the number of buffer cycles (PERIOD_COUNT). When the load is high, the buffer is increased to reduce jamming, and when the load is low, the buffer is reduced to reduce latency. Specifically, the total buffer size calculation formula is:

[0094] Total Buffer=PERIOD_SIZE×PERIOD_COUNT

[0095] For example, gear 2 corresponds to PERIOD_SIZE=2048, and PERIOD_COUNT=4, and the total buffer is 8192 frames.

[0096] Furthermore, the method further includes: when the system performance status recovers to a baseline threshold, automatically resetting the default buffer size corresponding to each scenario.

[0097] In this embodiment, when the system performance status is confirmed to meet the benchmark threshold for three consecutive monitoring cycles (1.5 seconds) through real-time monitoring (data is collected every 500ms) (the corresponding system performance status is "state 0" or "state 4", that is, CPU occupancy rate is less than 80%, memory occupancy rate is less than 80% and temperature control frequency limiting is not triggered), the system automatically obtains the name of the current foreground running application package and matches it with the preset whitelist to confirm the scene, and then sends an instruction to the audio hardware abstraction layer. The driver layer restores the default buffer size according to the scene type (such as 480 for scene 1 game / live broadcast, 3840 or 7680 for scene 2 music / video according to the channel type, etc.), and clears the freeze count counter and buffer update flag at the same time; among them, "state 0" is the typical state of the benchmark threshold, which directly triggers the restoration of the default buffer size for each scene. This mechanism avoids short-term fluctuation interference through anti-jitter continuous monitoring, realizes automatic regression of buffer configuration when system resources are sufficient, and balances audio delay and performance occupancy. Balance audio performance and latency when system resources are sufficient to avoid sound delays caused by excessive buffer size. The baseline threshold can be flexibly adjusted through the policy model to adapt to different devices.

[0098] In another embodiment, a dynamic audio buffer management system based on a predictive model is provided, comprising a scenario recognition module, a performance monitoring module, a stuttering statistics module, a dynamic adjustment strategy module, a buffer configuration module, and a recovery control module. The scenario recognition module is configured to preset a whitelist library of multiple application scenarios and match the package name of the currently running application with the whitelist library to determine the current application scenario. The performance monitoring module is configured to obtain system performance status parameters in real time, including at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status. The stuttering statistics module is configured to generate a buffer adjustment variable based on the number of buffer underruns reported by the audio driver layer or stuttering event records monitored by the system. The dynamic adjustment strategy module is pre-installed with a strategy model, receives the current application scenario output by the scenario recognition module, the system performance status parameters obtained by the performance monitoring module, and the buffer adjustment variable generated by the stuttering statistics module, and outputs a corresponding buffer gear value. The buffer configuration module is configured to dynamically adjust the DMA buffer parameters of the audio driver layer based on the gear value, including modifying at least one of the single DMA transfer data volume and the number of buffer cycles to dynamically adjust the buffer size. The recovery control module is used to automatically reset the default buffer parameters corresponding to each scenario when the system performance status recovers to the baseline threshold.

[0099] Furthermore, in the dynamic audio buffer management system, the performance monitoring module includes a CPU occupancy calculation unit, a memory occupancy calculation unit, and a temperature control status determination unit. The CPU occupancy calculation unit obtains the total CPU running time and idle time by reading the system node information, and calculates the CPU occupancy based on the ratio of the difference between the two to the total time. The memory occupancy calculation unit obtains the total memory size and the free memory size through the system interface, and calculates the memory occupancy based on the ratio of the difference between the two to the total memory size. The temperature control status determination unit determines whether the temperature control frequency limit is triggered by reading the CPU temperature node data and comparing it with the frequency limit threshold in the temperature control configuration file.

[0100] Furthermore, in the dynamic audio buffer management system, the strategy model preset in the strategy decision module is a multi-dimensional decision model, whose input includes application scenario classification labels, real-time values ​​of system performance status and buffer adjustment variables, and the output is the gear value corresponding to different buffer configuration strategies.

[0101] Furthermore, the dynamic audio buffer management system further includes a state recovery module and a calibration module. The state recovery module is configured to automatically reset the default buffer size corresponding to each scenario when the system performance status returns to a baseline threshold. The calibration module is configured to dynamically adjust the baseline values ​​of PERIOD_SIZE and PERIOD_COUNT corresponding to the gear position based on historical performance data of the audio driver or benchmark tests during system startup.

[0102] Example 3

[0103] This third embodiment provides a computer-readable storage medium, which stores program instructions. When the program instructions are executed by a processor, they can implement some or all of the steps of the dynamic audio buffer management method in the first embodiment, so as to solve the problem of lag or delay caused by the fixed buffer, optimize the audio transmission quality, and significantly improve the user experience.

[0104] In summary, this dynamic audio buffer management method addresses the issues of audio lag or delay caused by a fixed buffer by creating a whitelist of application scenarios, monitoring system performance and audio freezes in real time, and dynamically adjusting the audio buffer size based on a policy model. Furthermore, this method can adapt to varying system load scenarios, optimize audio transmission quality, and significantly enhance the user experience.

[0105] The above description is merely a preferred embodiment of the present invention and does not limit the present invention in any way. Any person skilled in the art who, without departing from the scope of the present invention, makes any equivalent substitution, modification, or other changes to the technical solution and technical content disclosed in the present invention shall be deemed to be within the scope of the present invention and still fall within the scope of protection of the present invention.

Claims

1. A dynamic audio buffer management method, characterized in that: The following steps are involved: Preset a whitelist library for multiple application scenarios, and match the package name of the currently running application in the foreground with the whitelist library to determine the current application scenario; Real-time acquisition of system performance status parameters, including at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status; Generate buffer adjustment variables based on the statistical results of the number of audio freezes; Input the current application scenario, system performance status parameters and buffer adjustment variables into a preset strategy model, and output a buffer gear value; The buffer size of the audio driver layer is dynamically adjusted according to the gear value to adapt to changes in system performance.

2. The dynamic audio buffer management method according to claim 1, wherein: The application scenarios include: Scenario 1: Games or live streaming applications; Scenario 2: Music or video players; Scenario 3: Social media apps; Scenario 4: System prompts or notifications; Each scenario corresponds to a different whitelist classification strategy.

3. The dynamic audio buffer management method according to claim 1, wherein: The method for obtaining the temperature control and frequency limiting state includes: Read the real-time temperature data of the CPU temperature node; Compare the frequency limit threshold defined in the temperature control configuration file to determine whether temperature control frequency limit is triggered.

4. The dynamic audio buffer management method according to claim 1, wherein: The CPU occupancy rate is calculated by reading the system node information to obtain the total CPU running time and idle time, and based on the ratio of the difference between the two to the total time; The memory occupancy rate is obtained by obtaining the total memory size and the free memory size through a system interface, and is calculated based on the ratio of the difference between the total memory size and the free memory size.

5. The dynamic audio buffer management method according to claim 1, wherein: The input of the strategy model includes the following multi-dimensional parameters: The classification label of the current application scenario; the real-time value of the system performance status parameter; the calculation result of the buffer adjustment variable; The output of the policy model is a preset buffer gear value, and the gear value corresponds one-to-one to different buffer size configuration strategies.

6. The dynamic audio buffer management method according to claim 2, wherein: The gear setting rules for each scenario in the strategy model are: In the scenario 1, if the system performance status is high load, gear 2 is used; if it is low load, the default gear is maintained; In the scenario 2, if the system performance state is low load, gear 3 is used; if it is high load, gear 4 is used; In the scenarios 3 and 4, if the system performance state is high load, gear 3 and gear 2 are used respectively; The definitions of high load and low load are as follows: The high load requires the system performance state to meet at least one of the following conditions: the CPU occupancy rate is higher than a preset first threshold; the memory occupancy rate is higher than a preset second threshold; the temperature control and frequency limiting state is a trigger state; The low load requires the system performance state to meet all of the following conditions: the CPU occupancy rate is lower than the first threshold; the memory occupancy rate is lower than the second threshold; the temperature control and frequency limiting state is not triggered.

7. The dynamic audio buffer management method according to claim 1, wherein: The process of dynamically adjusting the buffer size of the audio driver layer according to the gear value includes: Passing the gear value to the audio driver layer through the audio hardware abstraction layer; The audio driver layer modifies a DMA buffer parameter according to the gear value, where the DMA buffer parameter includes at least one of a single DMA transfer data volume and a buffer cycle number.

8. The dynamic audio buffer management method according to claim 1, wherein: The method further comprises: When the system performance status returns to the baseline threshold, the default buffer size corresponding to each scenario is automatically reset.

9. A dynamic audio buffer management system, characterized in that: Includes the following modules: A scenario recognition module is used to preset a whitelist library of multiple application scenarios and match the package name of the currently running application with the whitelist library to determine the current application scenario; A performance monitoring module is used to obtain system performance status parameters in real time, including at least one of CPU occupancy, memory occupancy, and temperature control and frequency limiting status; The jam statistics module is used to generate buffer adjustment variables based on the number of buffer underruns reported by the audio driver layer or the jam event records monitored by the system; A dynamic adjustment strategy module is pre-installed with a strategy model, receives the current application scenario output by the scenario recognition module, the system performance status parameters obtained by the performance monitoring module, and the buffer adjustment variable generated by the jam statistics module, and outputs the corresponding buffer gear value; a buffer configuration module, configured to dynamically adjust DMA buffer parameters of the audio driver layer according to the gear value, including modifying at least one of a single DMA transfer data amount and a buffer cycle number to dynamically adjust the buffer size; and a recovery control module for automatically resetting the default buffer parameters corresponding to each scenario when the system performance status recovers to the baseline threshold.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores program instructions, which, when executed, are used to implement the dynamic audio buffer management method according to any one of claims 1 to 8.

Images