Audio communication interruption test method and device, computer equipment and storage medium

Abstract

The invention relates to an audio communication interruption test method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring an interrupt request signal, and generating an interrupt request event based on the interrupt request signal; in response to the fact that a current configuration environment is a sending test environment, based on the interrupt request event, executing an interrupt test operation in the sending test environment; and in response to the fact that the current configuration environment is a receiving test environment, executing an interrupt test operation in the receiving test environment based on the interrupt request event. Through the method, the test accuracy can be improved, the verification period is shortened, and the verification process is optimized.

Description

Technical Field

[0001] The present application relates to the technical field of data transmission and processing, and in particular to an audio communication interruption test method, device, computer equipment and storage medium. Background Art

[0002] I2S (Inter-IC Sound) is a serial data transmission protocol for audio devices. It is usually used to transmit audio data between integrated circuits and is widely used in audio codecs, digital signal processors (DSPs), and other audio-related hardware devices. The I2S protocol has two important FIFO buffers: TX FIFO and RX FIFO, which are used to store audio data to be sent and received, respectively.

[0003] In the process of hardware design and verification, system-level verification is usually performed after the entire system is integrated, aiming to simulate and verify the interaction and functions between multiple modules or components. In system-level verification, the entire SoC (system on chip) is integrated into a simulation platform to simulate the collaborative work of various hardware modules including CPU, memory, peripheral interfaces, etc. By integrating all hardware components (such as I2S, CPU, peripherals, etc.), the complete system behavior is simulated for comprehensive verification.

[0004] Although system-level verification can fully simulate real scenarios, the simulation speed is very slow because it involves the integration of the entire SoC (system on chip), and it is impossible to quickly debug and fix problems. Taking a 20ms simulation as an example, system-level verification takes 1 day to complete the simulation. The simulation process is too time-consuming and the verification cycle is too long. Summary of the invention

[0005] Based on this, it is necessary to provide a module-level audio communication interruption test method, device, computer equipment and storage medium that can improve verification efficiency, improve test accuracy, reduce verification cycle and optimize the verification process in response to the above technical problems.

[0006] In one aspect, a target tracking method is provided, the method comprising:

[0007] Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0008] In response to the current configuration environment being a sending test environment, based on the interrupt request event, executing an interrupt test operation under the sending test environment;

[0009] In response to the current configuration environment being a receiving test environment, an interruption test operation is performed in the receiving test environment based on the interruption request event.

[0010] In one embodiment, it is characterized in that obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal includes:

[0011] Parsing the interrupt request signal to obtain the original format of the interrupt request signal;

[0012] Converting the original format of the interrupt request signal into a preset signal format by transferring a data matching mechanism;

[0013] The interrupt request signal in the preset format is stored in the interrupt request event through the transfer data matching mechanism.

[0014] In one embodiment, it is characterized in that the method of obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal further comprises:

[0015] In response to reaching a preset time, a new interrupt request signal is obtained;

[0016] The interrupt request event is updated according to the new interrupt request signal.

[0017] In one embodiment, after obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal, the method includes:

[0018] The interrupt request event is transmitted to the sending test environment and the receiving test environment through a handle.

[0019] In one embodiment, in response to the current configuration environment being a sending test environment, executing an interruption test operation under the sending test environment based on the interruption request event includes:

[0020] In response to detecting the interrupt request event in the sending test environment, monitoring the data buffer;

[0021] In response to the data buffer being full, stopping writing data into the data buffer;

[0022] In response to the data buffer being not full, continuing to write data into the data buffer.

[0023] In one embodiment, in response to the current configuration environment being a receiving test environment, executing an interruption test operation under the receiving test environment based on the interruption request event includes:

[0024] In response to the current configuration environment being a receiving test environment, detecting the data buffer;

[0025] In response to the data buffer being non-empty, reading the data in the data buffer;

[0026] In response to the data buffer being empty, waiting for receiving data.

[0027] In one embodiment, the sending test environment and the receiving test environment include an arbitration mechanism, wherein the arbitration mechanism includes a main function and an interrupt service function, including:

[0028] In response to the test mode being the sending mode, calling the main function to write data into the data buffer;

[0029] In response to receiving the interrupt request event, stopping writing data to the data buffer and jumping to the interrupt service function through the arbitration mechanism;

[0030] Calling the interrupt service function to query the state of the data buffer;

[0031] In response to the data buffer being full, the interrupt service function continues to query the data buffer;

[0032] In response to the data buffer being not full, the interrupt service function stops operating and jumps to the main function through the arbitration mechanism;

[0033] Calling the main function to continue writing data into the data buffer;

[0034] In response to the test mode being the receiving mode, the main function waits for receiving data;

[0035] In response to receiving the interrupt request event, jumping to the interrupt service function through the arbitration mechanism;

[0036] Calling the interrupt service function to query the state of the data buffer;

[0037] In response to the data buffer being non-empty, the interrupt service function reads the data in the data buffer;

[0038] In response to the data buffer being empty, the interrupt service function stops operating and jumps back to the main function through the arbitration mechanism;

[0039] Control the main function to wait for receiving data.

[0040] On the other hand, a simulated audio communication interruption test verification device is provided, the device comprising:

[0041] A signal acquisition module, used for acquiring an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0042] A sending test module, configured to respond to the current configuration environment being a sending test environment and, based on the interrupt request event, perform an interrupt test operation under the sending test environment;

[0043] The receiving test module is used to respond to the current configuration environment being a receiving test environment and execute an interruption test operation under the receiving test environment based on the interruption request event.

[0044] In another aspect, a computer device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the following steps are implemented:

[0045] Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0046] In response to the current configuration environment being a sending test environment, based on the interrupt request event, executing an interrupt test operation under the sending test environment;

[0047] In response to the current configuration environment being a receiving test environment, an interruption test operation is performed in the receiving test environment based on the interruption request event.

[0048] In another aspect, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0049] Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0050] In response to the current configuration environment being a sending test environment, based on the interrupt request event, executing an interrupt test operation under the sending test environment;

[0051] In response to the current configuration environment being a receiving test environment, an interruption test operation is performed in the receiving test environment based on the interruption request event.

[0052] In the above-mentioned audio communication interruption test method, first, by obtaining the interrupt request signal and generating an interrupt request event based on it, it can be ensured that the test focuses on the triggering mechanism and event response of the interrupt signal. By distinguishing between the sending test environment and the receiving test environment, the corresponding interruption test operations are performed in different environments. In the sending test environment, verify whether the interrupt request can be stopped in time; in the receiving test environment, verify whether the received data can trigger the interrupt and ensure that the system can operate. This targeted verification ensures that the interrupt response mechanism of each environment can be executed independently and accurately, thereby verifying the system's multi-scenario adaptability.

[0053] Different test operations are adaptively selected according to the current configuration environment. This flexible verification method can cover different usage scenarios of the I2S protocol, improving the reusability and efficiency of test cases. Each time, you only need to modify the environment configuration to perform corresponding interrupt tests for different working modes, avoiding multiple writing and maintenance of repeated test codes.

[0054] In real applications, the interrupt events of the I2S protocol are not just simple triggers of hardware signals, but also require responses to these events in a specific operating environment. By verifying the interrupt request events in the sending and receiving test environments respectively, the complex behaviors after the interrupt request are simulated, which can be closer to the interrupt scenarios in actual use, provide effective support for verification, and improve the comprehensiveness of the verification process. At the same time, simulating these interrupt scenarios in module-level verification can effectively reduce the burden of verification, reduce simulation time, and thus reduce the verification cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 An application environment diagram of an audio communication interruption test in one embodiment;

[0056] Figure 2 A schematic diagram of a flow chart of an audio communication interruption test in one embodiment;

[0057] Figure 3 A structural block diagram of a sending test environment for an audio communication interruption test in one embodiment;

[0058] Figure 4 A structural block diagram of a receiving test environment for an audio communication interruption test in one embodiment;

[0059] Figure 5 An environmental structural block diagram of an audio communication interruption test in one embodiment;

[0060] Figure 6 A structural block diagram of an apparatus for audio communication interruption testing in one embodiment;

[0061] Figure 7 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0062] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0063] The audio communication interruption test method provided in this application can be applied to Figure 1In the application environment shown. An interrupt request event is generated according to the obtained interrupt request signal, and an interrupt test is completed based on the interrupt request event and the test environment. The terminal 102 communicates with 104 through a network. The terminal 102 can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, and portable wearable devices, and the server 104 can be implemented with an independent server or a server cluster consisting of multiple servers.

[0064] In one embodiment, Figure 2 As shown, a method for testing audio communication interruption is provided, and the method is applied to Figure 1 The terminal in is used as an example to illustrate, including the following steps:

[0065] Step 201: Obtain an interrupt request signal, and generate an interrupt request event based on the interrupt request signal.

[0066] Among them, the interrupt request signal is the core of the hardware interrupt. Verifying whether the signal is generated as expected is a key step to ensure the normal operation of the system.

[0067] Step 202 , in response to the current configuration environment being a sending test environment, based on an interrupt request event, executing an interrupt test operation in the sending test environment.

[0068] Specifically, in the sending test environment, by generating the interrupt request event and triggering the interrupt test, the timeliness and correctness of the interrupt response after the interrupt is triggered can be verified. This ensures the stability of the system and the fluency of data. This improves the accuracy and pertinence of the test and ensures that the interrupt mechanism in each working mode is independently verified.

[0069] Step 203: In response to the current configuration environment being the receiving test environment, an interruption test operation is performed in the receiving test environment based on an interruption request event.

[0070] Specifically, in the receiving test environment, by executing the test operation in the receiving test environment based on the interrupt request event, it can be ensured that when data is received, the correctness of the interrupt processing when receiving data can be verified, and the robustness of the system is improved.

[0071] In the above-mentioned audio communication interruption test method, first, by obtaining the interrupt request signal and generating an interrupt request event based on it, it can be ensured that the test focuses on the triggering mechanism and event response of the interrupt signal. By distinguishing the sending test environment and the receiving test environment, the corresponding interruption test operations are performed in different environments. In the sending test environment, it is verified whether the interrupt request can be stopped in time; in the receiving test environment, it is verified whether the received data can trigger the interruption and ensure that the system can operate. This targeted verification ensures that the interrupt response mechanism of each environment can be executed independently and accurately, thereby verifying the multi-scenario adaptability of the system. According to the current configuration environment, different test operations can be adaptively selected. This flexible verification method can cover different usage scenarios of the I2S protocol and improve the reusability and efficiency of test cases. Each time, the corresponding interruption test can be performed for different working modes by simply modifying the environment configuration, avoiding multiple writing and maintenance of repeated test codes. In real applications, the interrupt event of the I2S protocol is not only a simple trigger of the hardware signal, but also needs to respond to these events in a specific operating environment. By verifying the interrupt request events in the sending and receiving test environments respectively, the complex behaviors after the interrupt request are simulated, which can be closer to the interrupt scenarios in actual use, provide effective support for verification, and improve the comprehensiveness of the verification process. At the same time, simulating these interrupt scenarios in module-level verification can effectively reduce the burden of verification, reduce simulation time, and thus reduce the verification cycle.

[0072] In one embodiment, obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal includes:

[0073] Parse the interrupt request signal to obtain the original format of the interrupt request signal;

[0074] Convert the original format of the interrupt request signal into a preset signal format through a transfer data matching mechanism;

[0075] The interrupt request signal in the preset format is stored in the interrupt request event through the transfer data matching mechanism.

[0076] Among them, the delivery data matching mechanism is a mechanism used in the data transmission and processing process, mainly used to ensure the correct transmission and reception of data between different modules or systems. This mechanism ensures that there is no loss, error or inconsistency in the data transmission process by comparing or verifying the transmitted data with the expected data. In audio or video data transmission, the delivery data matching mechanism ensures the consistency between audio or video data blocks in various processing stages (such as encoding, transmission, decoding).

[0077] Specifically, by parsing the interrupt request signal, the system can correctly understand and obtain the format of the original signal. The original interrupt request signal obtained is converted into a preset signal format through a data matching mechanism. This conversion process helps to standardize the interrupt signal and avoid compatibility issues caused by inconsistent signal formats between different modules or systems. And the interrupt request signal in the preset format after format conversion is stored in the interrupt request event through the data transfer matching mechanism, and the system can clearly record the specific circumstances of each interrupt. This not only helps to improve the efficiency of interrupt response, but also ensures that the system can respond quickly and accurately in different interrupt scenarios. Storing the converted signal format means that these standardized interrupt request events can be quickly found and responded to in subsequent processing. By reducing the complexity of real-time processing of interrupt signals, the interrupt response efficiency of the entire system can be significantly improved.

[0078] In one embodiment, obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal further includes:

[0079] In response to reaching a preset time, a new interrupt request signal is obtained;

[0080] According to the new interrupt request signal, the interrupt request event is updated.

[0081] The new interrupt request signal is converted into a preset signal format through a data transfer matching mechanism, and the converted new preset interrupt request signal is stored in the interrupt request event.

[0082] Specifically, by acquiring a new interrupt request signal at a preset time point, the system can ensure that the new interrupt request is captured in time. This timing mechanism enables the system to handle interrupt events more accurately and timely, avoiding omission or delay in processing important interrupt signals. Especially in a multi-interrupt source environment, this timing response method can help the system better handle interrupt requests in different time periods. Ensure that the interrupt event information is real-time and accurate. This enables the system to adjust the interrupt processing logic in real time according to the current interrupt signal, avoiding delayed processing and improving the timeliness and accuracy of interrupt processing. By continuously updating interrupt request events, the system can adjust the interrupt response strategy according to the real-time interrupt signal situation. For example, when a new interrupt request signal arrives, the system can decide whether to respond immediately or postpone processing based on the current operating status and priority. This flexibility can effectively cope with complex scenarios and changing interrupt modes that may occur in the system.

[0083] In one embodiment, after obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal, the method includes:

[0084] The interrupt request event is delivered to the sending test environment and the receiving test environment through the handle.

[0085] Among them, a handle refers to an identifier used in a program to reference a resource, object, or service. It does not directly represent the resource itself, but is a unique identifier used internally by the system or application to indirectly access or operate certain resources. Handles provide an abstract method that allows access to complex resources or objects without directly manipulating the memory or specific implementation of these resources. For example, through a file handle, a program can open, read, and write a file without understanding the internal structure of the file. Handles are often used to manage resources in the operating system or application (such as files, network connections, windows, images, databases, etc.). They act as a bridge between the operating system and the application, allowing programs to access and operate resources without directly handling the resources.

[0086] Specifically, by passing interrupt request events through handles, the system avoids directly passing complex interrupt data structures or memory addresses. As an abstract layer, the handle simplifies the transmission and management of interrupt events, allowing each environment (sending test environment and receiving test environment) to share resources efficiently and safely. Through the handle, the management of all resources (such as the life cycle of interrupt request events, memory management, etc.) can be centrally handled by the operating system or a specific resource manager, reducing the direct operation and management of the underlying resources by developers and improving the maintainability of the system. The handle provides a resource isolation method for different tasks or threads, so that each environment will not interfere with each other when processing interrupt request events, and can share resources efficiently. For example, the sending test environment and the receiving test environment can process interrupt request events at different stages through a shared handle without directly accessing resources to each other. This makes the system more efficient, flexible, and secure when processing interrupt request events, and also enhances the maintainability and scalability of the system.

[0087] In one embodiment, Figure 3 As shown, in response to the current configuration environment being a sending test environment, based on an interrupt request event, an interrupt test operation is performed in the sending test environment, including:

[0088] In response to detecting an interrupt request event in the sending test environment, monitoring the data buffer;

[0089] In response to the data buffer being full, stopping writing data to the data buffer;

[0090] In response to the data buffer being not full, data continues to be written into the data buffer.

[0091] The sending test environment includes a data buffer, which is a memory area in a computer system used to temporarily store and manage data. The buffer plays a role of caching and regulation in the data transmission process, and is usually used to solve the problem of mismatched processing speeds, that is, when one component produces data faster than another component consumes data, the buffer can temporarily store data to ensure smooth data transmission and processing.

[0092] Specifically, in the sending test environment, the interrupt request event is responded to, and the data writing operation is controlled by monitoring the data storage status of the data buffer. When the data in the data buffer is full, the data writing is stopped; and when the data in the data buffer is not full, the data writing continues. By monitoring whether the data buffer is full, it can be ensured that further data writing is stopped when the buffer is full. This can effectively avoid buffer overflow or data loss, thereby ensuring the integrity of data transmission. If the buffer is full and data is continued to be written, it will not only waste system resources, but also may cause erroneous interruptions or operations. Therefore, by reasonably controlling the timing of data writing, the efficiency of system resource utilization can be maximized and invalid write operations can be reduced.

[0093] In one embodiment, Figure 4 As shown, in response to the current configuration environment being a receiving test environment, based on an interrupt request event, executing an interrupt test operation in the receiving test environment includes:

[0094] In response to the current configuration environment being a receiving test environment, detecting the data buffer;

[0095] In response to the data buffer being not empty, reading the data in the data buffer;

[0096] In response to the data buffer being empty, waiting for receiving data.

[0097] The receiving test environment includes a data buffer.

[0098] Specifically, the data storage status of the data buffer is monitored. When there is data in the buffer, the data can be read in time to ensure that the system works normally according to the expected process, thereby ensuring stable data transmission and processing. When there is no data in the buffer, waiting for data to be written to avoid invalid repeated read operations can effectively avoid unnecessary calculations and resource consumption. This can reduce the burden on the processor and optimize the efficiency of system resource use. Only when there is data in the buffer is the read operation performed, which avoids unnecessary resource occupation when the buffer is empty and improves the overall efficiency of the system. Help the system to receive and process data efficiently and stably, and improve the overall performance and maintainability of the system.

[0099] In one embodiment, the sending test environment and the receiving test environment include an arbitration mechanism, wherein the arbitration mechanism includes a main function and an interrupt service function, including:

[0100] In response to the test mode being the sending mode, calling a main function to write data into the data buffer;

[0101] In response to receiving an interrupt request event, stop writing data to the data buffer and jump to the interrupt service function through an arbitration mechanism;

[0102] Call the interrupt service function to query the status of the data buffer;

[0103] In response to the data buffer being full, the interrupt service function continues to query the data buffer;

[0104] In response to the data buffer being not full, the interrupt service function stops operating and jumps to the main function through the arbitration mechanism;

[0105] Call the main function to continue writing data to the data buffer;

[0106] In response to the test mode being the receiving mode, the main function waits for receiving data;

[0107] In response to receiving an interrupt request event, the interrupt service function is jumped to through the arbitration mechanism;

[0108] Call the interrupt service function to query the status of the data buffer;

[0109] In response to the data buffer being not empty, the interrupt service function reads the data in the data buffer;

[0110] In response to the data buffer being empty, the interrupt service function stops operating and jumps back to the main function through an arbitration mechanism;

[0111] Control the main function to wait for receiving data.

[0112] Arbitration Mechanism refers to a control mechanism used to resolve conflicts among multiple resources or multiple processes / devices competing for the same resource (such as bus, memory, CPU, etc.) in a computer system. It determines how to allocate resources fairly and effectively in the case of resource contention, thereby avoiding conflicts and ensuring the normal operation of the system.

[0113] Specifically, in the sending test environment, the main process is occupied by the main function to write data to the data buffer. After the interrupt request event is detected, the main function stops writing data to the data buffer and jumps to the interrupt service function through the arbitration mechanism. At this time, the interrupt service function continuously monitors the state of the data buffer. If the data in the data buffer is detected to be full, it waits for the data to be processed and continuously monitors the state of the data buffer. If the data in the data buffer is detected to be not full, the arbitration mechanism controls the interrupt service function to occupy the main process and jump back to the main function to control the main process. At this time, the main function continues to write data to the data buffer. In the receiving test environment, the main process is occupied by the main function and waits for receiving data. After the interrupt request event is detected, the arbitration mechanism jumps to the interrupt service function. At this time, the interrupt service function continuously monitors the state of the data buffer. If the data in the data buffer is detected to be not empty, the interrupt service function reads the data in the data buffer and continuously monitors the state of the data buffer. If the data in the data buffer is detected to be empty, the interrupt service function stops the reading operation and controls the interrupt service function to occupy the main process and jump back to the main function to control the main process through the arbitration mechanism. The main function continues to wait for receiving data.

[0114] When the data buffer is empty or full, the system stops unnecessary operations, avoiding excessive interrupts and frequent CPU switching, thereby reducing system load and latency. Through real-time detection of the buffer status, the system can process data at the right time to prevent data loss or overflow, avoid empty operations or data backlogs, and further reduce the system burden. Through the control of the arbitration mechanism, the system can perform data write or read operations according to predetermined steps when receiving an interrupt request, ensuring that the operations at each stage are within a controllable range and avoiding unnecessary unpredictable behaviors. Through clear process design, switching between the main function and the interrupt service function becomes simple and clear. The system can take corresponding actions based on the status of the data buffer, reducing the complexity of development. Developers can more easily monitor the status of the system, quickly locate and solve problems, and reduce the difficulty of maintenance and debugging.

[0115] In one embodiment, Figure 5 As shown, the configuration test environment includes: host, slave, drive component, monitoring component and verification component including:

[0116] Configure the monitoring component, set the sampling mode and data length to collect interrupt request signals, package them into interrupt request events and send them to the verification component; configure the verification component to perform corresponding verification and comparison operations after receiving the interrupt event; create a host and a slave to send and receive data; configure the driver component to drive the host or slave to perform the corresponding test operations.

[0117] Among them, the host sends the end and the slave receives the end. In the test environment, the driver component usually works with other verification components to drive the interface and is responsible for verifying whether the communication between the host and the slave is as expected. The monitoring component is a module for data sampling and monitoring of the I2S protocol (Inter-IC Sound). The sampled data will form a transaction after packaging and be transmitted to other modules or buses through the FIFO queue for further processing and verification. The I2S protocol is a serial communication protocol for digital audio data transmission, which is widely used in audio devices, sound cards, audio interfaces and other systems. I2S is mainly used to transmit audio data in digital audio systems. It can transmit audio data for left and right channels. FIFO (First-In-First-Out) is a data structure used as a management method for cache, queue or buffer in hardware or software systems. The first data to enter is processed first, that is, the data is processed in the order in which it enters. The verification component is used to compare and verify the data in the test environment.

[0118] Specifically, in the present application, a sending test environment and a receiving test environment are specifically configured. It should be understood that in the above configuration process, the conversion from the sending test environment to the receiving test environment can be completed by modifying some parameters. Through precise testing and verification, potential problems in the system design can be discovered and fixed in advance to ensure the stability and reliability of the system in actual operation. Through the collaborative work of monitoring components, verification components, and driving components, all aspects of the data transmission process can be fully covered, including data sending, receiving, error handling, interrupt signals, etc., to provide a complete verification environment. Targeted testing of different test environments improves the accuracy of interrupt test verification as a whole.

[0119] It should be understood that although Figure 2 The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0120] In one embodiment, Figure 6As shown, an audio communication interruption test device applied to the module level is provided, comprising: a signal acquisition module 301, a sending test module 302 and a receiving test module 303, wherein:

[0121] A signal acquisition module 301, used to acquire an interrupt request signal, and generate an interrupt request event based on the interrupt request signal;

[0122] A sending test module 302, configured to respond to the current configuration environment being a sending environment and, based on the interrupt request event, perform an interrupt test operation under the sending environment;

[0123] The receiving test module 303 is used to respond to the current configuration environment being a receiving environment and execute an interruption test operation in the receiving environment based on the interruption request event.

[0124] In one embodiment, the signal acquisition module 301 is used to:

[0125] Parsing the interrupt request signal to obtain the original format of the interrupt request signal;

[0126] Converting the original format of the interrupt request signal into a preset signal format by transferring a data matching mechanism;

[0127] The converted interrupt request signal is stored in the interrupt request event through the transfer data matching mechanism.

[0128] In one embodiment, the sending test module 302 is used to:

[0129] In response to detecting an interrupt request event in a sending environment, the data buffer is monitored;

[0130] In response to the data buffer being full, stopping writing data to the data buffer;

[0131] In response to the data buffer being not full, data continues to be written into the data buffer.

[0132] In one embodiment, the receiving test module 303 is used to:

[0133] In response to the current configuration environment being a receiving environment, detecting the data buffer;

[0134] In response to the data buffer being not empty, reading the data in the data buffer;

[0135] In response to the data buffer being empty, waiting for receiving data.

[0136] For the specific definition of an audio communication interruption test device applied to the module level, please refer to the definition of the audio communication interruption test method mentioned above, which will not be repeated here. Each module in the above-mentioned audio communication interruption test device applied to the module level can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0137] In one embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a target tracking method is implemented. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a key, trackball or touchpad set on the computer device housing, or an external keyboard, touchpad or mouse, etc.

[0138] Those skilled in the art will understand that Figure 7 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0139] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0140] Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0141] In response to the current configuration environment being a sending environment, based on an interrupt request event, executing an interrupt test operation in the sending environment;

[0142] In response to the current configuration environment being a receiving environment, an interruption test operation in the receiving environment is performed based on an interruption request event.

[0143] In one embodiment, when the processor executes the computer program, the processor further implements the following steps:

[0144] Parse the interrupt request signal to obtain the original format of the interrupt request signal;

[0145] Convert the original format of the interrupt request signal into a preset signal format through a transfer data matching mechanism;

[0146] The converted interrupt request signal is stored in the interrupt request event through the transfer data matching mechanism.

[0147] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0148] Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal;

[0149] In response to the current configuration environment being a sending environment, based on an interrupt request event, executing an interrupt test operation in the sending environment;

[0150] In response to the current configuration environment being a receiving environment, an interruption test operation in the receiving environment is performed based on an interruption request event.

[0151] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0152] In response to reaching a preset time, a new interrupt request signal is obtained;

[0153] According to the new interrupt request signal, the interrupt request event is updated.

[0154] In one embodiment, a computer program product is provided, comprising a computer program, which, when executed by a processor, implements the following steps:

[0155] In response to detecting an interrupt request event in a sending environment, the data buffer is monitored;

[0156] In response to the data buffer being full, stopping writing data to the data buffer;

[0157] In response to the data buffer being not full, data continues to be written into the data buffer.

[0158] In one embodiment, when the computer program is executed by a processor, the following steps are also implemented:

[0159] In response to the current configuration environment being a receiving environment, detecting the data buffer;

[0160] In response to the data buffer being not empty, reading the data in the data buffer;

[0161] In response to the data buffer being empty, waiting for receiving data.

[0162] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0163] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0164] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A method for testing audio communication interruption, characterized in that: include: Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal; Acquire the current configuration environment, where the configuration environment includes a sending test environment and a receiving test environment; In response to the current configuration environment being a sending test environment, based on the interrupt request event, executing an interrupt test operation under the sending test environment; In response to the current configuration environment being a receiving test environment, an interruption test operation is performed in the receiving test environment based on the interruption request event.

2. The audio communication interruption test method according to claim 1, characterized in that: Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal, including: Parsing the interrupt request signal to obtain the original format of the interrupt request signal; Converting the original format of the interrupt request signal into a preset signal format by transferring a data matching mechanism; The interrupt request signal in the preset format is stored in the interrupt request event through the transfer data matching mechanism.

3. The audio communication interruption test method according to claim 2, characterized in that: Obtaining an interrupt request signal, and generating an interrupt request event based on the interrupt request signal, further comprising: In response to reaching a preset time, a new interrupt request signal is obtained; The interrupt request event is updated according to the new interrupt request signal.

4. The audio communication interruption test method according to claim 3, characterized in that: After obtaining an interrupt request signal and generating an interrupt request event based on the interrupt request signal, the method includes: The interrupt request event is transmitted to the sending test environment and the receiving test environment through a handle.

5. The audio communication interruption test method according to claim 1, characterized in that: In response to the current configuration environment being a sending test environment, executing an interruption test operation under the sending test environment based on the interruption request event includes: In response to detecting the interrupt request event in the sending test environment, monitoring the data buffer; In response to the data buffer being full, stopping writing data into the data buffer; In response to the data buffer being not full, continuing to write data into the data buffer.

6. The audio communication interruption test method according to claim 5, characterized in that: In response to the current configuration environment being a receiving test environment, executing an interruption test operation under the receiving test environment based on the interruption request event includes: In response to the current configuration environment being a receiving test environment, monitoring the data buffer; In response to the data buffer being non-empty, reading the data in the data buffer; In response to the data buffer being empty, waiting for receiving data.

7. The audio communication interruption test method according to claim 6, characterized in that: The sending test environment and the receiving test environment include an arbitration mechanism, wherein the arbitration mechanism includes a main function and an interrupt service function, including: In response to the test mode being the sending mode, calling the main function to write data into the data buffer; In response to receiving the interrupt request event, stopping writing data to the data buffer and jumping to the interrupt service function through the arbitration mechanism; Calling the interrupt service function to query the state of the data buffer; In response to the data buffer being full, the interrupt service function continues to query the data buffer; In response to the data buffer being not full, the interrupt service function stops operating and jumps to the main function through the arbitration mechanism; Calling the main function to continue writing data into the data buffer; In response to the test mode being the receiving mode, the main function waits for receiving data; In response to receiving the interrupt request event, jumping to the interrupt service function through the arbitration mechanism; Calling the interrupt service function to query the state of the data buffer; In response to the data buffer being non-empty, the interrupt service function reads the data in the data buffer; In response to the data buffer being empty, the interrupt service function stops operating and jumps back to the main function through the arbitration mechanism; Control the main function to wait for receiving data.

8. A module-level audio communication interruption test device, characterized in that: The device comprises: A signal acquisition module, used for acquiring an interrupt request signal, and generating an interrupt request event based on the interrupt request signal; A sending test module, configured to respond to the current configuration environment being a sending test environment and execute an interruption test operation under the sending test environment based on the interruption request event; The receiving test module is used to respond to the current configuration environment being a receiving test environment and execute an interruption test operation under the receiving test environment based on the interruption request event.

9. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images