Audio output channel establishment method and system based on TinyAlsa

Abstract

The invention discloses a method and a system for establishing an audio output channel based on TinyAlsa. Calling an interface of the TinyAlsa library through a pre-established application program; permission configuration of the application program is completed in advance, and an interface of the TinyAlsa library is used for outputting audio data to an opened sound card equipment node; for each path of audio data to be played, traversing sound card equipment nodes of a system, and screening out available sound card equipment nodes; for each available sound card equipment node, executing a node opening operation; and if the sound card equipment node is successfully opened, establishing a TinyAlsa-based audio output channel according to the interface of the TinyAlsa library and the opened sound card equipment node. According to the method and the device, the original audio path of Android can be bypassed, the audio data can be directly output to the sound card equipment, the audio delay is remarkably reduced, and simultaneous playing of multiple paths of audio data can be supported.

Description

Technical Field

[0001] The present invention relates to the technical field of audio output, and particularly to a method and system for establishing an audio output path based on TinyAlsa. Background Art

[0002] The Android system currently supports multiple audio output methods, among which the common ones are ordinary AudioTrack audio output and fast track fast output. Ordinary AudioTrack is mainly applicable to conventional audio scenarios, and its audio stream will pass through a complete audio processing path. Fast track, on the other hand, allows a higher real-time priority with the support of hardware, reduces latency by using a smaller audio buffer and skipping some audio processing links. However, both of these methods need to go through a complete audio path, and each link has a certain delay, resulting in a relatively high delay in the final audio output. In scenarios such as TV screen mirroring where high requirements for audio-video synchronization are required, this delay may cause audio-video out-of-sync, which has an adverse impact on the user experience.

[0003] Therefore, the existing technology still needs to be improved and developed. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to provide a method and system for establishing an audio output path based on TinyAlsa in view of the above-mentioned defects of the existing technology, aiming to solve the problem that the existing audio output methods all need to go through a complete audio path, resulting in a relatively high delay in the final audio output.

[0005] The technical solution adopted by the present invention to solve the problem is as follows:

[0006] In the first aspect, an embodiment of the present invention provides a method for establishing an audio output path based on TinyAlsa, the method comprising:

[0007] Pre-establish an interface for an application program to call the TinyAlsa library; wherein, the application program has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node;

[0008] For each path of audio data to be played, traverse the sound card device nodes of the system, and screen out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation;

[0009] If the opening is successful, establish a path of audio output based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node.

[0010] In an embodiment, the method for configuring the permissions of the application program includes:

[0011] Obtain the signature key file of the platform;

[0012] Configure the signature key file in the core configuration file of the application to make the signature key file effective;

[0013] Add the system shared user ID to the information description file to enable the compiled application to have system signature and permissions.

[0014] In one implementation, establishing an interface for the application to call the TinyAlsa library includes:

[0015] Integrate the TinyAlsa source code into the project of the application, compile to generate a dynamic library, and obtain the TinyAlsa library;

[0016] Link the TinyAlsa library to the project of the application to obtain the interface for the application to call the TinyAlsa library.

[0017] In one implementation, integrating the TinyAlsa source code into the project of the application and compiling to generate a dynamic library includes:

[0018] Copy the TinyAlsa source code to the target path of the project of the application;

[0019] Write a configuration file for the CMake compilation tool, and compile the TinyAlsa source code into a dynamic library through the CMake compilation tool.

[0020] In one implementation, linking the TinyAlsa library to the project of the application includes:

[0021] Link the TinyAlsa library according to the business code path of the application, and add the header file of the TinyAlsa library to the business code of the application.

[0022] In one implementation, the method further includes:

[0023] If the opening fails, perform the node opening operation for the next available sound card device node;

[0024] If the application has not completed the permission configuration, establish an audio output path based on the oboe framework.

[0025] In one implementation, the method further includes:

[0026] If the application has completed permission configuration but fails to open all the available sound card device nodes, an audio output path based on the oboe framework is established.

[0027] In a second aspect, an embodiment of the present invention further provides an audio output path establishment system based on TinyAlsa, the system includes:

[0028] An interface establishment module, configured to pre - establish an interface for the application to call the TinyAlsa library; wherein, the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to the opened sound card device node;

[0029] A node traversal module, configured to traverse the sound card device nodes of the system for each path of audio data to be played, filter out the available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation;

[0030] A path establishment module, configured to, if the opening is successful, establish an audio output path based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node.

[0031] In a third aspect, an embodiment of the present invention further provides a terminal, the terminal includes a memory and more than one processor; the memory stores more than one program; the program contains instructions for executing the method for establishing an audio output path based on TinyAlsa as described in any one of the above; the processor is configured to execute the program.

[0032] In a fourth aspect, an embodiment of the present invention further provides a computer - readable storage medium, on which multiple instructions are stored, and the instructions are suitable for being loaded and executed by a processor to implement the steps of the method for establishing an audio output path based on TinyAlsa as described in any one of the above

[0033] Advantages of the present invention: In the embodiments of the present invention, an interface for the application to call the TinyAlsa library is pre - established; the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to the opened sound card device node; for each path of audio data to be played, the sound card device nodes of the system are traversed, and the available sound card device nodes are filtered out; for each of the available sound card device nodes, a node opening operation is performed; if the opening is successful, an audio output path based on TinyAlsa is established according to the interface of the TinyAlsa library and the opened sound card device node. The present invention can bypass the native audio path of Android, directly output audio data to the sound card device, significantly reduce audio latency, and support simultaneous playback of multiple paths of audio data, ensuring the independence and synchronization of multiple audio streams and meeting the requirements of multi - task scenarios. Brief Description of the Drawings

[0034] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0035] Figure 1 It is a schematic flowchart of the method for establishing an audio output path based on TinyAlsa provided by an embodiment of the present invention.

[0036] Figure 2 It is a block diagram of the steps for directly playing audio using the TinyAlsa API provided by an embodiment of the present invention.

[0037] Figure 3 It is an architecture diagram of the APP directly calling the TinyAlsa API audio output path provided by an embodiment of the present invention.

[0038] Figure 4 It is a flowchart for implementing multi-channel TinyAlsa audio output provided by an embodiment of the present invention.

[0039] Figure 5 It is a flowchart for the implementation of rolling back to oboe when TinyAlsa fails to open provided by an embodiment of the present invention.

[0040] Figure 6 It is a schematic diagram of the modules of the system for establishing an audio output path based on TinyAlsa provided by an embodiment of the present invention.

[0041] Figure 7 It is a schematic block diagram of the terminal provided by an embodiment of the present invention. Detailed Embodiments

[0042] The present invention discloses a method and system for establishing an audio output path based on TinyAlsa. To make the objectives, technical solutions and effects of the present invention clearer and more definite, the following further elaborates on the present invention with reference to the accompanying drawings and by way of examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0043] Those skilled in the art can understand that, unless specifically stated, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the description of the present invention means the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. It should be understood that when we say an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The phrase "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0044] Those skilled in the art can understand that, unless otherwise defined, all terms (including technical terms and scientific terms) used herein have the same meaning as the general understanding of those of ordinary skill in the art to which the present invention pertains. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted with an idealized or overly formal meaning unless specifically defined as here.

[0045] In view of the above-mentioned defects of the prior art, the present invention provides a method for establishing an audio output path based on TinyAlsa. The method includes pre-establishing an interface for an application to call the TinyAlsa library; wherein, the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node; for each path of audio data to be played, traverse the sound card device nodes of the system and filter out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation; if the opening is successful, establish an audio output path based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node. The method for establishing an audio output path based on TinyAlsa provided by the present invention can bypass the native audio path of Android and directly output audio data to the sound card device, thereby significantly reducing audio latency and improving the stability and real-time performance of audio output.

[0046] As Figure 1 shown, the method specifically includes the following steps:

[0047] Step S100, pre-establish an interface for an application to call the TinyAlsa library; wherein, the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node.

[0048] Specifically, the application (APP) in this embodiment needs to be pre-configured with permissions so that it can subsequently call the interfaces (APIs) of the TinyAlsa library normally. The application needs to interact with the audio processing function, and the TinyAlsa library provides a simplified interface to the ALSA audio system. Establishing the interface in advance is to enable the application to conveniently and standardly call the functional functions in the TinyAlsa library, so as to output the user's pcm audio data to the opened sound card device through the Tinyalsa interface, realizing the audio playback function. In an actual application scenario, the application directly calls the API interface of the TinyAlsa library, bypasses the Android native audio path, and directly interacts with the hardware to achieve low-latency audio output.

[0049] In one implementation, the method for configuring the permissions of the application includes:

[0050] Obtain the signature key file of the platform;

[0051] Configure the signature key file in the core configuration file of the application to make the signature key file effective;

[0052] Add the system shared user ID to the information description file to enable the generated application to have system signature and permissions.

[0053] Specifically, the first core step to enable the application to directly call the interface of the TinyAlsa library is: system signature verification. As Figure 2 shown, since directly accessing the interface of the TinyAlsa library requires system signature and system permission authentication, this step can ensure that the application has the corresponding permissions. First, obtain the signature key file of the platform. Among them, the platform signature refers to the common system signature applicable to specific product models of a certain solution provider. Then add the relevant information of the signature key file, including but not limited to the path, alias, password, etc. of the key, to the configuration file of the application to make the signature effective. Then add the system shared user ID to the information description file of the application, and configure the permissions and functions required by the application to indicate that the application has specified-level permissions and signatures.

[0054] For example, for an Android TV product named mtk9653 (mtk solution provider), first, the system signature can be obtained through the system source code of mtk9653, that is, obtain the signature key file (key file) through the platform source code. Then configure the signature key file in the build.gradle file of the APP to make the signature effective. Then perform permission configuration, that is, add the system shared user ID to the AndroidManifest.xml file:

[0055] <manifest

[0056] xmlns:android="http: / / schemas.android.com / apk / res / android"

[0057] android:sharedUserId="android.uid.system">

[0058] Through the above configuration, ensure that the compiled APP has system signature and permissions, so as to allow the API of the TinyAlsa library to be called.

[0059] In one implementation, establish an interface for the application to call the TinyAlsa library, including:

[0060] Integrate the TinyAlsa source code into the project of the application, compile to generate a dynamic library, and obtain the TinyAlsa library;

[0061] Link the TinyAlsa library to the project of the application to obtain the interface for the application to call the TinyAlsa library.

[0062] Specifically, the second core step to implement the application to directly call the interface of the TinyAlsa library is: compile the TinyAlsa source code. This step mainly includes integrating the TinyAlsa source code into the APP project, compiling to generate a dynamic library, and linking it to the application project. First, add the source code files of TinyAlsa to the development project of the application, that is, in the file structure of building the application project, the TinyAlsa source code will become a part of it. A dynamic library is a library that can be loaded at runtime. When the TinyAlsa source code is integrated, it is compiled into a dynamic library through a preset compilation method. Then link the compiled dynamic library with the application, so that the application can call the functions of the TinyAlsa library when running. The TinyAlsa library provides a series of function interfaces, such as functions for audio playback, recording, etc. When the TinyAlsa library is successfully linked to the application project, the application can use these function interfaces in its own code.

[0063] In one implementation, integrating the TinyAlsa source code into the project of the application and compiling to generate a dynamic library includes:

[0064] Copy the TinyAlsa source code to the target path of the project of the application;

[0065] Write a configuration file for the CMake compilation tool, and compile the TinyAlsa source code into a dynamic library through the CMake compilation tool.

[0066] Specifically, place the TinyAlsa source code in the target path of the APP project, making the TinyAlsa source code part of the APP project for subsequent compilation operations on the TinyAlsa source code. CMake is a cross-platform compilation management tool. After writing the configuration file for CMake, the project can be built through the CMake command. The purpose of writing the configuration file for CMake in this embodiment is to inform CMake how to process the TinyAlsa source code and then compile it into a dynamic library.

[0067] Illustrating with an example, the process of generating a dynamic library specifically includes the following steps:

[0068] (1) Source code copy: Copy the TinyAlsa source code in the platform source code repository to the native C++ source path of the APP project;

[0069] (2) CMake build: Write a CMakeLists.txt file to compile the TinyAlsa source code into a dynamic library:

[0070] add_library(TinyAlsa SHARED TinyAlsa_src1.c TinyAlsa_src2.c #... other TinyAlsa source code files);

[0071] Target_include_directories(TinyAlsa PUBLIC ${CMAKE_SOURCE_DIR} / include);

[0072] (3) Generate dynamic library: Complete the compilation through the CMake tool to generate the libTinyAlsa.so file and link it to the project.

[0073] In one implementation, linking the TinyAlsa library to the project of the application includes:

[0074] Link the TinyAlsa library according to the business code path of the application and add the header file of the TinyAlsa library to the business code of the application.

[0075] Specifically, the third core step to implement the application directly calling the interface of the TinyAlsa library is: the use of the TinyAlsa interface. The TinyAlsa library contains the function implementations for handling audio-related operations. The purpose of linking the TinyAlsa library is to enable the application to use the functions provided by the TinyAlsa library. Further, linking the TinyAlsa library according to the business code path of the application can ensure that the linking process matches the overall structure and build process of the application. The header files of the TinyAlsa library contain important information such as the declarations of the functions in the library and the definitions of data structures. Adding the header files of TinyAlsa to the business code can enable the compiler to recognize and use the functions and data structures in the TinyAlsa library during the compilation phase. Finally, the application can call the TinyAlsa library to implement audio-related business functions.

[0076] For example, as Figure 3 shown, it shows the architecture diagram of the APP directly calling the audio output path of the TinyAlsa API. The process of directly calling the API provided by TinyAlsa in the business code to achieve the rapid output of audio data mainly includes the following steps:

[0077] (1) Link the TinyAlsa dynamic library, that is, link the TinyAlsa library in the CMakeLists.txt in the business code path:

[0078] target_link_libraries(${TARGET} PUBLIC TinyAlsa);

[0079] (2) Include the header files, that is, add the TinyAlsa header files to the business code:

[0080] #include<TinyAlsa / asoundlib.h>;

[0081] (3) Open and close the PCM device, that is, open and close the PCM device through the API of TinyAlsa:

[0082] Open the PCM device: Use the pcm_open() API and specify the card and device parameters of the sound card:

[0083] struct pcm* pcm_handle;

[0084] pcm_handle = pcm_open(0, 0, PCM_OUT, &config);

[0085] Closing the PCM device: Use pcm_close() to close the opened PCM device:

[0086] pcm_close(pcm_handle);

[0087] (4) Outputting PCM data, that is, calling the pcm_writei() API to directly write the PCM data received by the network to the sound card:

[0088] int frames = pcm_writei(pcm_handle, data, frame_count);

[0089] Among them, pcm_handle is the PCM device handle, data is the array storing PCM data, and frame_count is the number of frames of PCM data.

[0090] By directly calling this API, the audio data bypasses the Android native path and is directly written to the sound card, thus significantly reducing the audio output latency.

[0091] Step S200: For each audio data to be played, traverse the sound card device nodes of the system, and filter out the available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation.

[0092] Step S300: If the opening is successful, establish an audio output path based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node.

[0093] To support the playback of multiple TinyAlsa audio data streams, that is, to enable multiple TinyAlsa players to work in parallel, this embodiment needs to coordinate the resource allocation and management of each audio stream to ensure that different audio data streams can be output synchronously and without interference. Specifically, TinyAlsa opens the sound card device (card-device) node in an exclusive manner. As Figure 4As shown, an application with system signature and system permissions can traverse the sound card device nodes of the system. Different application programs can open different sound card device nodes at the same time and establish different TinyAlsa playback paths, so as to achieve simultaneous playback of multiple TinyAlsa audio. Taking an application program as an example, if it successfully opens a sound card device node, it successfully enables a TinyAlsa output path; if the opening of the current sound card device node fails, it means that a TinyAlsa output has been enabled for this sound card device node, or this sound card device node has been occupied by other processes, then it tries to open the next sound card device node. Repeating the above steps can enable different application programs to open different sound card device nodes respectively, and then achieve simultaneous output of multiple TinyAlsa audio. It is applicable to scenarios of multiple audio, such as the scenario of multiple-screen mirroring audio playback, or the scenario of multi-window and multiple-audio processing.

[0094] For example, first traverse the sound card device nodes:

[0095] Traverse the system sound card nodes in the APP and store the names of the playback device nodes that meet the conditions in the available sound card array available_playback_devices. For example, traverse the nodes ending with p under / proc / asound / card0 (such as pcm0p and pcm1p) and save them to available_playback_devices.

[0096] Then try to open the sound card device nodes one by one:

[0097] Try to open the nodes in available_playback_devices with pcm_open() in sequence. If the opening is successful, establish a TinyAlsa audio path; if the return is a failure, it means the node is occupied, and then try the next node. For example, currently, two sound card device nodes [pcm0p, pcm1p] are already saved in available_playback_devices. First, try to open the pcm0p node with pcm_open. If pcm_open returns normally, it means the node is successfully opened, and a TinyAlsa output path is successfully enabled; if pcm_open returns a failure, it means the node opening fails, and a TinyAlsa output path has already been enabled for the current node, or the node has been occupied by other processes. Then try to open the next node pcm1p. Repeat the above steps, and it is possible to open the pcm0p and pcm1p nodes respectively to achieve simultaneous output of two channels of TinyAlsa audio. The same principle applies to more than two channels of TinyAlsa output. Through the above method, multi-channel TinyAlsa audio output can be achieved, and the maximum number of output channels is determined by the number of cards and devices supported by the system.

[0098] In one implementation, the method further includes:

[0099] If the application has not completed the permission configuration, establish an audio output path based on the oboe framework.

[0100] Specifically, if the application has not completed the permission configuration, that is, it does not have both system signature and permissions at the same time, do not try to open the sound card device node in the TinyAlsa way, but use the oboe way to establish an audio output path. Through the AudioStreamBuilder and related APIs provided by Oboe, establish an oboe low-latency audio path to achieve function compatibility.

[0101] In one implementation, the method further includes:

[0102] If the application has completed the permission configuration, but all available sound card device nodes fail to open, establish an audio output path based on the oboe framework.

[0103] In addition to being unable to access the TinyAlsa API due to insufficient permissions and thus unable to establish a TinyAlsa path, it may also be due to device occupation, that is, the sound card device node is occupied by other processes, resulting in the failure of pcm_open() to return. To improve compatibility, this embodiment also provides a fault tolerance mechanism for rolling back oboe when opening TinyAlsa fails. Specifically, use pcm_open() of the TinyAlsa API to open the sound card device node. If the return is successful, the establishment of the TinyAlsa output path is successful; if the current sound card device node returns a failure, continue to open the next sound card device node; if all sound card device nodes return failures, it means that opening TinyAlsa fails, and use oboe to output audio, that is, switch to the audio output path established based on the oboe framework.

[0104] As Figure 5 shown, when the opening of the TinyAlsa player fails (for example, due to device non - support or permission restrictions), it automatically rolls back to the Android - native Oboe framework for audio playback to ensure the continuity and compatibility of the audio output function. Through this fault tolerance mechanism, the system can flexibly adapt to different devices and environments, improving the robustness, stability, and universality of the system.

[0105] To facilitate the understanding of the technical solutions of the present invention, the following provides several possible application scenarios of the technical solutions of the present invention:

[0106] Scenario 1: In the development of TV screen mirroring applications, as the developer of the screen mirroring receiver (with system signature and system permissions), the TV manufacturer adopts the technical solution provided by the present invention to create an audio player module based on TinyAlsa. This module is used to play the audio stream received through the network (such as PCM data stream) and directly output it to the sound card device. By bypassing the Android native audio path, the lowest audio latency is achieved, ensuring precise synchronization of the screen mirroring and audio, thereby significantly enhancing the viewing experience of users in the TV screen mirroring scenario. After actual measurement, on the TV platform, when using the same audio parameters for testing, the audio playback latency of the technical solution of the present invention is reduced by 70 - 300 ms compared to the Android native audio path, significantly improving the audio-visual synchronization effect. Additionally, if there are multiple screen mirrorings at this time, on the premise that the system supports multiple sound card devices, multiple TinyAlsa audio paths can be opened simultaneously; if the system only supports one device, one TinyAlsa is opened, and the remaining screen mirroring paths open oboe audio output; if the APP does not have system signature or system permissions, the establishment of the audio paths for all screen mirrorings adaptively rolls back to use oboe to open the corresponding audio output. The present invention can be used as the core function of the audio rendering and playback module and applied to the screen mirroring receiver of Android TVs. Through the audio processing path with the lowest latency, the audio data stream received from the network (such as PCM raw stream, AAC, FLAC, etc., the PCM stream after decoding the encoded audio stream) is quickly output to the audio playback device, realizing the real-time audio playback function and providing an excellent audio-visual synchronization experience for the TV screen mirroring scenario.

[0107] Scenario 2: In the development of XR (Extended Reality) devices on the Android platform, the device developer utilizes the technical solution of the present invention to create an audio player based on TinyAlsa for real-time playback of media audio data. By directly outputting the audio data to the sound card device, the audio latency is significantly reduced, ensuring high-precision synchronization of the screen and audio, and greatly enhancing the immersive experience of users in the XR scenario.

[0108] Scenario 3: In the multi-window application scenario of Android TVs, multiple windows respectively create multiple audio output paths to play audio. By adopting the technical solution provided by the present invention, different TinyAlsa audio paths can be created for multiple windows, achieving the lowest latency audio output and enhancing the user experience.

[0109] The advantages of the present invention are as follows:

[0110] 1. Lowest latency output: The traditional Android audio output path is long and goes through multiple system levels for processing, resulting in a significant increase in latency, which cannot meet the strict requirements of audio-video synchronization in the screen mirroring scenario. By directly outputting the PCM data received over the network to the sound card, this invention bypasses the native Android audio path, eliminates the intermediate links, significantly reduces the audio latency, and meets the requirements of real-time performance and audio-video synchronization in the screen mirroring scenario.

[0111] 2. Get rid of the dependence on shared memory: Existing optimization solutions rely deeply on the shared memory mechanism and the native audio path, lacking flexibility and being difficult to run independently. This invention does not need to rely on the shared memory mechanism and directly realizes audio output through the API interface provided by TinyAlsa, completely getting rid of the dependence on the shared memory mechanism, achieving higher flexibility and independence, and being applicable to more scenarios with strict latency requirements.

[0112] 3. Improved stability: For screen mirroring or other real-time scenarios, existing methods are subject to complex interactions between system levels in the audio path, resulting in poor stability. By simplifying the audio output path and introducing the rollback mechanism (fault tolerance mechanism) from TinyAlsa to Oboe, this invention effectively solves the audio anomalies caused by permissions or device occupation, and greatly improves the stability and compatibility of audio output.

[0113] 4. Enhanced multi-task adaptation ability: Existing solutions lack flexibility when dealing with multiple audio data streams, which may lead to resource conflicts or synchronization problems. This invention supports multiple TinyAlsa to play simultaneously, ensuring the independence and synchronization of multiple audio streams, and meeting the scenario requirements of simultaneous output of multiple audio streams. This invention solves the resource conflict problem during the playback of multiple audio streams and meets the requirements of complex multi-task scenarios.

[0114] 5. Easy to implement: Based on the standard API interface of TinyAlsa, it has high development feasibility and engineering maintainability, and is also compatible with different audio output frameworks, with stronger adaptability.

[0115] In summary, by directly calling the TinyAlsa API and combining multiple audio playback with the Oboe fault tolerance mechanism, this invention realizes the fast output of Android system audio, solves problems such as high latency of the native audio path, strong dependence on shared memory, and poor multi-task adaptability. It can significantly reduce audio latency, improve output stability, and provide an efficient, stable, and low-latency audio output solution for high-real-time scenarios such as TV screen mirroring, XR devices, and online streaming media.

[0116] Based on the above embodiments, this invention also provides a system for establishing an audio output path based on TinyAlsa, as Figure 6 shown, the system includes:

[0117] An interface establishment module 01 is used to pre - establish an interface for an application to call the TinyAlsa library. Among them, the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node.

[0118] A node traversal module 02 is used to traverse the sound card device nodes of the system for each path of audio data to be played, and filter out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation.

[0119] A path establishment module 03 is used to, if the opening is successful, establish a TinyAlsa - based audio output path according to the interface of the TinyAlsa library and the opened sound card device node.

[0120] Based on the above - mentioned embodiments, the present invention also provides a terminal, and its principle block diagram can be as Figure 7 shown. The terminal includes a processor, a memory, a network interface, and a display screen connected through a system bus. Among them, the processor of the terminal is used to provide computing and control capabilities. The memory of the terminal includes a non - volatile storage medium and an internal memory. The non - volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non - volatile storage medium. The network interface of the terminal is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it realizes a method for establishing a TinyAlsa - based audio output path. The display screen of the terminal can be a liquid crystal display screen or an electronic ink display screen.

[0121] Those skilled in the art can understand that Figure 7 the principle block diagram shown is only a block diagram of a part of the structure related to the solution of the present invention, and does not constitute a limitation on the terminal to which the solution of the present invention is applied. A specific terminal may include more or fewer components than those shown in the figure, or combine some components, or have a different component layout.

[0122] In one implementation, more than one program is stored in the memory of the terminal, and is configured to be executed by more than one processor. The more than one program includes instructions for performing a method for establishing a TinyAlsa - based audio output path.

[0123] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the embodiments provided by the present invention can include non-volatile and / or volatile memories. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0124] In summary, the present invention discloses a method and system for establishing an audio output path based on TinyAlsa. The method includes pre-establishing an interface for an application program to call the TinyAlsa library; wherein, the application program has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node; for each path of audio data to be played, traverse the sound card device nodes of the system and filter out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation; if the opening is successful, establish a path of audio output based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node. The present invention can bypass the native audio path of Android and directly output audio data to the sound card device, significantly reducing audio latency, and can support simultaneous playback of multiple paths of audio data, ensuring the independence and synchronization of multiple audio streams and meeting the requirements of multi-task scenarios.

[0125] It should be understood that the application of the present invention is not limited to the above examples. For those of ordinary skill in the art, improvements or transformations can be made according to the above description, and all such improvements and transformations should fall within the protection scope of the appended claims of the present invention.

Claims

1. A method for establishing an audio output path based on TinyAlsa, characterized in that: The method comprises: Establishing in advance an interface for an application to call a TinyAlsa library; wherein the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node; For each channel of audio data to be played, traverse the sound card device nodes of the system and filter out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation; If the opening is successful, a TinyAlsa-based audio output path is established according to the interface of the TinyAlsa library and the opened sound card device node.

2. The method for establishing an audio output path based on TinyAlsa according to claim 1, characterized in that: The permission configuration method of the application program includes: Get the platform's signature key file; Configuring the signature key file in the core configuration file of the application to make the signature key file effective; A system shared user ID is added to the information description file to ensure that the compiled application has system signature and permissions.

3. The method for establishing an audio output path based on TinyAlsa according to claim 1, characterized in that: Establish an interface for the application to call the TinyAlsa library, including: Integrate the TinyAlsa source code into the project of the application, compile and generate a dynamic library, and obtain the TinyAlsa library; The TinyAlsa library is linked to the project of the application to obtain an interface for the application to call the TinyAlsa library.

4. The method for establishing an audio output path based on TinyAlsa according to claim 3, characterized in that: Integrate the TinyAlsa source code into the application project and compile to generate a dynamic library, including: Copy the TinyAlsa source code to the target path of the project of the application; Write a configuration file of the CMake compilation tool, and compile the TinyAlsa source code into a dynamic library through the CMake compilation tool.

5. The method for establishing an audio output path based on TinyAlsa according to claim 3, characterized in that: Link the TinyAlsa library to the application project, including: Link the TinyAlsa library according to the business code path of the application, and add the header file of the TinyAlsa library to the business code of the application.

6. The method for establishing an audio output path based on TinyAlsa according to claim 1, characterized in that: The method further comprises: If the application has not completed the permission configuration, an audio output path based on the oboe framework is established.

7. The method for establishing an audio output path based on TinyAlsa according to claim 1, characterized in that: The method further comprises: If the application has completed the permission configuration, but all the available sound card device nodes fail to open, an audio output path based on the oboe framework is established.

8. A system for establishing an audio output path based on TinyAlsa, characterized in that: The system comprises: An interface establishment module, used to pre-establish an interface for an application to call a TinyAlsa library; wherein the application has completed permission configuration in advance, and the interface of the TinyAlsa library is used to output audio data to an opened sound card device node; The node traversal module is used to traverse the sound card device nodes of the system for each channel of audio data to be played, and filter out available sound card device nodes; for each of the available sound card device nodes, perform a node opening operation; The channel establishment module is used to establish an audio output channel based on TinyAlsa according to the interface of the TinyAlsa library and the opened sound card device node if the opening is successful.

9. A terminal, characterized in that: The terminal includes a memory and one or more processors; the memory stores one or more programs; the program contains instructions for executing the TinyAlsa-based audio output path establishment method as described in any one of claims 1-7; and the processor is used to execute the program.

10. A computer-readable storage medium having a plurality of instructions stored thereon, characterized in that: The instructions are suitable for being loaded and executed by a processor to implement the steps of the method for establishing an audio output path based on TinyAlsa as described in any one of claims 1-7.

Images