System-on-chip and multi-domain audio management method

Abstract

A system on chip (SoC) includes a system processor and an audio processor. The system processor executes a virtual machine hypervisor to virtualize a plurality of virtual machines (VMs). The virtual machines output audio data and control data from a plurality of in-vehicle devices. One of the virtual machines is a host virtual machine, and the other virtual machines are guest virtual machines. The audio processor is electrically connected to the system processor. The audio processor receives the audio data and the control data from the system processor, establishes a plurality of tasks based on the audio data and the control data from the virtual machines, mixes and processes the audio data per task to generate processed audio data, and outputs the processed audio data to audio hardware.

Description

[Technical Field]

[0001] This invention relates to an electronic device, and more particularly to a system-on-chip (SoC) and a multi-domain audio management method. [Background Technology]

[0002] Currently, in-vehicle infotainment systems are developing rapidly, and they are extremely complex in terms of multi-domain chip management. For example, each domain (such as driver, passenger, T-Box, and instrument panel) requires its own master control chip. To achieve multi-domain functionality on a single chip, virtualization technology is inevitably involved.

[0003] Currently, there are two types of intelligent cockpit systems: single-master SoC and multi-master SoC. Both primarily rely on external audio digital signal processors (ADSPs) for multi-domain audio processing. Multi-master SoCs depend on the external ADSP having sufficient audio input / output and communication interface capabilities to meet the increasingly large and diverse audio scenario requirements. Single-master SoCs are similar, but they additionally require the master SoC itself to have sufficient audio input / output and communication interface capabilities.

[0004] On the other hand, the audio application scenarios for each domain actually overlap, such as media sounds and key press sounds. If multi-domain audio processing can be completed within a single main control SoC, the design complexity of the entire system can be greatly reduced. [Summary of the Invention]

[0005] One embodiment of the present invention provides a system-on-chip (SoC). The SoC includes a system processor and an audio processor. The system processor executes a hypervisor to virtualize multiple virtual machines (VMs). The VMs output audio data and control data from multiple in-vehicle devices. One VM is a host VM, and the others are guest VMs. The audio processor is electrically connected to the system processor. The audio processor receives audio data and control data from the system processor, establishes multiple tasks based on the audio data and control data from the VMs, mixes and processes the audio data task by task to generate processed audio data, and outputs the processed audio data to audio hardware.

[0006] According to the aforementioned SoC, each virtual machine includes user space and kernel space.

[0007] Based on the aforementioned SoC, the hypervisor virtualizes audio input / output (I / O) ports and digital signal processing (DSP) I / O ports in the kernel space of each guest virtual machine.

[0008] Based on the aforementioned SoC, the hypervisor establishes an audio backend and an audio digital signal processing (ADSP) backend in the user space of the host virtual machine.

[0009] According to the aforementioned SoC, each guest virtual machine sends audio data to the host virtual machine through a virtualized audio I / O port in kernel space. The host virtual machine receives the audio data from each guest virtual machine through an audio backend in user space.

[0010] Based on the aforementioned SoC, each guest virtual machine sends control data to the host virtual machine via virtualized DSP I / O ports in kernel space. The host virtual machine receives control data from each guest virtual machine through the ADSP backend in user space.

[0011] Based on the aforementioned SoC, the hypervisor establishes audio and DSP drivers in the kernel space of the host virtual machine. The audio driver drives the audio hardware based on audio data from the in-vehicle equipment. The DSP driver sends control data from the in-vehicle equipment to the audio processor to control the audio hardware.

[0012] According to the aforementioned SoC, the virtual machine includes a first virtual machine, a second virtual machine, and a third virtual machine. The in-vehicle device includes a first in-vehicle device, a second in-vehicle device, and a third in-vehicle device. The first virtual machine outputs audio data and control data from the first in-vehicle device. The second virtual machine outputs audio data and control data from the second in-vehicle device. The third virtual machine outputs audio data and control data from the third in-vehicle device.

[0013] According to the aforementioned SoC, the audio processor establishes a first task group based on audio data and control data from a first virtual machine. The audio processor establishes a second task group based on audio data and control data from a second virtual machine. The audio processor establishes a third task group based on audio data and control data from a third virtual machine.

[0014] According to the aforementioned SoC, the first task group includes tasks corresponding to the first virtual machine. The second task group includes tasks corresponding to the second virtual machine. The third task group includes tasks corresponding to the third virtual machine.

[0015] Based on the aforementioned SoC, the audio data and control data from the in-vehicle equipment correspond to different audio application scenarios.

[0016] According to the aforementioned SoC, the audio processor mixes and processes audio data based on the application requirements of each task.

[0017] An embodiment of the present invention also provides a multi-domain audio management method. This method is applied to a system processor and an audio processor. The method includes the following steps: virtualizing multiple virtual machines (VMs). The VMs output audio data and control data from multiple in-vehicle devices. One VM is a host VM, and the others are guest VMs. Audio data and control data are received from the VMs. Multiple tasks are established based on the audio data and control data from the VMs. The audio data is mixed and processed on a task-by-task basis to generate processed audio data. The processed audio data is output to audio hardware.

[0018] According to the multi-domain audio management method described above, each virtual machine includes user space and kernel space.

[0019] The multi-domain audio management approach also includes virtualizing audio input / output (I / O) ports and digital signal processing (DSP) I / O ports in the kernel space of each guest virtual machine.

[0020] Multi-domain audio management methods also include establishing an audio backend and an audio digital signal processing (ADSP) backend in the user space of the host virtual machine.

[0021] The multi-domain audio management method also includes the following steps: Each guest virtual machine sends audio data to the host virtual machine through a virtualized audio I / O port in kernel space. The host virtual machine receives the audio data from each guest virtual machine through an audio backend in user space.

[0022] The multi-domain audio management method also includes the following steps: Each guest virtual machine sends control data to the host virtual machine through a virtualized DSP I / O port in kernel space. The host virtual machine receives the control data from each guest virtual machine through an ADSP backend in user space.

[0023] The multi-domain audio management approach also includes creating audio drivers and DSP drivers in the kernel space of the host virtual machine. The audio driver drives the audio hardware based on audio data from the in-vehicle equipment. The DSP driver sends control data from the in-vehicle equipment to the audio processor to control the audio hardware.

[0024] According to the above multi-domain audio management method, audio data and control data from in-vehicle devices correspond to different audio application scenarios.

[0025] According to the above multi-domain audio management method, the steps of mixing and processing audio data on a task-by-task basis include mixing and processing audio data based on the application requirements of each task. [Attached Image Description]

[0026] This invention can be more fully understood by reading the following detailed description and referring to the examples in the accompanying drawings, wherein:

[0027] Figure 1 A schematic diagram of a system-on-a-chip (SoC) 100 according to certain embodiments of the present invention is shown;

[0028] Figure 2 Some embodiments of the present invention are shown. Figure 1 Detailed schematic diagram of SoC 100;

[0029] Figure 3 Some embodiments of the present invention are shown. Figure 1 Detailed schematic diagram of SoC 100;

[0030] Figure 4 A flowchart of a multi-domain audio management method according to certain embodiments of the present invention is shown.

Detailed Implementation Methods

[0031] To make the above-described objects, features and advantages of certain embodiments of the present invention more readily understood, a detailed description is provided below in conjunction with the accompanying drawings.

[0032] Certain terms are used throughout the specification and subsequent claims to refer to specific components. As will be understood by those skilled in the art, electronic device manufacturers may use different names to refer to a component. This document is not intended to distinguish between components with different names but identical functions. It should be understood that the words “comprising,” “having,” and “including” are used in an open-ended manner and should therefore be interpreted as “including but not limited to…”. Therefore, when the terms “comprising,” “having,” or “including” are used in this invention, they are used to indicate the presence of specific technical features, values, method steps, operations, units, or components. However, this does not preclude the possibility of adding more technical features, values, method steps, operating processes, units, components, or any combination thereof.

[0033] Directional terms used throughout the specification and subsequent claims, such as “up,” “above,” “below,” “under,” “front,” “back,” “left,” and “right,” are merely for reference to the drawings. Therefore, these directional terms are used to explain, and not to limit, the invention. Regarding the drawings, they illustrate the general characteristics of the methods, structures, or materials used in specific embodiments. However, the drawings should not be construed as defining or limiting the scope or properties covered by these embodiments. For example, for clarity, the relative size, thickness, and position of each layer, region, or structure may be reduced or enlarged.

[0034] When referring to a component, such as a layer or region, as "on another component," it may be directly on this other component, or there may be other components between them. On the other hand, when a component is referred to as "directly on another component (or a variation thereof)," there are no components between them. Furthermore, when a corresponding component is referred to as "on another component," the corresponding component and the other component have an arrangement relationship in the top view / vertical direction. The corresponding component may be below or above the other component, and the arrangement relationship in the top view / vertical direction is determined by the orientation of the device.

[0035] It should be understood that when a component or layer is said to be "connected to" another component or layer, it can be directly connected to that other component or layer, or there may be intervening components or layers. Conversely, when a component is said to be "directly connected to" another component or layer, there are no intervening components or layers.

[0036] The electrical connections or couplings described herein may refer to direct or indirect connections. In the case of a direct connection, the endpoints of components on two circuits are directly connected or interconnected via conductor segments, while in the case of an indirect connection, there is a switch, diode, capacitor, inductor, resistor, other suitable component, or combination of the above between the endpoints of components on two circuits, but the intermediate component is not limited to this.

[0037] The terms “first,” “second,” and “third” are used to describe components. They are not used to indicate priority or hierarchy, but simply to distinguish components with the same name.

[0038] It should be noted that the technical features of the different embodiments described below can be replaced, recombined or mixed with each other to form another embodiment without departing from the spirit of the invention.

[0039] Figure 1 A schematic diagram of a system-on-a-chip (SoC) 100 according to certain embodiments of the present invention is shown. Figure 1 As shown, SoC 100 includes a system processor 102, an audio processor 104, and audio hardware (HW) 112. System processor 102 is electrically connected to audio processor 104. Audio processor 104 is electrically connected to audio hardware 112. In some embodiments, system processor 102 executes hypervisor 120 to virtualize multiple virtual machines (VMs), such as VM1, VM2, and VM3. The VMs output audio and control data from multiple in-vehicle devices. For example, VM1 outputs audio and control data from in-vehicle device 106. VM2 outputs audio and control data from in-vehicle device 108. VM3 outputs audio and control data from in-vehicle device 110.

[0040] In some embodiments, the audio processor 104 receives audio data and control data from the system processor 102, establishes multiple tasks based on the audio data and control data from virtual machines VM1, VM2, and VM3, mixes and processes the audio data task by task to generate processed audio data, and outputs the processed audio data to the audio hardware 112. For example, the audio processor 104 mixes and processes the audio data based on the application requirements of each task (such as volume control, media effects, format conversion). Specifically, each VM includes a user space and a kernel space. For example, virtual machine VM1 includes user space 122 and kernel space 124. Virtual machine VM2 includes user space 126 and kernel space 128. Virtual machine VM3 includes user space 130 and kernel space 132. Figure 1 In some embodiments, virtual machine VM2 is a host virtual machine, while virtual machines VM1 and VM3 are guest virtual machines, but the invention is not limited thereto.

[0041] In some embodiments, in-vehicle devices 106 and 110 may be T-boxes, and in-vehicle device 108 may be a dashboard, but the invention is not limited thereto. For example, when a user touches the display screen of in-vehicle device 106 to select an application to play music in the vehicle, the user space 122 of virtual machine VM1 acquires audio data and control data from in-vehicle device 106. Then, user space 122 sends the audio data and control data from in-vehicle device 106 to kernel space 124 of virtual machine VM1. Since virtual machine VM1 is a guest virtual machine, kernel space 124 of virtual machine VM1 may send the audio data and control data from in-vehicle device 106 to user space 126 of virtual machine VM2 so that audio processor 104 and audio hardware 112 can be driven by kernel space 128 of virtual machine VM2 (i.e., the host VM) based on the audio data and control data from in-vehicle device 106.

[0042] For example, when the vehicle speed exceeds the speed limit, the user space 126 of virtual machine VM2 obtains audio and control data from the vehicle-mounted device 108 for use in an alarm sound. Then, user space 126 sends the audio and control data from the vehicle-mounted device 108 to the kernel space 128 of virtual machine VM2. Since virtual machine VM2 is a host virtual machine, audio hardware 112 can be driven by the kernel space 128 of virtual machine VM2 based on the audio and control data from the vehicle-mounted device 108. In some embodiments, audio hardware 112 can simultaneously or sequentially play music from vehicle-mounted device 106 and an alarm sound from vehicle-mounted device 108. Figure 1 In some embodiments, the audio hardware 112 includes multiple input ports IN and multiple output ports OUT. The audio hardware 112 can play music and alarm sounds through the output ports OUT.

[0043] In some embodiments, when a user enables voice recognition from the in-vehicle device 110, the user space 130 of the virtual machine VM3 acquires control data for voice recognition. The user space 130 then sends the control data from the in-vehicle device 110 to the kernel space 132 of the virtual machine VM3. Since the virtual machine VM3 is a guest virtual machine, the kernel space 132 of the virtual machine VM3 can send the control data from the in-vehicle device 110 to the user space 126 of the virtual machine VM2 so that the input port IN of the audio hardware 112 (e.g., a microphone) can be driven by the kernel space 128 of the virtual machine VM2 (i.e., the host VM) according to the control data from the in-vehicle device 110.

[0044] Figure 2 Some embodiments according to the present invention are shown. Figure 1 Detailed schematic diagram of the SoC 100. (See attached image.) Figure 2 As shown, the SoC 100 includes a system processor 102, an audio processor 104, and audio hardware 112. The system processor 102 is electrically connected to the audio processor 104. The audio processor 104 is electrically connected to the audio hardware 112. In some embodiments, the system processor 102 executes a hypervisor 120 to virtualize virtual machines VM1, VM2, and VM3. Virtual machine VM1 outputs audio and control data from an in-vehicle device 106. Virtual machine VM2 outputs audio and control data from an in-vehicle device 108. Virtual machine VM3 outputs audio and control data from an in-vehicle device 110.

[0045] In some embodiments, the audio processor 104 receives audio data and control data from the system processor 102, and establishes multiple tasks (e.g., based on the audio data and control data from virtual machines VM1, VM2, and VM3). Figure 2 The task function in the audio processor 104 mixes and processes audio data on a task-by-task basis to generate processed audio data (e.g., Figure 2 The audio processor 104 includes mixing and processing functions, and outputs the processed audio data to the audio hardware 112. Specifically, virtual machine VM1 includes user space 122 and kernel space 124. Virtual machine VM2 includes user space 126 and kernel space 128. Virtual machine VM3 includes user space 130 and kernel space 132. Figure 2 In some embodiments, virtual machine VM2 is a host virtual machine, while virtual machines VM1 and VM3 are guest virtual machines, but the invention is not limited thereto.

[0046] In some embodiments, since virtual machines VM1 and VM3 are guest virtual machines, hypervisor 120 virtualizes an audio input / output (I / O) port (virtIO-SND) 208 and a digital signal processing (DSP) I / O port (virtIO-DSP) 210 in the kernel space 124 of virtual machine VM1. Hypervisor 120 virtualizes an audio I / O port 212 and a DSP I / O port 214 in the kernel space 132 of virtual machine VM3. In some embodiments, since virtual machine VM2 is a host virtual machine, hypervisor 120 establishes an audio backend 200 and an audio digital signal processing (ADSP) backend 202 in the user space 126 of virtual machine VM2. Hypervisor 120 establishes an audio driver 204 and a DSP driver 206 in the kernel space 128 of virtual machine VM2. In some embodiments, audio driver 204 may be an Advanced Linux Sound Architecture (ALSA) driver, but the invention is not limited thereto. The audio driver 204 drives the audio hardware 112 based on audio data from the in-vehicle devices 106, 108, and 110. The DSP driver 206 sends control data from the in-vehicle devices 106, 108, and 110 to the audio processor 104 to control the audio hardware 112.

[0047] For example, in Figure 2 In some embodiments, virtual machine VM1 sends audio data to virtual machine VM2 via virtualized audio I / O port 208 in kernel space 124. Virtual machine VM2 receives audio data from virtual machine VM1 via audio backend 200 in user space 126. Similarly, virtual machine VM3 sends audio data to virtual machine VM2 via virtualized audio I / O port 212 in kernel space 132. Virtual machine VM2 receives audio data from virtual machine VM3 via audio backend 200 in user space 126.

[0048] For example, in Figure 2 In some embodiments, virtual machine VM1 sends control data to virtual machine VM2 via virtualized DSP I / O port 210 in kernel space 124. Virtual machine VM2 receives control data from virtual machine VM1 via ADSP backend 202 in user space 126. Similarly, virtual machine VM3 sends control data to virtual machine VM2 via virtualized DSP I / O port 214 in kernel space 132. Virtual machine VM2 receives control data from virtual machine VM3 via ADSP backend 202 in user space 126.

[0049] When a user touches the display screen of the in-vehicle device 106 to select an application to play music in the vehicle, the user space 122 of the virtual machine VM1 obtains audio data and control data from the in-vehicle device 106. Then, the user space 122 sends the audio data and control data from the in-vehicle device 106 to the kernel space 124 of the virtual machine VM1. Since the virtual machine VM1 is a guest virtual machine, the kernel space 124 of the virtual machine VM1 can send the audio data of the in-vehicle device 106 to the user space 126 of the virtual machine VM2 via the virtualized audio input / output port 208. The kernel space 124 of the virtual machine VM1 can send the control data of the in-vehicle device 106 to the user space 126 of the virtual machine VM2 via the virtualized digital signal processing input / output port 210. Therefore, the audio hardware 112 can be driven by the audio driver 204 (e.g., in the attached figure) in the kernel space 128 of the virtual machine VM2 (i.e., the host virtual machine). Figure 2 The ALSA driver shown is driven by audio data from the in-vehicle device 106. Similarly, the audio hardware 112 can be driven by digital signal processing 206 in the kernel space 128 of the virtual machine VM2 (i.e., the host virtual machine) (see attached figure). Figure 2 The DSP driver shown is driven by the control data of the vehicle device 106.

[0050] When the vehicle speed exceeds the speed limit, the user space 126 of virtual machine VM2 obtains the audio data of the alarm sound from the vehicle device 108 through the audio backend 200. The user space 126 of virtual machine VM2 obtains the control data of the alarm sound from the vehicle device 108 through the audio digital signal processing backend 202. Then, the user space 126 sends the audio data and control data from the vehicle device 108 to the kernel space 128 of virtual machine VM2. Since virtual machine VM2 is a host virtual machine, the audio hardware 112 can be driven by the audio driver 204 in the kernel space 128 of virtual machine VM2 according to the audio data. Similarly, the audio hardware 112 can be driven by the digital signal processing driver 206 in the kernel space 128 of virtual machine VM2 according to the control data of the vehicle device 108.

[0051] When a user enables the voice recognition function of the in-vehicle device 110, the user space 130 of the virtual machine VM3 acquires the voice recognition control data of the in-vehicle device 110. Then, the user space 130 sends the control data from the in-vehicle device 110 to the kernel space 132 of the virtual machine VM3. Since the virtual machine VM3 is a guest virtual machine, the virtualized digital signal processing input / output port 214 in the kernel space 132 of the virtual machine VM3 can send the control data from the in-vehicle device 110 to the audio digital signal processing backend 202 in the user space 126 of the virtual machine VM2, so that the input port IN of the audio hardware 112 (e.g., a microphone) can be driven by the digital signal processing drive 206 in the kernel space 128 of the virtual machine VM2 (i.e., the host virtual machine) according to the control data from the in-vehicle device 110.

[0052] Figure 3 Some embodiments according to the present invention are shown. Figure 1 A detailed schematic diagram of the System-on-Chip 100 is shown below. Figure 3 As shown, the system-on-a-chip 100 includes a system processor 102, an audio processor 104, and audio hardware 112. The system processor 102 is electrically connected to the audio processor 104. The audio processor 104 is electrically connected to the audio hardware 112. In some embodiments, the system processor 102 executes a hypervisor 120 to virtualize virtual machines VM1, VM2, and VM3. Virtual machine VM1 outputs audio and control data from the in-vehicle device 106. Virtual machine VM2 outputs audio and control data from the in-vehicle device 108. Virtual machine VM3 outputs audio and control data from the in-vehicle device 110.

[0053] In some embodiments, the audio processor 104 receives audio data and control data from the system processor 102, and establishes multiple tasks (e.g., based on the audio data and control data of virtual machines VM1, VM2, and VM3) Figure 3 The task function in the audio processor 104 mixes and processes audio data on a task-by-task basis to generate processed audio data (e.g., Figure 3 The audio processor 104 includes mixing and processing functions, and outputs the processed audio data to the audio hardware 112. Figure 3 In some embodiments, virtual machine VM2 is a host virtual machine, and virtual machines VM1 and VM3 are guest virtual machines, but the present invention is not limited thereto.

[0054] In detail, virtual machine VM1 generates multiple audio application scenarios based on audio data and control data from vehicle device 106, such as audio application scenarios VM1-1, VM1-2..., VM1-X. Virtual machine VM2 generates multiple audio application scenarios based on audio data and control data from vehicle device 108, such as audio application scenarios VM2-1, VM2-2..., VM2-X. Similarly, virtual machine VM3 generates multiple audio application scenarios based on audio data and control data from vehicle device 110, such as audio application scenarios VM3-1, VM3-2..., VM3-X. Then, audio processor 104 creates task group 300 for virtual machine VM1 based on the audio data and control data of virtual machine VM1 (e.g., based on audio application scenarios VM1-1, VM1-2..., VM1-X). Audio processor 104 creates task group 302 for virtual machine VM2 based on the audio data and control data of virtual machine VM2 (e.g., based on audio application scenarios VM2-1, VM2-2..., VM2-X). The audio processor 104 creates a task group 304 for the virtual machine VM3 based on the audio data and control data of the virtual machine VM3 (e.g., based on audio application scenarios VM3-1, VM3-2..., VM3-X).

[0055] Each task in task group 300 may correspond to one of the audio application scenarios VM1-1, VM1-2, ..., VM1-X. For example, when a user touches the display screen of the in-vehicle device 106 to select an application to play music in the vehicle, virtual machine VM1 generates audio application scenario VM1-1. Next, audio processor 104 creates a task in task group 300 to process audio application scenario VM1-1.

[0056] Each task in task group 302 may correspond to one of the audio application scenarios VM2-1, VM2-2, ..., VM2-X. For example, when a vehicle exceeds the speed limit, virtual machine VM2 generates audio application scenario VM2-1. Next, audio processor 104 creates a task in task group 302 to process audio application scenario VM2-1.

[0057] Each task in task group 304 may correspond to one of the audio application scenarios VM3-1, VM3-2, ..., VM3-X. For example, when a user enables the voice recognition function from the in-vehicle device 110, virtual machine VM3 generates audio application scenario VM3-1. Next, audio processor 104 creates a task in task group 304 to process audio application scenario VM3-1. Audio processor 104 mixes and processes audio data task by task to generate processed audio data. That is, audio processor 104 mixes and processes audio data based on the application requirements in each task. Afterward, audio processor 104 outputs the processed audio data to audio hardware 112 through an audio output port. In some embodiments, audio processor 104 receives audio data from audio hardware 112 (e.g., a microphone) through an audio input port.

[0058] Figure 4 A flowchart illustrating a multi-domain audio management method according to certain embodiments of the present invention is provided. The multi-domain audio management method is applied to... Figures 1-3 The system-on-chip (SoC) 100 in the system-on-chip. The multi-domain audio management method includes the following steps: Virtualizing multiple virtual machines (VMs). The VMs output audio data and control data from multiple in-vehicle devices. One of the VMs is a host VM, and the others are guest VMs (step S400). Receiving audio data and control data from the VMs (step S402). Establishing multiple tasks based on the audio data and control data from the VMs (step S404). Mixing and processing the audio data task by task to generate processed audio data (step S406). Outputting the processed audio data to audio hardware (step S408). In some embodiments, steps S400 and S402 are executed by a hypervisor (e.g., hypervisor 120) executed by a system processor (e.g., system processor 102) in the system-on-chip 100. Steps S404, S406, and S408 are executed by an audio processor (e.g., audio processor 104) in the system-on-chip 100.

[0059] In some embodiments, in step S400, each VM includes a user space and a kernel space. Audio data and control data from the in-vehicle device correspond to different audio application scenarios. The multi-domain audio management method further includes the following steps: The hypervisor virtualizes audio input / output (I / O) ports and digital signal processing (DSP) I / O ports in the kernel space of each guest VM. The hypervisor establishes an audio backend and an audio digital signal processing (ADSP) backend in the user space of the host VM. The hypervisor establishes an audio driver and a DSP driver in the kernel space of the host VM. The audio driver drives the audio hardware based on audio data from the in-vehicle device. The DSP driver sends control data from the in-vehicle device to the audio processor to control the audio hardware.

[0060] In some embodiments, the multi-domain audio management method further includes the following steps: Each guest virtual machine sends audio data to the host VM through a virtualized audio I / O port in its kernel space. The host VM receives the audio data from each guest virtual machine through an audio backend in its user space. In some embodiments, each guest virtual machine sends audio data to the host VM through a virtualized audio I / O port in its kernel space. The host VM receives control data from each guest virtual machine through an ADSP backend in its user space.

[0061] Figures 1-3 The System-on-Chip 100 and the multi-domain audio management method of the present invention use the built-in ADSP to complete the audio processing and mixing of multi-domain audio data within a single main control SoC, and the audio data of the same application scenario are mixed in advance, saving the audio I / O requirements.

[0062] While the invention has been described by way of example and preferred embodiments, it should be understood that the invention is not limited to the disclosed embodiments. Rather, it is intended to cover various modifications and similar arrangements (which will be apparent to those skilled in the art). Therefore, the scope of the appended claims should be given the broadest interpretation to cover all such modifications and similar arrangements.

Claims

1. A system-on-a-chip (SoC), comprising: The system processor is configured to execute a hypervisor to virtualize multiple virtual machines (VMs); wherein the VMs output audio and control data from multiple in-vehicle devices; wherein one of the VMs is a host VM, and the other VMs are guest VMs; An audio processor, electrically connected to the system processor, is configured to receive audio data and control data from the system processor, establish multiple tasks from the virtual machine based on the audio data and control data, perform mixing and audio processing on the audio data task by task to generate processed audio data, and output the processed audio data to audio hardware.

2. The system-on-a-chip as claimed in claim 1, wherein each virtual machine includes a user space and a kernel space.

3. The system-on-a-chip as claimed in claim 2, wherein the hypervisor virtualizes audio input / output (I / O) ports and digital signal processing (DSP) input / output ports in the kernel space of each guest virtual machine.

4. The system-on-a-chip as claimed in claim 3, wherein the hypervisor establishes an audio backend and an audio digital signal processing (ADSP) backend in the user space of the host virtual machine.

5. The system-on-a-chip as claimed in claim 3, wherein each guest virtual machine sends the audio data to the host virtual machine through the virtualized audio I / O port in the kernel space; and the host virtual machine receives the audio data from each guest virtual machine through the audio backend in the user space.

6. The system-on-a-chip as claimed in claim 3, wherein each guest virtual machine sends the control data to the host virtual machine through the virtualized DSP I / O port in the kernel space; and the host virtual machine receives the control data from each guest virtual machine through the ADSP backend in the user space.

7. The system-on-a-chip as claimed in claim 3, wherein the hypervisor establishes an audio driver and a DSP driver in the kernel space of the host virtual machine; the audio driver drives the audio hardware based on the audio data from the vehicle-mounted device; and the DSP driver sends the control data from the vehicle-mounted device to the audio processor to control the audio hardware.

8. The system-on-a-chip as claimed in claim 1, wherein the virtual machine includes a first virtual machine, a second virtual machine, and a third virtual machine; the vehicle-mounted device includes a first vehicle-mounted device, a second vehicle-mounted device, and a third vehicle-mounted device; the first virtual machine outputs audio data and control data from the first vehicle-mounted device, the second virtual machine outputs audio data and control data from the second vehicle-mounted device, and the third virtual machine outputs audio data and control data from the third vehicle-mounted device.

9. The system-on-a-chip of claim 8, wherein the audio processor is configured as follows: A first task group is established from the first virtual machine based on the audio data and the control data; A second task group is established from the second virtual machine based on the audio data and the control data; and A third task group is established from the third virtual machine based on the audio data and the control data.

10. The system-on-a-chip of claim 9, wherein the first task group includes tasks corresponding to the first virtual machine; the second task group includes tasks corresponding to the second virtual machine; and the third task group includes tasks corresponding to the third virtual machine.

11. The system-on-a-chip as claimed in claim 1, wherein the audio data and the control data from the vehicle-mounted device correspond to different audio application scenarios.

12. The system-on-a-chip of claim 1, wherein the audio processor mixes and processes the audio data based on the application requirements of each of the tasks.

13. A multi-domain audio management method, applied to a system processor and an audio processor, comprising: The system virtualizes multiple virtual machines (VMs); wherein the VMs output audio data and control data from multiple in-vehicle devices; wherein the VMs are host VMs, and the other VMs are guest VMs. Receive the audio data and control data from the virtual machine; Multiple tasks are created from the virtual machine based on the audio data and the control data; The audio data is mixed and processed on a task-by-task basis to generate processed audio data, and the processed audio data is output to the audio hardware.

14. The multi-domain audio management method as described in claim 13, wherein each virtual machine includes user space and kernel space.

15. The multi-domain audio management method as described in claim 14, further comprising: Audio input / output (I / O) ports and digital signal processing (DSP) input / output ports are virtualized in the kernel space of each guest virtual machine.

16. The multi-domain audio management method as described in claim 15, further comprising: An audio backend and an audio digital signal processing (ADSP) backend are established in the user space of the host virtual machine.

17. The multi-domain audio management method as described in claim 15, further comprising: Each guest virtual machine sends the audio data to the host virtual machine through the virtualized audio I / O port in the kernel space; and The host virtual machine receives audio data from each guest virtual machine through the audio backend in the user space.

18. The multi-domain audio management method as described in claim 15, further comprising: Each guest virtual machine sends control data to the host virtual machine through the kernel space virtualized audio input / output port; as well as The host virtual machine receives control data from each guest virtual machine in user space through the ADSP backend.

19. The multi-domain audio management method as described in claim 15, further comprising: Create audio drivers and DSP drivers in the kernel space of the host virtual machine; The audio driver drives the audio hardware based on audio data from the in-vehicle device; and the DSP driver sends control data from the in-vehicle device to the audio processor to control the audio hardware.

20. The multi-domain audio management method as described in claim 13, wherein the audio data and control data from the vehicle-mounted device correspond to different audio application scenarios.

21. The multi-domain audio management method of claim 13, wherein the step of performing task-by-task mixing and audio processing of audio data includes: The audio data is mixed and processed based on the application requirements of each task.

Images