Cross-environment bluetooth audio low latency transmission method based on resource dynamic arbitration

Abstract

The application discloses a cross-running environment Bluetooth audio low-delay transmission method based on resource dynamic arbitration. After a host is started, a device resource file is generated, a permission synchronization service is initialized, and a protocol agent layer is deployed to realize the same Bluetooth audio protocol interface as a client environment. When the client environment is started, a protocol decoupling layer is deployed, a local rule copy is loaded, and a permission token is generated by the permission synchronization service. After the client application initiates a Bluetooth audio connection request, the protocol decoupling layer and the protocol agent layer complete protocol negotiation, determine an encoding scheme and return negotiation results after verifying the legality of the token. The host allocates a shared memory pool according to the negotiation results, generates a memory configuration list, and maps the client environment to a virtual address and configures an audio output link. The application generates original audio to write into the shared memory, and the host reads the audio data and submits a sending application by the protocol agent layer. The host arbitrator allocates bandwidth and time slices according to the rule library, adapts a gateway to recombine audio data packets, and completes transmission through Bluetooth in time sharing mode.

Description

Technical Field

[0001] This invention belongs to the field of computer software development technology, specifically relating to a method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration. Background Technology

[0002] In the embedded system ecosystem where multiple runtime environments coexist, when upper-layer applications access physical Bluetooth hardware via virtualization or container layers, they generally follow a hierarchical access architecture consisting of the application, client-side protocol stack, host-side protocol stack, and hardware. Existing cross-environment Bluetooth audio implementations only offer customized development for specific systems, failing to address the common defects in cross-runtime environment resource interaction at the general architecture level. Furthermore, they lack end-to-end optimization tailored to the low latency and high real-time characteristics of Bluetooth audio, ultimately resulting in cross-environment Bluetooth audio transmission latency significantly higher than native hardware direct connection solutions. The main technical problems are as follows: First, cross-dual-runtime environment permissions employ a serial double-check architecture, with full-scale permission information exchanged and transmitted. Each permission check introduces a fixed latency of 20 to 30 milliseconds. The check logic and Bluetooth protocol negotiation are executed serially, lengthening the link initialization time. Second, the Bluetooth protocol stacks at both ends are coupled and bound to their respective system-specific data structures and interface definitions. During cross-environment interaction, all interaction commands must undergo full-field translation and conversion, leading to protocol conversion issues. Overhead accounts for more than 40% of the overall processing time; third, instruction filtering relies solely on fixed static whitelist configurations, lacking standardized dynamic filtering rules based on instruction function, transmission necessity, and data redundancy, which easily leads to the erroneous removal of critical instructions and the omission of redundant control instructions, resulting in additional bandwidth consumption; fourth, shared memory is only roughly partitioned according to major data categories, without detailed rules for sub-regional division of instructions, audio data, and verification status, causing various types of data to be mixed in the same memory space, leading to data addressing errors and frame synchronization failures; fifth, physical Bluetooth hardware is a dedicated resource, and when multiple applications concurrently request Bluetooth links in multiple operating environments, there is a lack of unified resource priority arbitration and scheduling logic, causing native applications and applications within virtualized containers to compete for hardware bandwidth, frequently resulting in transmission jitter and audio interruptions.

[0003] In summary, most existing optimization methods are limited to single-point local optimizations such as buffer size and send / receive timing, lacking a closed-loop optimization architecture covering the entire chain from permissions, protocols, memory, resource scheduling to synchronization verification, and thus cannot meet the deployment requirements of Bluetooth audio low-latency services such as games and real-time voice calls. Summary of the Invention

[0004] In view of this, the present invention provides a method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration. By building a rule base, a cross-end protocol adaptation system and a partitioned three-dimensional shared memory pool residing in physical memory, and using protocol pass-through links to complete parameter negotiation, zero-copy data interaction and dynamic bandwidth scheduling, reliable low-latency Bluetooth audio transmission across operating environments is achieved.

[0005] The present invention provides a method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration, which specifically includes the following steps:

[0006] After the host starts up, it traverses Bluetooth to collect hardware information to form a device resource file and stores it in the Bluetooth resource pool. It initializes the permission synchronization service of the built-in rule base and deploys the protocol proxy layer to implement the same Bluetooth audio protocol interface as the customer environment. When the customer environment starts up, it deploys the protocol decoupling layer, loads a local copy of the rule base, extracts information from the permission proxy unit and uploads it to the permission synchronization service, verifies permissions, generates permission tokens and stores them in the host permission cache pool, and sends them back to the customer environment.

[0007] When the client environment application initiates a Bluetooth audio connection request, the protocol decoupling layer initiates a protocol negotiation request to the protocol proxy layer. The protocol proxy layer retrieves the permission cache pool to verify the token's validity. If the token is valid, it retrieves the Bluetooth resource pool to obtain the device's compatible protocols and bandwidth limits, determines the encoding scheme, forms the negotiation result, and sends it back to the client environment.

[0008] The host creates a shared memory pool based on the negotiation results, which includes an instruction synchronization area, an audio data area, and a check and status area. The fixed starting address determines the offset address of the sub-interval within the partition. A memory configuration list is generated and sent to the client environment. The client environment maps it to the virtual address space and sets up an audio output link to write audio data into the audio data area.

[0009] The client environment application generates raw audio data according to the negotiation result. The audio encoding module generates audio data containing audio frames and verification data and writes it into memory. It is synchronized to the host and triggers a read signal. After the host receives the read signal, the data processing thread queries the instruction synchronization area, calculates the memory address according to the read sequence number, reads the audio data, obtains the corresponding CRC check code to complete the verification, and the protocol proxy layer initiates an audio transmission request.

[0010] After receiving the audio transmission request, the host arbitrator obtains the bandwidth quota and transmission time slice configuration from the rule base and sends them to the data processing thread; the adapter gateway reassembles the audio data into audio data packets according to the negotiation results and sends them to Bluetooth using time slices.

[0011] Furthermore, the audio encoding module generates audio data containing audio frames and verification data and writes it into memory in the following way: the audio service reads the status flag of the shared memory pool, retrieves the queue load judgment threshold in the rule base, and if the load of the main data queue is less than the threshold, the audio data is written into the main data queue; otherwise, it switches to the backup data queue and sends a partition write queue switching notification to the control instruction. The storage address is calculated based on the current write position, and the audio data is written into the corresponding memory location.

[0012] Furthermore, the system periodically reads the memory usage rate, matches it with the rule base's graded speed adjustment standard, and dynamically changes the writing interval of audio frames.

[0013] Furthermore, the method for calculating the memory address based on the read sequence number to read audio data and obtaining the corresponding CRC checksum to complete the verification is as follows: CRC checksum verification is used. If the verification passes, the audio data is valid. If the verification fails, the client environment is requested to resend the data. If no information is received within a set time threshold, the frame is discarded and silence is used to fill the gap. The frame sequence number is checked. If the sequence number is not continuous, the frame is marked as lost and silence is played to fill the gap. The read position number is updated, the memory usage information is refreshed, and a read completion message is sent to the client environment.

[0014] Furthermore, after receiving an audio transmission request, the host arbitrator obtains the bandwidth quota and transmission time slice configuration from the rule base and distributes them to the data processing thread in the following manner:

[0015] The system retrieves pre-stored bandwidth allocation criteria from the rule base and determines the device resource status based on the rule base configuration. If the device is idle, it allocates all bandwidth to the client environment application according to the rules in the rule base. If the device is occupied by the host system's native application, it distinguishes the service type according to the rules. If the client environment is a real-time service, it allocates a preset proportion of bandwidth, while ordinary media services are placed in a queue. When multiple client environment applications make concurrent requests, resources are allocated according to the predefined service priority order and first-come-first-served principle in the rule base. Finally, it outputs the corresponding bandwidth quota and sending time slice configuration according to the rules and sends them to the data processing thread.

[0016] Furthermore, before initiating a protocol negotiation request to the host's protocol proxy layer, the protocol decoupling layer filters invalid instructions and redundant fields by matching classification rules with an index, and then adds a version tag.

[0017] Furthermore, the control command partition is configured with a bidirectional synchronization identifier. The client environment is writable by default, while the host initially waits to read. In the audio data area, the read / write position number is initially set to zero, and an occupancy threshold is set. When the load of the main data queue exceeds the threshold, it switches to the backup data queue. In the verification status partition, the host refreshes the memory occupancy data according to the refresh cycle, and the client environment reads the status data according to the read cycle, dynamically adjusting the data write speed. The verification storage space and audio frame sequence number are bound one-to-one to achieve addressing.

[0018] Furthermore, when writing audio data to the corresponding memory location, if the written audio data exceeds the upper limit of the main data queue, the system switches to the backup data queue, reports an overflow notification, and the host prioritizes reading data from the backup data queue. When an error occurs during data verification, the audio data of this frame is re-encoded and resent until the maximum number of retries is reached. When the frame sequence numbers are not consecutive for three consecutive times, a frame loss notification is reported, and missing frames at the remote end are filled with silence.

[0019] Furthermore, during the initialization of the Bluetooth audio transmission link, the host scheduler and coordinator completes CPU optimization configuration, reserves two cores to form a dedicated Bluetooth audio core group, independently isolates and schedules them, locks the highest operating frequency of the cores, and disables hyper-threading and deep sleep mechanisms. At the same time, it monitors the load of the dedicated cores according to a set period. When the core utilization rate exceeds the threshold, the lower priority auxiliary threads are migrated to the energy-efficient cores. Core binding and real-time priority configuration are performed for all Bluetooth audio key threads in the client environment and the host. In the client environment, dedicated cores are bound to the protocol decoupling instruction processing, audio encoding and shared memory writing, permission proxy and exception handling threads, and corresponding gradient real-time priorities are configured. In the host, core binding and priority level settings are completed for protocol proxy and resource arbitration, data processing and HAL protocol adaptation, interrupt handling and forwarding, status monitoring and synchronization key threads in sequence. When there is a conflict between threads of the same priority in the two systems, only the corresponding high-priority thread runs on the same core.

[0020] Furthermore, after Bluetooth completes the audio data transmission, a hardware interrupt is triggered. The interrupt signal is handled by a dedicated interrupt forwarding thread. This thread extracts the corresponding frame number, hardware timestamp, and transmitted data, assembles them into a fixed-length interrupt feedback data, and writes it into the dedicated storage space reserved in the control command sub-area. Simultaneously, it refreshes the hardware transmit and receive information in the system status partition. The client environment synchronization thread reads the interrupt feedback data at fixed intervals. Based on the hardware timestamp and the time information recorded by each link in the entire link, it calculates the end-to-end total delay, host processing delay, and hardware transmission delay. Based on the value of the end-to-end total delay, it dynamically adjusts the client environment audio write rate and hardware transmission time slice, schedules the host thread, and calculates the clock difference between the client environment and the host after accumulating a set number of frames. When the clock offset is greater than a threshold, the client environment reference clock is corrected based on the host clock.

[0021] Beneficial effects:

[0022] In the host startup phase, this invention involves a Bluetooth management component that collects Bluetooth hardware information to construct a hash-indexed Bluetooth resource pool, establishes a rule base with three-level filtering logic and a hash linked list storage structure, and provides a permission synchronization service. A protocol proxy layer is deployed, and a cross-environment universal data structure is constructed. After the client environment starts, a protocol decoupling layer is deployed, and a local copy of the rule base is loaded. After field format conversion and permission verification, a permission token is generated and stored in the host permission cache pool. The host synchronizes the Bluetooth device information cache to the client via a dedicated channel. When the client initiates an audio connection, the protocol decoupling layer submits a negotiation message carrying the token and encoded parameters using a protocol pass-through link. The host verifies the token and queries the Bluetooth resource pool to determine the transmission parameters. The primary requester creates a three-dimensional shared memory pool for physical memory. After partitioning, it issues a memory configuration list for the client environment to complete address mapping and initialization. During service operation, the client environment collects raw audio encoded into standard frames based on negotiated parameters, manages the primary and backup queue writing logic according to the rule base threshold, and adaptively adjusts the frame rate. After synchronously storing verification and sequence number data, it triggers the host to read the signal. After the host reads the data and completes CRC, frame order verification, and exception handling, the protocol proxy submits a transmission request. The arbitrator retrieves the rule base bandwidth allocation strategy to complete resource and time slice allocation. Finally, the adapter gateway assembles the packets and sends them to the peripherals via Bluetooth hardware according to the time slice. The transmission and reception status is uniformly written back to the shared memory status partition. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration provided by the present invention. Detailed Implementation

[0024] The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0025] The present invention provides a method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration. Its core idea is as follows: During the host startup phase, the Bluetooth management component collects Bluetooth hardware information to construct a hash-indexed Bluetooth resource pool, establishes a rule base with three-level filtering logic and a hash linked list storage structure, and deploys a protocol proxy layer and constructs a cross-environment general data structure. After the client environment starts, a protocol decoupling layer is deployed and a local copy of the rule base is loaded. After field format conversion and permission verification, a permission token is generated and stored in the host permission cache pool. The host synchronizes the Bluetooth device information cache to the client via a dedicated channel. When the client initiates an audio connection, the protocol decoupling layer submits a negotiation message carrying the token and encoded parameters using a protocol pass-through link, which is then verified by the host. The token and Bluetooth resource pool are used to determine transmission parameters; the host requests physical memory to create a three-dimensional shared memory pool, and after partitioning, a memory configuration list is issued for the client environment to complete address mapping and initialization; during service operation, the client environment collects raw audio encoded into standard frames according to the negotiated parameters, manages the primary and backup queue writing logic according to the rule base threshold and adaptively adjusts the frame rate, and triggers the host to read the signal after synchronously storing verification and sequence number data; after the host reads the data and completes CRC, frame sequence verification and exception fault handling, the protocol proxy submits a transmission request, the arbitrator calls the rule base bandwidth allocation strategy to complete resource and time slice division, and finally the adapter gateway assembles the packets and sends them to the peripherals via Bluetooth hardware according to the time slice, and the transmission and reception status is uniformly written back to the shared memory status partition.

[0026] The present invention provides a method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration, the processing flow of which is as follows: Figure 1 As shown, the specific steps include:

[0027] Step 1: After the host system starts up, the Bluetooth management component traverses the physical Bluetooth hardware, collects information such as hardware address, compatible audio protocols, bandwidth limits, and occupancy status to form a device resource file, which is then stored in a Bluetooth resource pool based on hash indexes. Simultaneously, it initializes a cross-environment permission synchronization service. This service has a built-in rule update unit and builds a hierarchical filtering rule base. The rule base is designed according to a three-level judgment logic based on instruction function, transmission necessity, and data redundancy, and is built using a hybrid storage structure of hash and linked lists. A protocol proxy layer is deployed on top of the host Bluetooth protocol stack. The protocol proxy layer implements the same Bluetooth audio protocol standard interface as the client environment, ensuring interoperability and compatibility between the two interfaces. The proxy layer has a built-in protocol conversion unit, pre-configured with mapping rules from general structures to the host's private data structures, and directly connected to the host's underlying Bluetooth protocol capability entry point. The general structure only retains necessary business parameters such as encoding type, bitrate, sampling rate, and latency threshold, and does not contain any system-customized fields.

[0028] When the customer environment starts, a protocol decoupling layer is deployed between the local Bluetooth protocol stack and the upper-layer application call interface, and a local copy of the rule base is loaded in this layer. The protocol decoupling layer removes system-specific data fields and converts the platform's private data structure into a cross-environment general structure. The embedded interface adaptation unit uses field mapping to convert the application's native interface calls into standard interface calls. At the same time, the built-in permission proxy unit extracts the application's Bluetooth permissions, application identifier, and identity information, and uploads them to the permission synchronization service through an authentication cross-domain channel. The permission synchronization service calls the permission control module and completes permission verification based on a one-time verification and long-term caching mechanism. After the verification is successful, a permission token carrying the permission scope, validity period, and application number is generated. The token is stored in the host permission cache pool and sent back to the customer environment for local storage. The permission cache pool is used to store the application identifier, permission token, permission effective scope, and token validity period.

[0029] The host sends a device summary containing hardware address, supported protocols, and idle status to the client environment through an independent device status synchronization channel, which is then cached locally by the device agent unit within the client environment.

[0030] The customer environment can be a customer environment, a virtual machine, or an independent subsystem, and is suitable for multi-platform migration.

[0031] The three-level judgment logic is as follows: Level 1 divides instructions into four categories: audio core, permission verification, system redundancy, and debugging. Only the first two categories enter Level 2 filtering. Level 2 filters instructions based on whether they affect real-time audio transmission. Level 3 removes useless extended fields and simplifies effective data.

[0032] Step 2: When the client environment application initiates a Bluetooth audio connection request, the protocol decoupling layer of the client environment initiates a protocol negotiation request to the host's protocol proxy layer through the protocol pass-through link. The request message includes an authorization token, a target device identifier, and multiple sets of encoded parameter information encapsulated in a general structure.

[0033] The host's protocol proxy layer retrieves the permission cache pool to complete the token validity verification. After the verification is successful, it calls the Bluetooth resource pool to obtain the target device's compatible protocol and bandwidth limit. It determines the encoding scheme according to the low latency priority strategy, and simultaneously locks key transmission parameters such as encoding type, bit rate, sampling rate, and single frame size to form a negotiation result. Then, it encapsulates the negotiation result in a general structure and sends it back to the client environment via the protocol direct link. At the same time, it stores the negotiation result in the negotiation parameter cache area.

[0034] Furthermore, before initiating a protocol negotiation request to the host's protocol proxy layer, the protocol decoupling layer filters invalid instructions and redundant fields by matching classification rules with an index, and then adds a version tag. In addition, during operation, the protocol decoupling layer queries the host for the rule base version at fixed intervals. If the versions are inconsistent, it obtains an encrypted rule base data packet and replaces the local copy of the rule base using a double-buffering mechanism. The rule base update process does not affect the ongoing audio transmission service.

[0035] Step 3: The host requests contiguous physical memory based on the negotiated parameters to create a three-dimensional shared memory pool. It restricts memory swapping out by locking this segment of shared physical memory to prevent it from being swapped to the Swap disk by the system, while allowing bidirectional access permissions between the client environment and the host. The three-dimensional shared memory pool is divided into three areas: an instruction synchronization area, an audio data area, and a verification and status area. The instruction synchronization area includes a permission instruction sub-area and a control instruction sub-area; the audio data area includes a main data queue and a backup data queue; and the verification and status area includes a CRC check sub-area, a frame sequence check sub-area, and a system status sub-area. Offset addresses are divided between each sub-area based on a fixed starting address. A memory configuration list is generated, including the starting address, offsets of each partition, single frame size, and maximum number of frames the queue can hold. This list is then sent to the client environment via a protocol pass-through link.

[0036] The client environment maps the received 3D shared memory pool to its own virtual address space, synchronously initializes the queue read / write flags, synchronous control rules and status refresh mechanism, locks the memory, and verifies that the memory space is complete and without gaps; sets its audio output link and writes the audio data into the audio data area of ​​the shared memory.

[0037] The control command partition is configured with a bidirectional synchronization identifier. The client environment is writable by default, while the host initially waits to read. The audio data area has its read / write position number initially set to zero and an occupancy threshold is set. When the load of the main data queue exceeds the threshold, it switches to the backup data queue. The verification status partition refreshes the memory occupancy data according to the refresh cycle, and the client environment reads the status data according to the read cycle. The data write speed is dynamically adjusted, and the verification storage space and audio frame sequence number are bound one-to-one to achieve addressing.

[0038] Specifically, the permission instruction sub-area is used to store permission verification results and permission change notifications; the control instruction sub-area is used to save audio control commands such as start, stop, and pause; the main data queue uses a circular queue structure to store audio frames normally; the CRC check sub-area is used to save data check values ​​frame by frame; the frame order check sub-area records frame numbers and checks for lost or out-of-order frames; and the system status sub-area records memory usage, queue full / empty status, and hardware transmit / receive status.

[0039] Step 4: The customer environment application generates raw audio data according to the negotiated sampling rate, bit depth, and channel parameters. The audio encoding module in the customer environment adopts the negotiated encoding format and enables simplified encoding logic to generate a standard audio frame with a fixed format, including frame number, system timestamp, encoding data, frame type, and check data. Audio data is formed by the audio frame and check data.

[0040] The audio service reads the status flag of the three-dimensional shared memory pool, retrieves the queue load judgment threshold pre-stored in the rule base, and if the load of the main data queue is less than the threshold, the audio data is written to the main data queue; otherwise, it switches to the backup data queue and sends a queue switch notification to the control command partition. It calculates the storage address based on the current write position and writes the audio data to the corresponding memory location, synchronizing the data to the host in real time. It calculates the checksum and frame sequence number, storing them in the CRC checksum sub-area and frame sequence checksum sub-area, respectively. It updates the write position flag and triggers a read signal. Simultaneously, it periodically reads the memory occupancy rate, matches it to the rule base's graded speed adjustment standard, and dynamically changes the audio frame write interval to achieve adaptive rate control.

[0041] Furthermore, when writing audio data to the corresponding memory location, if the written audio data exceeds the upper limit of the main data queue, switch to the backup data queue, report an overflow notification, and the host prioritizes reading the data from the backup data queue; when an error occurs during data verification, re-encode and resend the audio data of this frame, with a maximum of the set number of retries; when the frame sequence number is not consecutive for three consecutive times, report a frame loss notification, and fill the missing frames at the remote end with silence.

[0042] Step 5: After receiving the read signal, the host data processing thread queries the instruction synchronization area, selects to read the main data queue or the backup data queue according to the queue status, and synchronously refreshes the occupancy information of the backup data queue; calculates the corresponding memory address based on the current read sequence number, reads the audio data, and obtains the corresponding CRC checksum; performs verification using the CRC checksum, if the verification passes, the data is valid, if the verification fails, it requests the client environment to resend, if no information is received within the set time threshold, the frame is discarded and silence is used to fill the gap; checks the frame sequence number, if the sequence number is not consecutive, it marks the frame as lost and plays silence to fill the gap; updates the read position number, refreshes the memory occupancy information, and sends a read completion message to the client environment; the protocol proxy layer initiates an audio transmission request.

[0043] After receiving an audio transmission request, the host arbitrator retrieves the pre-stored bandwidth allocation criteria from the rule base. Based on the rule base configuration, it determines the device resource status. If the device is idle, it allocates all bandwidth to the client environment application according to the rules in the rule base. If the device is occupied by the host system's native application, it distinguishes the service type according to the rules. If the client environment is a real-time service, it allocates a preset proportion of bandwidth, while ordinary media services are placed in a queue. When multiple client environment applications make concurrent requests, resources are allocated according to the predefined service priority order and first-come-first-served principle in the rule base. Finally, based on the rules, it outputs the corresponding bandwidth quota and transmission time slice configuration and sends it to the data processing thread.

[0044] The host adapter gateway reassembles the read audio data into audio data packets according to the encoding scheme in the negotiation result, and the Bluetooth hardware sends them to the physical Bluetooth peripheral using a determined time slice; it records the transmission and reception results and hardware timestamps, and writes the status information into the system status sub-area.

[0045] Furthermore, during the initialization of the Bluetooth audio transmission link, the host scheduler and coordinator completes the underlying CPU optimization configuration, reserving two cores from the device's high-performance cores to form a dedicated Bluetooth audio core group, which is independently isolated and scheduled, and the highest operating frequency of the core is locked, while hyper-threading and deep sleep mechanisms are disabled. At the same time, the load of the dedicated core is monitored at high frequency, and when the core utilization exceeds the threshold, low-priority auxiliary threads are migrated to energy-efficient cores. Core binding and real-time priority configuration are performed on all Bluetooth audio key threads on both the client environment side and the host side. On the client environment side, dedicated cores are bound to the protocol decoupling instruction processing, audio encoding and shared memory writing, permission proxy and exception handling threads, and corresponding gradient real-time priorities are configured. On the host side, core binding and priority classification settings are completed for key threads such as protocol proxy and resource arbitration, data processing and HAL protocol adaptation, interrupt handling and forwarding, status monitoring and synchronization. When there is a conflict between threads of the same priority in the two systems, only the corresponding high-priority thread runs on the same core.

[0046] Furthermore, after the Bluetooth hardware completes the audio data transmission, it triggers a high-priority hardware interrupt. The interrupt signal bypasses the system's redundant processing logic and is directly handled by a dedicated interrupt forwarding thread. This thread extracts the corresponding frame sequence number, high-precision hardware timestamp, and transmission result, assembles them into a fixed-length interrupt feedback data, writes it into the dedicated storage space reserved in the control command sub-area, and simultaneously refreshes the hardware transmission and reception information in the system status partition. The client environment's synchronization thread reads the above interrupt feedback data at fixed intervals. Based on the hardware timestamp and the time information recorded at each link in the entire link, it calculates three types of parameters: end-to-end total latency, host processing latency, and hardware transmission latency. Based on the different threshold ranges of the total latency, it dynamically adjusts the client environment's audio writing rate, fine-tunes the hardware transmission time slice, or optimizes the host thread scheduling configuration. At the same time, it calculates the clock difference between the client environment and the host every set number of frames. When the clock offset exceeds the limit range, it corrects the client environment's reference clock based on the host clock.

[0047] Example:

[0048] This embodiment employs the cross-operational environment Bluetooth audio low-latency transmission method based on dynamic resource arbitration provided by this invention. Using OpenHarmony version 5.0 or higher as the host system and Android as the client environment, it solves the high latency and stability issues of Bluetooth audio in Android applications by reconstructing the decoupled architecture of the dual-end Bluetooth protocol stack, designing a dynamic instruction filtering rule base, optimizing the three-dimensional shared memory partitioning mechanism, and supplementing the cross-system permission and device arbitration process. The specific process includes:

[0049] S1. Cross-system permission pre-verification and Bluetooth device resource registration: By pre-synchronizing permissions and pre-registering devices, permission verification delays during the protocol negotiation phase are avoided.

[0050] S1.1, Permission pre-synchronization during container startup.

[0051] A cross-system permission synchronization service has been added to the OpenHarmony host side. This service is bound to the container management service lxc-manager and automatically triggers permission synchronization requests when the Android container starts.

[0052] The container-side permission proxy module extracts the list of Bluetooth audio-related permissions in the Android system, such as android.permission.BLUETOOTH_ADMIN, android.permission.ACCESS_FINE_LOCATION, and android.permission.BLUETOOTH_CONNECT, and sends it along with the application signature information and package name to the host-side permission synchronization service through the permission fast synchronization channel. Based on the kernel-mode KMSG mechanism, it avoids user-mode IPC overhead.

[0053] The host-side permission synchronization service interfaces with OpenHarmony's permission management subsystem permission_manager to perform a one-time verification and long-term caching of container application permissions. After successful verification, a permission token is generated, which includes the permission type, validity period of 1 hour, and application unique identifier. This token is stored in the host-side permission cache pool, and the token is returned to the container side.

[0054] The container-side permission proxy module caches the permission token locally. When initiating a Bluetooth audio connection later, it only needs to send the token to the host side for validity verification. There is no need to repeatedly transmit the permission list and signature information, reducing the verification latency from 20 to 30 ms to 1 to 2 ms.

[0055] S1.2 Bluetooth device resource pre-registration and status synchronization.

[0056] When the host-side Bluetooth management service bluetooth_manager starts, it automatically scans physical Bluetooth devices, extracts key device information, including MAC address, supported audio protocols A2DP or LEAudio, maximum bandwidth, current connection status, and generates device resource profiles.

[0057] Device resource files are stored in the host-side Bluetooth resource pool using a hash table structure. The key is the MAC address, and the value is a device information structure, supporting fast lookup within 1ms. Simultaneously, the host pushes a file summary to the container side via a device status synchronization channel. The summary contains only the MAC address, supported protocols, and idle status.

[0058] The container-side device agent module caches device profile summaries locally. When an application initiates a Bluetooth connection, it first queries the local summary and only requests detailed parameters of the target device, such as bandwidth and latency thresholds, from the host side, avoiding redundant transmission of full device information synchronization.

[0059] S2, Deep decoupling of the dual-end Bluetooth protocol stack and negotiation of the protocol pass-through bridge, achieves low-coupling interaction of the dual-end protocol stack through the decoupling layer and dynamic rule base.

[0060] S2.1, Deep decoupling of dual-end protocol stacks.

[0061] S2.1.1 Design of Android container-side protocol decoupling layer:

[0062] A new protocol decoupling layer is added between the Android Bluetooth protocol stack (bluetoothd) and the application API. This layer adopts an interface abstraction and implementation separation architecture, and defines a Bluetooth audio protocol standard interface independent of the Android system, including 12 core interfaces such as NegotiateCodec, StartAudioStream, and StopAudioStream.

[0063] The decoupling layer removes system-dependent fields from the Android protocol stack and converts Android private structures such as android.bluetooth.CodecInfo and android.bluetooth.BluetoothDevice into cross-system general structures. For example, CommonCodecInfo contains 1 byte of encoding type, 4 bytes of code rate, 2 bytes of sampling rate, and 2 bytes of latency threshold, without any system-private fields.

[0064] The decoupling layer has a built-in interface adapter that converts Android native APIs called by the application, such as BluetoothA2dp.negotiateCodec, into standard interface calls. The adaptation process only requires field mapping, takes less than 1μs, and does not require modification of the application code.

[0065] S2.1.2, Design of OpenHarmony Host-Side Protocol Proxy Layer.

[0066] A new protocol proxy layer is added on top of the OpenHarmony Bluetooth protocol stack. This layer implements a Bluetooth audio protocol standard interface that is completely consistent with the Android side, ensuring interface compatibility. The OpenHarmony Bluetooth protocol stack is a derivative of BlueZ.

[0067] The proxy layer has a built-in protocol conversion sublayer, which predefines a mapping table from general structures to OpenHarmony private structures. For example, the encoding type 0x0A of CommonCodecInfo corresponds to OHOS_CODEC_APTX_LL, and the sampling rate 0xBB80 corresponds to OHOS_SAMPLING_RATE_48K.

[0068] The proxy layer directly interfaces with the host Bluetooth protocol stack's native interfaces, such as ohos_bluetooth_a2dp_negotiate_codec, avoiding forwarding through general services such as bluetooth_manager, thus reducing interface call latency by 50%.

[0069] S2.2 Design of a dynamic instruction filtering rule base for Bluetooth protocol pass-through bridge.

[0070] S2.2.1 Rule base architecture and dimension definition:

[0071] The rule base adopts a three-level filtering dimension design, including the first-level dimension of instruction function classification, the second-level dimension of transmission necessity, and the third-level dimension of data redundancy. Each dimension defines clear judgment criteria.

[0072] The primary dimension of command function classification divides Bluetooth commands into four categories: audio core commands, permission verification commands, system redundancy commands, and debugging commands. Only audio core commands and permission verification commands are included in the secondary filtering.

[0073] The second-level dimension of transmission necessity is determined by whether the instructions after the first-level filtering affect the real-time audio transmission. For example, CODEC_NEGOTIATE and STREAM_START are retained, while SYSTEM_STATUS_SYNC is removed.

[0074] The third-level dimension of data redundancy filters the instructions retained at the second level according to the necessity of the data fields. For example, the debug log field and the vendor extended field in CODEC_NEGOTIATE are removed, and only the encoding parameter field is retained.

[0075] S2.2.2 Rule base storage and matching process:

[0076] The rule base uses a hybrid storage structure of hash table and linked list. The first-level dimension uses a hash table, where the key is the instruction type identifier and the value is the rule linked list, with a query time complexity of O1. The second and third-level dimensions use linked lists to store specific rules. For example, the linked list of instruction 0x01, i.e., CODEC_NEGOTIATE, contains a list of retained fields, the offset of the removed fields, and their length.

[0077] The instruction matching process is as follows: After receiving an instruction, the container-side decoupling layer extracts the instruction type identifier and queries the first-level dimension rules through a hash table to determine the instruction category. If it is an audio core instruction, it queries the second-level dimension rules to determine whether to retain it. Retained instructions enter the third-level dimension filtering, where redundant fields are removed according to the rules, such as removing the debug field of CODEC_NEGOTIATE, and compressing the instruction length from 256 bytes to 16 bytes. After filtering, a rule version number is added to the instruction to identify the current rule library version, ensuring that the host side uses the same rules for parsing.

[0078] S2.2.3, Rule base dynamic update mechanism:

[0079] The host-side permission synchronization service has added a rule base update module, which supports pushing rule packages via OTA in encrypted format, including new instruction rules and field mapping updates.

[0080] The container-side decoupling layer periodically requests the rule base version from the host side every 24 hours. If the versions are inconsistent, the local rule base is downloaded and updated. The update process does not interrupt the current audio transmission. A double-buffered rule base is used, and the new rule base is temporarily stored before it takes effect and is used in the next transmission.

[0081] S2.3 Low-latency protocol negotiation and parameter confirmation.

[0082] The container-side decoupling layer sends a protocol negotiation request to the host-side proxy layer via a protocol pass-through bridge. The request includes a 16-byte authorization token, a 6-byte target device MAC address, and a list of supported encodings in a generic structure format, with each encoding occupying 8 bytes. The protocol pass-through bridge is based on netlink sockets and implemented with the Nagle algorithm disabled.

[0083] The host-side proxy layer verifies the validity of the permission token, queries the permission cache pool, and then queries the Bluetooth resource pool to obtain the supported protocols and maximum bandwidth of the target device.

[0084] Encoding negotiation is conducted according to the principle of low latency priority, with priority given to LEAudioLC3, aptXLowLatency, and SBC low latency sub-mode. After negotiation, the core parameters are determined, including encoding type, bitrate R, sampling rate F, and frame size S, which is equal to R multiplied by 1ms.

[0085] The host-side proxy layer returns the negotiation result in a general structure format to the container side through the protocol pass-through bridge, and stores the result in the negotiation parameter cache for use in subsequent steps 2 (shared memory initialization) and 4 (data sending).

[0086] S3, Sub-partition design and initialization of the three-dimensional shared memory pool, constructing a refined three-dimensional shared memory pool based on negotiated parameters.

[0087] S3.1, Sub-partition architecture definition of a three-dimensional shared memory pool.

[0088] The total size of the memory pool is calculated based on the bitrate R negotiated in step 1. The total size S_total is equal to R multiplied by 1.5 multiplied by 2, where 1.5 is the redundancy factor and 2 is for double buffering backup. For example, if R is equal to 450kbps, S_total is equal to 56.25 multiplied by 1.5 multiplied by 2, which is equal to 168.75KB. The result is rounded up to the nearest multiple of 10KB for easier memory management.

[0089] The 3D partitioning is divided in a 2:7:1 ratio, and the sub-partitions are defined as follows:

[0090] The primary partition instruction synchronization area accounts for 20%, including a 3.4KB permission instruction sub-area used to store permission token verification results and permission update notifications to avoid duplicate verification. The control instruction sub-area is 30.6KB in size and is used to store control instructions such as stream start / stop, pause / resume, etc.

[0091] The primary partition audio data area accounts for 70% of the total data volume. It includes a main data queue of 119KB, which stores audio frames during normal transmission using a circular queue. Each frame occupies 56 bytes. The backup data queue is 119KB in size and is activated when the main queue utilization rate is greater than 90% to avoid data overflow. Its parameters are completely consistent with those of the main queue.

[0092] The primary partition verification and status area accounts for 10%, including a 17KB CRC check sub-area to save data verification values ​​frame by frame, a 17KB frame order verification sub-area to record frame numbers to check for lost or out-of-order frames, and a 17KB system status sub-area to record memory pool usage, queue full / empty status, and hardware transmit / receive status.

[0093] The sub-partition address planning adopts a design of continuous physical addresses plus fixed offsets, with the total memory pool base address being 0x80000000.

[0094] The address range of the permission instruction sub-region is 0x80000000 to 0x80000D5F.

[0095] The address range of the control instruction sub-region is 0x80000D60 to 0x80007FFF.

[0096] The main data queue address range is from 0x80008000 to 0x80020FFF.

[0097] The backup data queue address range is 0x80021000 to 0x80039FFF.

[0098] The CRC checksum sub-area address range is from 0x8003A000 to 0x8003E4AF.

[0099] The frame sequence check sub-area address range is from 0x8003E4B0 to 0x8004295F.

[0100] The system status sub-region address range is from 0x80042960 to 0x80046E0F.

[0101] S3.2 Creation and mapping of shared memory pools.

[0102] After receiving the negotiation result, the host-side memory management service mmms calls shmget to create a physically contiguous memory pool, sets IPC_CREAT and permissions to 0666, which are accessible to both the container and the host, and disables memory swapping.

[0103] The host side generates a memory pool metadata file, which includes information such as base address, sub-partition offset, frame size, queue length, and the main queue length equals the main data queue size divided by the frame size. For example, 119KB divided by 56B is approximately equal to 2125 frames. This information is then sent to the container side via a protocol pass-through bridge.

[0104] The container-side memory proxy module calls mmap to map the host-side physical memory to the container virtual addresses 0xA0000000 to 0xA0046E0F, sets the MAP_SHARED and MAP_LOCKED flags, shares and locks the memory for writes, and verifies the address continuity through msync after mapping to ensure there are no address gaps.

[0105] The container-side audio service, audioflinger, is bound to the memory proxy module. The data output logic is modified, changing the original multi-level buffered stream to a direct write to the shared memory main data queue applied to audioflinger, and disabling the local buffer.

[0106] S3.3, Sub-partition synchronization mechanism initialization.

[0107] The control instruction sub-region initializes the semaphore synchronizer, sets the container's write semaphore initial value to 1, allows writing, and the host reads the semaphore initial value to 0, waiting to read. It uses POSIX semaphores, is implemented in kernel mode, and has a response time of less than 1μs.

[0108] The primary backup data queue initializes the ring queue controller, writes the index W_idx, reads the initial value of index R_idx (0), and updates it through atomic operations to avoid multi-threaded contention. At the same time, it sets the queue switching threshold. When the primary queue W_idx minus R_idx is greater than 0.9 times the queue length, the backup queue is switched.

[0109] The verification and status area initialization status monitor updates the system status sub-area every 0.5ms on the host side. The memory pool utilization rate is equal to the number of bytes used divided by the total size, accurate to 0.1%. The container side reads once every 1ms to adjust the write rate. The CRC check sub-area and frame sequence check sub-area are mapped one-to-one according to the frame sequence number address. The CRC address corresponding to the frame sequence number N is equal to the CRC base address plus N multiplied by 4.

[0110] S4. Application audio stream generation and shared memory sub-partition zero-copy writing: Based on the sub-partition architecture, structured zero-copy writing of audio data is achieved.

[0111] S4.1 Application audio data generation and encoding.

[0112] The Android application calls AudioTrack to generate raw PCM data with parameters consistent with the negotiation result: 48kHz, 16bit, dual channels, generating 18.75KB of data per ms.

[0113] The container-side audio encoding module is based on the Androidaudioflinger extension, calls the negotiated encoding algorithm LC3, enables fast encoding mode, simplifies redundant encoding steps, skips noise reduction processing of non-key frames, and controls the encoding latency to within 3ms.

[0114] Generate a standard audio frame with the following structure: frame number (4 bytes, incrementing from 0), timestamp (4 bytes, host monotonic clock), encoded data (56 bytes), and frame type (1 byte, where 0 represents a normal frame and 1 represents a key frame). The total length is 65 bytes, including a 4-byte CRC checksum, which is subsequently written to the checksum sub-area.

[0115] S4.2, Zero-copy write process based on sub-partitions.

[0116] The container-side audio service reads the main queue status from the system status sub-area. A status of 1 indicates normal operation with a utilization rate of less than 90%, and the data is written to the main data queue. A status of 2 indicates full operation with a utilization rate of 90% or higher, and the data is switched to the backup data queue. At the same time, a queue switching notification is sent in the control instruction sub-area, including the switching reason and the backup queue index.

[0117] The main data queue write operation reads the current W_idx of the main queue and calculates the write address as the main data queue base address plus W_idx multiplied by the 65-byte frame length.

[0118] The valid fields of the audio frame are written directly to this address via memcpy, with only one copy and no intermediate transfer. CPU caching is disabled during the write process to ensure that the data is synchronized to the host in real time.

[0119] Calculate the CRC32 checksum of the audio frame, write it to the corresponding address of the CRC checksum sub-region, and add W_idx to the CRC base address multiplied by 4 bytes.

[0120] Write the current frame sequence number to the corresponding address in the frame sequence check sub-region, and add W_idx multiplied by 4 bytes to the frame sequence base address.

[0121] The write index is updated via atomic operations, and a host read semaphore is sent to notify the host that a new frame is available.

[0122] S4.2.1 Dynamic adjustment of write speed.

[0123] The container reads the memory pool usage rate of the system status sub-region every 1ms.

[0124] If the utilization rate is less than 70%, maintain the current write rate of 1 frame per ms.

[0125] 70% or less utilization rate and less than 90% reduce the write rate by 1 frame per 1.2ms.

[0126] A 1ms short wait is triggered when the utilization rate is greater than or equal to 90%, and writing will only resume when the utilization rate drops below 80%.

[0127] S4.2.2, Abnormal data processing.

[0128] If an address out-of-bounds error is detected during writing, and W_idx exceeds the queue length, the system immediately switches to the backup queue. At the same time, a main queue overflow notification is sent in the control instruction sub-area. Upon receiving the notification, the host side prioritizes processing the backup queue data.

[0129] If the CRC checksum calculation fails and the deviation from the historical frame checksum exceeds the threshold, the current audio frame is re-encoded and resent to the shared memory. The number of resentments will not exceed 2 to avoid infinite retries that could cause delays.

[0130] If the frame sequence number does not increment for three consecutive times, a frame loss notification is sent in the control command sub-area. After receiving the notification, the host side marks the missing frame and fills it with silence during playback to avoid interruption.

[0131] S5, Bluetooth device resource arbitration and shared memory data reading and sending: a new resource arbitration mechanism has been added to the key link of data from shared memory to hardware.

[0132] S5.1, Bluetooth device resource arbitration.

[0133] A new Bluetooth resource arbitrator has been added to the host side, which is bound to the Bluetooth management service and scans the connection status and bandwidth usage of Bluetooth devices every 0.5ms.

[0134] When the host-side proxy layer initiates an audio data transmission request, the arbitrator queries the resource usage status of the target device.

[0135] If the device is idle and not occupied by other applications, allocate 100% bandwidth to the container application and mark the device status as container exclusive.

[0136] The device is occupied by the OpenHarmony native application. Arbitration is based on real-time priority. The container application is a high real-time scenario for calls and games, so 80% of the bandwidth is allocated to the container and 20% is allocated to the native application. The container application is a low real-time scenario for normal playback, so it will be allocated after the native application releases the bandwidth.

[0137] When a device is requested by multiple container applications simultaneously, resources are allocated according to a first-come, first-served plus priority compensation rule, with call applications having higher priority than games, which in turn have higher priority than regular playback.

[0138] After arbitration is completed, the arbitrator generates bandwidth allocation results, allocating bandwidth and allocating 0.8ms of transmission time slices per 1ms to audio, and sends it to the host-side data processing thread.

[0139] S5.2 Shared memory sub-partition data reading and verification.

[0140] The host-side data processing thread waits for the host to read the semaphore, and after triggering it, reads the queue state of the control instruction sub-area.

[0141] The status indicates that the main queue is reading the main data queue normally.

[0142] The status is set to enable reading backup data from the backup queue, and the backup queue utilization rate in the system status sub-area is updated.

[0143] The main data queue read operation reads the current R_idx of the main queue and calculates the read address as the main data queue base address plus R_idx multiplied by 65 bytes.

[0144] Read 61 bytes of audio frame from this address, extract the frame sequence number and the corresponding value of the CRC checksum sub-area, and add R_idx to the CRC base address and multiply by 4 bytes.

[0145] Recalculate the CRC32 value of the read data and compare it with the value in the checksum sub-area.

[0146] The numerical consistency check passed, and processing continues.

[0147] If the values ​​are inconsistent, a data retransmission request is sent to the container side, and the frame is waited for retransmission. If the timeout is 1ms, the frame is skipped and filled with silence.

[0148] The frame sequence is checked. If the frame sequence number of the current R_idx is equal to the previous frame sequence number plus 1, it is considered normal. If the sequence number is not continuous, it is marked as a lost frame and silence is filled during playback.

[0149] After the read is complete, the read index is updated through atomic operations, the main queue utilization is updated in the system status sub-area, and a read confirmation is sent to the container side.

[0150] S5.3, HAL layer protocol adaptation and hardware transmission.

[0151] The host-side HAL protocol adaptation gateway receives and reads audio frames, and encapsulates them according to the negotiation protocol in step 1.

[0152] The LEAudioLC3 format is encapsulated into a standard frame, with the synchronization word 0x55AA, the frame sequence number, the LC3 encoded data, and the CRC. The corresponding HAL sending interface is called, and the frame duration is set to 10ms.

[0153] The aptXLowLatency format is encapsulated as a corresponding frame header plus encoding type plus data length plus encoded data. Hardware acceleration capabilities allow calling dedicated interfaces, while without hardware acceleration, it relies on optimized software encapsulation to call general interfaces.

[0154] Hardware transmission prioritizes time slices, sending data according to the transmission time slice determined by the arbitration result, and disables the power-saving mode of the Bluetooth chip to avoid transmission delays caused by power saving.

[0155] After transmission is completed, the HAL layer returns the transmission status as successful or failed. The host-side data processing thread writes the status to the system status sub-area and records the hardware transmission timestamp of the host monotonic clock for use in step 6 for synchronization calibration.

[0156] S6, full-process dual-system collaborative scheduling guarantee, refined CPU core binding and scheduling strategies.

[0157] S6.1, a refined configuration of a dedicated CPU core group.

[0158] The host-side scheduler scans the CPU core information. The 8-core configuration is divided into 4 performance cores (CPU0 to CPU3) and 4 energy efficiency cores (CPU4 to CPU7). Two performance cores (CPU2 and CPU3) are reserved to form a dedicated Bluetooth audio core group. An affinity mask is set and the cores are isolated to an independent scheduling pool.

[0159] Configure core parameters to disable CPU dynamic frequency scaling, lock the core frequency to a maximum of 2.8GHz to avoid frequency scaling latency, disable hyper-threading to ensure that each core runs only one critical thread without context switching, disable deep sleep of the core, and restrict C-state to C0 only active state to avoid wake-up latency.

[0160] Load monitoring of the reserved core group is implemented. The scheduler monitors the core utilization rate every 0.1ms. If the utilization rate of a certain core is greater than 80%, the low-priority auxiliary thread status monitoring thread is migrated to the energy-efficient core CPU4.

[0161] S6.2 Priority binding of critical threads in dual systems.

[0162] S6.2.1 Container-side critical thread binding.

[0163] Thread 1, the protocol decoupling layer instruction processing thread, is bound to CPU3, with a scheduling policy of SCHED_FIFO and a priority of 97; Thread 2, the audio encoding and shared memory writing thread, is bound to CPU2, with a scheduling policy of SCHED_FIFO and a priority of 98; Thread 3, the permission proxy and exception handling thread, is bound to CPU3, with a scheduling policy of SCHED_FIFO and a priority of 96.

[0164] S6.2.2, Host-side critical thread binding.

[0165] Thread A, the protocol proxy layer, is bound to CPU3 with the arbitrator thread, using the SCHED_FIFO scheduling policy and a priority of 97.

[0166] Thread B processes data and is bound to CPU2 for HAL adaptation, with a scheduling policy of SCHED_FIFO and a priority of 98.

[0167] Thread C handles interrupt forwarding and is bound to CPU2, with a scheduling policy of SCHED_FIFO and a highest priority of 99.

[0168] Thread D's state monitoring is bound to CPU3 with the synchronization thread, using the SCHED_FIFO scheduling policy and a priority of 95.

[0169] Priority conflict handling is to avoid conflicts when threads in both systems have the same priority by using core exclusivity, with CPU2 running only thread 2 or thread B at any given time.

[0170] S7, interrupt feedback and high-precision clock synchronization calibration, refine interrupt forwarding and clock calibration.

[0171] S7.1 Fast capture and forwarding of hardware interrupts.

[0172] After the Bluetooth hardware completes the audio transmission, it triggers the transmission completion interrupt IRQ120, which is pre-configured as a high-priority interrupt. The host-side interrupt controller directly forwards the interrupt to the interrupt handling forwarding thread, skipping the redundant processing of the general ISR, and printing system logs and multi-service notifications.

[0173] The interrupt handling thread extracts the interrupt information, including the sequence number N of the completed frame, the hardware transmission timestamp T_hw with a precision of 1μs, and the transmission status (success or failure), and encapsulates it into an interrupt feedback frame. The frame sequence number is 4 bytes, T_hw is 4 bytes, and the status is 1 byte, for a total of 9 bytes.

[0174] Interrupt feedback frames are written directly to the interrupt feedback subpartition of the control instruction subregion. The control instruction subregion reserves 5KB of space and updates the hardware transmission status of the system status subregion. This does not require forwarding through the kernel or user space, and the interrupt handling latency is less than 5μs.

[0175] S7.2, High-precision clock synchronization calibration.

[0176] The container-side synchronous calibration thread is bound to CPU3 and reads the interrupt feedback frame of the control instruction sub-region every 0.5ms, extracting T_hw and frame number N.

[0177] Calculate multi-dimensional delay parameters.

[0178] The end-to-end delay Delay_total equals T_hw minus T_container, where T_container is the timestamp of the container-side write to shared memory.

[0179] The host processing delay Delay_host is equal to T_hw minus T_host, where T_host is the timestamp for the host side reading shared memory.

[0180] The hardware transmission delay Delay_hw is equal to T_hw minus T_send, where T_send is the timestamp of the data being sent to the HAL layer.

[0181] Dynamic calibration strategy:

[0182] If Delay_total is greater than the 50ms threshold, reduce the container-side write rate by 1 frame every 1.2ms, and simultaneously notify the host side to increase the priority of the data processing thread.

[0183] If 20ms is less than or equal to 50ms (which is within the normal range), maintain the current configuration and fine-tune the HAL layer's transmission time slice by ±0.1ms.

[0184] If Delay_total is less than or equal to 20ms, the write rate is increased to 1 frame every 0.9ms to avoid empty reads of shared memory.

[0185] Dual-system clock skew calibration:

[0186] The clock bias is calculated every 10 frames and is equal to the host clock T_hw minus the container clock T_container.

[0187] If the absolute value of the bias exceeds 1ms and the deviation exceeds the threshold, adjust the reference clock of the container-side audio service to use the host clock as a reference to ensure timestamp consistency and avoid frame misalignment.

[0188] S8. Abnormal recovery and orderly release of resources.

[0189] S8.1, Interaction of transmission termination command and anomaly detection.

[0190] When the Android application calls disconnect normally, the container-side decoupling layer generates a stream termination instruction, which includes the termination reason (0 indicates normal) and the total number of frames transmitted. This instruction is sent to the host side through the protocol pass-through bridge, and the host-side proxy layer notifies the Bluetooth protocol stack to stop transmitting.

[0191] Abnormal termination is detected when shared memory mapping breaks, protocol interaction timeouts exceed 5ms, or frame loss occurs more than 5 times consecutively, triggering the abnormal termination process.

[0192] The container sends an emergency termination command, and the host immediately stops sending data and marks the device as idle.

[0193] The host-side data processing thread cleans up unsent audio frames to prevent residual data from interfering with the next transmission.

[0194] S8.2, Abnormal Recovery Mechanism.

[0195] S8.2.1, Shared memory mapping break recovery.

[0196] The container detected a SIGSEGV memory access error and immediately invoked munmap to remove the old mapping.

[0197] Request the host to recreate the shared memory pool, reuse the defined parameters, and re-execute mmap. The recovery time is less than 10ms.

[0198] S8.2.2, Protocol interaction timeout recovery.

[0199] The container checks the interaction status of the protocol pass-through bridge every 5ms. If the timeout occurs, the protocol pass-through bridge is restarted and the connection is re-established based on netlink.

[0200] The recovery negotiation parameters are read from the host-side negotiation parameter cache, without the need for renegotiation, and the recovery time is less than 8ms.

[0201] S8.3, orderly release of resources.

[0202] S8.3.1, Shared memory release.

[0203] The host side marks the memory pool as unwritable, waiting for the data processing thread to complete sending the remaining data.

[0204] The container calls munmap to unmap the memory pool, while the host calls shmctl to delete the memory pool and release physical space.

[0205] S8.3.2, Schedule resource release.

[0206] The scheduler coordinator removes the isolation of the dedicated core group and returns it to the system's general scheduling pool.

[0207] Restore CPU dynamic frequency scaling and hyper-threading, and restore the scheduling policy of all critical threads to SCHED_OTHER.

[0208] S8.3.3, Bluetooth resource release.

[0209] The resource arbiter marks the device as idle and releases the allocated bandwidth.

[0210] The protocol proxy layer clears the negotiation parameter buffer, closes the protocol pass-through bridge, and restores itself to the initial state.

[0211] The cross-system permission synchronization service, deployed on the OpenHarmony host side, is a system-level service bound to the container management service lxc-manager. Its core function is to receive the container's Bluetooth audio permission list, including application signature and package name, and then interface with the host permission management subsystem to complete a primary verification, long-term caching, and generate a 16-byte permission token. This replaces the traditional two-stage permission verification from container to host, reducing verification latency from 20-30ms to 1-2ms and avoiding time-consuming permission negotiation during the protocol negotiation phase.

[0212] The Bluetooth audio protocol standard interface is a set of independent interfaces defined by the Android container-side protocol decoupling layer. It includes 12 core interfaces, NegotiateCodec, and StartAudioStream. Its core features are independent of Android and OpenHarmony system-private fields. It adopts an interface abstraction and implementation separation architecture, supporting cross-system compatibility. Its function is to decouple the two-end protocol stack, avoiding the need for OpenHarmony to fully translate Android private instructions, and reducing interface call latency by 50%.

[0213] A dynamic instruction filtering rule base is deployed on the protocol pass-through bridge, employing a three-level filtering rule set and using a hybrid storage of hash tables and linked lists. The core design's first-level dimension categorizes instructions into four types, retaining only core audio and permission verification instructions. The second-level dimension filters redundant instructions that do not affect real-time transmission based on transmission necessity. The third-level dimension eliminates debugging and vendor-extended fields from instructions, compressing the 256-byte CODEC_NEGOTIATE instruction to 16 bytes. The effect is a 90% redundancy filtering rate, reducing the amount of protocol interaction data and lowering transmission latency.

[0214] The three-dimensional shared memory pool sub-partition architecture is a structured design that divides the shared memory pool into seven functional sub-partitions based on a 2:7:1 ratio. Core components include instruction synchronization sub-partitions that differentiate between permission instructions and control instructions, distinguishing between permission verification and flow control instructions; audio data that uses primary and backup circular queues to prevent data overflow; and verification and status sub-partitions that differentiate between CRC frame sequence check sub-partitions and system status sub-partitions to detect frame loss and misalignment and monitor memory status in real time. This architecture solves the problems of mixed data and chaotic synchronization in traditional partitioned systems, reducing the data synchronization error rate from 15% to below 0.1%.

[0215] The Bluetooth resource arbiter, deployed on the host side, is a resource scheduling component bound to the Bluetooth management service. Its core logic allocates 100% bandwidth to container applications when the device is idle. When multiple applications compete for bandwidth, bandwidth allocation is based on real-time priority: calls take precedence over games, which in turn take precedence over normal playback. High real-time applications in containers receive 80% of the bandwidth. A 0.8ms hardware time slice is guaranteed for audio every 1ms. Its function is to resolve Bluetooth device sharing conflicts, reducing latency fluctuations from 30-50ms to less than 5ms and the disconnection rate from 8% to below 0.5%.

[0216] A dual-system clock skew calibration mechanism is a closed-loop mechanism that adjusts the container-side audio service clock based on the Bluetooth hardware-transmitted timestamp T_hw.

[0217] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for low-latency Bluetooth audio transmission across operating environments based on dynamic resource arbitration, characterized in that, Specifically, the following steps are included: After the host starts up, it traverses Bluetooth to collect hardware information to form a device resource file and stores it in the Bluetooth resource pool. It initializes the permission synchronization service of the built-in rule base and deploys the protocol proxy layer to implement the same Bluetooth audio protocol interface as the customer environment. When the customer environment starts up, it deploys the protocol decoupling layer, loads a local copy of the rule base, extracts information from the permission proxy unit and uploads it to the permission synchronization service, verifies permissions, generates permission tokens and stores them in the host permission cache pool, and sends them back to the customer environment. When the client environment application initiates a Bluetooth audio connection request, the protocol decoupling layer initiates a protocol negotiation request to the protocol proxy layer. The protocol proxy layer retrieves the permission cache pool to verify the token's validity. If the token is valid, it retrieves the Bluetooth resource pool to obtain the device's compatible protocols and bandwidth limits, determines the encoding scheme, forms the negotiation result, and sends it back to the client environment. The host creates a shared memory pool based on the negotiation results, which includes an instruction synchronization area, an audio data area, and a check and status area. The fixed starting address determines the offset address of the sub-interval within the partition. A memory configuration list is generated and sent to the client environment. The client environment maps it to the virtual address space and sets up an audio output link to write audio data into the audio data area. The client environment application generates raw audio data according to the negotiation results. The audio encoding module generates audio data containing audio frames and verification data and writes it into memory, synchronizes it to the host, and triggers a read signal. After the host receives the read signal, the data processing thread queries the instruction synchronization area, calculates the memory address based on the read sequence number, reads the audio data, obtains the corresponding CRC check code to complete the verification, and the protocol proxy layer initiates an audio transmission request. After receiving the audio transmission request, the host arbitrator obtains the bandwidth quota and transmission time slice configuration from the rule base and sends them to the data processing thread; The adapter gateway reassembles the audio data into audio data packets according to the negotiation results and sends them to Bluetooth using time slices.

2. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, The audio encoding module generates audio data containing audio frames and verification data and writes it into memory in the following way: The audio service reads the status flag of the shared memory pool, retrieves the queue load judgment threshold in the rule base, and if the load of the main data queue is less than the threshold, the audio data is written into the main data queue; otherwise, it switches to the backup data queue and sends a partition write queue switching notification to the control command. The storage address is calculated based on the current write position, and the audio data is written into the corresponding memory location.

3. The Bluetooth audio low-latency transmission method across operating environments according to claim 2, characterized in that, Periodically read memory usage, match it with the rule base's graded speed adjustment standard, and dynamically change the writing interval of audio frames.

4. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, The method for calculating the memory address based on the read sequence number to read audio data and obtaining the corresponding CRC checksum to complete the verification is as follows: CRC checksum verification is used. If the verification passes, the audio data is valid. If the verification fails, the client environment is requested to resend the data. If no information is received within a set time threshold, the frame is discarded and silence is used to fill the gap. The frame sequence number is checked. If the sequence number is not continuous, the frame is marked as lost and silence is played to fill the gap. The read position number is updated, the memory usage information is refreshed, and a read completion message is sent to the client environment.

5. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, After receiving an audio transmission request, the host arbitrator obtains the bandwidth quota and transmission time slice configuration from the rule base and sends them to the data processing thread in the following way: The system retrieves pre-stored bandwidth allocation criteria from the rule base and determines the device resource status based on the rule base configuration. If the device is idle, it allocates all bandwidth to the client environment application according to the rules in the rule base. If the device is occupied by the host system's native application, it distinguishes the service type according to the rules. If the client environment is a real-time service, it allocates a preset proportion of bandwidth, while ordinary media services are placed in a queue. When multiple client environment applications make concurrent requests, resources are allocated according to the predefined service priority order and first-come-first-served principle in the rule base. Finally, it outputs the corresponding bandwidth quota and sending time slice configuration according to the rules and sends them to the data processing thread.

6. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, Before initiating a protocol negotiation request to the host's protocol proxy layer, the protocol decoupling layer filters invalid instructions and redundant fields by matching classification rules with an index, and then adds a version tag.

7. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, The control command partition is configured with a bidirectional synchronization identifier. The client environment is writable by default, while the host initially waits to read. The audio data area has its read / write position number initially set to zero and an occupancy threshold is set. When the load of the main data queue exceeds the threshold, it switches to the backup data queue. The verification status partition refreshes the memory occupancy data according to the refresh cycle, and the client environment reads the status data according to the read cycle. The data write speed is dynamically adjusted, and the verification storage space and audio frame sequence number are bound one-to-one to achieve addressing.

8. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, When writing audio data to the corresponding memory location, if the written audio data exceeds the upper limit of the main data queue, switch to the backup data queue, report an overflow notification, and the host will read the data from the backup data queue first; if an error occurs during data verification, re-encode and resend the audio data of this frame until the maximum number of retries is reached. When three consecutive frame sequence numbers are not consecutive, a frame loss notification is reported, and missing frames at the remote end are filled with silence.

9. The Bluetooth audio low-latency transmission method across operating environments according to claim 1, characterized in that, During Bluetooth audio transmission link initialization, the host scheduler and coordinator optimizes CPU configuration, reserving two cores to form a dedicated Bluetooth audio core group. This group is independently isolated and scheduled, with the core's highest operating frequency locked and hyper-threading and deep sleep mechanisms disabled. Simultaneously, the dedicated core load is monitored at set intervals. When core utilization exceeds a threshold, lower-priority auxiliary threads are migrated to energy-efficient cores. Core binding and real-time priority configuration are performed for all Bluetooth audio critical threads in both the client and host environments. In the client environment, dedicated cores are bound to the protocol decoupling instruction processing, audio encoding and shared memory writing, permission proxy, and exception handling threads, and corresponding real-time priority gradients are configured. The host sequentially completes core binding and priority grading for protocol proxy and resource arbitration, data processing and HAL protocol adaptation, interrupt handling and forwarding, and status monitoring and synchronization critical threads. When conflicts arise between threads of equal priority in both systems, only the corresponding high-priority thread runs on the same core.

10. The method for low-latency Bluetooth audio transmission across operating environments according to claim 1, characterized in that, After Bluetooth completes the audio data transmission, a hardware interrupt is triggered. The interrupt signal is handled by a dedicated interrupt forwarding thread. This thread extracts the corresponding frame number, hardware timestamp, and transmitted data, assembles them into fixed-length interrupt feedback data, and writes it into the dedicated storage space reserved in the control command sub-area. It also refreshes the hardware transmit and receive information in the system status partition at the same time. The client environment synchronization thread reads the interrupt feedback data at fixed intervals. Based on the hardware timestamp and the time information recorded by each link in the entire link, it calculates the end-to-end total delay, host processing delay, and hardware transmission delay. Based on the value of the end-to-end total delay, it dynamically adjusts the audio write rate and hardware transmission time slice of the client environment, schedules the host thread, and calculates the clock difference between the client environment and the host after accumulating a set number of frames. When the clock offset is greater than the threshold, the client environment reference clock is corrected based on the host clock.

Images