Cross-domain audio sharing method, device, electronic device and storage medium

Abstract

The embodiments of the present application provide a cross-domain audio sharing method, device, electronic device and storage medium. The method includes: when receiving an audio playback request from the first system domain, calling the virtual sound card driver, and sending the audio playback request of the first system domain to the second system domain; the second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run; the second system domain writes the first audio data to the shared memory area of ​​the direct access memory, and the first audio data comes from the audio playback request of the first system domain; the direct access memory moves the audio data in the shared memory area to the time-division multiplexing buffer. This method is used to reduce the audio delay of the AP domain and the CP domain and improve the audio playback effect of the vehicle computer.

Description

Technical Field

[0001] The present application relates to audio processing technology, and in particular to a cross-domain audio sharing method, device, electronic device and storage medium. Background Art

[0002] With the rapid development of automotive electronic technology, the integration of automotive computers is getting higher and higher. For example, a system on chip (SOC) is often used to support the operation of multiple systems. Specifically, SOC contains three independent central processing units (CPU), namely the adaptive platform (AP) domain, the classic platform (CP) domain, and the real-time processor (RP) domain. The AP domain is a cluster of CPUs (Cluster0), which contains 2 A55 cores (Cortex-A55) and 4 A76 cores (Cortex-A76). The AP domain is used to run the Android system. The CP domain is another cluster of CPUs (Cluster1), which contains 2 A55 cores (Cortex-A55). The CP domain is used to run the Linux system. The RP domain is a security processor, which contains 1 R52 core (Cortex-R52).

[0003] There are many audios in the car, some of which are applicable to the AP domain and some to the CP domain. For example, media audio, navigation audio, and voice interaction audio are applicable to the AP domain, while pedestrian warning sounds, seat belt or turn signal warning sounds are applicable to the CP domain. When both the AP domain and the CP domain have sound requirements, the SOC has only one Audio Direct Memory Access (Audio DMA) controller, which cannot meet the simultaneous use of DMA by the AP domain and the CP domain, resulting in high audio latency in the AP domain or the CP domain.

[0004] Therefore, how to reduce the audio delay in the AP domain and CP domain and improve the audio playback effect of the car computer still needs to be solved. Summary of the invention

[0005] The embodiments of the present application provide a cross-domain audio sharing method, device, electronic device, storage medium and program product, which are used to reduce the audio delay between the AP domain and the CP domain and improve the audio playback effect of the vehicle computer.

[0006] In a first aspect, an embodiment of the present application provides a cross-domain audio sharing method, which is applied to a system on chip, wherein the system on chip is deployed with a first system domain and a second system domain, the first system domain is deployed with a virtual sound card driver, and the second system domain is deployed with a direct access memory and a physical sound card driver, the direct access memory includes a shared memory area and a time division multiplexing buffer, and the method includes:

[0007] When receiving the audio play request from the first system domain, calling the virtual sound card driver to send the audio play request of the first system domain to the second system domain;

[0008] The second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run;

[0009] The second system domain writes first audio data into the shared memory area of ​​the direct access memory, the first audio data originating from an audio play request of the first system domain;

[0010] The direct access memory transfers the audio data in the shared memory area to the time division multiplexing buffer.

[0011] In a possible implementation, the method further includes:

[0012] When receiving an audio playback request from the second system domain, the second system domain writes second audio data to the shared memory area of ​​the direct access memory, where the second audio data originates from the audio playback request of the second system domain.

[0013] In a possible implementation manner, the second system domain writing the first audio data to the shared memory area of ​​the direct access memory includes:

[0014] The second system domain writes the first audio data into a first position divided into the shared memory area of ​​the direct access memory;

[0015] The second system domain writes the second audio data to the shared memory area of ​​the direct access memory, comprising:

[0016] The second system domain writes the second audio data into a second location divided in the shared memory area of ​​the direct access memory.

[0017] In a possible implementation manner, after the direct access memory moves the audio data in the shared memory area to the time division multiplexing buffer, the method further includes:

[0018] After the audio data is started to be transferred, the size update value of the transferred audio data is sent to the virtual sound card driver of the first system domain through the first system domain across domains;

[0019] The first system domain updates the size of the memory available in the first system domain according to the size update value.

[0020] In a possible implementation manner, the receiving the audio play request from the first system domain includes:

[0021] A plurality of virtual pulse code modulation nodes are provided to the application layer to receive audio playback requirements of a plurality of audio sources in the first system domain.

[0022] In a possible implementation manner, the second system domain is further deployed with an integrated circuit built-in audio bus I2S, and the method further includes:

[0023] receiving an operation of the first system domain on the virtual PCM node, and sending the operation to a physical sound card driver of the second system domain in a kernel corresponding interface function;

[0024] The second system domain receives the operation from the first system domain and drives the physical sound card driver to run so as to configure the direct access memory and the I2S parameters.

[0025] In a possible implementation, the direct access memory transferring the audio data in the shared memory area to the time division multiplexing buffer includes:

[0026] The direct access memory moves the audio data in the shared memory area to the time division multiplexing buffer according to the cycle size.

[0027] In a possible implementation, the first system domain is deployed with an advanced Linux sound architecture ALSA interface, and calling the virtual sound card driver includes:

[0028] The virtual sound card driver is called through the ALSA.

[0029] In a possible implementation manner, the first system domain and the second system domain perform cross-domain communication via a remote processing message transfer (RPMSG) protocol.

[0030] In a second aspect, the present application provides a cross-domain audio sharing device, which is applied to a system on chip, wherein the system on chip is deployed with a first system domain and a second system domain, the first system domain is deployed with a virtual sound card driver, and the second system domain is deployed with a direct access memory and a physical sound card driver, the direct access memory includes a shared memory area and a time division multiplexing buffer, and the device includes:

[0031] a calling module, configured to call the virtual sound card driver upon receiving an audio playback request from the first system domain, and send the audio playback request of the first system domain to the second system domain;

[0032] A driver module, used for the second system domain to receive an audio playback request from the first system domain through cross-domain communication, and drive the direct access memory and the physical sound card driver of the second system domain to run;

[0033] A writing module, used for the second system domain to write first audio data into the shared memory area of ​​the direct access memory, where the first audio data originates from an audio playback request of the first system domain;

[0034] The data transfer module is used for transferring the audio data in the shared memory area to the time division multiplexing buffer through the direct access memory.

[0035] In a third aspect, the present application provides an electronic device, including: a memory, a processor;

[0036] The memory stores computer-executable instructions;

[0037] The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to the first aspect.

[0038] In a fourth aspect, the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, they are used to implement the method described in the first aspect.

[0039] In a fifth aspect, the present application provides a computer program product, including a computer program, which implements the method described in the first aspect when executed by a processor.

[0040] Embodiments of the present application provide a cross-domain audio sharing method, device, electronic device and storage medium. The cross-domain audio sharing method is applied to a system on chip, which is deployed with a first system domain and a second system domain. The first system domain is deployed with a virtual sound card driver, and the second system domain is deployed with a direct access memory and a physical sound card driver, and the direct access memory includes a shared memory area and a time-division multiplexing buffer. The method includes: when receiving an audio playback request from the first system domain, calling the virtual sound card driver, and sending the audio playback request of the first system domain to the second system domain; the second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run; the second system domain writes the first audio data to the shared memory area of ​​the direct access memory, and the first audio data comes from the audio playback request of the first system domain; the direct access memory carries the audio data in the shared memory area to the time-division multiplexing buffer.

[0041] That is to say, by implementing a virtual sound card (Audio) driver in the first system domain, the audio playback request (Audio request) of the first system domain is sent to the second system domain. The second system domain proxies the audio playback request of the first system domain to meet the sound requirements of the first system domain. When the second system domain proxies the audio playback request of the first system domain, it directly writes the first audio data carried by the audio playback request into the corresponding address of the shared memory area of ​​DMA, without the need for additional memory copying and without additional delay. Therefore, the method provided in the present application can reduce the audio delay of the AP domain and the CP domain, and improve the audio playback effect of the vehicle computer. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] Figure 1 A schematic diagram of a scenario of the cross-domain audio sharing method provided in this application;

[0044] Figure 2 A schematic diagram of a system on a chip in the cross-domain audio sharing method provided in this application;

[0045] Figure 3 Schematic diagram of the cross-domain audio sharing method provided in this application Figure 1 ;

[0046] Figure 4 Schematic diagram of the cross-domain audio sharing method provided in this application Figure 2 ;

[0047] Figure 5 A schematic diagram of the structure of the cross-domain audio sharing device provided by this application;

[0048] Figure 6 A schematic diagram of the structure of the electronic device provided in this application.

[0049] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0050] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0051] First, the terms involved in this application are explained:

[0052] CPU: Central Processing Unit.

[0053] SOC: System on Chip, also known as system on chip. SOC is a purpose-built integrated circuit that contains the entire system and all the embedded software.

[0054] Pulse Code Modulation Node: Pulse Code Modulation, also known as Pulse-code modulation, or PCM for short. PCM nodes, also known as PCM devices, have the function of converting analog signals into digital signals.

[0055] Linux: A recursive abbreviation of Linux Is Not Unix, which is an operating system that follows multi-user, multi-tasking, supports multi-threading and multi-CPU.

[0056] ALSA interface: The full name of ALSA is Advanced Linux Sound Architecture, which refers to the advanced Linux sound architecture and provides audio support on the Linux operating system.

[0057] I2S: Inter-IC Sound, the Chinese name is the integrated circuit built-in audio bus.

[0058] TDM FIFO: TDM buffer for short. TDM is an audio interface. TDM FIFO is an audio interface buffer inside I2S.

[0059] TDM, the full English name is time-division multiplexing, and the Chinese abbreviation is time-division multiplexing technology.

[0060] FIFO, the full name of which is First In First Out, is a first-in-first-out data buffer. The difference between FIFO and ordinary memory is that it has no external read and write address lines, which makes it very simple to use.

[0061] DMA: Direct Memory Access, direct access to memory.

[0062] Share Buffer: data page buffer, in this application, refers to the shared memory area of ​​the DMA module.

[0063] PCM node: PCM, the full name of which is Pulse-code modulation. PCM node can also be called PCM device.

[0064] Remote Processor Messaging: Remote Processor Messaging, referred to as RPMsg, defines a standard binary interface used for communication between cores in a heterogeneous multi-core processing system.

[0065] TTS: Text to Speech, voice prompt.

[0066] VR: Virtual Reality, virtual reality technology.

[0067] With the rapid development of automotive electronic technology, the integration of automotive computers is becoming increasingly higher. For example, one SOC is often used to support the operation of multiple systems.

[0068] The SOC contains three independent central processing units (CPUs), namely the Adaptive Platform (AP) domain, the Classic Platform (CP) domain, and the Real-Time Processor (RP) domain. The AP domain is a CPU cluster (Cluster0), which contains 2 A55 cores (Cortex-A55) and 4 A76 cores (Cortex-A76). The AP domain is used to run the Android system. The CP domain is another CPU cluster (Cluster1), which contains 2 A55 cores (Cortex-A55). The CP domain is used to run the Linux system. The RP domain is a security processor, which contains 1 R52 core (Cortex-R52).

[0069] Figure 1 A schematic diagram of a cross-domain audio sharing method provided in this application, such as Figure 1 As shown, the specific application scenario of the present application is the scenario of multi-type audio playback.

[0070] There are many audios in the car, some of which are applicable to the AP domain and some to the CP domain. For example, media audio, navigation audio, and voice interaction audio are applicable to the AP domain, while pedestrian warning sounds, seat belt or turn signal warning sounds are applicable to the CP domain. When both the AP domain and the CP domain have sound requirements, the SOC has only one audio (Audio) DMA controller, which cannot meet the simultaneous use of DMA by the AP domain and the CP domain, resulting in high audio latency in the AP domain or the CP domain.

[0071] Based on this, the present application provides a cross-domain audio sharing method, device, electronic device and storage medium. The cross-domain audio sharing method is applied to a system on chip, and the system on chip is deployed with a first system domain and a second system domain. The first system domain is deployed with a virtual sound card driver, and the second system domain is deployed with a direct access memory and a physical sound card driver, and the DMA includes a shared memory area and a time division multiplexing buffer. The method includes: when receiving an audio playback request from the first system domain, calling the virtual sound card driver, and sending the audio playback request of the first system domain to the second system domain; the second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the DMA and the physical sound card driver of the second system domain to run; the second system domain writes the first audio data to the shared memory area of ​​the DMA, and the first audio data comes from the audio playback request of the first system domain; the DMA transports the audio data in the shared memory area to the TDM buffer.

[0072] That is to say, by implementing a virtual sound card (Audio) driver in the first system domain, the audio playback request (Audio request) of the first system domain is sent to the second system domain. The second system domain proxies the audio playback request of the first system domain to meet the sound requirements of the first system domain. When the second system domain proxies the audio playback request of the first system domain, it directly writes the first audio data carried by the audio playback request into the corresponding address of the shared memory area of ​​DMA, without the need for additional memory copying and without additional delay. Therefore, the method provided in the present application can reduce the audio delay of the AP domain and the CP domain, and improve the audio playback effect of the vehicle computer.

[0073] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0074] See also Figure 2 The cross-domain audio sharing method provided in the present application is applied to SOC, and the SOC is deployed with a first system domain (adaptive platform domain shown in the figure) and a second system domain (classic platform domain shown in the figure), and the first system domain and the second system domain are applied to process pulse code modulation data (PCM audio data). The first system domain can be an AP domain as shown in the figure, and the second system domain can be a CP domain as shown in the figure.

[0075] As shown in the figure, the first system domain is deployed with a virtual audio driver (Virtual Audio Driver), and the second system domain is deployed with direct memory access (DMA) and a physical sound card driver (Multi-PCM Driver). The DMA includes a shared memory area (Share Buffer) and a time-division multiplexing buffer (TDM FIFO).

[0076] Optionally, the various audio sources of the first system domain, such as media audio (Media), navigation audio (Navi), voice interaction audio (TTS, VR), etc., can call the virtual sound card driver by calling the Tiny Alsa Lib interface as shown in the figure. Specifically, the corresponding virtual pulse code modulation (PCM) node is called by calling Tiny Alsa Lib to input audio data. The virtual pulse code modulation (PCM) nodes are virtual pulse code modulation node 1, virtual pulse code modulation node 2, virtual pulse code modulation node 3 and virtual pulse code modulation node 4 as shown in the figure.

[0077] Optionally, the various sound sources of the second system domain, such as seat belts, turn signal prompt sounds (Chime), low-speed driving prompt sounds (Acoustic Vehicle Alerting System, referred to as AVAS), etc., can call the physical sound card driver by calling the advanced Linux sound architecture (Alsa Lib) interface as shown in the figure. Specifically, the pulse code modulation (PCM) node is called by calling the advanced Linux sound architecture to input audio data. The PCM nodes are pulse code modulation node 1, pulse code modulation node 2, pulse code modulation node 3 and pulse code modulation node 4 as shown in the figure.

[0078] The following description will be further described Figure 2 SOC deployment shown.

[0079] Figure 3 Schematic diagram of the cross-domain audio sharing method provided in this application Figure 1 .

[0080] S301, when receiving an audio play request from the first system domain, calling the virtual sound card driver, and sending the audio play request of the first system domain to the second system domain.

[0081] As described above, some audios are applicable to the first system domain, such as media audios, navigation audios, voice interaction audios, etc. When these audios have a need to be sounded, an audio play request from the first system domain is received.

[0082] The integrated circuit audio bus (I2S) and direct memory access (DMA) are configured in the second system domain. The second system domain implements the physical I2S and DMA drivers and actually controls I2S and DMA. Since I2S and DMA are not configured in the first system domain, the first system domain cannot directly operate I2S and DMA. At this time, the first system domain implements a set of virtual sound card drivers, and the second system domain implements the physical sound card driver, and the audio playback request of the first system domain is proxied through the second system domain.

[0083] S302: The second system domain receives an audio play request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run.

[0084] The first system domain and the second system domain may perform cross-domain communication via a Remote Processor Messaging (RPMSG) protocol, or perform cross-domain communication via other methods.

[0085] After receiving the audio playback request from the first system domain, the second system domain drives the DMA and the physical sound card driver of the second system domain to run. After the DMA runs, audio data can be written and read normally. The physical sound card driver runs to write audio data to or read audio data from the shared memory area of ​​the DMA.

[0086] S303: The second system domain writes first audio data into the shared memory area of ​​the direct access memory, where the first audio data originates from an audio play request of the first system domain.

[0087] The first audio data is carried by the audio play request and is received by the second system domain. After receiving the first audio data, the second system domain writes the first audio data to a corresponding position of the shared memory area of ​​the DMA.

[0088] The first system domain and the second system domain share a shared memory area as a DMA buffer to transfer audio data.

[0089] S304, the direct access memory moves the audio data in the shared memory area to the time division multiplexing buffer.

[0090] The second system domain directly writes the first audio data to the location (Slot) allocated in the shared memory area, and the DMA moves the audio data to the TDM buffer without the need for additional memory copying, thereby reducing audio delay.

[0091] Optionally, the DMA moves the audio data in the shared memory area to a TDM buffer according to the cycle size. The TDM buffer then outputs the received audio data to an external device to complete audio playback.

[0092] In summary, the cross-domain audio sharing method provided in this embodiment is applied to a system on chip, and the system on chip is deployed with a first system domain and a second system domain. The first system domain is deployed with a virtual sound card driver, and the second system domain is deployed with direct access memory and a physical sound card driver, and the DMA includes a shared memory area and a time-division multiplexing buffer. The method includes: when receiving an audio playback request from the first system domain, calling the virtual sound card driver, and sending the audio playback request of the first system domain to the second system domain; the second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the DMA and the physical sound card driver of the second system domain to run; the second system domain writes the first audio data to the shared memory area of ​​the DMA, and the first audio data comes from the audio playback request of the first system domain; the DMA moves the audio data in the shared memory area to the TDM buffer.

[0093] That is to say, by implementing a virtual sound card (Audio) driver in the first system domain, the audio playback request (Audio request) of the first system domain is sent to the second system domain. The second system domain proxies the audio playback request of the first system domain to meet the sound requirements of the first system domain. When the second system domain proxies the audio playback request of the first system domain, it directly writes the first audio data carried by the audio playback request into the corresponding address of the shared memory area of ​​DMA, without the need for additional memory copying and without additional delay. Therefore, the method provided in the present application can reduce the audio delay of the AP domain and the CP domain, and improve the audio playback effect of the vehicle computer.

[0094] In some embodiments, upon receiving an audio playback request from the second system domain, the second system domain writes second audio data to the shared memory area of ​​the DMA, where the second audio data originates from the audio playback request of the second system domain.

[0095] As mentioned above, media audio, navigation audio, and voice interaction audio are applicable to the CP domain. When these audios have a sounding requirement, an audio playing requirement from the second system domain is received. At this time, the second system domain writes the second audio data to the shared memory area.

[0096] It should be noted that when receiving an audio playback request from the first system domain and receiving an audio playback request from the second system domain, the second system domain writes the first audio data and the second audio data to the shared memory area without the need for additional memory copying and without additional delay, thereby reducing the audio delay between the AP domain and the CP domain and improving the audio playback effect of the vehicle computer.

[0097] In some embodiments, when the second system domain writes the first audio data to the shared memory area of ​​the DMA, the first audio data is written to a first position that is divided in the shared memory area of ​​the DMA. When the second system domain writes the second audio data to the shared memory area of ​​the DMA, the second audio data is written to a second position that is divided in the shared memory area of ​​the DMA. The first position and the second position are different positions that are divided in advance.

[0098] In some embodiments, after the DMA moves the audio data in the shared memory area to the TDM buffer, the cross-domain audio sharing method further includes:

[0099] Step 1: After the audio data is started to be transferred, the size update value of the transferred audio data is sent across the first system domain to the virtual sound card driver of the first system domain.

[0100] Since I2S and DMA are both deployed in the second system domain, the first system domain cannot know how much data DMA has moved. Therefore, after starting to move the audio data, the size update value of the moved audio data is sent across the first system domain to the virtual sound card driver of the first system domain.

[0101] See also Figure 2 Preferably, the second system domain notifies the first system domain of the size update value (Pos update) through a shared memory (Shared Memory). The reason is that the size update value is updated frequently and has high real-time requirements. If RPMSG is used, it will cause problems such as blocking, loss and delay, so the shared memory method is used.

[0102] Step 2: The first system domain updates the size of the memory available in the first system domain according to the size update value.

[0103] The second system domain writes the size update value into the shared memory, and the first system domain starts a thread to monitor the update of the size update value. Through monitoring, the first system domain updates the size of the memory available in the first system domain according to the size update value, and adjusts its own data storage capacity. The data storage capacity is used as a reference when reading (Read) or writing (Write) data.

[0104] The method provided in this embodiment enables the first system domain to adjust its own data storage capacity in time by timely sharing the data handling capacity of the shared memory area in the DMA, thereby improving the practicality and use effect of the first system domain.

[0105] For some examples, see Figure 2 When receiving an audio playback request from the first system domain, multiple virtual pulse code modulation (PCM) nodes are provided to the application layer to receive audio playback requirements of multiple audio sources in the first system domain. Figure 2 The virtual audio driver (Virtual Audio Driver) shown in the figure includes 4 virtual pulse code modulation (PCM) nodes, namely virtual pulse code modulation 1, virtual pulse code modulation 2, virtual pulse code modulation 3 and virtual pulse code modulation 4. Specifically, different virtual virtual pulse code modulation (PCM) nodes provide different data channels to meet the audio playback requirements of multiple sound sources.

[0106] Figure 4 Schematic diagram of the cross-domain audio sharing method provided in this application Figure 2 .

[0107] The second system domain is also deployed with an integrated circuit internal audio bus (I2S), and the cross-domain audio sharing method includes:

[0108] S401, receiving the operation of the first system domain on the virtual pulse code modulation node, sending the operation to the physical sound card driver of the second system domain in the kernel corresponding interface function, the second system domain receives the operation from the first system domain, drives the physical sound card driver to run, so as to configure the direct access memory and the built-in audio bus parameters of the integrated circuit.

[0109] The user control of the first system domain sends the operations of the virtual pulse code modulation (PCM) node, such as opening, closing and triggering, to the physical sound card driver of the second system domain through RPMSG in the corresponding interface function of the kernel, and the physical sound card driver of the second system domain implements the configuration of I2S and DMA.

[0110] S402: When receiving the audio play request from the first system domain, calling the virtual sound card driver, sending the audio play request of the first system domain to the second system domain.

[0111] S403: The second system domain receives the audio play request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run.

[0112] S404: The second system domain writes first audio data into the shared memory area of ​​the direct access memory, where the first audio data originates from an audio play request of the first system domain.

[0113] S405, the direct access transfers the audio data in the shared memory area to the time division multiplexing buffer.

[0114] For the related description of step S402 to step S405, reference may be made to the related description of step S301 to step S304, which will not be repeated here.

[0115] The method provided in this embodiment configures DMA and I2S according to the operation of the virtual pulse code modulation (PCM) node by the user space before processing the audio playback request of the first system domain, so that DMA and I2S can write the first audio data described above and carry the audio data under the control of the second system domain.

[0116] In some embodiments, the first system domain is deployed with an ALSA interface, and when the virtual sound card driver is called, the virtual sound card driver is called through the ALSA interface. Figure 2The first system domain is deployed with an Android Tiny ALSA interface. The media audio, navigation audio, and voice interaction audio of the first system domain call a virtual sound card driver through the Android Tiny ALSA interface.

[0117] In some embodiments, the second system domain is deployed with an ALSA interface, and pedestrian warning sounds, seat belt or turn signal warning sounds, etc. call the physical sound card driver interface through the ALSA interface.

[0118] The cross-domain audio sharing method provided in this embodiment is implemented in the kernel, complies with the ALSA standard interface, has no effect on the user layer, and application developers do not need to care about the underlying implementation.

[0119] See also Figure 5 An embodiment of the present application also provides a cross-domain audio sharing device 50, which is applied to a system on a chip, wherein the system on a chip is deployed with a first system domain and a second system domain, the first system domain is deployed with a virtual sound card driver, the second system domain is deployed with a direct access memory (DMA) and a physical sound card driver, and the direct access memory (DMA) includes a shared memory area and a time division multiplexing (TDM) buffer.

[0120] The cross-domain audio sharing device 50 includes:

[0121] The calling module 501 is used to call the virtual sound card driver when receiving the audio play request from the first system domain, and send the audio play request of the first system domain to the second system domain.

[0122] The driver module 502 is used for the second system domain to receive the audio play request from the first system domain through cross-domain communication, and drive the DMA and the physical sound card driver of the second system domain to run.

[0123] The writing module 503 is used for the second system domain to write first audio data into the shared memory area of ​​the DMA, where the first audio data originates from the audio playing request of the first system domain.

[0124] The data transfer module 504 is used for transferring the audio data in the shared memory area to the TDM buffer through the DMA.

[0125] In a possible implementation, the write module 503 is used to, upon receiving an audio playback request from the second system domain, cause the second system domain to write second audio data to the shared memory area of ​​the DMA, where the second audio data originates from the audio playback request of the second system domain.

[0126] In a possible implementation, the writing module 503 is used by the second system domain to write the first audio data into the first position of the shared memory area of ​​the DMA. The writing module 503 is used by the second system domain to write the second audio data into the second position of the shared memory area of ​​the DMA.

[0127] In one possible implementation, after the data transport module 504 starts transporting audio data, the size update value of the transported audio data is sent across the domain of the first system domain to the virtual sound card driver of the first system domain; the first system domain updates the size of the memory available in the first system domain according to the size update value.

[0128] In a possible implementation, the calling module 501 is used to provide a plurality of virtual pulse code modulation (PCM) nodes to the application layer to receive audio playback requirements of a plurality of audio sources in the first system domain.

[0129] In a possible implementation, the second system domain is also deployed with I2S, and the calling module 501 is also used to receive the operation of the first system domain on the virtual pulse code modulation (PCM) node, and send the operation to the physical sound card driver of the second system domain in the kernel corresponding interface function; the second system domain receives the operation from the first system domain, drives the physical sound card driver to run, so as to configure the DMA and the I2S parameters.

[0130] In a possible implementation, the data transfer module 504 is used for the DMA to transfer the audio data in the shared memory area to the TDM buffer according to a cycle size.

[0131] In a possible implementation, the first system domain is deployed with an Advanced Linux Sound Architecture (ALSA) interface, and the calling module 501 is used to call the virtual sound card driver through the ALSA.

[0132] In a possible implementation, the first system domain and the second system domain perform cross-domain communication via a remote processing message transfer (RPMSG) protocol.

[0133] Figure 6 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 6 As shown, the electronic device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0134] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

[0135] The specific implementation process of the processor 601 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0136] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0137] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.

[0138] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0139] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0140] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0141] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0142] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0143] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0144] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0145] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0146] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0147] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0148] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A cross-domain audio sharing method, characterized in that: Applied to a system on chip, the system on chip is deployed with a first system domain and a second system domain, the first system domain is deployed with a virtual sound card driver, the second system domain is deployed with a direct access memory and a physical sound card driver, the direct access memory includes a shared memory area and a time division multiplexing buffer, the method includes: When receiving an audio playback request from the first system domain, calling the virtual sound card driver, sending the audio playback request of the first system domain to the second system domain, and proxying the audio playback request of the first system domain through the second system domain; The second system domain receives the audio playback request from the first system domain through cross-domain communication, and drives the direct access memory and the physical sound card driver of the second system domain to run; The second system domain writes first audio data into the shared memory area of ​​the direct access memory, the first audio data originating from an audio play request of the first system domain; The direct access memory transfers the audio data in the shared memory area to the time division multiplexing buffer.

2. The method according to claim 1, characterized in that The method further comprises: When receiving an audio playback request from the second system domain, the second system domain writes second audio data to the shared memory area of ​​the direct access memory, where the second audio data originates from the audio playback request of the second system domain.

3. The method according to claim 2, characterized in that The second system domain writes the first audio data to the shared memory area of ​​the direct access memory, comprising: The second system domain writes the first audio data into a first position divided into the shared memory area of ​​the direct access memory; The second system domain writes the second audio data to the shared memory area of ​​the direct access memory, comprising: The second system domain writes the second audio data into a second location allocated in the shared memory area of ​​the direct access memory.

4. The method according to any one of claims 1 to 3, characterized in that: After the direct access memory transfers the audio data in the shared memory area to the time division multiplexing buffer, the method further includes: After the audio data is started to be transferred, the size update value of the transferred audio data is sent to the virtual sound card driver of the first system domain through the first system domain across domains; The first system domain updates the size of the memory available in the first system domain according to the size update value.

5. The method according to any one of claims 1 to 3, characterized in that: The receiving the audio play request from the first system domain includes: A plurality of virtual pulse code modulation nodes are provided to the application layer to receive audio playback requirements of a plurality of audio sources in the first system domain.

6. The method according to claim 5, characterized in that The second system domain is also deployed with an integrated circuit built-in audio bus, and the method further includes: receiving an operation of the first system domain on the virtual pulse code modulation node, and sending the operation to a physical sound card driver of the second system domain in a kernel corresponding interface function; The second system domain receives the operation from the first system domain and drives the physical sound card driver to run so as to configure the direct access memory and configure the parameters of the built-in audio bus of the integrated circuit.

7. The method according to any one of claims 1 to 3, characterized in that: The direct access memory transfers the audio data in the shared memory area to the time division multiplexing buffer, comprising: The direct access memory moves the audio data in the shared memory area to the time division multiplexing buffer according to the cycle size.

8. The method according to any one of claims 1 to 3, characterized in that: The first system domain is deployed with an advanced Linux sound architecture interface, and the calling of the virtual sound card driver includes: The virtual sound card driver is called through the advanced Linux sound architecture.

9. The method according to any one of claims 1 to 3, characterized in that: The first system domain and the second system domain perform cross-domain communication via a remote processing information transfer protocol.

10. A cross-domain audio sharing device, characterized in that: Applied to a system on chip, the system on chip is deployed with a first system domain and a second system domain, the first system domain is deployed with a virtual sound card driver, the second system domain is deployed with a direct access memory and a physical sound card driver, the direct access memory includes a shared memory area and a time division multiplexing buffer, the device comprises: a calling module, configured to, upon receiving an audio playback request from the first system domain, call the virtual sound card driver, send the audio playback request of the first system domain to the second system domain, and proxy the audio playback request of the first system domain through the second system domain; A driver module, used for the second system domain to receive an audio playback request from the first system domain through cross-domain communication, and drive the direct access memory and the physical sound card driver of the second system domain to run; A writing module, used for the second system domain to write first audio data into the shared memory area of ​​the direct access memory, where the first audio data originates from an audio playback request of the first system domain; The data transfer module is used for transferring the audio data in the shared memory area to the time division multiplexing buffer through the direct access memory.

11. An electronic device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 9 when executed by a processor.

13. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 9 when being executed by a processor.

Images