A microkernel-based method of audio virtualization

Abstract

The application discloses a kind of audio virtualization methods based on microkernel, it is related to audio virtualization technical field, to solve the problem of slow response speed, insufficient real-time of existing virtualization audio technology under macrokernel architecture, by significantly improving the efficiency and real-time of virtual audio device processing audio signal.DMA technology is used to make the audio signal in the virtual machine bypass the traditional virtual audio processing flow, directly and quickly transmit to the hardware audio device through the virtual machine controller for playing, significantly reduce the processing delay of audio signal, guarantee the purity and coherence of sound quality.Stronger interrupt mechanism is used to realize the control and communication between virtualization audio device and hardware audio device, to ensure that the system can respond quickly when emergency or high-priority audio event occurs, realize the instant playback of audio signal.

Description

Technical Field

[0001] This invention relates to the field of audio virtualization technology, and in particular to a microkernel-based audio virtualization method. Background Technology

[0002] Audio virtualization technology abstracts physical audio hardware resources, simulating audio devices in a virtual environment. This provides independent audio input / output interfaces for applications within virtual machines or containers, ensuring that audio processing tasks in different virtual environments do not interfere with each other. The technology also allows users to dynamically adjust the resource configuration of the virtual environment according to actual needs, providing flexibility in resource utilization and allocation.

[0003] In the currently widely adopted monolithic kernel architecture, audio virtualization typically integrates audio processing functions into the kernel and utilizes kernel scheduling, memory management, and device drivers to achieve the virtualization and isolation of audio resources. In this architecture, the workflow of virtual audio devices is relatively complex. Audio signals generated by applications within the virtual machine need to be forwarded to the physical hardware audio device via complex routing by the virtualization software to ensure proper playback. This process involves multiple layers of data exchange and protocol conversion, inevitably leading to delays in sound propagation and potential sound quality loss. Furthermore, due to the high complexity of the monolithic kernel, the operation of virtual audio devices cannot guarantee real-time performance, potentially causing delays in audio processing tasks. In some application scenarios with extremely high real-time audio requirements, such as within in-vehicle operating systems, applications running within virtual machines rely on virtualized audio devices to issue critical alarm sounds instantly. The rapid triggering of these sound signals is crucial for ensuring driving safety. However, audio virtualization technology under the monolithic kernel architecture falls short in meeting such high-time-sensitivity demands, struggling to satisfy the requirements for immediate, zero-latency audio output.

[0004] Microkernel architecture decouples kernel functions, with non-core functions such as the file system and device drivers designed as independent services running in user space. This decoupled, lightweight kernel can respond quickly to external events and requests. Furthermore, the modular design ensures that services are independent of each other; a delay or failure in one service will not directly affect other services, thus improving the overall system's real-time performance. However, audio virtualization technology under a microkernel architecture also faces a series of challenges. The transmission of audio signals from the virtual audio device inside the virtual machine to the physical audio device involves complex routing, and due to the characteristics of microkernel architecture, it also involves multiple switches between user mode and kernel mode. This significantly impacts audio signal transmission efficiency, potentially causing playback delays and resulting in unsatisfactory playback quality.

[0005] Therefore, a microkernel-based audio virtualization method is needed. Summary of the Invention

[0006] To address all or some of the aforementioned problems, the present invention aims to provide a microkernel-based audio virtualization method that can solve the problems of slow response speed and insufficient real-time performance of existing virtualized audio technologies under monolithic kernel architecture.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a microkernel-based audio virtualization method, comprising the following steps:

[0008] S1: The virtualization manager (3) encapsulates the corresponding control interface, which is used to receive requests from audio devices in UOS and forward the requests to SOS. When the audio device completes the requested task, it will return the processing status to UOS;

[0009] S2: The virtual PCM device and virtual control device in UOS send control signals. The generated control signals are placed in the message queue. The virtual audio processing module reads the control signals from the message queue and processes the signals using the APIs provided in the audio interface library. The virtualization manager forwards the processed control signals to SOS. After receiving the control signals, SOS transmits the signals to the physical hardware audio devices through the audio device driver to execute the actual audio control operations. After the hardware audio devices complete the control operations, they will feed back the operation results to the virtualization manager, which then notifies the virtual audio devices in the user's virtual machine, thus completing the entire control process.

[0010] S3: When UOS starts and initializes its audio subsystem, it loads the audio driver and recognizes the audio hardware. Then, it creates the corresponding virtual PCM device. At this point, under the coordination of the virtualization manager, a region in memory is allocated for DMA access. UOS then sends the address of this memory region to SOS via a message queue. SOS writes this address into the driver settings of the hardware audio device. Both the virtual audio device in UOS and the hardware audio device in SOS access the same memory region via DMA, enabling direct data exchange between them.

[0011] S4: Virtual audio devices in UOS and hardware audio devices in SOS can access the same memory block via DMA. When one of them writes data to the DMA memory, a DMA interrupt will be triggered when the buffer is full. The shared interrupt service process in the microkernel virtual machine manager is responsible for responding to and handling such interrupts.

[0012] Furthermore, the initialization steps of the virtual audio device are as follows:

[0013] 1. Initialize the virtual sound card and complete the configuration in SOS;

[0014] 2. SOS continuously monitors messages on the UOS side;

[0015] 3. After SOS detects a message from UOS, it immediately processes the message and then resumes listening.

[0016] 4. In UOS, the message queue is initialized first to control information communication;

[0017] 5. UOS creates a new virtual sound card;

[0018] 6. UOS sends a request to SOS and obtains the correct configuration parameters for the virtual sound card;

[0019] 7. UOS constructs virtual PCM, chamap, control, and jack nodes according to the configuration parameters;

[0020] 8. UOS completes the registration of the virtual sound card device in the system, and then uses the device to process audio tasks.

[0021] Furthermore, in S2, the UOS and SOS communicate via a message queue to exchange control information about the virtual PCM / control interface. The virtual PCM interface information control includes: opening / closing the virtual PCM interface, setting hardware parameter information, and device prepare.

[0022] Furthermore, the virtual PCM / control interface information transmission steps are as follows:

[0023] S21: UOS encapsulates PCM control information or control command information in the audio device driver and then puts it into the message queue;

[0024] S22: The virtual audio processing module in the microkernel virtual machine manager retrieves encapsulated information from the message queue;

[0025] S23: The virtual audio processing module uses the API provided by the audio interface library to parse information;

[0026] S24: The virtual audio processing module transfers information to the virtual machine monitor in the service virtual machine;

[0027] S25: The virtual machine monitor calls the control information / control command parsed from the corresponding interface in the audio interface library in the kernel;

[0028] S26: Control commands are sent to the audio device driver;

[0029] S27: Access or control audio hardware via audio device drivers;

[0030] S28: The audio device driver receives feedback on the running results;

[0031] S29: The result is returned to the audio device interface library;

[0032] S210: The result is returned to the virtual machine monitor;

[0033] S211: The result is returned to the virtual audio processing module in the virtual machine manager;

[0034] S212: The virtual audio processing module puts the returned result into the message queue;

[0035] S213: The UOS audio device driver retrieves the result of calling the audio hardware device from the message queue.

[0036] Furthermore, the PCM interface data transfer steps are as follows:

[0037] S201: UOS allocates memory for DMA access in the audio device driver's hardware parameter setting function;

[0038] S202: The audio device driver records the allocated DMA memory address, calls the virtual control interface, and adds the control information containing the DMA memory address to the message queue in the form of control commands.

[0039] S203: The virtual audio processing module in the virtual machine manager reads messages from the message queue and parses the DMA memory address from the messages;

[0040] S204: The virtual audio processing module sets the DMA memory address through the audio interface library, bringing this memory area under the supervision of the virtual machine manager, who is responsible for restricting access permissions and protecting data security.

[0041] S205: The virtual audio processing module sends the DMA memory address to the virtual machine monitor in the service virtual machine;

[0042] S206: The virtual machine monitor calls the corresponding API in the pcm / Control interface library in the kernel of the service virtual machine to pass the DMA memory address to the DMA management module;

[0043] S207: The DMA management module adds the DMA memory address to the interface corresponding to PCM, enabling the service operating systems SOS and UOS to share this memory and achieve data exchange;

[0044] S208: GuestOSVM puts the "readiness information" of the virtual PCM interface into the message queue to notify the virtual machine manager that its virtual PCM interface is ready and working normally;

[0045] S209: The virtual audio processing module in the virtual machine manager reads messages from the message queue;

[0046] S2010: The virtual audio processing module updates the status parameters of the corresponding PCM device it manages through the audio interface library;

[0047] S2011: The virtual audio processing module sends "preparation information" to the virtual machine monitor in the service virtual machine;

[0048] S2012: The virtual machine monitor calls the corresponding API in the pcm / Control interface library in the kernel to set the status parameters of the corresponding pcm device in the service virtual machine;

[0049] S2013: When setting status parameters, the audio device driver will also configure the DMA memory address in the audio device.

[0050] Furthermore, the virtual PCM interface data flow and interrupt control processing flow are as follows: the virtual PCM interface writes data to the DMA. When the buffer is full, an interrupt is triggered. This interrupt is responded to by the microkernel-based virtualization manager. First, the SOSmanager determines the correct handler for the interrupt. If the interrupt is sent to the SOS, the SOSmanager will transfer it to the SOS for processing through the VCPUinterface. If the interrupt is sent to the UOS, the SOSmanager will transfer it to the corresponding UOSmanager, which will then transfer it to the corresponding UOS for processing.

[0051] Furthermore, the specific steps of the virtual PCM interface data flow process and interrupt control processing process are as follows:

[0052] (1) The audio device driver writes data to the DMA memory, and an interrupt is triggered when the buffer is full;

[0053] (2) The audio device driver directly writes to the register to start the audio device interrupt;

[0054] (3) The shared interrupt service process in the virtual machine manager captures the interrupt;

[0055] (4) The virtual machine manager calls the service virtual machine manager to handle the interrupt. It first saves the current interrupt status information and then determines its sending target;

[0056] (5) If the target of the interrupt is a certain UOS, the service virtual machine will forward the interrupt to the corresponding user virtual machine manager, and the subsequent processing flow is similar to that in the service virtual machine.

[0057] (6) After the interrupt is handled, the CPU will restore the previously saved breakpoint and context information, and return to the next instruction of the interrupted program to continue execution.

[0058] Furthermore, the specific steps in step (4) are as follows:

[0059] (4.1) If its target is the service virtual machine SOS, the interrupt is sent to SOS and received by the virtual machine CPU interface in SOS;

[0060] (4.2) Call the interrupt request handler to process the interrupt;

[0061] (4.3) The audio device interface library provides an API interface to handle this interrupt;

[0062] (4.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory;

[0063] (4.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module.

[0064] Furthermore, the specific steps in step (5) are as follows:

[0065] (5.1) The interrupt is sent to UOS and received by the virtual machine CPU interface in UOS;

[0066] (5.2) Call the interrupt request handler to process the interrupt;

[0067] (5.3) The audio device interface library provides an API interface to handle this interrupt;

[0068] (5.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory;

[0069] (5.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module.

[0070] Compared with the prior art, the beneficial effects of the present invention are:

[0071] This invention proposes a microkernel-based audio virtualization method, which redefines the overall architecture and workflow of audio virtualization under a microkernel framework to significantly improve the efficiency and real-time performance of virtual audio devices in processing audio signals. Utilizing DMA (Direct Memory Access) technology, audio signals in the virtual machine can bypass traditional virtual audio processing flows and be directly and quickly transmitted to the hardware audio device for playback via the virtual machine controller, significantly reducing audio signal processing latency and ensuring pure and consistent sound quality. A more real-time interrupt mechanism is employed to implement control and communication between the virtualized audio device and the hardware audio device, ensuring that the system can respond quickly to urgent or high-priority audio events, achieving instant playback of audio signals. Attached Figure Description

[0072] Figure 1 This is a schematic diagram of the overall architecture of the microkernel-based audio virtualization method of the present invention;

[0073] Figure 2 This is a schematic diagram illustrating the initialization process of a virtual audio device based on the microkernel-based audio virtualization method of the present invention.

[0074] Figure 3 This is a schematic diagram of the virtual PCM / control interface information transmission process in the microkernel-based audio virtualization method of the present invention;

[0075] Figure 4 This is a schematic diagram of the PCM interface data flow structure of the microkernel-based audio virtualization method of the present invention;

[0076] Figure 5 This diagram illustrates the specific data flow transmission and interrupt handling process of the microkernel-based audio virtualization method of this invention. Detailed Implementation

[0077] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0078] like Figures 1-5 As shown, a microkernel-based audio virtualization method is presented. This invention provides a method and device for virtualized audio processing in a microkernel-based virtualization environment, enabling multiple User VMs and Server VMs to share the same physical resources, making full use of physical audio resources and reducing costs.

[0079] like Figure 1As shown in the diagram, the User OS (UOS) is the guest virtual machine, and there can be multiple guest virtual machines in the entire architecture. Each guest virtual machine is an isolated runtime environment, running its own operating system and applications independently, ensuring the security and stability of applications and services running in the virtual machine. APP represents the application software and services running in the virtual machine. The main function of the Audio Hardware Abstraction Layer (HHI) is to provide a unified interface for audio applications, enabling them to access and control virtual audio devices. The audio interface library provides a set of APIs for direct interaction with the audio driver. The audio device driver is used to control and interact with the audio device, performing various audio-related tasks. The UOS virtualizes devices such as PCM, control, and Jack, and the UOS interacts with these virtual audio devices through the audio device driver. When an application in the guest virtual machine needs to play audio, the application calls the audio interface library through the interface provided by the HHI to perform the operation. The audio interface library forwards the request to the corresponding audio device driver. The audio device driver interacts directly with the virtual audio device, performing data capture, processing, or playback.

[0080] In the diagram, the Server OS (SOS) is the service virtual machine, the central control point of the entire virtualization architecture. The service virtual machine is responsible for the allocation, management, and monitoring of hardware and software resources, as well as providing services to guest virtual machines. It has direct access to physical hardware resources, such as CPU, memory, storage devices, network interfaces, and audio devices. The Virtual Machine Monitor (VMM) monitors the running status of guest virtual machines through the Micro-Kernel Hypervisor. In this invention, the main function of the VMM is to communicate with the virtual audio processing module in the Hypervisor to receive control information sent by the UOS through message queues, and to parse and process these instructions using the audio device interface library. The audio device interface library forwards the control information to the corresponding audio device driver, thereby achieving precise control of the physical audio hardware.

[0081] The microkernel hypervisor is a key component connecting the service virtual machine (SOS) and the user virtual machine (UOS). It not only manages and monitors both, but also handles the transfer of data and instructions between virtual machines and between virtual machines and physical hardware. Employing a microkernel architecture, various functions are mounted as modules on the kernel, allowing for functional expansion. Therefore, it can be considered an operating system, as shown in the diagram as the Microkernel Hypervisor OS. Audio control information is exchanged between the hypervisor and the user operating system (UOS) via message queues. The virtual audio processing module listens to the message queues, reads control information, and, with the cooperation of the virtual machine monitor, forwards it to the audio device driver through the audio device interface library. A shared interrupt service process handles various interrupt requests in audio virtualization. When an interrupt is triggered, this service process quickly intervenes, identifies the interrupt type, and determines whether the interrupt request should be handled by the service operating system (SOS) or the user operating system (UOS) based on the flag bits in the interrupt signal, forwarding it to the appropriate system.

[0082] Furthermore, the steps of the microkernel-based audio virtualization method are as follows:

[0083] (1) UOS virtualizes audio devices such as PCM, control, and Jack, and establishes a mapping relationship between virtual devices and physical hardware devices with the support of the hypervisor. The hypervisor encapsulates the corresponding control interface to receive requests from virtual audio devices in UOS and forward these requests to the service operating system (SOS). When the audio device completes the requested task, it returns the processing status to UOS, thereby ensuring the smooth operation of audio.

[0084] (2) Control information between the virtual audio device and the hardware audio device is communicated through a message queue mechanism. The virtual PCM device and virtual control device in the guest virtual machine (UOS VM) send control signals, which may include operations such as play, pause, volume adjustment, and status query. The generated control signals are placed in a message queue, which is used to transmit information between the virtual audio device and the virtualization manager. The virtual audio processing module in the virtualization manager continuously monitors the message queue and waits for new control signals. The virtual audio processing module reads the control signals from the message queue and processes the signals using the APIs provided in the audio interface library. The virtualization manager forwards the processed control signals to the service virtual machine (SOS). After receiving the control signals, the service virtual machine (SOS) transmits the signals to the physical hardware audio device through the audio device driver to perform the actual audio control operation. After the hardware audio device completes the control operation, it feeds back the operation result to the virtualization manager, which then notifies the virtual audio device in the user virtual machine (UOS VM), thus completing the entire control process.

[0085] (3) Virtual audio devices and hardware audio devices achieve rapid audio information flow through DMA technology. When UOS starts and initializes its audio subsystem, it loads the audio driver and identifies the audio hardware, then creates the corresponding virtual PCM device. At this time, under the coordination of the virtualization manager, a region in memory is allocated for DMA access. Then UOS sends the address of this memory to SOS through the message queue (i.e., the message queue in step (2)). SOS writes the address into the driver settings of the hardware audio device. Thus, the virtual audio device in UOS and the hardware audio device in SOS, mainly the PCM device, realize the interaction of audio information data flow through the DMA mechanism, and both can perform DMA access on the same memory. Through this DMA memory, direct data exchange is realized between the two.

[0086] (4) The virtual audio device in UOS and the hardware audio device in SOS can access the same memory block via DMA. When one of them writes data to the DMA memory, a DMA interrupt will be triggered when the buffer is full. The shared interrupt service process in the microkernel virtual machine manager is responsible for responding to and handling such interrupts. This invention customizes the bits in the "shared IRQ" and adds bits indicating the forwarding object of the interrupt to the IRQ. The microkernel virtual machine manager stores the ownership relationship of the PCM interfaces, that is, which PCM interfaces are used by the UOS VM and which PCM interfaces are used by the SOS VM. When the microkernel virtual machine manager captures an interrupt, it can parse the destination of the interrupt from the corresponding bit, compare it with the record in the PCM interface ownership relationship file, and finally determine whether the interrupt is handled by UOS or SOS, and forward it to the corresponding object. DMA interrupts are hardware interrupts and will be captured and processed immediately by the virtual machine manager, thus ensuring the continuity and real-time performance of the audio information stream.

[0087] like Figure 2 As shown, the specific steps of the virtual audio device initialization process are as follows:

[0088] (1) Initialize the virtual sound card and complete the configuration in the Service Operating System (SOS);

[0089] (2) SOS continuously listens for messages on the UOS side;

[0090] (3) After SOS detects a message from UOS, it immediately processes the detected message and then returns to the listening state after processing.

[0091] (4) First, the message queue is initialized in the user operating system (UOS) to control the communication of information;

[0092] (5) UOS creates a new virtual sound card;

[0093] (6) UOS sends a request to SOS and obtains the correct configuration parameters of the virtual sound card;

[0094] (6) UOS constructs virtual PCM, chamap, control, and jack nodes according to the configuration parameters.

[0095] (7) UOS completes the registration of the virtual sound card device in the system, and then the device can be used to process audio tasks.

[0096] like Figure 3As shown, the control information exchange process of the virtual PCM / control interface between UOS and SOS is implemented through a message queue. The virtual PCM interface control information includes: opening / closing the virtual PCM interface, setting hardware parameters, and device prepare; these are encapsulated information conforming to the virtual sound device specification. The virtual PCM / control interface information transmission process is shown in the following diagram, which includes the following 10 steps:

[0097] (1) The UOS VM encapsulates PCM control information or control command information in the audio device driver and then puts it into the message queue;

[0098] (2) The virtual audio processing module in the microkernel virtual machine manager obtains the encapsulated information from the message queue;

[0099] (3) The virtual audio processing module uses the API provided by the audio interface library to parse information;

[0100] (4) The virtual audio processing module transfers the information to the virtual machine monitor in the service virtual machine;

[0101] (5) The virtual machine monitor calls the corresponding interface in the audio interface library in the kernel to parse the control information / control command;

[0102] (6) Control commands are sent to the audio device driver;

[0103] (7) Access or control audio hardware via audio device drivers;

[0104] (8) The audio device driver receives feedback on the running results;

[0105] (9) The result is returned to the audio device interface library;

[0106] (10) The results are returned to the virtual machine monitor;

[0107] (11) The result is returned to the virtual audio processing module in the virtual machine manager;

[0108] (12) The virtual audio processing module puts the returned results into the message queue;

[0109] (13) The UOS audio device driver retrieves the result of calling the Audio hardware device from the message queue.

[0110] like Figure 4 As shown, the virtual PCM interface DMA memory configuration process and the PCM stream data transfer process are as follows:

[0111] (1) The UOS VM allocates memory for DMA access in the function for setting hardware parameters of the audio device driver;

[0112] (2) The audio device driver records the allocated DMA memory address and calls the virtual control interface to add the control information containing the DMA memory address to the message queue in the form of control commands.

[0113] (3) The virtual audio processing module in the virtual machine manager reads messages from the message queue and parses the DMA memory address from the messages;

[0114] (4) The virtual audio processing module sets the DMA memory address through the audio interface library, brings this area of ​​memory under the supervision of the virtual machine manager, and the virtual machine manager is responsible for restricting access permissions and protecting data security;

[0115] (5) The virtual audio processing module sends the DMA memory address to the virtual machine monitor in the service virtual machine;

[0116] (6) The virtual machine monitor calls the corresponding API in the PCM / Control interface library in the kernel of the service virtual machine to pass the DMA memory address to the DMA management module;

[0117] (7) The DMA management module adds the DMA memory address to the interface corresponding to PCM, so that the service operating system (SOS) and user operating system (UOS) can share this memory and realize data exchange;

[0118] (8) The Guest OS VM puts the "readiness information" of the virtual PCM interface into the message queue to notify the virtual machine manager that its virtual PCM interface is ready and can work normally.

[0119] (9) The virtual audio processing module in the virtual machine manager reads messages from the message queue;

[0120] (10) The virtual audio processing module updates the status parameters of the corresponding PCM device it manages through the audio interface library;

[0121] (11) The virtual audio processing module sends the "preparation information" to the virtual machine monitor in the service virtual machine;

[0122] (12) The virtual machine monitor calls the corresponding API in the PCM / Control interface library in the kernel to set the status parameters of the corresponding PCM device in the service virtual machine;

[0123] (13) When setting the status parameters, the audio device driver will also configure the DMA memory address into the audio device.

[0124] It should be noted that preparation information is a type of control information, marked with the "prepare" tag, indicating that preparation is complete and the system is ready to function. Because it is control information, it is transmitted to the virtual machine manager via a message queue.

[0125] like Figure 5 As shown, the virtual PCM interface writes data to the DMA. When the buffer is full, an interrupt is triggered, which is responded to by the microkernel-based virtualization manager. First, the SOS manager determines the correct handler for the interrupt. If the interrupt was sent to the SOS, the SOS manager will forward it to the SOS for processing via the VCPU interface. If the interrupt was sent to the UOS, the SOS manager will forward it to the corresponding UOS manager, which will then forward it to the corresponding UOS for processing. The specific data flow and interrupt handling process is as follows:

[0126] (1) The audio device driver writes data to the DMA memory, and an interrupt is triggered when the buffer is full;

[0127] (2) The audio device driver directly writes to the register to start the audio device interrupt;

[0128] (3) The shared interrupt service process in the virtual machine manager captures the interrupt;

[0129] (4) The virtual machine manager calls the service virtual machine manager to handle the interrupt. It first saves the current interrupt status information and then determines its sending target;

[0130] (4.1) If its target is a Service Virtual Machine (SOS), the interrupt is sent to the SOS and received by the virtual machine CPU interface in the SOS;

[0131] (4.2) Call the interrupt request handler to process the interrupt;

[0132] (4.3) The audio device interface library provides an API interface to handle this interrupt;

[0133] (4.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory;

[0134] (4.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module;

[0135] (5) If the interruption is to a user virtual machine (UOS), the service virtual machine manager will forward the interruption to the corresponding user virtual machine manager. The subsequent processing flow is similar to that in the service virtual machine.

[0136] (5.1) The interrupt is sent to UOS and received by the virtual machine CPU interface in UOS;

[0137] (5.2) Call the interrupt request handler to process the interrupt;

[0138] (5.3) The audio device interface library provides an API interface to handle this interrupt;

[0139] (5.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory;

[0140] (5.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module;

[0141] (6) After the interrupt is handled, the CPU will restore the previously saved breakpoint and context information, and return to the next instruction of the interrupted program to continue execution.

[0142] It should be noted that, in the description of this application, the terms "length," "thickness," "inner," "outer," "axial," "radial," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limiting the present invention.

[0143] Furthermore, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Moreover, 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 process, method, article, or apparatus.

[0144] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A microkernel-based audio virtualization method, characterized in that, Includes the following steps: S1: The virtualization manager (3) encapsulates the corresponding control interface to receive requests from audio devices in the guest virtual machine and forward the requests to the connection service virtual machine. When the audio device completes the requested task, it will return the processing status to the guest virtual machine. S2: The virtual PCM device and virtual control device in the client virtual machine send control signals. The generated control signals are placed in the message queue. The virtual audio processing module reads the control signals from the message queue and processes the signals using the API provided in the audio interface library. The virtualization manager forwards the processed control signals to the connection service virtual machine. After receiving the control signals, the connection service virtual machine transmits the signals to the physical hardware audio device through the audio device driver to execute the actual audio control operation. After the hardware audio device completes the control operation, it will feed back the operation result to the virtualization manager, and then the virtualization manager will notify the virtual audio device in the user virtual machine, thus completing the entire control process. S3: When the guest virtual machine starts and initializes its audio subsystem, it loads the audio driver and recognizes the audio hardware. Then, it creates the corresponding virtual PCM device. At this point, under the coordination of the virtualization manager, a region in memory is allocated for DMA access. The guest virtual machine then sends the address of this memory region to the connection service virtual machine via a message queue. The connection service virtual machine writes this address into the driver settings of the hardware audio device. Both the virtual audio device in the guest virtual machine and the hardware audio device in the connection service virtual machine access the same memory region via DMA, enabling direct data exchange between them. S4: The virtual audio device in the guest virtual machine and the hardware audio device in the connection service virtual machine can access the same memory block via DMA. When one of them writes data to the DMA memory, a DMA interrupt will be triggered when the buffer is full. The shared interrupt service process in the microkernel virtual machine manager is responsible for responding to and handling such interrupts.

2. The microkernel-based audio virtualization method as described in claim 1, characterized in that, The initialization steps for the virtual audio device are as follows: (1) Initialize the virtual sound card and complete the configuration in the connection service virtual machine; (2) The connection service virtual machine continuously listens for messages from the client virtual machine; (3) After the connection service virtual machine listens to the message from the client virtual machine, it immediately processes the message and resumes listening after processing. (4) First, initialize the message queue in the guest virtual machine to control the communication of information; (5) Create a new virtual sound card in the client virtual machine; (6) The client virtual machine sends a request to the connection service virtual machine and obtains the correct configuration parameters of the virtual sound card; (7) The customer virtual machine constructs virtual PCM, chamap, control and jack nodes according to the configuration parameters; (8) The client virtual machine completes the registration of the virtual sound card device in the system, and then uses the device to process audio tasks.

3. The microkernel-based audio virtualization method as described in claim 1, characterized in that, In S2, the client virtual machine and the connection service virtual machine exchange control information through a message queue to realize the virtual PCM / control interface. The virtual PCM interface information control includes: opening / closing the virtual PCM interface, setting hardware parameter information, and device prepare.

4. The microkernel-based audio virtualization method as described in claim 3, characterized in that, The steps for transmitting information via the virtual PCM / control interface are as follows: S21: The guest virtual machine encapsulates PCM control information or control command information in the audio device driver and then puts it into the message queue; S22: The virtual audio processing module in the microkernel virtual machine manager retrieves encapsulated information from the message queue; S23: The virtual audio processing module uses the API provided by the audio interface library to parse information; S24: The virtual audio processing module transfers information to the virtual machine monitor in the service virtual machine; S25: The virtual machine monitor calls the control information / control command parsed from the corresponding interface in the audio interface library in the kernel; S26: Control commands are sent to the audio device driver; S27: Access or control audio hardware via audio device drivers; S28: The audio device driver receives feedback on the running results; S29: The result is returned to the audio device interface library; S210: The result is returned to the virtual machine monitor; S211: The result is returned to the virtual audio processing module in the virtual machine manager; S212: The virtual audio processing module puts the returned result into the message queue; S213: The audio device driver of the guest virtual machine retrieves the result of the call to the audio hardware device from the message queue.

5. The microkernel-based audio virtualization method as described in claim 3, characterized in that, In step S3, the PCM interface data flow steps for audio data exchange between the client virtual machine and the connection service virtual machine through shared DMA memory are as follows: S201: The guest virtual machine allocates memory for DMA access in the set hardware parameters function of the audio device driver; S202: The audio device driver records the allocated DMA memory address, calls the virtual control interface, and adds the control information containing the DMA memory address to the message queue in the form of control commands. S203: The virtual audio processing module in the virtual machine manager reads messages from the message queue and parses the DMA memory address from the messages; S204: The virtual audio processing module sets the DMA memory address through the audio interface library, bringing this memory area under the supervision of the virtual machine manager, who is responsible for restricting access permissions and protecting data security. S205: The virtual audio processing module sends the DMA memory address to the virtual machine monitor in the service virtual machine; S206: The virtual machine monitor calls the corresponding API in the pcm / Control interface library in the kernel of the service virtual machine to pass the DMA memory address to the DMA management module; S207: The DMA management module adds the DMA memory address to the interface corresponding to the PCM, enabling the service operating system to share this memory with the service virtual machine and the guest virtual machine, thus achieving data exchange. S208: GuestOSVM puts the "readiness information" of the virtual PCM interface into the message queue to notify the virtual machine manager that its virtual PCM interface is ready and working normally; S209: The virtual audio processing module in the virtual machine manager reads messages from the message queue; S2010: The virtual audio processing module updates the status parameters of the corresponding PCM device it manages through the audio interface library; S2011: The virtual audio processing module sends "preparation information" to the virtual machine monitor in the service virtual machine; S2012: The virtual machine monitor calls the corresponding API in the pcm / Control interface library in the kernel to set the status parameters of the corresponding pcm device in the service virtual machine; S2013: When setting status parameters, the audio device driver will also configure the DMA memory address in the audio device.

6. The microkernel-based audio virtualization method as described in claim 3, characterized in that, The process for responding to DMA interrupts in S4 includes: the virtual PCM interface writes data to the DMA. When the buffer is full, an interrupt is triggered. This interrupt is responded to by the microkernel-based virtualization manager. First, the connection service virtual machine manager determines the correct handler for the interrupt. If the interrupt was sent to the connection service virtual machine, the connection service virtual machine manager will transfer it to the connection service virtual machine for processing through the VCPU interface. If the interrupt was sent to the guest virtual machine, the connection service virtual machine manager will transfer it to the corresponding guest virtual machine manager, which will then transfer it to the corresponding guest virtual machine for processing.

7. The microkernel-based audio virtualization method as described in claim 6, characterized in that, The specific steps of the virtual PCM interface data flow process and interrupt control processing process are as follows: (1) The audio device driver writes data to the DMA memory, and an interrupt is triggered when the buffer is full; (2) The audio device driver directly writes to the register to start the audio device interrupt; (3) The shared interrupt service process in the virtual machine manager captures the interrupt; (4) The virtual machine manager calls the service virtual machine manager to handle the interrupt. It first saves the current interrupt status information and then determines its sending target; (5) The interruption is targeted at a guest virtual machine. The service virtual machine will forward the interruption to the corresponding user virtual machine manager. The subsequent processing flow is similar to that in the service virtual machine. (6) After the interrupt is handled, the CPU will restore the previously saved breakpoint and context information, and return to the next instruction of the interrupted program to continue execution.

8. The microkernel-based audio virtualization method as described in claim 7, characterized in that, The specific steps in step (4) are as follows: (4.1) If its target is a service virtual machine connecting to a service virtual machine, the interrupt is sent to the service virtual machine and received by the virtual machine CPU interface in the service virtual machine. (4.2) Call the interrupt request handler to process the interrupt; (4.3) The audio device interface library provides an API interface to handle this interrupt; (4.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory; (4.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module.

9. The microkernel-based audio virtualization method as described in claim 7, characterized in that, The specific steps in step (5) are as follows: (5.1) The interrupt is sent to the guest virtual machine and received by the virtual machine CPU interface in the guest virtual machine; (5.2) Call the interrupt request handler to process the interrupt; (5.3) The audio device interface library provides an API interface to handle this interrupt; (5.4) The processing flow is transferred to the audio device driver, which is responsible for reading data from the DMA memory; (5.5) The audio device driver reads data from DMA memory with the assistance of the DMA management module.

Images