Method and device for multi-application sound transmission, electronic device and storage medium

Abstract

The present invention discloses a method and apparatus, an electronic device, and a storage medium for transmitting sound across multiple applications. The method comprises: receiving sound transmission requests from multiple applications, the sound transmission requests including sound playback requests and sound recording requests; selecting pulse code modulation devices corresponding to the multiple applications based on the multiple applications and a predetermined strategy, wherein each pulse code modulation device corresponds to a respective sound channel of the same sound card; matching the pulse code modulation devices with device channels based on the multiple applications, searching for corresponding sound channels and input / output devices based on the device channels; and playing or recording sound for the multiple applications via the input / output devices based on the sound transmission requests. The present invention enables multiple applications to simultaneously record or play different sounds on different input / output devices, thereby improving the flexibility and performance of simultaneous sound transmission across multiple applications.

Description

Technical Field

[0001] The present invention relates to the technical field of application sound output, and in particular to a method and device, an electronic device, and a storage medium for transmitting sound across multiple applications. Background Art

[0002] In current Android / AAOS car systems, multiple applications may need to output or record sounds simultaneously. In current SOC system platforms, the SOC's digital audio interface (I2S / TDM) is typically connected to a DSP (digital signal processor). The DSP is then connected to multiple DAC output devices or multiple ADC input devices, forming a multi-channel input and output system combining the SOC's digital audio interface and DSP.

[0003] For example, the DSP's digital audio interface can connect to 8 speakers, which are used to connect to output devices such as navigation NAV (2 channels), music MUSIC (2 channels), VR (2 channels), and system prompt sounds (2 channels). Therefore, the SOC's kernel driver also needs to register an ALSA (Advanced Linux Sound Architecture) sound card with 8-channel output. These sounds are emitted by different applications, and each application runs in a different process. In addition, the DSP's digital audio interface can connect to 8 ADC input devices. Therefore, the SOC's kernel driver also needs to register an ALSA sound card with 8-channel input. These inputs are provided by different devices, and each application runs in a different process.

[0004] However, in the current Android / AAOS system, ALSA SOUND's PCM (Pulse Code Modulation) device can only be opened by one process / thread. Once a process / thread occupies the device, other process threads can no longer use the device, resulting in difficulties for multiple applications to input and output different sounds through a multi-channel ALSA device at the same time. When an Android application occupies an ALSA multi-channel PCM device, other applications will not be able to use the device, resulting in conflicts between applications and waste of resources. In applications that need to input and output multiple sounds at the same time, such as recording, navigation, music, VR, and system prompts, it is necessary to use other methods to merge or route the sounds, which increases the complexity of software development and system design. Summary of the Invention

[0005] The present invention provides a method and device, an electronic device, and a storage medium for multi-application sound transmission, which can solve the problems of the current Android / AAOS vehicle SOC platform system that cannot realize multi-application transmission of different sounds, increases the complexity of software development and system design, and causes conflicts between applications and waste of resources. Improving these problems will improve the flexibility and performance of multi-application sound transmission.

[0006] In one aspect of the present invention, a method for transmitting sound across multiple applications is provided. The method comprises: receiving sound transmission requests from multiple applications, the sound transmission requests including sound playback requests and sound recording requests; selecting pulse code modulation devices corresponding to the multiple applications based on the multiple applications and a predetermined policy, wherein each pulse code modulation device corresponds to a sound channel of the same sound card; matching the pulse code modulation devices with device channels based on the multiple applications, searching for corresponding sound channels and input / output devices based on the device channels; and playing or recording sound for the multiple applications via the input / output devices based on the sound transmission requests.

[0007] In another aspect of the present invention, a device for transmitting sound for multiple applications is provided. The device includes: a controller configured to: receive sound transmission requests from multiple applications, the sound transmission requests including sound playback requests and sound recording requests; select pulse code modulation devices corresponding to the multiple applications based on the multiple applications and a predetermined policy, wherein each pulse code modulation device corresponds to a sound channel of the same sound card; match the pulse code modulation devices with device channels based on the multiple applications, and search for corresponding sound channels and input / output devices based on the device channels; and input / output devices electrically coupled to the controller and configured to play or record sound for the multiple applications via the input / output devices based on the sound transmission requests.

[0008] In another aspect of the present invention, an electronic device is provided, comprising a memory configured to store a processor-executable program and a processor configured to execute the program to perform the above-mentioned method for multi-application sound transmission.

[0009] In another aspect of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored on the medium, and the computer program is executed to implement the above-mentioned method for multi-application sound transmission.

[0010] According to the present invention, sound transmission requests from multiple applications are received, and pulse code modulation devices corresponding to the multiple applications are selected based on the multiple applications and a predetermined strategy. Each pulse code modulation device corresponds one-to-one to a channel of the same sound card. The pulse code modulation devices and their device channels are matched to the multiple applications, and the corresponding channels and input / output devices are searched based on the device channels. Finally, the sound is recorded through a microphone or output through a speaker. In this way, multiple applications can simultaneously record or play different sounds on different input / output devices, improving the flexibility and performance of simultaneous sound transmission for multiple applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a flowchart of a method for transmitting sound across multiple applications according to an embodiment of the present invention;

[0012] Figure 2 2. A diagram showing the system architecture for transmitting sound across multiple applications according to an embodiment of the present invention;

[0013] Figure 3 A diagram of a system architecture for simultaneously playing sounds for multiple applications according to an embodiment of the present invention;

[0014] Figure 4 is a diagram of a system architecture for simultaneously recording sound for multiple applications according to an embodiment of the present invention;

[0015] Figure 5 2 is a structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0016] To illustrate the technical content, achieved objectives and effects of the present invention in detail, the following description is given in conjunction with the embodiments and accompanying drawings.

[0017] In the existing technology, in the current Android / AAOS system, the ALSA SOUND PCM device can only be opened by one process / thread. Once a process / thread occupies the device, other process threads can no longer use the device, resulting in difficulties for multiple applications to input or output different sounds through a multi-channel ALSA device at the same time. When an Android application occupies an ALSA multi-channel PCM device, other applications will not be able to use the device, resulting in conflicts between applications and waste of resources. In applications that need to input or output multiple sounds at the same time, other methods are needed to achieve sound merging or routing, which increases the complexity of software development and system design.

[0018] In order to solve at least the above-mentioned technical problems, the present disclosure provides a method for transmitting sound for multiple applications. According to the present disclosure, sound transmission requests of multiple applications are received, and pulse code modulation devices corresponding to the multiple applications are selected according to the multiple applications and a predetermined strategy, and each pulse code modulation device corresponds one-to-one to each channel of the same sound card. The pulse code modulation devices and their device channels are matched according to the multiple applications, and the corresponding channels and input and output devices are searched according to the device channels. Finally, the sound is recorded through the microphone or output through the speaker device. In this way, multiple applications can record or play different sounds on different input and output devices at the same time, thereby improving the flexibility and performance of simultaneous sound transmission by multiple applications.

[0019] According to the embodiments of the present disclosure, in an Android / AAOS in-vehicle system, alsa-lib is ported to the Android / AAOS platform. Multiple pcmoutx or pcminx devices are virtualized through alsa-lib. These devices share a physical sound card and can map the physical sound card's channels. This improves the ability of multiple applications in the Android / AAOS in-vehicle system to simultaneously output or input different sounds, enhancing the user's audio experience and simplifying developers' work with multi-channel output or input. This will provide the in-vehicle system with more flexible and efficient sound management capabilities.

[0020] According to an embodiment of the present disclosure, a recording or playback application is associated with AudioHal through the recording and playback thread Thread in AudioFlinger via openstream. Each recording or playback thread corresponds to an inputstream or outputstream, and each inputstream or outputstream corresponds to an input and output device. This ensures that an application uses an input and output device alone, and ultimately sends the sound to the corresponding hardware processing circuit or receives the sound from the corresponding hardware processing circuit in a sound card with multi-channel input and output in the kernel.

[0021] Hereinafter, the technical solutions according to the present disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0022] Figure 1 FIG. 1 is a flow chart showing a method 100 for transmitting sound across multiple applications according to an embodiment of the present disclosure. Figure 1 , the method 100 includes the following steps 102 to 108.

[0023] In step 102, sound transmission requests from multiple applications are received, where the sound transmission requests include sound playing requests and sound recording requests.

[0024] In step 104, pulse code modulation devices corresponding to the multiple applications are selected based on the multiple applications and the predetermined policy, and each pulse code modulation device corresponds to a channel of the same sound card. In some embodiments, the recording thread or the playback thread is associated with the hardware abstraction layer through the audio policy executor.

[0025] In some embodiments, a hardware abstraction layer generates corresponding pulse code modulation device configuration items based on the number of applications, parses all pulse code modulation device configuration items, obtains pulse code modulation devices, and merges data from multiple pulse code modulation devices into multi-channel pulse code modulation data, which is transmitted to the sound card. The channels of the pulse code modulation data correspond one-to-one to the channels of the sound card. In this way, by virtualizing multiple pulse code modulation devices, these devices share a physical sound card and can be mapped to the channels of the physical sound card, so that multiple applications can play or record audio simultaneously without conflict.

[0026] In step 106, the pulse code modulation devices are matched to device channels according to the multiple applications, and the corresponding channels and input / output devices are searched based on the device channels. In some embodiments, each recording thread or playback thread is mapped to an input stream or output stream, and each input stream or output stream is mapped to an input / output device.

[0027] In some embodiments, an audio policy enforcer returns a corresponding pulse code modulation device for each application. Address information of the returned pulse code modulation device is stored in an input stream or an output stream. When the application inputs or outputs sound, the corresponding pulse code modulation device is opened using the stored address information. The pulse code modulation device is initialized, and a device channel for the pulse code modulation device is defined.

[0028] In step 108, sounds are played or recorded for the multiple applications via the input / output devices according to the sound transmission request. In some embodiments, the sounds are sent to or received from the device channels of the hardware circuit via the respective channels of the sound card of the kernel.

[0029] In some embodiments, multiple applications transmit sound through the same process, replacing the native shared memory method with a multi-threaded shared memory method based on global variables for communication. In this way, shared memory communication can be performed using global variables.

[0030] In some embodiments, the semaphore mechanism in process communication is removed. In this way, it is possible to avoid modifying Google's SELinux neverallow rules.

[0031] Figure 2FIG is a diagram showing the system architecture for transmitting sound for multiple applications according to an embodiment of the present invention. Figure 2 As shown in the signal flow of the double arrows in , the scenarios of multi-application sound transmission include two scenarios: sound playback (playback) and sound recording (recording). For these two scenarios, first, the direction of the data is different, one is recording and the other is playback. Secondly, the alsa plug-ins used are different, the pcm_dsnoop plug-in is used for recording and the dshare plug-in is used for playback. Then, the Android recording program operates the recording device through the inputstream of AudioHAL called by AudioFlinger's openInputstream, and the Android playback program operates the playback device through the outputstream of AudioHAL called by AudioFlinger's openOutputstream.

[0032] Reference Figure 2 Kernel refers to the Linux kernel, and sound card refers to a physical sound card. Furthermore, multiple Android apps play or record different types of sounds, and these different types of sound applications are returned to different devices through policies set by AudioFlinger (the audio policy executor, responsible for policy enforcement: managing audio stream devices and transmitting data). Audio HAL is the Android audio hardware abstraction layer.

[0033] Figure 3 Figure 1 is a diagram of a system architecture for playing sound simultaneously in multiple applications according to an embodiment of the present invention. The pcm_dshare plugin in alsa-lib can create multiple virtual PCMoutx devices, which can share the same physical PCM device and be mapped to different channels in the physical PCM device.

[0034] Audioflinger calls openOutputStream (opens the output stream device) to call the adev_open_output_stream function in the Android Audio HAL (Hardware Abstraction Layer). The adev_open_output_stream function stores the device address information passed in the struct stream_out. When playing, the start_output_stream function uses the alsa-lib interface to open the corresponding pcmoutx device based on the adderss information in the stream, perform initialization, play sound, and other operations. Finally, according to the information defined by pcmoutx, the corresponding channel (speaker) is selected and the alsa-lib interface is called for playback. In this way, multiple APP applications can play different sounds to different speakers at the same time, such as music and navigation sounds playing through different speakers at the same time.

[0035] For example, suppose four applications are playing audio simultaneously on the Android / AAOS system: Music Play, NavPlay, VR Play, and System Play. These applications correspond to Audio Hal's pcmout1, pcmout2, pcmout3, and pcmout4, respectively. alsa-lib parses the various pcmoutx configuration items in / vendor / etc / asound.conf and uses alsa-lib's dshare plugin to create virtual devices pcmout1, pcmout2, pcmout3, and pcmout4. Each application then outputs different sound content to the corresponding pcmoutx device through its own thread. Finally, the pcm_dshare plugin merges the data from multiple PCM devices into an 8-channel PCM data stream, which is then output to the corresponding physical ALSA sound card. Typically, one channel corresponds to one decoder (DAC), and one DAC is connected to one speaker, thus forming an 8-speaker audio playback system.

[0036] According to the embodiments of the present disclosure, the Android / AAOS platform uses tinyalsa by default, which allows a process / thread to access the same device. Tinyalsa does not have a function similar to the pcm_dshare plug-in, and does not use alsa-lib. The alsa-lib plug-in dshare is designed to support multiple applications playing audio simultaneously, improving the flexibility and performance of the system by effectively sharing audio output devices. It is used to share audio output devices so that multiple applications can play audio simultaneously without conflicts.

[0037] General features of dshare include:

[0038] Multi-application audio sharing: dshare allows multiple applications to send audio data to the audio output device at the same time without interfering with each other;

[0039] Avoid resource conflicts: dshare manages shared access to the audio output device to ensure that every app can use it as intended without conflicts or race conditions.

[0040] Buffering and data synchronization: Responsible for buffering audio data so that it can be transmitted to the audio output device at an appropriate rate to avoid audio interruptions or noise.

[0041] Performance optimization: dshare can optimize performance because it allows multiple applications to share the same audio output stream without copying the audio data.

[0042] For example, Music Play corresponds to channels 0 and 1, Nav Play corresponds to channels 2 and 3, VR Play corresponds to channels 4 and 5, and System Play corresponds to channels 6 and 7. This allows four applications to independently play unmixed sounds at the same time and output them to their respective speakers.

[0043] In some embodiments, all Android applications output sound through the same process, Audio Hal (android.hardware.audio.service), replacing the native SYSV shared memory method with a multi-threaded shared memory method based on global variables for communication. In this way, multi-threaded shared memory communication can be achieved using the global variables of the Audio Hal (android.hardware.audio.service) process.

[0044] According to the embodiments of the present disclosure, a multi-threaded shared memory approach using global variables replaces the kernel implementation of SysV IPC, eliminating the need to modify Google's default neverallow rule for public / domain.te. Because Android / AAOS apps all output music through the same process, Audio Hal (android.hardware.audio.service), global variables can be used for shared memory communication.

[0045] It is necessary to replace SysV's shared memory operation functions with a shared memory method based on global variables.

[0046] That is, redefine the definition of a function declared in ashmem.h

[0047] int shmctl(int shmid,int cmd,struct shmid_ds*buf);

[0048] int shmget(key_t key,size_t size,int shmflg);

[0049] void*shmat(int shmid,void const*shmaddr,int shmflg);

[0050] int shmdt(void const*shmaddr);

[0051] ashmem.c reimplements the definition of the above function.

[0052] typedef struct{

[0053] void*addr;

[0054] int id;

[0055] int shm_nattch;

[0056] size_t size;

[0057] key_t key;

[0058] }ashmem_t;

[0059] static ashmem_t shmem[SHMEM_COUNT];

[0060] static size_t ashm_count=0;

[0061] int shmget(key_t key,size_t size,int flags)

[0062] The function uses flags to determine whether it is IPC_CREAT. If flags contains IPC_CREAT, a new shmid is created, and then mmap is performed with shmem[idx].id = shmid and shmem[idx].key = key. If flags does not contain IPC_CREAT, it indicates that the corresponding shmid for the key needs to be searched from the shared memory of the global variable shmem[SHMEM_COUNT]. If not found, -1 is returned.

[0063] void*shmat(int shmid,void const*shmaddr,int shmflg)

[0064] Use shmid to find out whether there is a corresponding shmid that has been mmaped in shmem[SHMEM_COUNT]. If there is, return the corresponding shmem[idx].addr, and shmem[idx].shm_nattch++ can operate on shmem[idx].addr, otherwise return (void*)-1;

[0065] int shmdt(void const*shmaddr)

[0066] Check whether there is shmaddr in shmem[SHMEM_COUNT].addr. If so, the corresponding shmem[i].shm_nattch is --. If shmem[i].shm_nattch == 0, then munmap this part of memory and the memory cannot be used.

[0067] int shmctl(int shmid,int cmd,struct shmid_ds*buf)

[0068] The shared memory is operated through shmid. Currently, only IPC_RMID is supported for deleting shared memory and IPC_STAT is supported for querying shared memory status information.

[0069] Finally, add the #include<sys / shm.h> Replace all with #include "ashmem.h" and compile ashmem.c into it to completely replace the shm shared memory mechanism of sysV.

[0070] In some embodiments, the semaphore mechanism in process communication is removed. When operating PCM devices in Audio Hal, a locking mechanism prevents concurrent multi-threaded operations. However, alsa-lib's libasound internally doesn't require synchronization for concurrent multi-threaded operations. Therefore, removing the semaphore mechanism in communication avoids modifying Google's SELinux neverallow rules. The principle is that Android / AAOS apps all output data and play music through the same process, Audio Hal (android.hardware.audio.service). Global variables are scoped within the entire Audio Hal (android.hardware.audio.service) process. Therefore, multiple apps calling alsalib library files all belong to the same Audio Hal (android.hardware.audio.service) process, and multiple threads derived from it operate their respective PCM devices through alsa-lib. This allows multi-threading to replace SYSV multi-process communication, circumventing Google's SELinux neverallow rules. This allows multiple Android apps to share a multi-channel physical sound card and simultaneously output different sounds using only multi-threading. Similarly, when opening multiple PCM devices in the same process of Audio Hal (android.hardware.audio.service), a locking mechanism is implemented to prevent multiple threads from opening the same device concurrently. Therefore, the semaphore mechanism inside alsa-lib can be removed.

[0071] Figure 4 This figure illustrates the architecture of a system for simultaneously recording audio from multiple applications, according to an embodiment of the present invention. The pcm_dsnoop plugin in alsa-lib creates multiple virtual PCMinx devices, which share the same physical PCM device and can be mapped to different channels within the physical PCM device. alsa-lib's pcm_dsnoop is designed to support simultaneous audio capture by multiple applications, improving system flexibility and performance by effectively sharing audio input devices.

[0072] For example, consider a 2-ADC input (pcmin1) and a 6-ADC input (pcmin2) with different functional combinations. Two applications need to simultaneously record audio on the Android / AAOS system: HDMI input recording and voice recognition recording, corresponding to AudioHal Bus 1 and Bus 2, respectively. To record audio on Android, register a physical multi-channel PCMdeviceM. Then, using the alsa-lib dsnoop plugin, create virtual PCMin1 and PCMin2, mapping each to specific channels within PCMdeviceM. Each application then records audio from the corresponding PCMinx device in its own thread. For example, APP1 corresponds to PCMin1 (channels 1 and 2 of PCMdeviceM), and APP2 corresponds to PCMin2 (channels 3, 4, 5, 6, 7, and 8 of PCMdeviceM). This allows two applications to simultaneously capture multiple different sounds from the same multi-channel device.

[0073] dsnoop is a plugin in the alsa-lib library that is used to share audio input devices so that multiple applications can capture audio simultaneously without conflict. Its general features include:

[0074] Multi-application audio sharing: dsnoop allows multiple applications to collect audio data through audio input devices at the same time without interfering with each other. This is very useful for multiple applications that need to collect sound from different inputs at the same time.

[0075] Avoid resource conflicts: dsnoop manages shared access to audio input devices to ensure that each app can use it as intended without conflicts or race conditions.

[0076] Buffering and data synchronization: It is also responsible for buffering audio data and delivering it to the application at an appropriate rate from the audio input device to avoid audio stuttering or noise.

[0077] Performance optimization: dsnoop can optimize performance because it allows multiple applications to share the same audio input stream without duplicating the audio data.

[0078] For example, suppose two applications simultaneously capture audio on an Android / AAOS system: an HDMIIN application and a speech recognition application. These applications correspond to pcmin1 and pcmin2 of the Audio Hal, respectively. Using the alsa-lib dsnoop plugin, pcmin1 and pcmin2 are virtualized. Each application then uses its own thread to capture different sounds from the corresponding pcminx device and processes them based on its specific needs.

[0079] alsa-lib parses the various pcmin configuration items in / vendor / etc / asound.conf. It obtains various virtual pcminx devices, and finally maps the data of an 8-channel physical PCM device to each pcminx device through the pcm_dsnoop plug-in. Usually, one input channel corresponds to one ADC, and one ADC is connected to one audio input (mic or other analog signal input). This constitutes an audio acquisition system with 8 audio channel inputs. For example, the HDMIIN application corresponds to channel 0 and channel 1, and the voice recognition application corresponds to channel 2, channel 3, channel 4, channel 5, channel 6, channel 7 and channel 8. In this way, two applications can independently collect different sounds at the same time.

[0080] like Figure 4 As shown, many Android devices have multiple recording apps. Different types of recording apps return different devices through AudioFlinger's policy. AudioFlinger then calls openInputStream on the adev_open_input_stream function in the Android Audio HAL. The adev_open_input_stream function stores the device address information in structstream_in. During recording, the start_in_stream function uses the alsa-lib interface based on the addresserss information in stream to open the corresponding pcminx device, initialize it, and collect sound. Finally, the corresponding channel (microphone) is selected according to the pcminx information, and the alsa-lib interface is called to start recording. Multiple recording apps can simultaneously record to different recording devices. For example, a voice recognition app and an HDMIIN app can record simultaneously.

[0081] According to another aspect of the present invention, a device for multi-application sound transmission is provided, which includes a controller and input and output devices.

[0082] The controller is configured to receive sound transmission requests from multiple applications, the sound transmission requests including sound playback requests and sound recording requests. The controller is configured to select pulse code modulation devices corresponding to the multiple applications based on the multiple applications and a predetermined policy, wherein each pulse code modulation device corresponds to a respective audio channel of the same sound card. The controller is configured to match the pulse code modulation devices with device channels based on the multiple applications, and search for corresponding audio channels and input / output devices based on the device channels.

[0083] The input / output device is electrically coupled to the controller and is configured to play sounds or record sounds for the plurality of applications through the input / output device according to the sound transmission request.

[0084] It should be understood that the controller may be further configured to execute the various steps or actions in the method for multi-application sound transmission described above, which will not be described in detail here.

[0085] According to yet another aspect of the present invention, Figure 5 Schematic diagram of an electronic device 500 according to an embodiment of the present invention. Figure 5 The device 500 includes a memory 502, a processor 504, and a computer program stored in the memory and executable on the processor. When the processor 504 executes the computer program, the steps of the method for transmitting sound to multiple applications as described above are implemented.

[0086] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein a computer program is stored on the computer-readable storage medium, and the computer program is executed by a processor to implement the method for multi-application sound transmission as described above.

[0087] In summary, the method and apparatus, electronic device, and storage medium for multi-application sound transmission provided by the present invention receive sound transmission requests from multiple applications, select pulse code modulation devices corresponding to the multiple applications based on the multiple applications and a predetermined strategy, and each pulse code modulation device corresponds one-to-one to each channel of the same sound card. Pulse code modulation devices and their device channels are matched to the multiple applications, and the corresponding channels and input / output devices are searched based on the device channels. Finally, the sound is recorded through a microphone or output through a speaker device. In this way, multiple applications can simultaneously record or play different sounds on different input / output devices, improving the flexibility and performance of simultaneous sound transmission for multiple applications.

[0088] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's description and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A method for transmitting sound for multiple applications, characterized in that: include: Receiving sound transmission requests from multiple applications, the sound transmission requests including sound playing requests and sound recording requests; selecting pulse code modulation devices corresponding to the multiple applications respectively according to the multiple applications and a predetermined strategy, wherein each pulse code modulation device corresponds to each sound channel of the same sound card; Match the pulse code modulation devices and device channels respectively according to the multiple applications, and search for corresponding channels and input and output devices according to the device channels; as well as Play sounds or record sounds for the multiple applications through the input and output devices according to the sound transmission request.

2. The method according to claim 1, characterized in that Selecting pulse code modulation devices corresponding to the plurality of applications respectively according to the plurality of applications and the predetermined strategy includes: associating the recording thread or the playback thread with the hardware abstraction layer through the audio strategy executor, Matching the pulse code modulation devices and device channels according to the multiple applications includes: corresponding each recording thread or playback thread to an input stream or output stream, and each input stream or output stream corresponds to an input and output device, Transmitting the sound through the input / output device according to the sound transmission request includes: sending the sound to the device channel of the hardware circuit or receiving the sound from the device channel of the hardware circuit via each sound channel of the sound card of the kernel.

3. The method according to claim 2, characterized in that Selecting pulse code modulation devices corresponding to the multiple applications respectively according to the multiple applications and a predetermined strategy includes: A corresponding number of pulse code modulation devices is generated by the hardware abstraction layer according to the number of the multiple applications, and a device channel of each pulse code modulation device corresponds to a sound channel of the same sound card.

4. The method according to claim 3, characterized in that Generating a corresponding number of pulse code modulation devices according to the number of the multiple applications includes: Generate corresponding pulse code modulation device configuration items according to the number of applications, parse all the pulse code modulation device configuration items, and obtain the pulse code modulation device; Combining data from the plurality of pulse code modulation devices into multi-channel pulse code modulation data and transmitting the data to the sound card; and The channels of the pulse code modulation data correspond to the sound channels of the sound card.

5. The method according to claim 1, wherein Matching the pulse code modulation device and the device channel respectively according to the multiple applications includes: Return the corresponding pulse code modulation device for each application through the audio policy executor; The address information of the pulse code modulation device returned by the input stream or the output stream storage; When the application inputs or outputs sound, turning on the corresponding pulse code modulation device according to the stored address information; Initialize the pulse code modulation device and define a device channel of the pulse code modulation device.

6. The method according to claim 1, characterized in that Also includes: The multiple applications transmit sounds through the same process, replacing the native shared memory mode with a multi-threaded shared memory mode based on global variables for communication.

7. The method according to claim 6, characterized in that Also includes: Remove the semaphore mechanism from process communication.

8. A device for transmitting sound for multiple applications, characterized in that: include: The controller is configured as: Receiving sound transmission requests from multiple applications, the sound transmission requests including sound playing requests and sound recording requests; selecting pulse code modulation devices corresponding to the multiple applications respectively according to the multiple applications and a predetermined strategy, wherein each pulse code modulation device corresponds to each sound channel of the same sound card; Match the pulse code modulation devices and device channels respectively according to the multiple applications, and search for corresponding channels and input and output devices according to the device channels; as well as An input / output device is electrically coupled to the controller and configured to play sounds or record sounds for the plurality of applications according to the sound transmission request.

9. An electronic device, characterized in that: include: a memory configured to store a processor-executable program; as well as A processor configured to execute the program to perform the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: The computer program is executed to implement the method according to any one of claims 1 to 7.

Images