A microphone audio data processing system and method

Abstract

The application discloses a microphone audio data processing system and method. The system comprises: a drive sharing unit, which is used for sharing a default audio drive of a computer with an external microphone when the microphone is connected, and is not independently identified; a shared memory unit, which is used for receiving original audio data written by the default audio drive; an audio processing interaction unit, which comprises an injected self-developed audio processing object; an effect control unit, which controls the self-developed audio processing object to send the original audio data to a background of a matching application program for effect processing and return to the drive in response to a flag mark sent by the matching application program; and a session distribution unit, which distributes the audio data to each audio application software through an audio session layer of an operating system, and controls the effect processing to be performed only once and the distribution to be broadcast in sequence according to a distribution queue when multiple applications are concurrently used. The application realizes seamless switching of microphone plug-and-play and sound effects, and significantly reduces audio stream conversion delay and redundant loss of computing power when multiple applications are concurrently used.

Description

Technical Field

[0001] This invention belongs to the field of computer audio processing technology, specifically relating to a microphone audio data processing system and method. Background Technology

[0002] With the popularization of scenarios such as live streaming, online meetings, voice-based social networking, and game voice communication, users' needs for microphones are no longer limited to basic sound capture, but also include real-time audio effects processing such as voice changing, noise reduction, and reverb during the capture process.

[0003] In existing audio processing technologies, a common approach to achieving the aforementioned real-time effects processing and distribution is to utilize virtual audio driver technology. Specifically, when an external microphone is physically connected to the computer, the system runs accompanying effects processing software. This software installs and loads one or more virtual audio devices, intercepts and transfers audio data, thereby injecting the effects. However, this virtual driver-based approach has the following technical drawbacks in practical applications: (1) Redundancy in equipment identification and inconvenience in operation: The introduction of virtual drivers leads to additional virtual audio devices in the system's Device Manager, making the audio input device list bloated. When switching between "normal call mode" and "effects processing mode," users usually need to manually select the default audio input device in the operating system's sound settings or the target application software (such as WeChat or game clients), which is cumbersome and makes it difficult to achieve a seamless plug-and-play experience.

[0004] (2) High audio latency and system resource contention: In a typical virtual driver-based workflow architecture, audio data needs to undergo multiple memory copies and cross-process communications between the physical driver buffer, the virtual driver application layer, the audio effect algorithm processing layer, and the target application software. This data transfer process can easily introduce additional audio processing latency, which may lead to audio interruptions, noise, or audio-visual asynchrony in real-time voice interaction scenarios.

[0005] (3) The computing power consumption increases exponentially when multiple applications run concurrently: When a user simultaneously runs multiple applications that require audio data (such as game voice chat, live streaming, and local recording) and all have sound effects enabled, most traditional implementations execute the effects processing algorithm independently for each audio session. This causes CPU usage to rise significantly with the number of applications, potentially leading to system overheating and performance degradation.

[0006] Therefore, overcoming the problems of redundant device switching, high data latency, and repeated consumption of computing power under multi-channel concurrency caused by the virtual audio driver architecture is a technical challenge that urgently needs to be solved in the current audio processing field. Summary of the Invention

[0007] To address the aforementioned issues, this application provides a microphone audio data processing system and method that enables seamless switching of audio effects by sharing the external microphone with the computer's default driver and through flag marking and collaborative control with APO. Furthermore, in multiple application scenarios, only a single effect processing is required for sequential distribution, thereby achieving the technical effects of plug-and-play without driver selection, real-time uninterrupted switching of audio effects, significantly reduced computing power consumption during concurrent use of multiple applications, and continuous data flow.

[0008] In a first aspect, embodiments of this application provide a microphone audio data processing system, including: A shared driver unit is used to enable the external microphone to share the computer's default audio driver when the external microphone is connected to the computer, and the computer's operating system does not recognize the external microphone as an independent audio input device; the default audio driver acquires the raw audio data collected by the external microphone; A shared memory unit is used to receive the original audio data copied and written by the default audio driver; The audio processing interaction unit includes an injected self-developed audio processing object, which interacts with the supporting application through the audio processing port opened by the operating system. The effect control unit, in response to the flag sent by the supporting application, determines whether to perform audio effect processing on the raw audio data in the shared memory unit; when the flag is valid, the self-developed audio processing object transmits the raw audio data to the background of the supporting application for processing, generates processed audio data, and sends it back to the default audio driver. The session distribution unit is used to receive the audio data uploaded by the default audio driver and distribute it to one or more audio application software through the audio session layer of the operating system.

[0009] Preferably, the flag is generated by the supporting application based on the user's function key operations on the interface, and the flag is stored in the shared memory unit for the self-developed audio processing object to read; when the flag is in the first state, audio effect processing is triggered, and when it is in the second state, processing is skipped.

[0010] Preferably, the audio effects processing includes at least one of voice changing, noise reduction, and reverb.

[0011] Preferably, when multiple audio applications simultaneously enable audio effects, the session distribution unit controls the effect control unit to perform effect processing on the original audio data only once, and the processed audio data is distributed by the audio session layer to each audio application in the order in which the functions of the multiple audio applications are enabled.

[0012] Preferably, the audio session layer establishes an application software queue, which arranges the multiple audio applications in the order in which their respective audio effect functions are activated, and the audio session layer distributes the processed audio data sequentially according to the order of the application software queue.

[0013] Preferably, the flag and the original audio data are located in different address segments within the same shared memory region; The self-developed audio processing object acquires the flag and the original audio data simultaneously within the same reading cycle through a single batch read instruction.

[0014] Preferably, the self-developed audio processing object continuously monitors the status changes of the flag marker in the shared memory through a polling method; When the flag is detected to switch from the second state to the first state, the self-developed audio processing object responds to the change in real time and immediately starts to pull and transmit audio data in the shared memory.

[0015] Secondly, embodiments of this application also provide a microphone audio data processing method, including: When an external microphone is connected to the computer, it shares the computer's default audio driver and is not recognized as an independent audio input device. The default audio driver copies the raw audio data acquired through the external microphone to the shared memory; When the accompanying application receives the user's command to enable the effect, it sends a flag. The self-developed audio processing object retrieves raw audio data from shared memory based on the flag and sends it to the background of the supporting application for effect processing via the audio processing port, and then returns the processed data to the default audio driver. The default audio driver uploads the processed data to the audio session layer, which then distributes it to the target audio application software.

[0016] Preferably, the step of distributing data to the target audio application software through the session layer further includes: When multiple target audio applications are detected to be running simultaneously and all of them are in an enabled state, the original audio data, after running through the audio effect processing flow once, is directly distributed by the session layer to the multiple target audio applications in sequence.

[0017] The beneficial effects of this application are as follows: This solution uses an external microphone connected to a computer, sharing the same default audio driver without being recognized as an independent device. The default driver copies the raw audio data to shared memory, and uses flags to control the interaction between the self-developed audio processing object and the accompanying app for effect processing. The processed data is then sent back to the driver and distributed to various applications via the audio session layer. This achieves plug-and-play functionality and seamless effect switching, eliminating the need for users to manually select audio devices. When multiple applications are running concurrently, effect processing is performed only once and distributed sequentially, significantly reducing CPU consumption. The audio data stream remains continuous during effect switching without requiring pipeline rebuilding, effectively avoiding latency and stuttering. Furthermore, it eliminates the need for a separate virtual driver, ensuring compatibility with mainstream Windows systems and significantly reducing development and usage costs. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0019] Figure 1 This is a schematic diagram of the structure of the microphone audio data processing system provided in the embodiments of this application.

[0020] Figure 2 This is a diagram showing the overall architecture topology of the microphone audio data processing system provided in this application embodiment.

[0021] Figure 3 A flowchart illustrating the operation of a microphone audio data processing system provided in an embodiment of this application.

[0022] Figure 4 A flowchart illustrating the operation of a microphone audio data processing system provided in an embodiment of this application.

[0023] Figure 5 A flowchart illustrating the operation of a microphone audio data processing system provided in an embodiment of this application.

[0024] Figure 6 This is a schematic diagram illustrating multiple application optimizations provided in the embodiments of this application.

[0025] Figure 7 This is a schematic flowchart of a microphone audio data processing method provided in an embodiment of this application.

[0026] The objectives, functional features, and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0028] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, components, features, and elements with the same names in different embodiments of this application may have the same meaning or different meanings, the specific meaning of which must be determined by its interpretation in that specific embodiment or further in conjunction with the context of that specific embodiment.

[0029] It should be understood that although the terms first, second, third, etc., may be used herein to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this document, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if," as used herein, may be interpreted as "when," "when," or "in response to determination." Furthermore, as used herein, the singular forms "a," "an," and "the" are intended to also include the plural forms unless the context indicates otherwise. It should be further understood that the terms "comprising," "including," indicate the presence of the stated feature, step, operation, element, component, item, kind, and / or group, but do not exclude the presence, occurrence, or addition of one or more other features, steps, operations, elements, components, items, kinds, and / or groups. The terms "or," "and / or," "including at least one of the following," etc., as used in this application, may be interpreted as inclusive, or mean any one or any combination thereof. For example, "including at least one of the following: A, B, C" means "any one of the following: A; B; C; A and B; A and C; B and C; A and B and C." Similarly, "A, B, or C" or "A, B, and / or C" means "any one of the following: A; B; C; A and B; A and C; B and C; A and B and C." Exceptions to this definition only occur when the combination of elements, functions, steps, or operations is inherently mutually exclusive in some way.

[0030] It should be understood that although the steps in the flowcharts of this application's embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0031] Depending on the context, the words “if” or “suppose” as used here can be interpreted as “when” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrases “if determination” or “if detection (of the stated condition or event)” can be interpreted as “when determination” or “in response to determination” or “when detection (of the stated condition or event)” or “in response to detection (of the stated condition or event).”

[0032] It should be noted that step designations such as S1 are used in this paper for the purpose of more clearly and concisely describing the corresponding content, and do not constitute a substantial restriction on the order.

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

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings (see the accompanying drawings in the disclosure) and specific implementation methods. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0035] Example 1: refer to Figure 1 As shown, this application provides a microphone audio data processing system that does not rely on traditional virtual audio drivers. Instead, it employs an architecture that uses a user-mode Audio Processing Object (APO) in collaboration with specific shared memory. The system mainly includes: a driver sharing unit, a shared memory unit, an audio processing interaction unit, an effects control unit, and a session distribution unit.

[0036] refer to Figure 2 and Figure 3 As shown, in this embodiment, the driver sharing unit of the system is connected to the external microphone. When the external microphone (e.g., a USB microphone, a microphone connected via a sound card physical interface, or a 3.5mm audio jack) is connected to the computer, the external microphone shares the same audio driver as the computer (i.e., the audio driver that comes with the operating system, such as the Windows Direct Audio driver). For the upper-level operating system, no new microphone device name will be added to the sound control panel, thus completely avoiding the recognition confusion caused by multiple physical / virtual devices. At this time, the default audio driver directly takes over and obtains the raw audio data collected by the external microphone. This design prevents the operating system from recognizing the external microphone as an independent audio input device, and eliminates the bloated device list and cumbersome manual switching operations caused by recognizing the external microphone as an independent device in the prior art.

[0037] refer to Figure 4As shown, in this embodiment, the shared memory unit of the system is connected to the driver shared unit and is used to receive the raw audio data written by the default audio driver through a memory copy operation. To ensure the real-time performance and low latency of the audio data stream, the shared memory unit is configured at the underlying level as a relay buffer structure for audio data, providing a data source for subsequent effects processing.

[0038] In one embodiment, to ensure the real-time performance and low latency of the audio stream, the shared memory unit is configured as a circular buffer structure at the underlying level. The specific operation is as follows: Write pointer operation: After the default audio driver obtains the raw audio data, it performs a low-overhead memory copy operation, directly writing the raw audio data to the write pointer position of the circular buffer at high frequency. This write process does not require additional driver layer copying, thereby reducing data transmission latency.

[0039] Read pointer operation: The Audio Processing Object (APO) asynchronously reads the raw audio data from the read pointer position of the circular buffer for subsequent effects processing or direct return.

[0040] Backlog status determination: by continuously calculating the address difference between the write pointer and the read pointer. This allows for precise determination of the data backlog status in the current buffer. If the difference exceeds a preset threshold, it indicates that the upper-layer application is consuming audio data slower than the driver's acquisition speed. In this case, the size of the data block read per transaction will be adaptively adjusted, or a flow control mechanism will be triggered to dynamically eliminate the potential risks of audio popping, packet loss, and audio interruption.

[0041] Through the above-mentioned ring buffer configuration, the shared memory unit 200 realizes zero-copy transmission and read / write synchronization control of audio data, providing underlying support for the efficient and low-latency operation of the entire system.

[0042] In this embodiment, the audio processing interaction unit includes a self-developed audio processing object (APO) injected into the operating system's audio processing pipeline. This self-developed audio processing object maintains efficient cross-process interaction with its companion application (such as a microphone manufacturer's voice changing, noise reduction, and reverb control app, hereinafter referred to as the "companion app") through the operating system's native, open audio processing port (i.e., the APO port). Because the audio processing object runs at the system user layer, even if the companion app or algorithm malfunctions, it will never cause a system blue screen, ensuring the stability of the entire device.

[0043] In one embodiment, after audio effects processing is complete, the accompanying app writes the processed audio data to a pre-agreed designated memory address. The audio processing object does not passively receive data; instead, it actively retrieves the processed data from this designated memory address. This active retrieval mechanism, combined with the aforementioned polling and monitoring flag, constitutes a closed-loop data flow control, enabling the audio processing object to precisely control the timing of data retrieval and prevent data backlog or loss.

[0044] refer to Figure 3 and Figure 4 As shown, in this embodiment, the effect control unit of the system is the "master switch" that controls whether the audio stream is processed. It determines whether to perform audio effect processing on the raw audio data in the shared memory unit in response to a flag sent by the accompanying APP.

[0045] When the cleaning flag is set to the first state (e.g., flag=1), it indicates that the user has enabled sound effects. At this time, the effect control unit is activated. This self-developed audio processing object reads the raw audio data and transmits it in real-time through the audio processing port to the background of the accompanying APP for audio effect processing (including but not limited to at least one of voice changing, noise reduction, and reverb), generating processed audio data and sending it back to the default audio driver. For example... Figure 5 The diagram shown illustrates the retrieval mechanism after the corresponding sound effect processing is completed. After the accompanying APP finishes processing, it writes the finished audio data to a designated dedicated memory address. The self-developed audio processing object retrieves and reclaims the processed audio data from this designated memory address through an active retrieval method.

[0046] When the user disables the sound effects on the interface, the accompanying app resets or rewrites the flag to a second state (e.g., flag=0). At this time, the self-developed audio processing object listens for this state switch through continuous polling (or event triggering mechanism) and immediately responds in real time: it stops transmitting audio data to the background of the accompanying application. The data flow control then directly skips all effect processing flow paths, and the default audio driver directly uploads the raw audio data in shared memory to the operating system's audio session layer. Through this design, during the switching of effects "on / off", the physical device and system driver are never rebuilt, disconnected, or reloaded, and the data flow always remains absolutely continuous, achieving a seamless and lossless switching that is imperceptible to the user.

[0047] In one embodiment, the control mechanism for the flag is detailed as follows: Status Generation: The accompanying app's client interface features multiple function buttons (such as "Voice Changer On", "Professional Noise Reduction", and "Reverb Switch"). When a user clicks the corresponding function button on the interface, the accompanying app immediately generates a corresponding flag in its background.

[0048] Memory space isolation and single-access optimization: To maximize transmission efficiency, the flag is directly written to and stored in a shared memory unit. For example... Figure 4 As shown, the flag is located in a different address segment of the same shared memory region as the aforementioned original audio data (for example, the first 4 bytes store the flag status bit, and the subsequent space stores the audio PCM data block).

[0049] Based on this spatial design, the self-developed audio processing object can simultaneously obtain the latest flag and the corresponding raw audio data within the same bus read cycle by issuing a single batch read instruction in each audio loop cycle. This single-access mechanism significantly reduces CPU I / O overhead compared to the traditional two independent cross-process queries.

[0050] refer to Figure 6 As shown, in this embodiment, after the processed or skipped audio data returns to the default audio driver, the session distribution unit 500 of this application system will receive the audio data uploaded by the default audio driver (whether it is processed data or raw data), and distribute it to one or more upper-layer audio application software (such as WeChat, live streaming software, recording software, Discord, and game voice clients, etc.) through the operating system's audio session layer.

[0051] In one embodiment, when faced with a high-concurrency scenario where multiple audio applications are running simultaneously and all of these applications need to receive audio effects, the specific collaborative distribution steps are as follows: Unified interception and single-time effect processing: When the system detects that multiple target applications are opened at the same time and request audio streams, the session distribution unit forcibly controls the aforementioned effect control unit to run the effect processing algorithm "once and only once" in the background of the corresponding application for this frame of original audio data (such as performing voice-changing processing only once).

[0052] The establishment of the distribution queue: At the same time, the operating system's audio session layer allocates and establishes an application software distribution queue in memory. This queue statically and linearly arranges multiple currently active audio applications according to the order in which they enable their audio functions or the order in which they are mounted by the system.

[0053] Sequential distribution of finished data: After the algorithm backend sends back the uniquely processed audio data, the audio session layer directly and sequentially distributes the same processed audio data to each target audio application software according to the linked list order of the application software distribution queue.

[0054] Through this combined mechanism of "pre-processing in one go + sequential broadcasting and distribution at the session layer," the overhead of algorithm processing becomes a constant independent of the number of applications. Even if 10 voice software programs are running in the background simultaneously, the CPU computing power consumption of the computer is exactly the same as when only one program is running, fundamentally overcoming the historical pain point of system overload and game frame drops caused by traditional multi-channel virtual sound card switching.

[0055] Example 2: refer to Figure 7 As shown, this application embodiment provides a microphone audio data processing method, including: S1. When an external microphone is connected to a computer, it shares the computer's default audio driver and is not recognized as an independent audio input device.

[0056] In this embodiment, when an external microphone (such as a USB microphone or a 3.5mm jack microphone) is plugged into the computer, the driver sharing unit is activated, allowing the external microphone to share the computer's default audio driver (i.e., the audio driver built into the operating system). At this time, the computer's operating system does not add a new microphone device name to the sound control panel, and the external microphone is not recognized as an independent audio input device. The default audio driver directly takes over and begins acquiring raw audio data through the external microphone.

[0057] S2, the default audio driver copies the raw audio data captured by the external microphone to shared memory.

[0058] In this embodiment, after the default audio driver obtains the raw audio data, it writes the raw audio data into a shared memory unit through a low-overhead memory copy operation. As a preferred implementation, this shared memory unit is configured as a circular buffer, and the default audio driver continuously writes audio data to the write pointer position of the circular buffer.

[0059] S3. When the accompanying application receives the user's instruction to enable the effect, it sends a flag to the shared memory.

[0060] In this embodiment, after the user clicks the effect activation button (e.g., "Voice Changer Activated") on the interface of the accompanying application (e.g., a microphone control app), the accompanying application generates a flag and sends and stores the flag in a shared memory unit. This flag is located in a different address segment of the same shared memory region as the original audio data. When the flag is in a first state (e.g., logical value 1), it indicates that audio effect processing is triggered; when it is in a second state (e.g., logical value 0), it indicates that processing is skipped.

[0061] In one embodiment, the accompanying app (i.e., the client interface operated by the user) uses an event listener thread to continuously capture the user's UI interactions. When the user clicks the "One-Click Voice Changer" or "Professional Noise Reduction" virtual button on the interface, the client's business logic layer immediately responds by triggering an interrupt and invoking a memory rewrite instruction. Specifically, the accompanying app, through a pre-acquired shared memory handle and base address, locates a reserved global control status flag address segment (e.g., the first 4 bytes of space with an offset of 0x0000), and forcibly rewrites the value of this address segment from the second status value of the initialization state (e.g., the hexadecimal number 0x00000000) to a valid first status value (e.g., the hexadecimal number 0x00000001). This rewrite operation has global atomicity, ensuring absolute real-time updates and locks of the status bits.

[0062] S4. The self-developed audio processing object retrieves the raw audio data from the shared memory according to the flag, and sends it to the background of the accompanying APP for effect processing through the audio processing port. The processed data is then returned to the default audio driver.

[0063] In this embodiment, the audio processing object in the audio processing interaction unit continuously monitors the state changes of the flag in shared memory using a polling method. When the flag is detected to be in the first state, the audio processing object responds to the flag by retrieving the raw audio data from the shared memory—specifically, reading data from the read pointer position of the circular buffer. Then, the audio processing object sends the raw audio data to the background of the accompanying application via the audio processing port (APO port) opened by the operating system. The accompanying application performs audio effect processing (such as at least one of voice changing, noise reduction, or reverb), generates processed audio data, and writes the processed data to a specified memory address. Subsequently, the audio processing object actively retrieves the processed audio data from the specified memory address and returns the processed data to the default audio driver.

[0064] If the flag is marked as the second state, the audio processing object will not send data to the accompanying application, but will directly send the raw audio data in shared memory back to the default audio driver as is.

[0065] In one embodiment, the self-developed audio processing object injected into the system audio engine continuously reads the status flag bits in the shared memory by means of high-frequency time-slice polling (e.g., once every 2 to 5 milliseconds) or event semaphore triggering.

[0066] When the self-developed audio processing object executes a single batch read instruction, within the same bus read cycle, it not only pulls the flag, but also sequentially pulls the audio pulse code modulation (PCM) raw data block in the following circular buffer.

[0067] Once the flag value is determined to be 0x00000001, the audio processing object internally encapsulates a data packet containing a pointer to the current data block and delivers it across processes to the underlying algorithm core of the accompanying app via the system's open audio processing port. The algorithm core calls a preset noise reduction or voice-changing algorithm model to resample or perform Fast Fourier Transform (FFT) processing on the raw PCM data, generating processed audio data blocks. Subsequently, the accompanying app writes the processed audio data blocks to a designated dedicated reclaimable memory address and sends a completion signal to the audio processing object. The audio processing object uses an active retrieval mechanism to reclaim the finished data and overwrites it in the default audio driver's output buffer.

[0068] S5, the default audio driver uploads the processed data to the audio session layer, which then distributes it to the target audio application software.

[0069] In the embodiments of this application, the default audio driver uploads the received audio data (whether processed or raw) to the audio session layer. The session distribution unit distributes the audio data to one or more target audio applications (such as WeChat, live streaming software, recording software, etc.) that are currently running through the audio session layer.

[0070] S6. When multiple target audio applications are detected to be running simultaneously and all of them are in the enabled state, after the original audio data runs through the audio effect processing flow once, the session layer directly distributes the generated processed audio data to the multiple target audio applications in sequence.

[0071] In this embodiment, when multiple target audio applications are detected to be running simultaneously and all of them have their audio effects enabled, the above method further performs the following optimization operations: the original audio data only undergoes the effect processing flow once (i.e., the processing algorithm of the corresponding application is called only once in step S204). After processing is completed, an application software queue is established by the audio session layer, arranged according to the order in which the functions of each target audio application are enabled, and then the same processed audio data is directly distributed to the multiple target audio applications in sequence.

[0072] This optimization avoids the significant CPU consumption caused by performing effect processing independently for each application in the traditional approach, thus significantly reducing system resource usage.

[0073] In one embodiment, when the system detects that multiple third-party target applications, such as WeChat, live streaming software, and game voice chat, are simultaneously requesting input streams from the system's audio engine, the session distribution unit activates a concurrency optimization mechanism. At this point, regardless of the number of upper-layer applications, the system forcibly disconnects the default "one-to-many" independent call chain. The default audio driver always uploads only the finished audio data that has already been processed once by the accompanying application's background in step S104.

[0074] The audio session layer dynamically maintains a linked list queue of application software in memory. When each application registers for audio monitoring with the system, it is sequentially added to the linked list nodes according to the registration timestamp (e.g., WeChat is added to node 1, and the live streaming software is added to node 2). The audio session layer uses a single-threaded loop or asynchronous broadcast mechanism to distribute the starting address pointer of the same block of finished audio data in memory to each application software in the order of the linked list nodes.

[0075] Furthermore, during the method's execution, if the user disables the sound effects on the interface, the system executes a seamless switching sub-process: the accompanying application quickly resets the flag to 0x00000000, and the self-developed audio processing object, upon detecting this change, immediately shuts down the channel for sending data to the APO port. Data flow control is directly redirected, and the default audio driver seamlessly uploads the raw audio data from shared memory to the system audio session layer for queue distribution. The entire switch from "on" to "off" sound effects is completed within microseconds, without destroying or rebuilding the original audio session, ensuring absolute continuity of the user's call or live audio stream.

[0076] In summary, the microphone audio data processing system and method provided by this invention have the following significant advantages compared to traditional virtual audio driving solutions: 1. True "plug and play" and seamless switching greatly enhance the user experience: Driver-free and device-switching-free: This invention uses a shared driver unit to directly shield the exposure of independent nodes and redirect the data channel after a physical device is connected, allowing the external microphone to fully reuse the computer's default audio driver. Users do not need to frequently and manually switch the default audio input device in the operating system or third-party software when turning sound effects on or off, truly achieving "plug and play".

[0077] Seamless state transitions: Audio flow is controlled at the code logic layer using lightweight flags. When an effect is turned off, data flow control skips the effect processing path, and the default driver directly uploads the raw data to the session layer. The audio stream remains continuous throughout the switching process, without interruption or reconstruction, eliminating device stuttering or brief silences caused by switching sound effects in traditional solutions.

[0078] 2. A "zero-copy" data flow architecture was created, significantly reducing audio processing latency: High-efficiency memory management: This invention eliminates the cumbersome mechanism of frequent cross-process communication and high-frequency memory copying between multi-layer architectures in traditional virtual drivers. By introducing a shared memory unit configured as a circular buffer structure, the default audio driver and the self-developed audio processing object directly exchange data in real time through the difference between read and write pointers, achieving zero-copy-level pointer flow, significantly reducing audio flow latency, and effectively avoiding problems such as popping sounds, stuttering, and audio-visual desynchronization.

[0079] Atomic-level read optimization: The self-developed audio processing object obtains the flag and raw audio data from different address segments of shared memory simultaneously in the same read cycle through a single batch read instruction, further squeezing the transmission performance of the underlying hardware and ensuring extremely high real-time performance of audio control.

[0080] 3. It pioneered the "Session-based single-processing" mechanism, fundamentally overcoming the redundancy of computing power in multi-concurrency scenarios: Computational power consumption is reduced to a constant level: In concurrent scenarios where multiple audio applications are running simultaneously and all effects are enabled, this invention changes the outdated mechanism of "repeatedly running the algorithm for each audio session" in traditional solutions. This solution controls the effect control unit to perform the effect processing flow only once on the raw audio data.

[0081] Efficient sequential distribution mechanism: By establishing a distribution queue at the front end of the operating system's audio session layer, the processed audio data is directly distributed sequentially according to the order in which applications are opened. This prevents the system's CPU consumption from skyrocketing with the increase in the number of applications running, effectively solving the underlying pain points of computer overheating, slow system response, and game frame drops when running multiple applications.

[0082] It is understood that the above scenarios are merely examples and do not constitute a limitation on the application scenarios of the technical solutions provided in the embodiments of this application. The technical solutions of this application can also be applied to other scenarios. For example, as those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0083] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0084] The steps in the method of this application embodiment can be adjusted, combined, or deleted according to actual needs.

[0085] The units in the device of this application embodiment can be merged, divided, and deleted according to actual needs.

[0086] In this application, the same or similar terms, concepts, technical solutions and / or application scenario descriptions are generally described in detail only when they appear for the first time. When they appear again, they are generally not repeated for the sake of brevity. When understanding the technical solutions and other contents of this application, the same or similar terms, concepts, technical solutions and / or application scenario descriptions that are not described in detail later can be referred to their previous relevant detailed descriptions.

[0087] In this application, the descriptions of the various embodiments have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0088] The technical features of the present application can be combined in any way. For the sake of brevity, 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 the present application.

[0089] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A microphone audio data processing system, characterized in that, The system includes: A shared driver unit is used to enable the external microphone to share the computer's default audio driver when the external microphone is connected to the computer, and the computer's operating system does not recognize the external microphone as an independent audio input device; the default audio driver acquires the raw audio data collected by the external microphone; A shared memory unit is used to receive the original audio data copied and written by the default audio driver; The audio processing interaction unit includes an injected self-developed audio processing object, which interacts with the supporting application through the audio processing port opened by the operating system. The effect control unit, in response to the flag sent by the supporting application, determines whether to perform audio effect processing on the raw audio data in the shared memory unit; when the flag is valid, the self-developed audio processing object transmits the raw audio data to the background of the supporting application for processing, generates processed audio data, and sends it back to the default audio driver. The session distribution unit is used to receive the audio data uploaded by the default audio driver and distribute it to one or more audio application software through the audio session layer of the operating system.

2. The system according to claim 1, characterized in that, The flag is generated by the accompanying application based on the user's function key operations on the interface. The flag is stored in the shared memory unit for the self-developed audio processing object to read. When the flag is in the first state, audio effect processing is triggered; when it is in the second state, processing is skipped.

3. The system according to claim 1, characterized in that, The audio effects processing includes at least one of voice changing, noise reduction, and reverb.

4. The system according to claim 1, characterized in that, When multiple audio applications simultaneously enable audio effects, the session distribution unit controls the effect control unit to perform effect processing on the original audio data only once. The processed audio data is then distributed by the audio session layer to each audio application in the order in which the functions of the multiple audio applications are enabled.

5. The system according to claim 4, characterized in that, The audio session layer establishes an application software queue, which arranges the multiple audio applications in the order in which their respective audio effect functions are enabled. The audio session layer distributes the processed audio data sequentially according to the order of the application software queue.

6. The system according to claim 2, characterized in that, The flag and the original audio data are located in different address segments within the same shared memory region; The self-developed audio processing object acquires the flag and the original audio data simultaneously within the same reading cycle through a single batch read instruction.

7. The system according to claim 2, characterized in that, The self-developed audio processing object continuously monitors the status changes of the flag marker in the shared memory through a polling method. When the flag is detected to switch from the second state to the first state, the self-developed audio processing object responds to the change in real time and immediately starts to pull and transmit audio data in the shared memory.

8. The system according to claim 1, characterized in that, After the audio effects processing of the accompanying application is completed, the processed audio data is written to a specified memory address, and the self-developed audio processing object retrieves the processed audio data from the specified memory address in an active fetching manner.

9. A microphone audio data processing method, applied to the system described in claims 1-8, characterized in that, The method includes: When an external microphone is connected to the computer, it shares the computer's default audio driver and is not recognized as an independent audio input device. The default audio driver copies the raw audio data acquired through the external microphone to the shared memory; When the accompanying application receives the user's command to enable the effect, it sends a flag. The self-developed audio processing object retrieves raw audio data from shared memory based on the flag and sends it to the background of the supporting application for effect processing via the audio processing port, and then returns the processed data to the default audio driver. The default audio driver uploads the processed data to the audio session layer, which then distributes it to the target audio application software.

10. The method according to claim 9, characterized in that, The step of distributing data to the target audio application software through the session layer further includes: When multiple target audio applications are detected to be running simultaneously and all of them are in an enabled state, the original audio data, after running through the audio effect processing flow once, is directly distributed by the session layer to the multiple target audio applications in sequence.

Images