BLE Audio Time Sync via 802.1AS PTS and ATS
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods for synchronizing audio playback over Bluetooth Low Energy (BLE) face challenges in accurately determining and maintaining processing delays across multiple slave devices, especially when host software changes, leading to tedious recalculations and uncertainty in presentation delay determination.
Innovation Solution
The implementation of the 802.1AS IEEE protocol using presentation timestamps (PTS) and application timestamps (ATS) derived from a master device's host clock to synchronize audio playback across multiple BLE-connected slave devices, simplifying the determination of transport and processing delays and offloading the decision of payload presentation to the host based on PTS/ATS.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional methods are used to synchronize audio playback over BLE, then audio data can be transmitted to multiple slave devices, but accurately determining and maintaining processing delays becomes difficult especially when host software changes
Solution Approach 1:
The patent introduces an 802.1AS protocol as an intermediary mechanism that operates independently of host software changes. This protocol provides a standardized method for timestamp generation and exchange between master and slave devices, decoupling the synchronization logic from host-specific implementations. The protocol acts as a mediator that ensures consistent delay calculation regardless of software variations.
Solution Approach 2:
The patent changes the synchronization approach from relying on host software calculations to using protocol-defined timestamp parameters (PTS and ATS). By shifting from software-dependent delay determination to parameter-based synchronization using standardized timestamp fields in protocol packets, the system achieves reliability independent of host software changes while maintaining manageable controller complexity.
2Adaptability or versatility
If host software changes occur, then new synchronization methods may be needed, but frequent recalculations of transport and processing delays are tedious and time-consuming
Solution Approach 1:
The patent implements preliminary action by establishing the 802.1AS protocol framework in advance, which pre-defines the timestamp generation and exchange mechanism. This preliminary setup creates a robust synchronization foundation that remains valid across software changes, eliminating the need for frequent recalculations. The protocol structure is established beforehand to handle various software configurations without requiring reconfiguration.
Solution Approach 2:
The 802.1AS protocol serves as a universal synchronization mechanism that works across different host software versions and configurations. The protocol's multi-functionality allows it to handle timestamp generation, exchange, and delay calculation in a unified manner, making the system adaptable to software changes without requiring separate recalibration procedures for each software version.
3Measurement precision
If conventional synchronization methods are used, then audio data can be transmitted, but determination of presentation delay is uncertain and requires complex calculations
Solution Approach 1:
The patent replaces complex mechanical calculation systems with a protocol-based timestamp exchange mechanism. Instead of using intricate delay calculation algorithms in the controller, the system substitutes these with straightforward timestamp measurements (PTS and ATS) defined by the 802.1AS protocol. This substitution simplifies the controller logic while improving the precision of presentation delay determination through standardized timestamp-based measurement.
Data Source
AI summary
Example methods and apparatus to facilitate time synchronization of audio over Bluetooth Low Energy are disclosed herein. An apparatus includes a packet processor to process a data packet to identify a timestamp encoded in the data packet; a buffer to store the data packet with the timestamp; and a host to: when the data packet is removed from the buffer, initiate a timer; and when the timer reaches a time corresponding to a sum of the timestamp and a presentation delay time, out the data packet to render the data packet.