Thread priority adjustment method, electronic device and readable storage medium

Abstract

The present application relates to the technical field of computers. Provided are a thread priority adjustment method, an electronic device and a readable storage medium, which solve the problem of audio playback anomalies caused by the mismatch between the production rate and the playback rate of audio data. The method comprises: during the process of a terminal playing back an audio via a first application, acquiring the amount of data in a target buffer area, the target buffer area being used for buffering audio data via a first thread of the first application; and when the amount of data in the target buffer area is lower than a threshold, on the basis of a shortage level correlated to the amount of data in the target buffer area, adjusting the priority of the first thread, wherein the amount of data in the target buffer area is negatively correlated with the shortage level, and the priority of the first thread is positively correlated with the shortage level.

Description

A method for adjusting thread priority, an electronic device, and a readable storage medium.

[0001] This application claims priority to Chinese Patent Application No. 2024108084418, filed on June 20, 2024, entitled "A method for adjusting thread priority, an electronic device and a readable storage medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a method for adjusting thread priority, an electronic device, and a readable storage medium. Background Technology

[0003] Audio playback is one of the core functions of a mobile device. However, during audio playback, a phenomenon similar to "pop" noise sometimes occurs, severely impacting the user's auditory experience. A common cause of this is a mismatch between the audio data production rate and the playback rate, leading to abnormal audio playback. For example, if the application writes audio data to the audio data buffer too slowly, there may be no playable audio data in the buffer, resulting in the pop noise. This not only disrupts the continuity and integrity of the audio but also causes significant user discomfort. Summary of the Invention

[0004] This application provides a method for adjusting thread priority, an electronic device, and a readable storage medium, which solves the problem of audio playback abnormalities caused by a mismatch between the audio data production rate and the playback rate.

[0005] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0006] Firstly, a method for adjusting thread priority is provided, which may include:

[0007] During the process of playing audio through the first application on the terminal, the amount of data in the target buffer is obtained. The target buffer is used to cache audio data in the first thread of the first application. If the amount of data in the target buffer is lower than the threshold, the priority of the first thread is adjusted based on the scarcity level related to the amount of data in the target buffer. The amount of data in the target buffer is negatively correlated with the scarcity level, and the priority of the first thread is positively correlated with the scarcity level.

[0008] By employing the above technical solution, the terminal obtains the amount of data in the audio data buffer. When the amount of data in the buffer is below a threshold, the priority of the audio data producer thread is dynamically increased based on a scarcity level related to the amount of data in the buffer. In this way, dynamically adjusting the priority of the audio data producer thread according to the scarcity level of the audio data buffer ensures that audio data can be generated in a timely manner. This guarantees that there is sufficient data in the audio data buffer for scheduling, thereby avoiding noise during audio playback. Furthermore, this solution ensures that the audio data producer thread is scheduled in a timely manner even under high or overload conditions, preventing playback noise problems.

[0009] In conjunction with the first aspect, in one possible implementation, before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the above method may further include: determining that the first thread is currently a normal non-real-time task.

[0010] In conjunction with the first aspect, another possible implementation involves adjusting the priority of the first thread. Specifically, this could include changing the priority of the first thread from its current first priority to a second priority, making the first thread a real-time task after the priority adjustment, and ensuring that the second priority is positively correlated with the scarcity level. In this way, the priority of the audio data producer thread is adjusted according to the scarcity level of the audio data buffer, guaranteeing that audio data can be generated in a timely manner.

[0011] In conjunction with the first aspect, in another possible implementation, before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the above method may further include: determining a first flag bit as a first value and a second flag bit as a first value; wherein the first flag bit is used to indicate whether the target task is running, the first flag bit being a first value is used to indicate that the target task is not running, and the target task is used to determine whether the priority of the wake-up source thread of the first thread needs to be increased; the second flag bit is used to indicate whether the priority of the first thread has been increased, and the second flag bit being a first value is used to indicate that the priority of the first thread has not been increased.

[0012] For example, after adjusting the priority of the first thread, the second flag can also be set to a second value, which indicates that the priority of the first thread has been increased.

[0013] This effectively prevents the repeated execution of tasks, reduces the number of system scheduling operations, and optimizes system performance and power consumption.

[0014] In conjunction with the first aspect, in another possible implementation, the above method may further include: after adjusting the priority of the first thread for a first preset time, starting the target task to perform the following operations: obtaining the first running time of the first thread, the first running time being the running time of the first thread from the moment of creation to the moment when the target task is determined to start; if the first running time is equal to the second running time, adjusting the priority of the second thread; the second running time being the running time of the first thread from the moment of creation to the moment of determination, the moment of determination being the moment when the amount of data in the target buffer is lower than a threshold; wherein, the second thread is the thread among the wake-up source threads of the first thread that meets the wake-up conditions; the wake-up conditions include one or more of the following conditions: the proportion of times the first thread is woken up is greater than a threshold, it is a normal non-real-time task, and the third flag bit is a first value; the third flag bit is used to indicate whether the priority of the wake-up source thread has been increased, and the third flag bit being a first value is used to indicate that the priority of the wake-up source thread has not been increased.

[0015] For example, after starting the target task, a first flag can be set to a second value, whereby the first flag being set to the second value indicates that the target task is running.

[0016] In this way, when the audio data producer thread is not scheduled, the priority of the wake-up source thread is increased, effectively avoiding the blocking of the audio data producer thread scheduling by low-priority tasks.

[0017] In conjunction with the first aspect, in another possible implementation, the above method may further include: adjusting the priority of the first thread to the first priority if the first running time and the second running time are not equal.

[0018] In conjunction with the first aspect, another possible implementation involves adjusting the priority of the second thread. Specifically, this could include raising the priority of the second thread from the current third priority to the fourth priority, making the second thread a real-time task. In this way, by increasing the priority of the wake-up source thread, the scheduling of the audio data producer thread is effectively avoided from being blocked by low-priority tasks. This further ensures that the audio data producer thread can be scheduled in a timely manner.

[0019] In conjunction with the first aspect, in another possible implementation, the above method may further include: after a second preset time following the adjustment of the priority of the second thread, adjusting the priority of the first thread to the first priority and adjusting the priority of the second thread to the third priority.

[0020] For example, the target task can be considered complete after "adjusting the priority of the first thread to the first priority when the first and second running times are not equal," or after "adjusting the priority of the second thread," or even after "adjusting the priority of the first thread to the first priority and the priority of the second thread to the third priority." Upon completion of the target task, a first flag is set to a first value to indicate that the target task has not run.

[0021] After adjusting the priority of the first thread to the first priority, the second flag can also be set to the first value. The second flag being the first value is used to indicate that the priority of the first thread has not been promoted.

[0022] After adjusting the priority of the second thread to the third priority, the third flag corresponding to the second thread can be set to the first value. The third flag corresponding to the second thread being set to the first value is used to indicate that the priority of the second thread has not been increased.

[0023] In this way, the phenomenon of other threads deteriorating due to prolonged occupation of large amounts of processor resources can be effectively avoided.

[0024] In conjunction with the first aspect, in another possible implementation, before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the method may further include: determining that the current scenario is not a preset scenario; wherein the preset scenario includes one or more of the following scenarios: the audio playback progress bar is dragged by the user, audio playback ends, audio is played muted, and audio is faded out. Thus, by identifying the playback scenario, scenarios that will not cause noise are filtered out, reducing redundant priority-boosting operations.

[0025] In conjunction with the first aspect, in another possible implementation, the current scenario is determined not to be a preset scenario if one or more of the following conditions are met: the difference between the first and second moments is greater than a threshold; the first moment is the moment when the predetermined interface is called; the second moment is the moment when the amount of data in the target buffer is determined to be lower than the threshold; the energy of the audio being played at the current moment is greater than the preset energy of the audio being played; and the volume value of the terminal at the current moment is not 0. Thus, by identifying the playback scenario, scenarios that will not cause noise are filtered out, reducing redundant priority-boosting operations.

[0026] Secondly, an apparatus is provided that implements the method described in the first aspect. The function of this apparatus can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the described functions, such as an acquisition unit or module, a processing unit or module, or a storage unit or module.

[0027] Thirdly, an electronic device is provided, comprising: a processor; a memory; and a computer program, wherein the computer program is stored in the memory and, when executed by the processor, causes the electronic device to perform the method described in the first aspect above.

[0028] Fourthly, a computer-readable storage medium is provided, comprising a computer program that, when executed on an electronic device, enables the electronic device to perform the method described in the first aspect.

[0029] Fifthly, a computer program product containing instructions is provided that, when run on an electronic device, enables the electronic device to perform the method described in the first aspect.

[0030] In a sixth aspect, embodiments of this application provide a chip including a processor, the processor being configured to invoke a computer program in memory to perform the method described in the first aspect.

[0031] It is understood that the beneficial effects achieved by the apparatus described in the second aspect, the electronic device described in the third aspect, the computer-readable storage medium described in the fourth aspect, the computer program product described in the fifth aspect, and the chip described in the sixth aspect can be referred to the beneficial effects in the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0032] Figure 1 is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0033] Figure 2 is a software structure block diagram of a terminal provided in an embodiment of this application;

[0034] Figure 3 is a flowchart illustrating a thread priority adjustment method provided in an embodiment of this application;

[0035] Figure 4 is a schematic diagram of a thread priority adjustment process provided in an embodiment of this application;

[0036] Figure 5 is a flowchart illustrating another thread priority adjustment method provided in an embodiment of this application;

[0037] Figure 6 is a flowchart illustrating another thread priority adjustment method provided in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0039] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0040] In the following description, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0041] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0042] Audio playback is one of the core functions of a mobile device. However, during audio playback, a phenomenon called "pop" noise sometimes occurs, severely impacting the user's auditory experience. A common root cause of this problem is called XRun, which is a mismatch between the audio data production rate and the playback rate, leading to abnormal audio playback. Specifically, this could be underrun or overrun. For example, underrun refers to the application not writing audio data to the audio data buffer fast enough, resulting in no playable audio data in the buffer during playback. This phenomenon is called "underrun" and causes popping noise during audio playback. Similarly, overrun refers to the application not reading audio data from the buffer fast enough, causing data loss during recording due to data overflow. This phenomenon is called "overrun." These phenomena not only disrupt the continuity and integrity of the audio but also cause significant user discomfort.

[0043] To address the aforementioned technical problems, a solution is provided, describing an optimization method for audio noise issues arising during audio transmission in electronic devices when audio data scheduling is untimely. The main method involves performing different operations on the audio data transmission thread by monitoring the audio data buffer value at different times. Specifically: First, the current priority of the audio data transmission thread and its corresponding processor core are recorded. Then, the amount of data in the audio data buffer is continuously monitored. If the amount of data in the audio data buffer is lower than a set standard, the priority of the audio data transmission thread is increased. If the amount of data in the audio data buffer is still insufficient, the audio data transmission thread is migrated to a processor core with higher processing power. After this, if the amount of data in the audio data buffer is still insufficient, the operating frequency of the processor containing the audio data transmission thread is further increased. Finally, after the audio task playback is completed (i.e., playback stops), the priority of the audio data transmission thread and the processor state are restored to their state before task execution.

[0044] As can be seen, the above solution, when increasing the priority of the audio data transfer thread fails to resolve the audio noise issue, attempts to schedule audio data by migrating cores and increasing the operating frequency of the processor hosting the audio data transfer thread. However, it overlooks the limitations of core migration and frequency increase under high load conditions. In other words, when audio noise occurs, the system is usually already under high load, or even full load. At this point, the processor has virtually no remaining computing power and is typically operating at its highest frequency. In this scenario, the core migration or frequency increase operations performed after increasing the priority of the audio data transfer thread are not very meaningful. In other words, it cannot effectively schedule audio data, and noise may still occur, affecting the user's listening experience.

[0045] Furthermore, the wake-up of some audio data transmission threads depends on other threads within the audio application (such as the audio decoding thread). If only the priority of the audio data transmission thread is increased, this thread may still be blocked by lower-priority internal dependent threads, thus failing to be scheduled in a timely manner. Moreover, in the above solution, increasing the priority / relocation / frequency of the audio data transmission thread is only performed when the audio task stops playing. This will cause the audio data transmission thread to occupy a large amount of processor resources for a long time, potentially degrading the running state of other threads. In some scenarios, such as when the user drags the progress bar during audio playback, or when playing audio at 0 volume, no noise will occur even if there is insufficient audio data in the audio data buffer. If the priority / relocation / frequency of the audio data transmission thread is still increased in these scenarios, it may cause unnecessary resource allocation.

[0046] To address the aforementioned technical problems, this application provides a method for adjusting thread priority. Specifically, the terminal obtains the amount of data in the audio data buffer, and when the amount of data in the audio data buffer is below a threshold, dynamically increases the priority of the audio data producer thread based on a scarcity level related to the amount of data in the audio data buffer. In this way, dynamically adjusting the priority of the audio data producer thread according to the scarcity level of the audio data buffer ensures that audio data can be generated in a timely manner, thus ensuring that there is sufficient data in the audio data buffer for scheduling, thereby avoiding noise during audio playback. Furthermore, this solution can ensure timely scheduling of the audio data producer thread even under high or even overloaded system conditions, preventing playback noise problems.

[0047] Furthermore, if the audio data producer thread is not scheduled in a timely manner after adjusting its priority, the priority of its internal dependent threads (such as internal threads of the audio application, described in this application as wake-up source threads) can be increased. This further ensures that the audio data producer thread can be scheduled in a timely manner. For audio data producer threads with increased priority, or audio data producer threads with increased priority and their internal dependent threads, their priorities should be restored in a timely manner, rather than being kept in a high-priority state. This can effectively avoid the phenomenon of other threads deteriorating due to prolonged occupation of large amounts of processor resources. Scenarios where the audio data buffer is insufficient but no playback noise is generated can be identified. For these scenarios, the priority adjustment process can be omitted, improving the control precision of thread priority adjustment.

[0048] In some embodiments, the terminal in this application can be a device capable of playing audio, including but not limited to mobile phones, tablets, laptops, ultra-mobile personal computers (UMPCs), handheld computers, netbooks, smartwatches, televisions, and other devices that support audio playback. This application does not impose any limitations on this. The solution in this application is mainly used in scenarios where users play audio on their daily devices, and can be used to improve the smoothness of audio playback, reduce the chance of playback stuttering, and avoid playback noise.

[0049] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0050] Referring to Figure 1, taking a mobile phone as an example, Figure 1 is a schematic diagram of the hardware structure of a mobile phone provided in an embodiment of this application. As shown in Figure 1, the mobile phone may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0051] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the mobile phone. In other embodiments of this application, the mobile phone may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0052] Processor 110 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0053] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0054] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0055] In some embodiments, the processor 110 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0056] It is understood that the interface connection relationships between the modules illustrated in the embodiments of the present invention are merely illustrative and do not constitute a limitation on the structure of the mobile phone. In other embodiments of this application, the mobile phone may also adopt different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0057] The charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 receives charging input from the wired charger via the USB interface 130. In some wireless charging embodiments, the charging management module 140 receives wireless charging input via the phone's wireless charging coil. While charging the battery 142, the charging management module 140 can also supply power to the phone via the power management module 141.

[0058] The power management module 141 connects the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140, providing power to the processor 110, internal memory 121, display screen 194, camera 193, and wireless communication module 160, etc. The power management module 141 can also monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage current, impedance). In some other embodiments, the power management module 141 may also be located within the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may be located in the same device.

[0059] The wireless communication function of a mobile phone can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0060] In some embodiments, antenna 1 of the mobile phone is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling the mobile phone to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technology, etc. The GNSS may include Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), BeiDou Navigation Satellite System (BDS), Quasi-Zenith Satellite System (QZSS), and / or Satellite Based Augmentation Systems (SBAS).

[0061] The mobile phone implements its display function through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0062] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a Miniled LED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the mobile phone may include one or N displays 194, where N is a positive integer greater than 1.

[0063] Mobile phones can achieve shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0064] Video codecs are used to compress or decompress digital video. A mobile phone can support one or more video codecs. This allows the phone to play or record videos in various encoding formats, such as Moving Picture Experts Group (MPEG) 1, MPEG2, MPEG3, MPEG4, etc.

[0065] The external storage interface 120 can be used to connect an external storage card, such as a Micro SD card, to expand the phone's storage capacity. The external storage card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external storage card.

[0066] The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback, video playback, etc.), etc. The data storage area may store data created during the use of the mobile phone (such as audio data, phonebook, etc.). Furthermore, the internal memory 121 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the mobile phone by running instructions stored in the internal memory 121 and / or instructions stored in memory located in the processor. For example, in this embodiment, the processor 110 may be used to execute instructions stored in the internal memory 121 to implement the thread priority scheduling method provided in this embodiment.

[0067] Mobile phones can achieve audio functions through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor. For example, playing music and video audio.

[0068] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0069] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. Mobile phones can use the speaker 170A to listen to music or make hands-free calls.

[0070] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When answering a phone call or voice message, the receiver 170B can be brought close to the user's ear to hear the voice.

[0071] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C. A mobile phone can have at least one microphone 170C. In some embodiments, a mobile phone can have two microphones 170C, which, in addition to collecting sound signals, can also perform noise reduction. In other embodiments, a mobile phone can have three, four, or more microphones 170C, enabling sound signal collection, noise reduction, sound source identification, and directional recording, among other functions.

[0072] The 170D headphone jack is used to connect wired headphones. The 170D headphone jack can be a USB 130 interface or a 3.5mm Open Mobile Terminal Platform (OMTP) standard interface, a CTIA (Cellular Telecommunications Industry Association of the USA) standard interface.

[0073] The terminal's software system can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application's embodiment uses a layered architecture Android... Taking the system as an example, the software system of the terminal will be described exemplarily.

[0074] As shown in Figure 2, taking a mobile phone as an example, Figure 2 is a software structure block diagram of a mobile phone according to an embodiment of this application.

[0075] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, [the following is omitted as the text is incomplete and likely refers to a specific implementation or feature]. The system is divided into four layers, from top to bottom: the application layer, the application framework layer (hereinafter referred to as the framework layer), the hardware abstraction layer (HAL), and the kernel layer.

[0076] The application layer can include a series of application packages. As shown in Figure 2, an application package can include a music application. Application packages can also include video applications, game applications, short video applications, and other applications.

[0077] As an example, after an application starts at the application layer, a corresponding thread can be created. For instance, in applications capable of generating audio, such as the aforementioned music, video, game, or short video applications, a corresponding thread can be created upon startup. This thread may include an audio data producer thread, an audio data consumer thread, etc. The audio data producer thread, also known as the audio data transmission thread or simply the audio thread, is responsible for writing the audio data generated by the application into the audio data buffer. This embodiment does not limit the specific description of this thread. Other threads can also be created, such as threads that can wake up the audio data producer thread, referred to as the wake-up source thread. The wake-up source thread can be an internal thread of the application, such as a thread within the aforementioned music application, primarily used to listen for specific events (such as user actions, system events, or timer triggers) and wake up the audio data producer thread based on these events.

[0078] The application framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The application framework layer includes predefined functions. For example, it can include audio tracks and media players, which can be part of the audio framework, providing developers with service interfaces for recording and playing audio. Specifically, the audio track can be called by third-party applications to transfer audio data, while the media player can be called by system applications to transfer audio data.

[0079] As an example, the application framework layer may also include an anonymous audio data cache. This anonymous audio data cache is used to cache audio data passed by the audio data producer thread. The audio data consumer thread can consume (i.e., use or process) the cached audio data in the audio data cache; that is, the audio data consumer thread can read cached audio data from the anonymous audio data cache and pass the read audio data to the HAL layer. The anonymous audio data cache can be the target cache in this application.

[0080] As an example, the application framework layer can also include a noise prediction module. This module can be used to determine whether the amount of data in the target buffer is less than a threshold, and also to determine whether the current scenario is a preset scenario. Furthermore, if it is determined that the amount of data in the target buffer is less than the threshold, or if it is determined that the amount of data in the target buffer is less than the threshold and the current scenario is not a preset scenario, corresponding information is sent to the kernel layer so that the kernel layer can adjust the priority of the relevant threads.

[0081] As an example, the HAL layer can include a main HAL. The main HAL can be used to receive audio data from the audio data consumer thread and then pass the received audio data to the kernel layer.

[0082] The kernel layer is the layer between hardware and software. It may contain the Advanced Linux Sound Architecture (ALSA) and a noise cancellation module. This noise cancellation module can be used to adjust the priorities of relevant threads. Additionally, it can be used to restore the priorities of relevant threads, such as restoring the priority of a thread after 20 milliseconds. Relevant threads may include audio data producer threads and wake-up source threads.

[0083] As an example, the kernel layer may also include an audio data buffer used to cache audio data from the HAL layer. Finally, the audio data is transferred from the kernel layer to relevant hardware layer modules, such as effects and direct memory access (DMA), to enable audio playback.

[0084] The method for adjusting thread priority provided in the embodiments of this application will now be described with reference to the accompanying drawings.

[0085] Figure 3 is a flowchart illustrating a thread priority adjustment method provided in an embodiment of this application. As shown in Figure 3, the method may include:

[0086] S301. During the process of the first application playing audio, the terminal obtains the amount of data in the target buffer.

[0087] The first application can be an application that can play audio, such as a music application, a game application, or a video application.

[0088] The target buffer is used by the first thread of the first application to cache audio data, or in other words, for the first thread of the first application to write audio data. This audio data is the audio data of the first application. The first thread can be the aforementioned audio data producer thread. The target buffer can be included in the terminal's frame layer. For example, the target buffer can be an anonymous audio data buffer in the terminal's frame layer, or it can be referred to as an audio data buffer.

[0089] The amount of data in the target buffer can refer to the amount of audio data currently cached in the target buffer, or the amount of audio data remaining in the target buffer.

[0090] In this embodiment, as an example, the terminal plays audio while the user is using the first application. Specifically, after the terminal receives the user's operation to launch the first application, threads related to the first application are created, including an audio data producer thread (i.e., the aforementioned first thread) and an audio data consumer thread (the audio data consumer thread can be the third thread in this application). Subsequently, after the terminal receives the user's operation to trigger audio playback, in response to this operation, the terminal's first application can call the corresponding playback interface to transmit audio data. The transmission of audio data includes the audio data producer thread writing the audio data of the first application into the aforementioned target buffer. The transmission of audio data may also include the audio data consumer thread reading audio data from the aforementioned target buffer and passing it through the lower layer to the relevant hardware, thereby realizing audio playback.

[0091] The above explanation uses the example of relevant threads being created after the first application starts. In other examples, the aforementioned relevant threads, such as audio data producer threads and audio data consumer threads, may also be created after receiving a user's trigger to play audio. This embodiment of the application does not impose specific limitations here.

[0092] The terminal can monitor the data volume of the aforementioned target buffer while the first application is playing audio. This monitoring of the data volume of the target buffer can be performed by the terminal's framework layer.

[0093] As an example, a terminal, such as its framework layer, can periodically retrieve the data volume of a target buffer during the playback of audio in a first application. For instance, the terminal's framework layer can retrieve the data volume of the target buffer at predetermined intervals to monitor the remaining data in the target buffer.

[0094] As another example, a terminal, such as its framework layer, can also acquire the amount of data in the target buffer when preset conditions are met during the playback of audio by the first application. For example, the preset conditions may include before the audio data consumer thread reads data from the target buffer. In other words, the terminal, such as its framework layer, can acquire the amount of data in the target buffer before the audio data consumer thread reads audio data from the target buffer, thereby enabling the monitoring of the remaining amount in the target buffer.

[0095] S302. The terminal determines whether the amount of data in the target cache is lower than the threshold.

[0096] The threshold can be a predefined minimum safe data amount required in the target buffer to ensure playback without noise. It is understood that if the data amount in the target buffer is higher than the threshold, it can be considered that there is sufficient audio data in the target buffer. However, if the data amount in the target buffer is lower than the threshold, it can be considered that the remaining audio data in the target buffer is insufficient, and noise may occur. Therefore, the solution provided in the embodiments of this application can be implemented to avoid the occurrence of noise.

[0097] In this embodiment, after obtaining the amount of data in the target buffer, the terminal, such as its framework layer, can compare the current amount of data in the target buffer with a threshold to determine whether the remaining space in the target buffer is sufficient. If the amount of data in the current target buffer is lower than the threshold, it indicates that the remaining space in the current target buffer is insufficient. The terminal can then perform the following steps to adjust the priority of relevant threads to ensure that sufficient audio data is written to the target buffer. If the amount of data in the current target buffer is higher than the threshold, the terminal can re-execute S301.

[0098] S303. The terminal determines whether the current scene is a preset scene.

[0099] The preset scenarios may include one or more of the following: the progress bar of the audio playback is dragged by the user, the audio playback ends, the audio is played silently, the audio is faded out, etc.

[0100] In this implementation, when the terminal, such as the terminal's framework layer, determines that the amount of data in the target buffer is below a threshold, the terminal, such as the terminal's framework layer, can identify the current scenario based on one or more of the following: the call status of a predetermined interface, the energy of the played audio, and the terminal's volume. This allows them to determine whether the current scenario is a preset scenario, i.e., a scenario that will not produce playback noise. If the current scenario is a preset scenario, i.e., a scenario that will not produce playback noise, then there is no need to adjust the priority of the relevant threads, and S301 can be re-executed. If the current scenario is not a preset scenario, i.e., the current scenario may produce playback noise, then S304 can continue to be executed.

[0101] The specific implementation of S303 will be described in detail in the embodiment shown in Figure 6 below, and will not be repeated here.

[0102] S303 is an optional step. If S303 is not executed, the terminal may execute S304 if it determines that the amount of data in the target buffer is lower than the threshold.

[0103] Additionally, it should be noted that the above embodiments are described using the example of executing S301-S302 first, followed by S303. In some other embodiments, S303 may be executed first, followed by S301-S302. For example, during the playback of audio in the first application, the terminal may first determine whether the current scene is a preset scene. If it is determined that the current scene is not a preset scene, the amount of data in the target buffer is then obtained, and it is determined whether it is below a threshold. After determining that it is below the threshold, S304 is executed. In some other embodiments, S301-S302 and S303 may also be executed simultaneously. This application does not impose specific restrictions on the execution order of S301-S302 and S303 in this embodiment.

[0104] S304. The terminal determines whether the first flag bit is the first value and whether the second flag bit is the first value.

[0105] In this embodiment, after determining that the priority of a relevant thread needs to be adjusted, the terminal can first determine whether the relevant thread has already had its priority increased, and whether there is a corresponding task currently deciding whether to adjust the priority of the relevant thread. Specifically, the terminal can maintain corresponding flags to mark whether the relevant thread has already had its priority increased and whether there is a corresponding task currently deciding whether to adjust the priority of the relevant thread. This allows the terminal to determine whether the relevant thread has already had its priority increased and whether there is a corresponding task currently deciding whether to adjust the priority of the relevant thread after determining that the priority of the relevant thread needs to be adjusted, by querying the corresponding flags.

[0106] Specifically, the aforementioned flag bits may include a first flag bit and a second flag bit. The first flag bit can be used to indicate whether the target task is running. A first value for the first flag bit indicates that the target task is not running, and a second value for the first flag bit indicates that the target task is running. This target task is used to determine whether the wake-up source thread of the first thread (i.e., the aforementioned audio data producer thread) needs to be prioritized. A detailed description of the target task will be provided in the embodiment shown in Figure 5 below, and will not be repeated here.

[0107] The second flag indicates whether the priority of the first thread (i.e., the aforementioned audio data producer thread) has been increased. A first value for the second flag indicates that the priority of the first thread has not been increased. A second value for the second flag indicates that the priority of the first thread has been increased.

[0108] The terminal can determine whether the first flag bit and the second flag bit are the first value to determine whether the relevant thread has been promoted in priority and whether there is a corresponding task that is deciding whether the priority of the relevant thread needs to be adjusted.

[0109] If both the first and second flags are the first value, it indicates that the relevant thread has not been prioritized and there is no corresponding task deciding whether to adjust the priority of the relevant thread. In this case, the following steps can continue. If one or both of the first and second flags are not the first value but the second value, it indicates that the relevant thread has been prioritized and / or there is a corresponding task deciding whether to adjust the priority of the relevant thread. In this case, S301 can be re-executed.

[0110] As an example, the above S304 can be specifically executed by the terminal's kernel layer. For instance, after the terminal's framework layer determines that the amount of data in the target buffer is below a threshold and the current scenario is not a preset scenario, the terminal's framework layer can transmit target parameters to the terminal's kernel layer via a system call. These target parameters may include the identifier of the first thread, i.e., the audio data producer thread, such as its process ID. After receiving the identifier of the audio data producer thread, the terminal's framework layer can obtain the first and second flag bits corresponding to that identifier. Then, the terminal's kernel layer can determine whether the first and second flag bits are the first value. If the first flag bit is the first value and the second flag bit is also the first value, the following S305 can be executed. If the first flag bit is the second value and / or the second flag bit is the second value, the terminal's kernel layer can end this task and wait for the next call, i.e., wait for the next call from the framework layer.

[0111] The first value and the second value mentioned above can be two different values. For example, the first value is false and the second value is true. Or, the first value is 1 and the second value is 0.

[0112] The identifier of the aforementioned audio data producer thread, such as its process ID, can be recorded after its creation. For example, after the audio data producer thread is created, the terminal, such as the application layer, can record the identifier of the audio data producer thread, such as its thread ID. Then, the application layer can send the audio data producer's identifier to the terminal's framework layer. Upon receiving the identifier, the terminal's framework layer can record it and, if it determines that the amount of data in the target buffer is below a threshold and the current scenario is not a preset scenario, pass the audio data producer thread's identifier as a parameter to the terminal's kernel layer via a system call for use by the kernel layer.

[0113] Additionally, the aforementioned target parameters may also include a scarcity level related to the amount of data in the target buffer. The terminal, such as its framework layer, can determine the scarcity level related to the amount of data in the current target buffer if it is determined that the amount of data in the target buffer is less than a threshold. If it is determined that the amount of data in the target buffer is less than the threshold, and the current scenario is not a preset scenario, the kernel layer of the terminal is passed the identifier of the audio data producer thread and the scarcity level related to the amount of data in the current target buffer as parameters via a system call for use by the kernel layer.

[0114] The amount of data in the target cache is negatively correlated with the scarcity level.

[0115] As an example, the correspondence between the data volume of the target buffer and the scarcity level can be pre-stored in the terminal. The specific correspondence can be set according to the needs of the actual application scenario, and this embodiment does not impose specific limitations here. For example, the scarcity level can include 1 to 3 levels, with the scarcity degree gradually increasing. That is, the first scarcity level has the lowest scarcity degree, and the third scarcity level has the highest scarcity degree. Then, the terminal, such as the terminal's framework layer, can determine the scarcity level corresponding to the current data volume of the target buffer based on the correspondence between the data volume of the target buffer and the scarcity level when it is determined that the data volume in the target buffer is less than a threshold.

[0116] For example, referring to Figure 4, the process of determining the scarcity level is illustrated using the percentage of memory occupied by stored audio data in the target buffer as a representation of the total memory in the target buffer, with a threshold of 60%. It can be understood that 60% refers to the percentage of memory occupied by stored audio data in the total memory of the target buffer being 60%. Specifically, after the terminal, such as its framework layer, obtains the current data volume in the target buffer, it can determine whether the current data volume in the target buffer is less than 60%. If it is less than 60%, it can be considered that there is insufficient audio data in the current target buffer. The terminal's framework layer can determine the current data volume in the target buffer based on the correspondence between the data volume in the target buffer and the scarcity level. For example, the correspondence between the data volume in the target buffer and the scarcity level includes: when the data volume in the target buffer is 60%-40%, the scarcity level is the first scarcity level; when the data volume in the target buffer is 40%-20%, the scarcity level is the second scarcity level; and when the data volume in the target buffer is 20%-0%, the scarcity level is the third scarcity level. If the current target buffer contains 35% of the data, then the shortage level can be determined as the second shortage level.

[0117] S305. The terminal adjusts the priority of the first thread based on the scarcity level related to the amount of data in the target buffer.

[0118] Among them, the priority of the first thread is positively correlated with the scarcity level.

[0119] Once the terminal determines that the relevant thread has not been prioritized and there is no corresponding task currently deciding whether to adjust the priority of the relevant thread, the terminal can adjust the priority of the first thread, namely the audio data producer thread. In this embodiment, the terminal can adjust the priority of the audio data producer thread based on the scarcity of audio data in the target buffer. Specifically, the higher the scarcity of audio data in the target buffer, the higher the priority of the adjusted audio data producer thread. That is, the greater the scarcity level, the higher the priority of the adjusted audio data producer thread.

[0120] Understandably, different types of tasks have different priorities. For example, real-time (RT) tasks have a higher priority than regular non-real-time (CFS) tasks. Tasks of the same type can also have different priorities. The range of a task's priority value can be preset; the lower the value, the higher the priority. For example, the priority value range for a regular non-real-time task can be [100, 140], while the priority value range for a real-time task can be [0, 99]. Specifically, a regular non-real-time task with a priority value of 140 has a lower priority than a regular non-real-time task with a priority value of 100. Similarly, a real-time task with a priority value of 99 has a lower priority than a real-time task with a priority value of 0.

[0121] In one possible implementation, it can be assumed that when the task type is a real-time task, its priority is already relatively high, and the priority of the corresponding thread does not need to be adjusted. However, when the task type is a normal non-real-time task, its priority is relatively low, and the priority of the corresponding thread needs to be adjusted. Based on this, after determining that the relevant thread has not had its priority increased and that there is no corresponding task currently deciding whether to adjust the priority of the relevant thread, the terminal, such as the terminal's kernel layer, can determine whether the first thread, i.e., the audio data producer thread, is currently a normal non-real-time task. If it is determined that the audio data producer thread is currently a normal non-real-time task, its priority is adjusted from the current first priority to the second priority, so that the first thread after the priority adjustment becomes a real-time task. Furthermore, the adjusted second priority is positively correlated with the scarcity level. That is, the higher the scarcity level, the smaller the value of the adjusted second priority, and the higher the second priority. The correspondence between scarcity level and priority value can be pre-stored in the terminal, and this correspondence is set according to actual needs; this embodiment of the application does not impose specific limitations here.

[0122] For example, assuming the audio data producer thread is currently a regular non-real-time task with a priority value of 130, the correspondence between scarcity levels and priority values ​​is as follows: the first scarcity level corresponds to a priority value of 99, the second scarcity level to a priority value of 98, and the third scarcity level to a priority value of 97. In the terminal, after determining that the audio data producer thread is currently a regular non-real-time task, the kernel layer can adjust the priority value of the audio data producer thread from 130 to 98 based on the obtained scarcity level, such as the second scarcity level. This ensures that the first thread after the priority adjustment becomes a real-time task, and the adjusted second priority is positively correlated with the scarcity level. This example is merely illustrative; the division of scarcity levels and the corresponding priority values ​​can be set according to the needs of the actual scenario, and the finer the granularity of the division, the higher the accuracy of the priority adjustment.

[0123] The above example illustrates the adjustment of the priority of the audio data producer thread when it is currently a regular non-real-time task, and the adjusted audio data producer thread is now a real-time task. In other embodiments, when the audio data producer thread is currently a regular non-real-time task, priority adjustment only needs to ensure that the adjusted priority is higher than the current priority and positively correlated with the scarcity level. For example, if the audio data producer thread is currently a regular non-real-time task with a priority value of 140, and the scarcity level is not very high, the priority value of the audio data producer thread can be adjusted from 140 to 139. In yet another embodiment, priority adjustment can also be performed when the audio data producer thread is currently a real-time task, again only needing to ensure that the adjusted priority is higher than the current priority and positively correlated with the scarcity level. For example, if the audio data producer thread has a priority value of 80, and the scarcity level is relatively high, the priority value of the audio data producer thread can be adjusted from 80 to 79.

[0124] As described in the previous embodiments, the terminal maintains a flag bit to record whether the audio data producer thread has had its priority increased. Therefore, after executing S305, the terminal, such as the terminal's kernel layer, can also set the corresponding flag bit, such as the second flag bit mentioned above, to a second value to indicate that the priority of the audio data producer thread has been increased.

[0125] As described in the preceding embodiments, the wake-up of the audio data producer thread depends on other threads within the application. If only the priority of the audio data producer thread is increased, this thread may be blocked by lower-priority internal dependent threads, thus failing to be scheduled in a timely manner. To avoid this situation, in some embodiments, after executing S305, the following S306 can also be executed.

[0126] In addition, to identify the internal dependent threads blocking the audio data producer thread, such as the wake-up source thread, the terminal can record information about the wake-up source thread, referred to as wake-up source information. This wake-up source information can include: the thread number of the wake-up source thread, the number of times it has called the audio data producer thread, and whether its priority has been increased. The wake-up source information can be recorded in correspondence with the identifier (e.g., thread number) of the audio data producer thread, for example, using a red-black tree in the terminal. The wake-up source information can be reset when it is first determined that there is insufficient audio data in the target buffer, the identifier of the audio data producer thread changes, or the total number of times the recorded audio data producer thread has been woken up exceeds a threshold. For example, the terminal's kernel layer can reset the corresponding wake-up source information in the kernel red-black tree when it first receives target parameters from the framework layer, or when it determines that the identifier of the audio data producer thread carried in the target parameters has changed, or when the total number of times the recorded audio data producer thread has been woken up exceeds a threshold (e.g., 100 times).

[0127] If the target parameters are received for the first time and the identifier of the audio data producer thread has not changed, the terminal can also obtain the wake-up source thread that woke up the audio data producer thread during this process, such as its identifier (e.g., thread number). If it is determined that the wake-up source thread and the audio data producer thread belong to the same parent process, it is recorded in the kernel red-black tree, and the number of times the wake-up source thread wakes up the audio data producer thread is incremented, for use in subsequent decisions on whether to increase the priority of the wake-up source thread.

[0128] S306. Start the timer. The timer's timing period is the first preset time. After the timer's timing period expires, start the target task.

[0129] As described in the foregoing embodiments, the target task is used to determine whether the priority of the wake-up source thread of the first thread needs to be increased. The first preset time can be regarded as a time window (e.g., 20 milliseconds) provided by the terminal after adjusting the priority of the first thread (i.e., the audio data producer thread), which is used to trigger the start of the execution of the target task. By executing the target task, it can be decided whether the priority of the wake-up source thread of the audio data producer thread needs to be adjusted.

[0130] In some embodiments, after the terminal adjusts the priority of the audio data producer thread, the terminal, such as its kernel layer, can start a timer with a first preset time. After the first preset time, a task for determining whether the wake-up source thread of the audio data producer thread needs to be prioritized can be automatically started, i.e., the target task can be automatically started. This target task can be a kernel job task, or a kernel work queue, meaning it can be placed in a work queue within the kernel layer for execution. In other words, the terminal can execute the target task within the kernel layer. In other embodiments, the target task can also be triggered in other ways, such as user-mode application programming interface calls, semaphores, or event mechanisms, which are not limited herein.

[0131] For example, after adjusting the priority of the audio data producer thread, the terminal can start a kernel work queue that will be executed 20 milliseconds later, so that the target task can be executed 20 milliseconds after the priority of the audio data producer thread is adjusted.

[0132] The specific description of the target task will be provided in detail in the embodiment shown in Figure 5 below.

[0133] After S306, the current process ends, and S301 can be executed again.

[0134] By employing the above technical solution, the terminal obtains the amount of data in the audio data buffer. When the amount of data in the buffer is below a threshold, the priority of the audio data producer thread is dynamically increased based on a scarcity level related to the amount of data in the buffer. In this way, dynamically adjusting the priority of the audio data producer thread according to the scarcity level of the audio data buffer ensures that audio data can be generated in a timely manner. This guarantees that there is sufficient data in the audio data buffer for scheduling, thereby avoiding noise during audio playback. Furthermore, this solution ensures that the audio data producer thread is scheduled in a timely manner even under high or overload conditions, preventing playback noise problems.

[0135] Figure 5 is a flowchart illustrating another thread priority adjustment method provided in an embodiment of this application. This flowchart describes the execution flow of the target task. After the timer started by the terminal expires, the terminal can start the target task and execute the flow shown in Figure 5. This flow may include:

[0136] S501, Set the first flag bit to the second value.

[0137] As described in the previous embodiment, the terminal maintains a flag to record whether a corresponding task is currently deciding whether to adjust the priority of the relevant thread. Here, the task refers to the aforementioned target task, and the relevant thread refers to the wake-up source thread of the audio data producer thread. In other words, the terminal maintains a flag, called the first flag, to record whether the target task is running and to determine whether to prioritize the wake-up source thread of the audio data producer thread. Therefore, after the terminal starts the target task, the first flag can be set, such as by setting it to a second value, to indicate that a decision-making process for prioritizing the wake-up source thread of the audio data producer thread is underway, thus avoiding re-execution of the target task.

[0138] For example, the first flag bit mentioned above can be a run flag bit. The terminal, such as the terminal's kernel layer, can set the run flag bit of the target task, or the kernel work queue, to the second value.

[0139] S502. Determine whether the first thread has not been scheduled.

[0140] It is understandable that in the above embodiments, the terminal adjusts the priority of the first thread, i.e., the audio data producer thread, so that it can be scheduled in a timely manner to replenish the audio data in the target buffer. However, it may not be scheduled in a timely manner because its own priority is relatively low, or because the priority of the wake-up source thread that schedules it is relatively low. Therefore, even after adjusting the priority of the first thread, i.e., the audio data producer thread, it may still not be scheduled. In the application embodiment, if the audio data producer thread is not scheduled after its priority is increased, it can try to determine whether it is necessary to adjust the priority of its wake-up thread. Based on this, the terminal, such as the terminal's kernel layer, can determine whether the audio data producer thread has been scheduled before trying to determine whether it is necessary to adjust the priority of its wake-up thread. And if it is determined that the audio data producer thread has not been scheduled, it decides whether it is necessary to adjust the priority of its wake-up thread, such as executing the following S503. If it is determined that the audio data producer thread has been scheduled, in order to avoid the audio data producer thread occupying processor resources for a long time, the priority of the audio data producer thread can be restored, for example, the priority of the audio data producer thread can be adjusted to the first priority.

[0141] Referring back to Figure 4, generally, when the data volume in the target buffer is 100%, meaning the target buffer is full, the audio data producer thread can enter a sleep state. While in a sleep state, the audio data producer thread's runtime will pause. When the audio data in the target buffer is consumed to a threshold, such as 80% (or another value), the audio data producer thread will exit its sleep state and enter a running state, enabling it to write audio data to the target buffer. After the audio data producer thread enters a running state, its runtime will resume.

[0142] Based on this, a terminal, such as its kernel layer, can determine whether the audio data producer thread has been scheduled by judging the runtime of the first thread, i.e., the audio data producer thread. For example, the terminal's kernel layer can determine whether the audio data producer thread has been scheduled by judging whether its runtime increases after its priority is increased.

[0143] As an example, a terminal, such as its kernel layer, can obtain the first and second runtimes of the audio data producer thread. The first runtime can be considered the current runtime of the audio data producer thread, specifically the runtime from its creation to the moment the target task is determined to start. The second runtime is the runtime from the creation of the audio data producer thread to the first runtime. The first runtime could be the moment when the amount of data in the target buffer is determined to be below a threshold; it could also be the moment when the terminal's kernel layer receives the target parameters; or it could be the moment when the kernel layer determines, based on the target parameters, that the priority of the audio data producer thread needs to be adjusted, and then adjusts the priority of the audio data producer thread, etc. This application does not limit the scope of these possibilities. The second runtime can be obtained and saved at these corresponding moments for use in this step.

[0144] Then, the terminal, such as the terminal's kernel layer, can determine whether the first runtime and the second runtime are equal. If the first runtime is not equal to the second runtime, it indicates that the audio data producer thread has been scheduled, and its priority can be restored. If the first runtime is equal to the second runtime, it indicates that the audio data producer thread has not been scheduled, and in this case, the following S503 can be executed.

[0145] S503, Adjust the priority of the second thread.

[0146] The second thread can be any thread among the wake-up source threads of the first thread that meets the wake-up conditions. The wake-up conditions can include one or more of the following: the percentage of times the first thread is woken up is greater than a threshold; the second thread is a normal non-real-time task; and the priority of the wake-up source thread has not been increased.

[0147] The aforementioned thresholds can be preset. If the percentage of times a wake-up source thread wakes up the audio data producer thread (hereinafter simplified as wake-up count) is greater than the threshold, it can be considered that the probability of that wake-up source thread waking up the audio data producer thread is relatively high. The terminal can also maintain another flag to record whether the wake-up source thread has had its priority increased; this flag can be a third flag. Specifically, the third flag for a given wake-up source thread can be either a first value (indicating that the wake-up source thread's priority has not been increased) or a second value (indicating that the wake-up source thread's priority has been increased).

[0148] As an example, in a terminal, once the kernel layer determines that the audio data producer thread has not been scheduled, it can obtain the wake-up counts of all wake-up source threads corresponding to that audio data producer thread, such as reading the wake-up records of the last 100 times in a red-black tree. It then determines whether any wake-up source thread has a wake-up count percentage greater than a threshold, such as 80%. If it is determined that a certain wake-up source thread (i.e., the second thread) has a wake-up count greater than the threshold, it can further determine whether that wake-up source thread is a normal non-real-time task. If the wake-up source thread is a normal non-real-time task, it can further determine whether its priority has been increased. If its priority has not been increased, its priority can be adjusted, such as changing its priority from the third priority to the fourth priority, so that the adjusted wake-up source thread becomes a real-time task and terminates the target task. Furthermore, after adjusting the priority of the wake-up source thread, the third flag corresponding to that wake-up source thread can be set to the second value to indicate that its priority has been increased.

[0149] If the percentage of wake-up calls to the source thread does not exceed the threshold, or the source thread is not a normal non-real-time task, or the source thread has been promoted in priority, then restore the priority of the audio data producer thread, set the first flag bit to the first value, and set the second flag bit to the first value.

[0150] S504. After the second preset time following the adjustment of the priority of the second thread, the priority of the first thread is adjusted to the first priority, and the priority of the second thread is adjusted to the third priority.

[0151] To prevent the audio data producer thread and the wake-up source thread from occupying processor resources for extended periods, their priorities can be restored. For example, in a terminal, the kernel layer could adjust the priority of the second thread by a second preset time, such as 10 milliseconds, before raising the priority of the audio data producer thread to the first priority and the priority of the wake-up source thread (the second thread) to the third priority.

[0152] S505, Set the first flag bit to the second value.

[0153] After S503 is executed, the terminal, such as the terminal's kernel layer, can set the first flag to the second value to indicate that the target task has not been run.

[0154] The execution of S504 and S505 above has no specific order.

[0155] The technical solution provided in this application, if the audio data producer thread is not scheduled in a timely manner after adjusting its priority, can increase the priority of its internal dependent threads (such as internal threads of the audio application, described in this application as wake-up source threads). This further ensures that the audio data producer thread can be scheduled in a timely manner. For audio data producer threads with increased priority, or audio data producer threads with increased priority and their internal dependent threads, their priorities are promptly restored, rather than being kept in a high-priority state. This effectively avoids the phenomenon of other threads deteriorating due to prolonged occupation of large amounts of processor resources.

[0156] Figure 6 is a flowchart illustrating another thread priority adjustment method provided in an embodiment of this application. This flowchart describes the filtering process for a preset scenario. Specifically, it describes the detailed implementation process of S303 described above. This process may include:

[0157] S601. When it is determined that the amount of data in the target cache is lower than the threshold, determine whether a predetermined interface call has occurred within a preset time.

[0158] The predefined interfaces can include a start interface and / or a flush interface. The start interface is the system-exposed interface for initiating audio playback. Typically, the application calls the start interface when the user drags the progress bar or when audio loops and playback ends. The flush interface is the system-exposed interface for clearing the audio buffer. The application usually calls the flush interface when the user drags the progress bar. Since no playback noise occurs even if the audio data in the target buffer is insufficient in scenarios where the audio playback progress bar is dragged by the user or the audio playback ends, the terminal, such as the terminal's framework layer, can filter out scenarios where the audio playback progress bar is dragged by the user or the audio playback ends by determining whether a predefined interface call has occurred within a preset time.

[0159] As an example, when the amount of data in the target buffer is determined to be below a threshold, the terminal, such as the terminal's framework layer, can record the current time as the second moment and obtain the recorded first moment. Then, the terminal, such as the terminal's framework layer, can determine whether the difference between the first and second moments (e.g., subtracting the first moment from the second moment) is greater than the threshold, such as 2 seconds. The first moment is the moment when the application calls the start or flush interface. For example, when the application calls the start or flush interface, the time of the interface call can be recorded through inter-process communication, i.e., recorded as the aforementioned first moment, and stored in the process for easy retrieval when the amount of data in the target buffer is below the threshold. If the difference between the two is less than the threshold, such as 2 seconds, it can be considered that the insufficient audio data remaining in the current target buffer is triggered by normal behavior such as the progress bar being dragged or the audio playback ending, i.e., the current scenario is determined to be the preset scenario. If the difference between the two is greater than the threshold, such as 2 seconds, then the following S602 can continue to be executed.

[0160] S602. Determine whether the energy of the audio being played at the current moment is greater than the preset energy of the audio being played.

[0161] During normal playback, the terminal, such as its framework layer, can periodically calculate the energy of the played audio and record it within the process. In the judgment of S602 above, if the difference between the first and second moments exceeds a threshold, the terminal, such as its framework layer, can compare the energy of the last played audio (or the audio currently played) with a preset energy level for the played audio. If the energy of the last played audio is less than the preset energy level, it can be considered that the current audio has undergone fade-out processing, i.e., the current scene is determined to be a preset scene, and even if the audio data in the target buffer is insufficient, no playback noise will occur. Therefore, the terminal, such as its framework layer, can filter out scenes where audio fade-out processing is performed by determining whether the energy of the currently played audio is greater than the preset energy level for the played audio. If the energy of the last played audio is greater than the preset energy level for the played audio, then S603 can continue to be executed.

[0162] S603. Determine if the current terminal's volume value is 0.

[0163] Understandably, if the terminal's volume is 0, meaning it's in a muted state, no playback noise will occur even if the audio data in the target buffer is insufficient. Therefore, if S602 above determines that the energy of the last played audio is greater than the preset playback audio energy, it can further determine whether the current terminal's volume is 0. If the current terminal's volume is 0, it indicates that the current audio is playing silently, meaning the current scenario is a silent scenario, thus filtering out scenarios where audio is playing silently. If the current terminal's volume is not 0, it can be determined that the current scenario is not a preset scenario.

[0164] After determining that the current scenario is not a preset scenario, the terminal can execute relevant steps (such as S304-S306 above, as shown in Figure 5) to adjust the priority of the relevant threads. For example, after determining that the current scenario is not a preset scenario, the terminal, such as the terminal's framework layer, can notify the lower layers, such as the kernel layer, to execute the thread priority adjustment decision process. For example, the framework layer can notify the lower layers to perform the operation through the input / output control system (ioctl).

[0165] If the current scenario is determined to be the preset scenario, it means that thread priority scheduling is not required.

[0166] It should be noted that the execution order of S601-S603 above is only an example. The execution order of this application embodiment is not specifically limited, and S601-S603 can also be executed simultaneously.

[0167] The technical solution provided in this application embodiment allows the terminal to identify scenes that will not produce playback noise when the audio data buffer is insufficient, and to refrain from performing priority adjustment processing on these scenes. This reduces redundant priority boosting operations and improves the control precision of thread priority adjustment.

[0168] It should be noted that the thread priority adjustment method provided in this application embodiment can be applied not only to the scenario of eliminating "explosive" noise by adjusting the priority of the audio data producer thread and the wake-up source thread, but also to other scenarios where low-priority tasks block high-priority tasks within the application, such as camera output or frame drawing scenarios. This application does not limit this.

[0169] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0170] Other embodiments of this application also provide a computer storage medium that may include computer instructions that, when executed on a terminal, cause the terminal to perform the various steps performed by the terminal (such as a mobile phone) or server in the above embodiments.

[0171] Other embodiments of this application also provide a computer program product that, when run on a computer, causes the computer to perform the various steps performed by the terminal (such as a mobile phone) or server in the above embodiments.

[0172] Other embodiments of this application also provide an apparatus having the function of implementing the terminal (such as a mobile phone) or server behavior described in the above embodiments. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions, such as an acquisition unit or module, or a processing unit or module. As an example, the acquisition unit or module can execute S301 as described above; the processing unit or module can execute S302-S306 as described above. As another example, the processing unit or module can execute S501-S505 as described above. As another example, the processing unit or module can execute S601-S603 as described above.

[0173] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0174] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0175] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0176] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0177] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of this application embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0178] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope 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.

Claims

1. A method for adjusting thread priority, characterized in that, The method includes: During the process of playing audio through the first application on the terminal, the amount of data in the target cache is obtained. The target cache is used to cache audio data in the first thread of the first application. If the amount of data in the target cache is lower than a threshold, the priority of the first thread is adjusted based on the scarcity level related to the amount of data in the target cache; wherein the amount of data in the target cache is negatively correlated with the scarcity level, and the priority of the first thread is positively correlated with the scarcity level.

2. The method according to claim 1, characterized in that, Before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the method further includes: It is determined that the first thread is currently a normal non-real-time task.

3. The method according to claim 2, characterized in that, Adjusting the priority of the first thread includes: The priority of the first thread is adjusted from the current first priority to the second priority, so that the first thread after the priority adjustment is a real-time task, and the second priority is positively correlated with the scarcity level.

4. The method according to any one of claims 1-3, characterized in that, Before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the method further includes: Set the first flag bit to the first value and the second flag bit to the first value; Wherein, the first flag bit is used to indicate whether the target task is running, the first flag bit is a first value used to indicate that the target task is not running, and the target task is used to determine whether the wake-up source thread of the first thread needs to be prioritized. The second flag bit is used to indicate whether the priority of the first thread has been increased, and the second flag bit being a first value is used to indicate that the priority of the first thread has not been increased.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: After adjusting the priority of the first thread for a first preset time, the target task is started to perform the following operations: Obtain the first running time of the first thread, where the first running time is the running time of the first thread from the moment of its creation to the moment when the target task is determined to be started; If the first running time and the second running time are equal, the priority of the second thread is adjusted; the second running time is the running time of the first thread from the moment of its creation to the moment of the first time, and the moment of the first time is the moment when it is determined that the amount of data in the target cache is lower than the threshold. The second thread is the thread that meets the wake-up condition among the wake-up source threads of the first thread; The wake-up conditions include one or more of the following conditions: the percentage of times the first thread is woken up is greater than a threshold, it is a normal non-real-time task, and the third flag bit is the first value; the third flag bit is used to indicate whether the priority of the wake-up source thread has been increased, and the third flag bit being the first value is used to indicate that the priority of the wake-up source thread has not been increased.

6. The method according to claim 5, characterized in that, The method further includes: If the first running time is not equal to the second running time, the priority of the first thread is adjusted to the first priority.

7. The method according to claim 5 or 6, characterized in that, The adjustment of the priority of the second thread includes: Adjust the priority of the second thread from the current third priority to the fourth priority, so that the second thread after the priority adjustment becomes a real-time task.

8. The method according to any one of claims 5-7, characterized in that, The method further includes: After a second preset time following the adjustment of the priority of the second thread, the priority of the first thread is adjusted to the first priority, and the priority of the second thread is adjusted to the third priority.

9. The method according to any one of claims 1-8, characterized in that, Before adjusting the priority of the first thread based on the scarcity level related to the amount of data in the target cache, the method further includes: It has been determined that the current scene is not the preset scene; The preset scenarios include one or more of the following scenarios: the progress bar of the audio playback is dragged by the user, the audio playback ends, the audio is played in silent mode, and the audio is faded out.

10. The method according to claim 9, characterized in that, If the current scenario meets one or more of the following conditions, it is determined that the current scenario is not the preset scenario: The difference between the first moment and the second moment is greater than the threshold. The first moment is the moment when the predetermined interface is called, and the second moment is the moment when it is determined that the amount of data in the target cache is lower than the threshold. The energy of the audio being played at the current moment is greater than the preset energy of the audio being played. The volume value of the terminal is not 0.

11. An electronic device, characterized in that, The electronic device includes: a processor, a memory; and a computer program, wherein the computer program is stored in the memory and, when executed by the processor, causes the electronic device to perform the method as described in any one of claims 1-10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-10.

Images