Call quality detection method and related apparatus

Abstract

The method and related device for detecting call quality provided by the embodiments of the present application relate to the terminal technical field. The method comprises the following steps: when the electronic device detects that the rate of the uplink network or the rate of the downlink network is continuously lower than the rate threshold, and there is sound in the call, it can be judged that the application has a lag in the call process. The electronic device can optimize the network, thereby reducing the lag of the application and improving the user experience.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to call quality detection methods and related devices. Background Technology

[0002] Some applications in electronic devices support voice or video call functions, allowing users to make voice or video calls.

[0003] However, in voice or video call scenarios, electronic devices may experience poor call quality due to factors such as network fluctuations, resulting in issues like application lag and affecting the user experience. Summary of the Invention

[0004] The call quality detection method and related apparatus provided in this application can determine that the application is experiencing lag during a call when the electronic device detects that the uplink or downlink network speed is continuously lower than the speed threshold and there is sound in the call. The electronic device can then optimize the network to reduce application lag and improve user experience.

[0005] In a first aspect, the call quality detection method provided in the embodiments of this application includes:

[0006] The electronic device enters a call. During the first time period of the call, if the network speed is lower than a speed threshold, a first parameter is incremented by a first value, indicating the number of times the call experiences low speed. During the first time period, if the audio loudness is greater than an audio loudness threshold, a second parameter is incremented by a second value, indicating the number of times the call has sound. If, during the first time period, both the first parameter and the second parameter are greater than the first and second thresholds, a call interruption is determined. This allows the electronic device to optimize the network during a call, reducing interruptions and improving the user experience.

[0007] In one possible implementation, the method further includes: within a first time period, if the first parameter is less than or equal to a first threshold, and / or the second parameter is less than or equal to a second threshold, determining that no call interruption has occurred. This way, by comprehensively considering network speed and whether there is sound during the call, it is possible to more accurately determine whether the current call is interrupted and whether further network speed optimization is needed. This reduces the likelihood of misjudging call interruptions when the call is silent due to the user not speaking.

[0008] In one possible implementation, the method further includes: if the network speed is greater than a speed threshold within a first time period, setting the first parameter to a first initial value. Thus, if the network speed is greater than the speed threshold, it indicates that the current call has a high network speed and good call quality without any lag, so there is no need to continue accumulating the first parameter; therefore, the first parameter can be set to the first initial value.

[0009] In one possible implementation, the method further includes: if the audio loudness is less than the audio loudness threshold within the first time period, setting the second parameter to a second initial value. Thus, if the audio loudness is less than the audio loudness threshold, it indicates that the current call is silent, possibly due to the user not speaking during the call. This cannot be used to determine whether the call is interrupted; therefore, there is no need to accumulate the second parameter, and the second parameter can be set to the second initial value.

[0010] In one possible implementation, the network rate at the first moment is calculated as the average of N network rates recorded in the electronic device before the first moment, where N is a positive integer within the first time period. Using the average rate to determine the current network rate reflects the overall trend of the network rate over a period of time (N network rates). This results in more stable data, unaffected by fluctuations in individual unstable data points, leading to more accurate judgments and improved algorithm robustness.

[0011] In one possible implementation, the audio loudness at the second moment is calculated as the average of the root mean square (RMS) values ​​of M calls recorded in the electronic device before the second moment, where M is a positive integer within the first time period. This method of using the average of the RMS values ​​of the M calls to determine the current audio loudness reflects the overall trend of audio loudness over a period of time (the RMS values ​​of the M calls). The resulting data is more stable and unaffected by fluctuations in individual unstable data points, leading to more accurate judgments and improved algorithm robustness.

[0012] In one possible implementation, the electronic device includes an audio digital signal processor (ADSP) and a target module. The ADSP includes detection points for the target module. The target module is used to acquire and record the root mean square (RMS) values ​​of M calls based on the detection points. In this way, the target module can promptly acquire the RMS values ​​of the M adjacent calls at the current moment based on the detection points. This allows for obtaining more up-to-date RMS values, facilitating real-time detection of whether a call has sound, and yielding RMS values ​​more consistent with the current moment, resulting in more accurate judgments.

[0013] In one possible implementation, after determining that a call is experiencing buffering, the process further includes setting a target value as a third value. This third value is used to instruct the electronic device to perform network optimization. By setting the target value as a third value and performing network optimization, network quality can be improved, thus enhancing the user experience.

[0014] Secondly, embodiments of this application provide a control device for call quality detection. This device can be an electronic device, or a chip or chip system within an electronic device. The device may include a processing unit. The processing unit is used to implement any processing-related method executed in accordance with the first aspect or any possible implementation of the first aspect. When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. When the device is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to cause the electronic device to implement the method described in the first aspect or any possible implementation of the first aspect. The storage unit may be a storage unit within the chip (e.g., a register, cache, etc.), or a storage unit located outside the chip within the electronic device (e.g., a read-only memory, random access memory, etc.).

[0015] For example, the processing unit is used to enter a call; it is also used to accumulate a first value for a first parameter, and to accumulate a second value for a second parameter, and specifically, it is also used to determine that a call has been interrupted.

[0016] In one possible implementation, the processing unit is configured to determine that no stuttering has occurred in the call scenario if the first parameter is less than or equal to a first threshold and / or the second parameter is less than or equal to a second threshold.

[0017] In one possible implementation, the processing unit is configured to set the first parameter to a first initial value if the network rate is greater than a rate threshold.

[0018] In one possible implementation, the processing unit is configured to set the second parameter to a second initial value if the audio loudness is less than an audio loudness threshold.

[0019] In one possible implementation, the network rate at the first moment is calculated as the average of N network rates recorded in the electronic device before the first moment, where N is a positive integer within the first time period.

[0020] In one possible implementation, the audio loudness at the second moment is calculated as the average of the root mean square (RMS) values ​​of M calls recorded in the electronic device before the second moment, where M is a positive integer during the first time period.

[0021] In one possible implementation, the electronic device includes an audio digital signal processor (ADSP) and a target module. The ADSP includes detection points of the target module. The target module is used to obtain the root mean square (RMS) values ​​of M calls from the call based on the detection points and record the RMS values ​​of the M calls.

[0022] In one possible implementation, a processing unit is used to set the target value to a third value.

[0023] Thirdly, embodiments of this application provide an electronic device including one or more processors and a memory, the memory being coupled to one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, and one or more processors calling the computer instructions to cause the electronic device to perform the methods described in the first aspect or any possible implementation of the first aspect.

[0024] Fourthly, this application provides a chip or chip system applied to an electronic device. The chip or chip system includes one or more processors and a communication interface. The communication interface and at least one processor are interconnected via a circuit. The one or more processors are used to invoke computer instructions to cause the electronic device to execute the methods described in the first aspect or any possible implementation thereof. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0025] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0026] Fifthly, embodiments of this application provide a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first aspect or any possible implementation thereof.

[0027] In a sixth aspect, embodiments of this application provide a computer program product including computer program code, which, when run on an electronic device, causes the electronic device to perform the methods described in the first aspect or any possible implementation thereof.

[0028] It should be understood that the second to sixth aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0030] Figure 2 A schematic diagram of the software structure of an electronic device provided in an embodiment of this application;

[0031] Figure 3 A flowchart for detecting application stuttering based on uplink speed is provided in an embodiment of this application;

[0032] Figure 4 A flowchart for detecting application stuttering based on uplink speed and whether there is sound during a call, provided in an embodiment of this application;

[0033] Figure 5 A schematic diagram of an array structure for cyclically storing RMS values ​​is provided in an embodiment of this application;

[0034] Figure 6 This application provides a schematic diagram of a logic for determining application lag.

[0035] Figure 7 This application provides a schematic diagram of a VDM module call detection point.

[0036] Figure 8 A schematic diagram illustrating a call quality detection method provided in an embodiment of this application;

[0037] Figure 9 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0038] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0039] 1. Terminology

[0040] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0041] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0042] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0043] 2. Electronic equipment

[0044] The electronic devices in this application embodiment can also be any form of terminal device. For example, electronic devices may include: mobile phones, tablet computers, handheld computers, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, electronic devices in 5G networks, or future evolved public land mobile communication networks (PLANs). The embodiments of this application do not limit the scope of electronic devices in a mobile network (PLMN).

[0045] By way of example and not limitation, in this embodiment, the electronic device can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices that are worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices, but also achieve powerful functions through software support, data interaction, and cloud interaction. Broadly speaking, wearable smart devices include those that are feature-rich, large in size, and can achieve complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses, as well as those that focus on a specific type of application function and require the use of other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0046] Furthermore, in this application embodiment, the electronic device can also be an electronic device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0047] The electronic equipment in the embodiments of this application may also be referred to as: user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0048] In this embodiment, the electronic device or various network devices include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also called main memory). The operating system can be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer includes applications such as browsers, address books, word processing software, and instant messaging software.

[0049] For example, Figure 1 A schematic diagram of the electronic device is shown.

[0050] The electronic device 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. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0051] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device. In other embodiments of this application, the electronic device 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 include hardware, software, or a combination of software and hardware.

[0052] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors. The controller can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution.

[0053] 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 directly retrieve it from the aforementioned memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system. For example, in the embodiments of this application, the processor 110 can be used to detect uplink speed, detect whether there is sound during a call, etc.

[0054] 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 SIM card interface, and / or a USB interface, etc.

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

[0056] Internal memory 121 can be used to store executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc. The data storage area may store data created during the use of the electronic device, etc. Furthermore, internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor. For example, in this embodiment, internal memory 121 may be used to store code related to determining whether an application is lagging based on uplink rate detection and call audio detection.

[0057] Electronic devices can implement audio functions through audio modules 170, speakers 170A, receivers 170B, microphones 170C, headphone jacks 170D, and application processors. Examples include voice calls and video calls.

[0058] Audio module 170 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signal. Speaker 170A, also called a "loudspeaker," is used to convert audio electrical signals into sound signals. An electronic device may include one or N speakers 170A, where N is a positive integer greater than 1. The electronic device can listen to music, make video calls, or conduct voice calls through speaker 170A. Receiver 170B, also called a "handpiece," is used to convert audio electrical signals into sound signals. When the electronic device answers a phone call or voice message, the receiver 170B can be brought close to the ear to hear the voice. Microphone 170C, also called a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. Headphone jack 170D is used to connect wired headphones.

[0059] Figure 2 This is a software architecture diagram of an electronic device according to an embodiment of this application. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers, from top to bottom: the application layer, the application framework layer, the hardware abstraction layer (HAL), and the kernel layer.

[0060] The application layer, also known as the application layer, can include a series of application packages. For example... Figure 2As shown, the application package can include social networking, video, and other applications. Applications can include system applications and third-party applications.

[0061] The application framework layer, also known as the framework layer, provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. The framework layer can include some predefined functions.

[0062] like Figure 2 As shown, the Framework layer may include a call management module, a quality of experience (QOE) module, a self-healing integration module, and an audio decoding module. In addition, the Framework layer may also include an activity manager, window manager, resource manager, notification manager, content provider, and view system (not shown in the figure), etc. For details, please refer to relevant technologies; further elaboration is omitted here.

[0063] The call management module can be used to request the audio and video resources needed for a call, handle downlink operations such as dialing, answering, and hanging up, and manage uplink status such as incoming call status and call waiting status. The call management module may include a Telephony module.

[0064] The quality experience module can be used to acquire network parameters and determine the quality of the network based on these parameters. These network parameters can include network speed, reference signal receiving power (RSRP), etc. For example, network speed can be used to determine call speed, and RSRP can be used to determine the quality of the network signal.

[0065] The integrated self-healing module can be used to obtain the cause value passed by the quality experience module and perform corresponding processing on the network based on the cause value, such as resetting the network.

[0066] The video decoder manager (VDM) is used to manage the acquisition, encoding, decoding, and rendering of audio data. It can also be called an audio decoding module or a VDM module. For ease of description, the VDM module will be used as an example below.

[0067] Understandably, the software architecture of electronic devices can also include other layers, such as the Android runtime and system libraries, which can be found in relevant technologies and will not be elaborated here.

[0068] The Hardware Abstraction Layer (HAL) is a layer of abstraction located between the kernel layer and the Android runtime. The HAL can be a wrapper around hardware drivers, providing a unified interface for calls from upper-layer applications.

[0069] The kernel layer is the layer between hardware and software. In this embodiment, the kernel layer may include an audio digital signal processor (ADSP) driver, a microphone driver, a speaker driver, etc.

[0070] ADSP drivers can be used to process audio data, including audio data calculation, conversion, compression, filtering, enhancement, decoding, as well as audio data transmission and reception.

[0071] It should be noted that the embodiments of this application are only illustrated using the Android system. In other operating systems (such as Windows system, iOS system, etc.), as long as the functions implemented by each functional module are similar to those in the embodiments of this application, the solution of this application can also be implemented.

[0072] In voice or video call scenarios, electronic devices may experience poor call quality due to factors such as network fluctuations, resulting in issues like call stuttering or silence, thus affecting the user experience.

[0073] In view of this, the call quality detection method provided in this application embodiment can determine that the application is experiencing lag during a call when the electronic device detects that the uplink network rate or downlink network rate is continuously lower than the rate threshold and there is sound in the call. The electronic device can then optimize the network to reduce application lag and improve user experience.

[0074] In this embodiment, the uplink network rate can be referred to as the uplink rate, and the downlink network rate can be referred to as the downlink rate. For ease of description, subsequent embodiments of this application will be described using the uplink rate as an example.

[0075] Figure 3 A flowchart is shown to detect application stuttering based on uplink speed.

[0076] Understandable Figure 3 The corresponding embodiment only shows a flowchart of executing one loop. In actual execution, in voice call or video call scenarios, the electronic device can execute the loop repeatedly. Figure 3 Steps S303-S307 of the corresponding embodiment will not be described again. When the application exits the voice call scenario or video call scenario, the electronic device can stop execution. Figure 3 The process corresponding to the embodiment.

[0077] S301, Enter the application.

[0078] It is understood that the application can be any application in an electronic device, and the embodiments of this application are not limited thereto.

[0079] In one possible implementation, the electronic device can record applications that support voice calls and / or video calls in a whitelist, and the electronic device can perform step S302 based on the applications recorded in the whitelist.

[0080] For example, if the application currently running in the foreground of the electronic device is in the whitelist, it means that the application supports voice call and / or video call functions, and the electronic device can execute step S302; otherwise, it will not continue to execute the subsequent steps.

[0081] S302. Determine whether the application has entered a voice call scenario or a video call scenario.

[0082] When an application enters a voice call or video call scenario, it needs to call the call management module to implement the relevant functions of the voice call or video call. Therefore, the call management module can be used to detect whether the application has entered a voice call or video call scenario.

[0083] If the application enters a voice call or video call scenario, step S303 can be executed; otherwise, subsequent steps will not be executed.

[0084] S303. Take the average rate of the uplink network in the previous n seconds as input and detect the uplink rate.

[0085] Once the application enters a voice or video call scenario, the Quality of Experience (QA) module can detect the uplink rate of the audio data during the call. In a possible implementation, the QA module can obtain the audio data via Transmission Control Protocol (TCP) and / or User Datagram Protocol (UDP).

[0086] After acquiring the audio data, the Quality Experience module can take the audio data from the previous n seconds at the current moment to calculate the average rate, for example, denoted as avgLowRate, and use this average rate avgLowRate as the uplink rate.

[0087] Understandably, using the average rate to determine the network rate at the current moment can reflect the overall trend of the network rate over a period of time (the first n seconds). This results in more stable data that is not affected by fluctuations in individual unstable data, thus making the judgment more accurate and improving the robustness of the algorithm.

[0088] Of course, the uplink rate can also be calculated using other algorithms, such as summing the rates of the first n seconds, etc. This application does not limit the specific algorithms used.

[0089] After calculating the uplink rate, the Quality Experience module can execute step S304 to determine the uplink rate.

[0090] S304. Is the uplink rate lower than the uplink rate threshold?

[0091] If the uplink rate avgLowRate is lower than the uplink rate threshold ulRateThreshold, that is, the uplink rate is less than the uplink rate threshold, it indicates that the current uplink rate is low and the call quality of the uplink network is poor. Then the quality experience module can execute step S305 to count the number of times the uplink network is low.

[0092] If the uplink rate avgLowRate is not lower than the uplink rate threshold ulRateThreshold, that is, the uplink rate is greater than or equal to the uplink rate threshold, it indicates that the current uplink rate is high and the call quality of the uplink network is good. Then the quality experience module can execute step S308 to clear the low rate count of the uplink network.

[0093] S305, Increment the low-rate counter of the uplink network by 1.

[0094] When the uplink rate is lower than the uplink rate threshold, it indicates that the call quality of the uplink network is poor. The quality experience module can count the number of times the uplink network has a low rate, increment the uplink network low rate count by 1, and execute step S306.

[0095] Optionally, the low-rate count of the uplink network can be based on 0 plus 1, or it can be based on a certain number plus 1, as long as it can achieve statistical counting. This application does not limit the implementation.

[0096] Optionally, the low-rate count of the uplink network can be incremented by 1 or other values, as long as statistical counting can be achieved. This application does not limit this.

[0097] S306. Is the low-rate count of the uplink network greater than the first threshold?

[0098] If the low-rate count of the uplink network is greater than the first threshold, it means that the current application has experienced low-rate situations multiple times, and the quality experience module can execute step S307. Otherwise, the quality experience module executes step S309, indicating that the current application has not experienced any lag.

[0099] The first threshold can be preset by the electronic device based on empirical values, and the specific value of the first threshold is not limited in this embodiment.

[0100] After this loop ends, if the application is in a voice call or video call scenario, the electronic device can re-execute step S303; otherwise, the electronic device can terminate execution. Figure 3 The process corresponding to the embodiment.

[0101] S307. Determine if the application is lagging and set the cause value.

[0102] It is understandable that the quality experience module can set different cause values ​​for different network environments. For example, the cause value for a network disconnection can be represented by PS_DROP; the cause value for a slow or laggy network can be represented by PS_SLOW. The specific representation of the cause values, and the correspondence between network environments and cause values, are not limited in this embodiment.

[0103] In this embodiment, when the quality experience module determines that the Android application package (APK) of the current application is experiencing a continuous low upload speed during operation, it can be considered that the application is lagging. The quality experience module can set the corresponding cause value to QOE_APK_SUBREASON to indicate that the current application has entered a low-speed scenario. The cause value QOE_APK_SUBREASON can also be named using other fields; the specific naming of these fields is not limited in this embodiment.

[0104] The Quality Experience module can pass the cause value to the Fusion Self-Healing module. The Fusion Self-Healing module can execute corresponding self-healing actions based on different cause values. Self-healing actions can also be understood as network optimization processing, such as resetting the network and restarting the application, thereby improving network quality and enhancing user experience.

[0105] S308, Uplink low rate count is set to 0.

[0106] If the uplink rate is greater than or equal to the uplink rate threshold, it indicates that the call quality of the uplink network is good. The quality experience module can clear the low rate count of the uplink network and execute step S309.

[0107] It is understood that the low rate count can be cleared by the quality experience module setting the low rate count to 0, or by the quality experience module setting the low rate count to a negative number, such as -1, or by the quality experience module setting the low rate count to other possible values. This application embodiment does not limit this, as long as the value set by the quality experience module can indicate the cleared state of the low rate count.

[0108] S309. Determine that the application is not lagging.

[0109] When the Quality of Experience (QOE) module determines that the application is not experiencing any lag, it can clear the previously set cause value, QOE_APK_SUBREASON. This allows the electronic device to accurately record whether an application is experiencing lag based on the cause value, enabling more reasonable network settings and maintenance, and improving network stability.

[0110] In potential scenarios, during voice or video calls, if the user remains silent, the call may be in a silent state. In this case, the uplink rate detected by the quality of experience module may be lower than the uplink rate threshold. For example, if the user is not speaking during a call, and the uplink rate detected by the quality of experience module is 12 kilobytes (kb), with an uplink rate threshold of 20 kb, the uplink rate is lower than the threshold. The quality of experience module will then determine that the current network environment is poor, causing the application to lag. It will then set a cause value, allowing the electronic device to optimize the network.

[0111] In other words, a low uplink speed could be due to a poor network environment or because the user is not speaking, resulting in a small amount of audio data being transmitted. Therefore, judging solely by whether the uplink speed is below the uplink speed threshold cannot accurately determine whether the application is experiencing lag or whether network speed optimization is needed. This is because when the electronic device is in a silent call state where the user is not speaking, the quality experience module may misjudge application lag. Therefore, to address this situation, this application embodiment... Figure 3 Based on the corresponding embodiment, a determination of whether there is sound during the call can be added.

[0112] Figure 4 A flowchart is shown to detect application stuttering based on uplink speed and whether there is sound during a call.

[0113] It is understandable that steps S403-S408 are related to determining the uplink speed, steps S409-S413 are related to determining whether there is sound during the call, and step S314 is a step to determine whether the application is experiencing lag based on a combination of the uplink speed and whether there is sound during the call.

[0114] Among them, steps S401-S406 are the same Figure 3 Steps S301-S306 in the corresponding embodiment are similar, as are steps S407-S408. Figure 3 Steps S308-S309 in the corresponding embodiment are similar; the specific execution of each step can be referred to [reference needed]. Figure 3 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0115] S401, Enter the application.

[0116] S402. Determine whether the application has entered a voice call scenario or a video call scenario.

[0117] If the application enters a voice call or video call scenario, step S403 can be executed; otherwise, subsequent steps will not be executed.

[0118] S403. Take the average rate of the uplink network in the previous n seconds as input and detect the uplink rate.

[0119] After the quality experience module calculates the uplink rate, step S404 can be executed to determine the uplink rate.

[0120] S404. Is the uplink rate lower than the uplink rate threshold?

[0121] If the uplink rate avgLowRate is lower than the uplink rate threshold ulRateThreshold, the quality experience module can execute step S405 to count the number of times the uplink network experiences low rates.

[0122] If the uplink rate avgLowRate is not lower than the uplink rate threshold ulRateThreshold, the quality experience module can execute step S307 to clear the low rate count of the uplink network.

[0123] S405, Increment the low-rate counter of the uplink network by 1.

[0124] When the uplink rate is lower than the uplink rate threshold, the Quality Experience Module can increment the low rate count of the uplink network by 1 and execute step S406.

[0125] S406. Is the low-rate count of the uplink network greater than the first threshold?

[0126] If the low-rate count of the uplink network is greater than the first threshold, the quality experience module can execute step S414; otherwise, the quality experience module executes step S408.

[0127] S407, Uplink low rate count is set to 0.

[0128] If the uplink rate is greater than or equal to the uplink rate threshold, the quality experience module can clear the low rate count of the uplink network and execute step S408.

[0129] S408: The application is not experiencing any lag.

[0130] S409. Take the average audio stream of the previous n seconds as input and detect whether there is sound during the uplink call.

[0131] When the application enters a voice call or video call scenario, the audio decoding module can detect whether there is sound during the call.

[0132] In one possible implementation, a call detection point for the audio decoding module (VDM module) can be added to the ADSP driver to acquire audio data. For details on how to add a call detection point for the VDM module to the ADSP driver, please refer to [link / reference needed]. Figure 7 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0133] In the ADSP driver, the call detection point of the VDM module can acquire audio data and report it to the VDM module in the Framework layer. For example, the call detection point of the VDM module can report audio data once every 1 second (s), but other time intervals can also be used, such as once every 0.5s or 2s. This application embodiment does not limit the time interval.

[0134] The VDM module can convert audio data into root mean square (RMS) values ​​and store them in an array. These RMS values ​​can represent the loudness of an audio track, and can also be simply referred to as audio loudness.

[0135] like Figure 5 As shown, the VDM module can store the RMS value corresponding to the audio into a circular array at 1-second intervals. Other time intervals, such as 0.5s or 2s, can also be used; this embodiment does not limit the storage. The array size can be, for example, 10, allowing it to store a maximum of 10 RMS values. Of course, the array size can be preset by the electronic device based on empirical values, as long as it can detect the presence of sound during audio calls based on the RMS values ​​in the array. The specific array size is not limited in this embodiment.

[0136] Understandably, taking an array size of 10 as an example, when the VDM module's call detection point reports the audio data at the 11th second, the VDM module can discard the RMS value at the 1st second in the array and store the RMS value corresponding to the audio data at the 11th second in the array. In this way, the RMS value stored in the array can be in a relatively recent state, thus facilitating the VDM module to detect whether there is sound during the call in real time.

[0137] In this embodiment, empirical testing shows that approximately 10 seconds of audio data is relatively reliable. That is, approximately 10 seconds of data is sufficient to detect whether there is sound in the current audio. If the array stores too much audio data, on the one hand, the audio data may become discontinuous, affecting the audio detection result; on the other hand, the audio data will occupy a significant amount of memory space in the electronic device, and a large amount of audio data means a greater computational load for the electronic device, thus affecting its operating efficiency. If the array stores too little audio data, the detection of whether there is sound in the audio call will be inaccurate, affecting the audio optimization effect. Therefore, this embodiment uses an array size of approximately 10 as a preferred array size.

[0138] Understandably, the VDM module can store the timestamp corresponding to each RMS value when storing the RMS value. This allows for subsequent determination based on the timestamps to identify any low-rate issues during the audio portion of the call, enabling optimization to address these issues, improve call quality, and enhance the user experience.

[0139] When detecting whether there is sound in an uplink call, the VDM module can retrieve the RMS value of the previous m seconds from the array for calculation.

[0140] Since poor network quality typically lasts for a period of time, electronic devices can use the first m seconds of audio data from the array to determine if the application is lagging. However, to reduce the lag in the judgment, m can also be a value less than 10, such as 3 seconds, meaning the VDM module takes the RMS value of the first 3 seconds of the current moment from the array to detect whether there is sound in the call. It is understood that the specific value of m can be determined by different business modules according to their own business needs; m and n can be the same or different, and this application embodiment does not impose any limitations.

[0141] Understandably, using the average value to determine the audio loudness at the current moment can reflect the overall trend of audio loudness over a period of time (the previous m seconds). This results in more stable data that is not affected by fluctuations in individual unstable data, thus making the judgment more accurate and improving the robustness of the algorithm.

[0142] Of course, other algorithms can also be used to calculate audio loudness, such as summing the audio loudness of the first m seconds, etc. This application does not limit the specific methods used.

[0143] After detecting the uplink audio, the audio decoding module can execute step S410 to determine the uplink call.

[0144] S410, Determine if there is sound during an uplink call.

[0145] If there is sound during an uplink call, it indicates that the current uplink speed should be relatively high, for example, the uplink speed can be greater than the speed threshold. If the uplink speed is lower than the speed threshold, it can be determined that the application is lagging, and then step S411 can be executed to count the number of times there is sound during an uplink call.

[0146] If there is no sound during the uplink call, it indicates that the current uplink speed is low, which may be due to the user not speaking during the call, resulting in a small amount of audio data transmission. This should not be judged as application lag. In this case, step S413 can be executed to clear the uplink network call audio count to zero.

[0147] S411, Increment the voice count for uplink network calls by 1.

[0148] When there is sound during an uplink call, the audio decoding module can count the number of calls with sound on the uplink network, for example, by incrementing the uplink network call count ulCallMuteCount by 1 and executing step S412.

[0149] Optionally, the call volume count ulCallMuteCount can be 0 plus 1, or it can be a number plus 1. This application embodiment does not limit this.

[0150] Optionally, the call count ulCallMuteCount can be incremented by 1 or other values, as long as the statistical counting can be achieved. This application embodiment does not impose any limitations.

[0151] S412. Whether the voice count of the uplink network is greater than the second threshold.

[0152] If the call count ulCallMuteCount of the uplink network is greater than the second threshold, it means that the current application is not in a silent call state, and step S414 can be executed to determine whether the application is experiencing lag; otherwise, the current loop ends.

[0153] The second threshold can be preset by the electronic device based on empirical values. The specific value of the second threshold can be understood to be the same as or different from the first threshold, and this application embodiment does not limit it.

[0154] After this loop ends, if the application is in a voice call or video call scenario, the electronic device can re-execute step S409; otherwise, the electronic device can terminate execution. Figure 4 The process corresponding to the embodiment.

[0155] S413, The call audio count for the uplink network is set to 0.

[0156] If there is no sound during the uplink call, the audio decoding module can clear the uplink call count ulCallMuteCount to zero.

[0157] It is understood that the audio decoding module can set the call audio count to 0, or it can set the call audio count to a negative number, such as -1, or it can set the call audio count to other possible values. This application embodiment does not limit this, as long as the set value can indicate the zeroed state of the call audio count.

[0158] S414. When both low-rate counting and call audio counting are satisfied, determine that the application is lagging and set the cause value.

[0159] In a possible implementation, when the uplink network low-rate count is greater than or equal to a first threshold, and the call audio count is greater than or equal to a second threshold, the quality experience module can determine that the application is experiencing lag, and then set a cause value. In other words, when uplink network low rates occur consecutively while call audio is present, the quality experience module can determine that the application is experiencing lag. If the uplink network low-rate count is less than the first threshold, and / or the call audio count is less than the second threshold, the quality experience module can determine that the application is not experiencing lag.

[0160] Optionally, if the uplink network low-rate count equals the first threshold, it can also be determined that the low-rate condition is not met. Similarly, if the call audio count equals the second threshold, it can also be determined that the call audio condition is not met. The specific settings can be configured by the electronic device, and this application embodiment does not limit this.

[0161] Figure 6 A logical diagram illustrating how to determine application lag is shown.

[0162] When the application enters an audio or video scenario, the quality experience module can calculate the number of times the uplink rate is lower than the uplink rate threshold. The audio decoding module can calculate the number of times sound is present during the call.

[0163] Understandably, when there is sound during a call, the audio loudness is usually around -60. The quieter the call, the lower the audio loudness. When the audio loudness reaches -999, it can be determined that there is no sound during the call.

[0164] Taking the example of collecting audio loudness and uplink rate every 1 second, with the first threshold and the second threshold both being 3, when the uplink network low rate count is greater than or equal to the first threshold, and the uplink network call count is greater than or equal to the second threshold, it can also be understood that within 3 seconds, while there is a call, the uplink rate is at a low rate. In this case, the electronic device can determine that the application is lagging, and then the cause value can be set.

[0165] It should be noted that, Figure 4In the corresponding embodiments, the execution order does not strictly follow the step number sequence. For example, the process of detecting the uplink rate and the process of detecting whether there is sound during a call can be executed in parallel. It can also be understood that the uplink rate detection process and the call sound detection process can be executed separately in two threads, and there is no distinction between the execution order of the uplink rate detection process and the call sound detection process. The electronic device can execute the uplink rate detection process first, or it can execute the call sound detection process first, or it can execute the uplink rate detection process and the call sound detection process simultaneously in parallel.

[0166] It is understood that the execution of step S414 requires the detection results of the uplink rate and the detection results of whether there is sound during the call. Therefore, if the electronic device obtains the uplink rate detection result first, it still needs to wait to obtain the detection result of whether there is sound during the call; if the electronic device obtains the detection result of whether there is sound during the call first, it still needs to wait to obtain the uplink rate detection result. The electronic device will only execute step S414 after obtaining the detection results of the uplink rate and the detection results of whether there is sound during the call. Optionally, in this embodiment, the uplink rate threshold and the downlink rate threshold can be set to be the same or different, and this embodiment does not limit this.

[0167] Figure 7 A schematic diagram of the call detection points for the VDM module is shown.

[0168] In this embodiment, the call detection points of the VDM module can be added to the ADSP driver to acquire audio data. The ADSP driver can be used to transmit audio data streams, which can be transmitted via a speaker data transmission link or a microphone data transmission link.

[0169] (1) Description of the speaker data transmission link.

[0170] Taking the speaker data transmission link as an example, the ADSP driver may include a Down Mailbox module, a video quality manager (VQM) module, a streamRxPP port, a DeviceRxPP 3A driver, a deviceRx receiver port, and a speaker driver, etc.

[0171] The Down Mailbox module can be used to communicate with a modem.

[0172] The VQM module can include a first VQM module (VQM 158a0×1) and a second VQM module (VQM 158a0×2). Here, 158a0 can be used to represent an audio dump node. The first VQM module is used to calibrate the audio quality of the audio data, and VQM 158a0×1 indicates that the VQM is placed in a first position. The second VQM module is used to detect the audio quality and determine whether the calibration of the first VQM module is effective. VQM 158a0×2 indicates that the VQM is placed in a second position. Understandably, in some scenarios, the audio quality of the audio data captured by the microphone may be poor, such as due to high audio noise; in such cases, the VQM module can calibrate the audio quality.

[0173] The streamRxPP port can be used to optimize audio data based on echo markers. In a possible call scenario, after an electronic device receives and parses audio data from another electronic device, the streamRxPP port can perform echo-de-echo optimization based on the echo markers in the audio data, thereby improving the user experience. Optionally, the electronic device may or may not perform echo-de-echo optimization.

[0174] The deviceRx receiver port can be used to transmit audio data acquired by electronic devices to the speaker driver, which can then play the audio data through the speaker hardware to enable call functionality.

[0175] The DeviceRxPP 3A driver can convert audio data into audio data that the VQM module can recognize according to certain protocol specifications. In some scenarios, the DeviceRxPP 3A driver can also be understood as the DeviceRxPP 3A port.

[0176] In a possible implementation, the Down Mailbox module can communicate with a modem to receive audio data from the other party's electronic device and pass this audio data to the first VQM module. After calibrating the audio data, the first VQM module can pass the calibrated audio data to the streamRxPP port. The streamRxPP port optimizes the audio data according to echo markers and then passes the audio data to the DeviceRxPP 3A driver. The DeviceRxPP 3A driver can convert the audio data into audio data that the second VQM module can recognize according to a certain protocol specification and pass it to the second VQM module. After detecting that the calibration of the first VQM module is valid, the second VQM module can pass the audio data to the deviceRx receiving port. The deviceRx receiving port can then pass the audio data to the speaker driver, which can then play the audio data through the speaker hardware to realize the call function.

[0177] In this embodiment of the application, detection points of the VDM module can also be added to the ADSP driver. For example, this includes a first detection point (VDM0 / 1 point) and a second detection point (VDM5 point).

[0178] Among them, VDM0, VDM1, VDM3, VDM4 and VDM5 can all be used to represent audio dump nodes, which can be understood as a naming method of VDM.

[0179] For example, the first detection point can be located between the Down Mailbox module and the first VQM module, and the second detection point can be located between the second VQM module and the deviceRx receiving port. It is understood that the first and second detection points can also be set at other locations in the ADSP driver. The specific locations of the first and second detection points in the ADSP driver can be preset by the electronic device, and this embodiment does not limit the specific settings.

[0180] Specifically, during the process of the Down Mailbox module transmitting audio data to the first VQM module, the first detection point can acquire the audio data. During the process of the second VQM module transmitting audio data to the deviceRx receive port, the second detection point can verify whether the acquired audio data is consistent with the audio data acquired by the first detection point.

[0181] If the audio data obtained by the first detection point and the second detection point are consistent, it means that no data loss occurred during the transmission of the audio data. If the audio data obtained by the first detection point and the second detection point are inconsistent, it means that data loss may have occurred during the transmission of the audio data. In this case, the second detection point can optimize the data. For example, the audio data obtained by the first detection point and the second detection point can be averaged to improve the accuracy of the audio data.

[0182] In this embodiment, the first and second detection points in the ADSP driver can detect audio data in real time and report the audio data to the VDM module in the Framework layer. Thus, the VDM module in the Framework layer can detect whether there is sound during a call based on the audio data.

[0183] (2) Description of the microphone data transmission link.

[0184] Taking the microphone data transmission link as an example, the ADSP driver may include a microphone driver, deviceTx transmit port, deviceTxPP 3A driver, VQM module, streamTxPP port and Up Mailbox module, etc.

[0185] The deviceTx send port can be used to obtain audio data reported by the microphone driver.

[0186] The DeviceTxPP 3A driver can convert audio data into audio data that the VQM module can recognize according to certain protocol specifications. In some scenarios, the DeviceTxPP 3A driver can also be understood as the DeviceTxPP 3A port.

[0187] The VQM module may include a first VQM module (VQM 158a0×1) and a second VQM module (VQM 158a0×2). For details, please refer to the relevant description in the above (1) speaker data transmission link description, which will not be repeated here.

[0188] The StreamTxPP port can be used to mark echoes in audio data. In potential call scenarios, the audio data captured by the microphone may contain echoes. The StreamTxPP port can mark the audio data with echoes. When the receiving electronic device parses the audio data, it can use the echo mark to identify the audio data with echoes and perform echo-removal optimization processing, thereby improving the user experience.

[0189] The Up Mailbox module can be used to communicate with a modem.

[0190] In a possible implementation, after the microphone driver acquires audio data, it can pass the audio data to the deviceTx transmit port. The deviceTx transmit port can then pass the audio data to the DeviceTxPP 3A driver. The DeviceTxPP 3A driver can convert the audio data according to a certain protocol specification into audio data that the first VQM module can recognize, and then pass it to the first VQM module. After calibrating the audio data, the first VQM module can pass the calibrated audio data to the streamTxPP port. After the streamTxPP port marks the echoes in the audio data, it can pass the audio data to the second VQM module. After detecting that the calibration of the first VQM module is valid, the second VQM module can pass the audio data to the Up Mailbox module, so that the Up Mailbox module can communicate with the modem and send out the audio data.

[0191] In this embodiment, detection points of the VDM module can also be added to the ADSP driver. For example, this includes a third detection point (VDM4 point) and a fourth detection point (VDM3 point).

[0192] For example, the third detection point can be located between the deviceTx transmit port and the DeviceTxPP 3A driver, and the fourth detection point can be located between the second VQM module and the Up Mailbox module. It is understood that the third and fourth detection points can also be set at other locations in the ADSP driver. The specific locations of the third and fourth detection points in the ADSP driver can be preset by the electronic device, and this embodiment does not limit the specific location.

[0193] Specifically, during the process of transmitting audio data from the deviceTx send port to the DeviceTxPP 3A driver, the third detection point can acquire the audio data. During the process of transmitting audio data from the second VQM module to the Up Mailbox module, the fourth detection point can verify whether the acquired audio data is consistent with the audio data acquired by the third detection point.

[0194] If the audio data obtained from the third and fourth detection points are consistent, it indicates that no data loss occurred during the transmission of the audio data. If the audio data obtained from the third and fourth detection points are inconsistent, it indicates that data loss may have occurred during the transmission of the audio data. In this case, the second detection point can optimize the data processing. For example, the audio data obtained from the third and fourth detection points can be averaged to improve the accuracy of the audio data.

[0195] In this embodiment, the third and fourth detection points in the ADSP driver can detect audio data in real time and report the audio data to the VDM module in the Framework layer. Thus, the VDM module in the Framework layer can detect whether there is sound during a call based on the audio data.

[0196] The methods of this application will be described in detail below through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be described again in some embodiments.

[0197] Figure 8 A call quality detection method according to an embodiment of this application is illustrated. The method includes:

[0198] S801, Electronic device enters call.

[0199] In this embodiment of the application, the call may include a call implemented based on the TCP protocol and / or UDP protocol, such as a voice call or a video call.

[0200] For specific detection of electronic devices entering a call, please refer to... Figure 3 The relevant descriptions of step S302 in the corresponding embodiments will not be repeated here.

[0201] S802. During the first time period of a call, if the network speed during the call is less than the speed threshold, the first parameter is incremented by the first value. The first parameter is used to indicate the number of times the call experiences a low speed.

[0202] In this embodiment of the application, the length of the first time period can be preset by the electronic device. For example, the first time period can be the duration of the call, or the first time period can be a preset period of time, such as 3s, 10s, etc. The specific length of the first time period is not limited in this embodiment of the application.

[0203] Network speed can include uplink network speed and downlink network speed. If the network speed is the uplink network speed, then the speed threshold can be understood as... Figure 3 The uplink rate threshold is ulRateThreshold. If the network rate is the downlink network rate, then the rate threshold can have a corresponding downlink rate threshold.

[0204] The first parameter indicates the number of times the call experienced a low rate. The first parameter may include... Figure 3 The first parameter may also include the low-rate count of the downlink network.

[0205] The first value can include Figure 3In step S305, the low-rate count of the uplink network is incremented by 1. It is understood that the first value can also be set to other values, and this embodiment does not limit this.

[0206] It should be understood that if the network speed during a call is less than the speed threshold, it indicates that the network speed is low and the call quality is poor. Therefore, the number of times the low speed occurs during the call can be counted to help determine whether there is any lag in the call.

[0207] S803. If the audio loudness during the call is greater than the audio loudness threshold within the first time period, the second parameter is incremented by the second value. The second parameter is used to indicate the number of times the call is active.

[0208] In this embodiment, audio loudness can be represented by the root mean square (RMS) value during a call, which can be used to represent the loudness of an audio track. Audio loudness can include the audio loudness of the uplink network and the audio loudness of the downlink network.

[0209] During a call, if there is sound, the audio loudness range can be around -60. It should be understood that the quieter the call, the lower the audio loudness. When the audio loudness reaches -999, it can be determined that the call is silent. Therefore, in this embodiment, the audio loudness threshold can be set to -999, or it can be set to other smaller values; this embodiment does not limit this setting.

[0210] The second parameter indicates the number of times the call was recorded. The second parameter may include... Figure 4 The uplink voice count is used as the first parameter, and the second parameter may also include the downlink voice count.

[0211] The second value can include Figure 4 In step S411, the call audio count of the uplink network is incremented by 1. It is understood that the second value can also be set to other values; the first and second values ​​can be the same or different, and this embodiment does not impose any limitations.

[0212] It should be understood that if the audio loudness during a call is greater than the audio loudness threshold, it means that there is sound during the call. The number of times there is sound during the call can be counted, which makes it easier to determine whether there is any interruption during the call.

[0213] S804. During the first time period, if the first parameter is greater than the first threshold and the second parameter is greater than the second threshold, it is determined that the call has been interrupted.

[0214] In this embodiment, the first parameter is greater than a first threshold, meaning the low-speed count during a call is greater than the first threshold, indicating that the call has experienced low speed multiple times. The second parameter is greater than a second threshold, meaning the audio count during a call is greater than the second threshold, indicating that the call has audio. Therefore, when there is audio but the network speed is low, it can be determined that the call has been interrupted.

[0215] It should be understood that the first parameter being greater than the first threshold may include the first parameter being continuously greater than the first threshold within the first time period; it may also include the first parameter not being continuously greater than the first threshold within the first time period. This application embodiment does not limit this.

[0216] The call quality detection method provided in this application can determine that a call has been interrupted when the electronic device detects that the uplink or downlink network speed is continuously lower than the speed threshold during a voice or video call, and the call is still accompanied by sound. The electronic device can then optimize the network to reduce call interruptions and improve the user experience.

[0217] Optional, in Figure 8 Based on the corresponding embodiments, the method may further include: determining that no stuttering occurred in the call scenario during a first time period, provided that the first parameter is less than or equal to a first threshold and / or the second parameter is less than or equal to a second threshold.

[0218] In this embodiment, the first parameter is less than or equal to a first threshold, meaning the low-rate count during a call is less than or equal to the first threshold, indicating that low-rate occurrences are less frequent and call quality is better. The second parameter is less than or equal to a second threshold, meaning the audio count during a call is less than or equal to the second threshold, indicating that silent calls occur more frequently.

[0219] Since a silent call might be due to the user not speaking during the call, resulting in a smaller amount of audio data being transmitted, it can be determined that the call is not experiencing any interruptions when there is no sound and / or good call quality. Therefore, by comprehensively considering network speed and whether there is sound during the call, it is possible to more accurately determine whether a call is experiencing interruptions and whether further network speed optimization is needed. This reduces the likelihood of misjudging call interruptions when the call is silent due to the user not speaking.

[0220] Optional, in Figure 8 Based on the corresponding embodiments, the method may further include: if the network rate is greater than the rate threshold during the first time period, setting the first parameter to a first initial value.

[0221] In this embodiment of the application, the first initial value may include Figure 3 0 in step S308, or Figure 4 In step S407, the first initial value can be set to other values, as long as they can indicate the zeroing state of the first parameter. The specific value of the first initial value is not limited in this embodiment.

[0222] It is understandable that if the network speed is greater than the speed threshold, it means that the current call has a high network speed and good call quality without any lag. Therefore, it is not necessary to accumulate the count of the first parameter. Thus, the first parameter can be set to the first initial value.

[0223] Optional, in Figure 8 Based on the corresponding embodiments, the method may further include: if the audio loudness is less than the audio loudness threshold during the first time period, setting the second parameter to a second initial value.

[0224] In this embodiment of the application, the second initial value may include Figure 4 In step S413, the second initial value can be set to 0. Of course, the second initial value can also be set to other values, as long as it can indicate the zeroing state of the second parameter. The specific value of the second initial value is not limited in this embodiment.

[0225] Understandably, if the audio loudness is less than the audio loudness threshold, it indicates that the current call is silent, possibly due to the user not speaking during the call. This cannot be used to determine if there is a call interruption. Therefore, there is no need to accumulate the second parameter; the second parameter can be set to a second initial value. Optionally, in Figure 8 Based on the corresponding implementation, the network rate at the first moment is calculated as the average of N network rates recorded in the electronic device before the first moment, where N is a positive integer within the first time period.

[0226] In this embodiment, the network speed is calculated using the following method: Figure 3 In the relevant description of step S302 of the corresponding embodiment, the network rate at the first moment can be understood as the average rate avgLowRate, which will not be repeated here.

[0227] Understandably, using the average rate to determine the network rate at the current moment can reflect the overall trend of the network rate over a period of time (N network rates). The data obtained in this way is more stable and will not be affected by fluctuations in individual unstable data, thus making the judgment result more accurate and improving the robustness of the algorithm.

[0228] Optional, in Figure 8 Based on the corresponding embodiment, the audio loudness at the second moment is calculated as the average of the root mean square (RMS) values ​​of M calls recorded in the electronic device before the second moment, where M is a positive integer during the first time period.

[0229] In this embodiment, the method for calculating audio loudness can be referred to Figure 4 The relevant description in step S409 of the corresponding embodiment, and reference to Figure 5 Corresponding embodiments and Figure 6 The relevant descriptions of the corresponding embodiments will not be repeated. M and N can be the same or different, and this application does not limit this.

[0230] Understandably, using the root mean square (RMS) values ​​of M calls to calculate the average of the current audio loudness can reflect the overall trend of audio loudness over a period of time (RMS values ​​of M calls). This results in more stable data that is not affected by fluctuations in individual unstable data, thus making the judgment more accurate and improving the robustness of the algorithm.

[0231] Optional, in Figure 8 Based on the corresponding embodiment, the electronic device includes an audio digital signal processor (ADSP) and a target module. The ADSP includes detection points of the target module. The target module is used to obtain the root mean square (RMS) values ​​of M calls from the call based on the detection points and record the RMS values ​​of the M calls.

[0232] In this embodiment, the target module can be understood as an audio decoding module (VDM module). The specific implementation method for obtaining the root mean square (RMS) value based on the detection points can be found in [reference needed]. Figure 3 The relevant description in step S409 of the corresponding embodiment, and reference to Figure 5 Corresponding embodiments and Figure 7 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0233] Understandably, the target module can obtain the root mean square (RMS) values ​​of the M adjacent calls at the current time based on the detection point. This allows for the acquisition of more recent RMS values, facilitating real-time detection of whether a call has sound and obtaining RMS values ​​that are more consistent with the current time, thus making the judgment more accurate.

[0234] Optional, in Figure 8 Based on the corresponding embodiments, after determining that a call is stuck, the method may further include: setting a target value as a third value, which is used to instruct the electronic device to perform network optimization processing.

[0235] In this embodiment of the application, the target value can be understood as Figure 3 In the corresponding embodiment, the third value can be understood as QOE_APK_SUBREASON, which can be used to indicate that the current call has entered a low-rate scenario, and can also be used by the electronic device to perform network optimization processing.

[0236] Network optimization may include resetting the network, restarting applications, etc. Specific electronic devices can perform corresponding network optimization according to the actual situation, and this application embodiment does not limit this.

[0237] By setting the target value to a third value and performing network optimization, network quality can be improved and user experience enhanced.

[0238] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0239] The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the aforementioned functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the method steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0240] This application embodiment can divide the apparatus for implementing the method into functional modules based on the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0241] like Figure 9 The diagram shows a chip structure according to an embodiment of this application. The chip 900 includes one or more processors 901, communication lines 902, communication interfaces 903, and memory 904.

[0242] In some implementations, memory 904 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0243] The methods described in the embodiments of this application can be applied to, or implemented by, processor 901. Processor 901 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 901 or by instructions in software form. Processor 901 may be a general-purpose processor (e.g., a microprocessor or conventional processor), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates, transistor logic devices, or discrete hardware components. Processor 901 can implement or execute the various processing-related methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0244] The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in mature storage media in the art, such as random access memory, read-only memory, programmable read-only memory, or electrically erasable programmable read-only memory (EEPROM). This storage medium is located in memory 904, and processor 901 reads the information in memory 904 and, in conjunction with its hardware, completes the steps of the above method.

[0245] The processor 901, memory 904 and communication interface 903 can communicate with each other via communication line 902.

[0246] In the above embodiments, the instructions stored in the memory for execution by the processor can be implemented in the form of a computer program product. This computer program product can be pre-written into the memory, or it can be downloaded and installed into the memory as software.

[0247] This application also provides a computer program product comprising one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from a website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. For example, available media may include magnetic media (e.g., floppy disk, hard disk, or magnetic tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid-state disk (SSD)).

[0248] This application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. The computer-readable medium may include computer storage media and communication media, and may also include any medium capable of transferring a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0249] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM, or other optical disc storage; computer-readable media may also include disk storage or other disk storage devices. Furthermore, any connecting cable may also be appropriately referred to as computer-readable media. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. As used herein, disks and optical discs include optical discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers.

[0250] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

Claims

1. A method for detecting call quality, characterized in that, The method includes: Electronic devices enter a call; During a first time period in the call, the following actions are performed in parallel: if the network rate in the call is less than a rate threshold, a first parameter is incremented by a first value, where the first parameter indicates the number of times the call experiences a low rate; and if the audio loudness in the call is greater than an audio loudness threshold, a second parameter is incremented by a second value, where the second parameter indicates the number of times the call has sound. During the first time period, if the first parameter is greater than the first threshold and the second parameter is greater than the second threshold, it is determined that a call interruption has occurred.

2. The method according to claim 1, characterized in that, The method further includes: During the first time period, if the first parameter is less than or equal to the first threshold, and / or the second parameter is less than or equal to the second threshold, it is determined that no lag occurred in the call scenario.

3. The method according to claim 1 or 2, characterized in that, The method further includes: If the network rate is greater than the rate threshold during the first time period, the first parameter is set to a first initial value.

4. The method according to claim 1 or 2, characterized in that, The method further includes: If the audio loudness is less than the audio loudness threshold during the first time period, the second parameter is set to the second initial value.

5. The method according to claim 1 or 2, characterized in that, The network rate at the first moment is calculated as the average of N network rates recorded in the electronic device before the first moment, where the first moment is within the first time period and N is a positive integer.

6. The method according to claim 1 or 2, characterized in that, The audio loudness at the second moment is calculated as the average of the root mean square (RMS) values ​​of the M calls recorded in the electronic device before the second moment, where the second moment is within the first time period and M is a positive integer.

7. The method according to claim 6, characterized in that, The electronic device includes an audio digital signal processor (ADSP) and a target module. The ADSP includes detection points of the target module. The target module is used to obtain the root mean square (RMS) values ​​of the M calls from the calls based on the detection points, and to record the root mean square (RMS) values ​​of the M calls.

8. The method according to any one of claims 1-2 and 7, characterized in that, After determining that the call scenario has experienced a pause, the process further includes: The target value is set to a third value, which is used to instruct the electronic device to perform network optimization processing.

9. An electronic device, characterized in that, The electronic device includes: one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the electronic device to perform the method as described in any one of claims 1-8.

10. A chip system, characterized in that, The chip system is applied to an electronic device, the chip system including one or more processors, the one or more processors being used to invoke computer instructions to cause the electronic device to perform the method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-8.

12. A computer program product, characterized in that, The computer program product includes computer program code that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1-8.

Images