【IOT开发】音频传输中的时序与同步问题
音频传输中的时序与同步问题
abstract
在流媒体应用和音频服务中，同步问题是决定用户体验的重要一环。在处理多媒体数据同步问题时，可以使用等时间间隔同步、时间轴同步和流控制同步等策略，这些同步规范方法可以根据具体的需求选择和应用。这篇文档将从实际应用场景出发，参考蓝牙音频协议栈及其他解决方案中关于音频传输时序问题的处理方法，尝试解释音频同步的基本思想和实现难点。最后，特定的应用场景，尝试提出可行的解决方案。
introduction
在蓝牙耳机、视频播放等场景，对时序同步要求较高，音画不同步以及蓝牙耳机的时延较大会严重影响用户体验。早期视频网站或直播网站经常出现音画不同步的问题，蓝牙耳机也或多或少存在时延问题。一般而言，我们对于音频与视频延时到 80ms 时，会较容易被察觉到。同时，声音比视频提前，会比视频提前更容易接受。
以蓝牙传输音频数据为例，我们假想最简单的模型：蓝牙音频发送端等时间间距，均匀的发送数据包，接收端等时间间距均匀的接收数据，这种情况下接收端可稍微延迟后将收到数据通过喇叭送出，在喇叭播放完这包数据之前可收到下包数据继而能够连续不断的播放，此时蓝牙音频的时延取决于发包间隔和传输时间，而这个时间是非常小的。在最早的 STM32F103 上基于定时器、UART 和 DMA 就是这种等时间间距收发、播放的策略，在有线传输的稳定传输下可以几乎不考虑时延（最终调整时延在 10~20ms）。
然而，现实中会有信号干扰，有可能出现传输错误的。传输错误重传导致其中某些包重传次数多传输时间变长(传输错误重传是在蓝牙协议层中进行的，在应用层开发看到的只是每次成功 write 的时间不一致)，接收端收到的数据包并不是等时间均匀的。这种情况下接收端想要流畅播放必须先缓存一定时间长度的数据之后再进行播放，以防止其中包晚到导致播放不连续。这种情况下真实主要因素是为了抵抗网络传输不稳定性而人为添加的延迟(缓存)，也就是蓝牙耳机主要的延时是因为要缓存一段时间的数据。
在实现音频同步主要是在应用层处理，操作系统和驱动层的目标是确保单个媒体流单元的平稳呈现。多个媒体流之间的同步需要在更高的层次上进行处理，例如在应用程序层或媒体层。接下来将简要介绍如何在下位机的驱动层实现对媒体流的稳定、连续播放，然后介绍一些经典的同步策略，并为目前的应用场景指定对应的同步机制和算法。
音频流模型
尝试用一个数据流-管道-蓄水池模型来解释音频流的播放时序问题。音视频数据，我们可以看作一个数据流,数据流的最小处理单元是 LDU，Logical Data Unit。在对音频数据进行传输时，使用类似于 stream 类的数据流方式。stream 类没有预定长度，易于分段与组合，在底层可以基于 queue 结构实现。传输的过程，可以看作是数据流在管道中进行，不同的管道类型对应着不同的传输模式-wifi、蓝牙、UART；他们有着不同的带宽和稳定程度。在播放设备的控制器中，可能会有类似于蓄水池的缓存，来存储接收到的，还未播放的 stream。
先进的音视频处理过程都会把音视频数据转换成流式处理。音视频数据一般比较大，所以对内存需求也比较高，流式处理可以在一段新数据到达时即开始处理。同时我们播放的音视频很多时候是无尽事件流，没有明确的停止时间，流式处理可以收到即处理，处理即注销。在我最早的 STM32F103 播放 HAPTIC 驱动中，数据是即发即用的数组格式，只能应用于收发时间间隔稳定的应用场景。而之后采用了队列结构，底层 PCM 数组仍然以数组存储，但基于队列控制数据流式播放，能有效地提高稳定性。
对于流的连续播放，在无法保证发送管道稳定时间间隔发送的情况下，会需要一定的缓存帮助。当收到下一段数据前播放上一段数据，就会造成卡顿，而蓝牙耳机协议的解决方法是缓存一段时间再播放。越大的缓存空间，能够抵抗越高强度的发送不稳定，但同时也会导致更高的延时。在使用蓝牙耳机时，暂停后点击“播放“需要卡一小下才能播放，这很可能是缓存延时导致的。在目前 ESP32-AHAP 解码的驱动中，还没有加入缓存播放机制，所以可能会造成卡顿，详情见 AHAP 上位机 时序优化 。虽然通过上位机超量发送人为造成了一段冗余缓存解决了卡顿问题，但这也会造成数据堵塞造成小卡顿的隐患。但在该应用中加入缓存播放是不可能的——一个数据包的间隔是 100ms，缓存一个包就会导致 >100ms 的延时，这会在播放、调整进度条、暂缓恢复时都会产生，显然是无法接受的。所以之后对于该驱动的优化，如果加入缓存机制，则需要改小包数据到 10ms 每个包（这对于 SPP 协议是极限了），然后缓存一两个包。
LDU 的数据长度与播放质量相关。模型中的流是连续的，但基于 LDU 发送的数据包显然是离散的数据。显然的，我们减小流的最小单位，可以提高数据流的”流畅程度“。但减小 LDU 的代价是什么呢？在基于 RFCOMM 的 SPP 蓝牙传输中，LDU 对应最小时间长度是 10ms，这对应了蓝牙 100HZ 的回报率。需要注意的是，RFCOMM 是伪双工程协议，所以如果希望基于 RFCOMM 建立同步链路，更小的包会影响下位机的回报效率。另一方面，蓝牙传输的带宽是和每个包的数据量相关的，一个包传输更多的数据能够得到更大的带宽。目前的 AHAP 数据流的回报和带宽都没有达到上限，所以后续可以基于减小 LDU 进行优化。
值得一提的是，在讨论连续播放时，我们更多的是关于发送时间间隔不稳定的讨论，而不是丢包、数据帧错误等情况。丢包的影响是致命的，这会导致数据流的不连续，如果没有相应的错误处理会影响流的后续播放。但无论 UART 还是 SPP 都有对应的纠错重发机制，成熟的传输接口都有类似的机制。目前的应用中还没有遇到丢包的情况，如果后续考虑强干扰环境，需要加入对应的错误处理机制。
同步机制
文献[3]中，对于时间依赖的媒体数据的同步方法，总结了以下同步策略：
- 基于时间间隔的同步：要求多媒体对象之间的播放时间间隔保持一致。可以简单理解为在固定的 interval 内处理需要播放的数据单元。
- 基于轴的同步：要求多媒体对象之间的时间轴保持一致。1.在多媒体对象中添加时间轴信息，例如音频时间轴、视频时间轴等。在播放过程中，通过比较时间轴信息来同步多媒体对象之间的播放。可以使用一个全局时钟来同步多媒体数据，所有媒体对象都附加到全局实时时间轴。2.基于时间戳的同步。在多媒体数据中嵌入时间戳，然后建立虚拟时间轴，在接收端使用这些时间戳来同步多媒体数据。这更适用于被拆分的信号流。
- 基于控制流的同步：基于控制流来同步多媒体对象。在多媒体对象中添加控制流信息，例如播放、暂停、快进、倒退等操作。在播放过程中，通过比较控制流信息来同步多媒体对象之间的播放。控制流也可以基于反馈，在发送端和接收端之间建立反馈通道，通过接收端向发送端发送反馈信息来控制多媒体数据的播放速度与进度。
例如上图中的事件控制流控制同步模型，需要播放的数据以树的数据结构存储，播放命令对应某一层的数据。但就音视频的同步而言，会简化成两个数组，只需要同步最小 LDU 的同时播放、暂停状态即可。
这些同步规范方法需要根据具体的需求选择和应用。对于没有用户互动的简单演示，可以选用基于全局定时器的方法。对于有交互的复杂结构，基于控制流的参考点模型似乎是合适的。
discussion
对于最经典的流式音频播放，下位机对数据的实时性要求较高，而上位机无法满足稳定、精确的定时发送。所以我们需要一定的缓存空间。就像出水管道在蓄水池中的一定高度，要等蓄水量到一定值之后才会播放。而缓存的时间会导致一定的延时，即在更改进度条时需要新的等待时间。
在上位机发送数据的策略中，目前 python 上位机的做法是通过一个定时器，固定 interval 给下位机发送相应的数据包。在播放器中，通过进度条的回调函数让定时器发送函数的 index 与进度条同步。这种方法相当于固定给下位机发送包，通过进度条回调让发送的数据定期和视频画面同步。由于使用了微超量发送的策略保证流的连续播放，所以没有使用缓存时间，同步实现的较好。
对于稳定的延时，我们可以通过固定偏执的修正来减小延时的影响。例如大多数情况是音频延时，这时候可以让画面进行等待。当然，更常见的做法是通过控制流来达到稳定的延时，并通过调整偏执来进行同步。
在具体的应用中，我们会考虑基于轴同步的音视频同步，即在播放端的音频轴与发送端的音频轴同步，并基于事件控制进行音频流控制。需要注意到的是，音频缺失比存在稳定延时，对体验的影响小很多。所以在通过等待-轴同步的方案中，可以省略一定量的音频数据，让画面实时运行，在之后再进行同步。
从理论到实践：AHAP-DECODE 解码时序优化
附录
蓝牙链路
Synchronous Connection Oriented (SCO) link and the Asynchronous Connection-Less (ACL) link
SCO 更多是在语音信号流中使用，它只能支持 point to point 的连接。我们的设备目前是 point to point 的，不过没有使用 SCO 链路。因为在 SCO 实现的过程中，是基于等间距时隙交换实现同步的，所以 master 的收带宽会占用发一样通用量级的带宽。
| Time processbar | |||||
|---|---|---|---|---|---|
| MO | MI | MO | MI | MO | MI |
| SI | SO | SI | SO | SI | SO |
这种不同于流式的异步收-存储-连续播放的策略。信号不稳定不会导致时延，只会导致音频质量降低。
The term ‘advanced audio’ should be distinguished from ‘Bluetooth audio’, which indicates distribution of narrow band voice on SCO channels as defined by the Bluetooth Baseband specification.
The master maintains the SCO link by using reserved slots at regular intervals. The basic unit of reservation is two consecutive slots (one in each transmission direction).
| Time processbar | |||||
|---|---|---|---|---|---|
| MO | slots | MI | slots | MO | slots |
| SI | slots | SO | slots | SI | slots |
SCO 链路预留插槽后，微网中其他 ACL 链路的微微网带宽非常有限。
The transmission of audio/video over the Internet requires the support of audio encoding and decoding schemes and a packet switched based network connection—which is not offered by the SCO connection.
SCO
在配置A2DP蓝牙协议栈时，偶然发现有个东西叫：SCO -Synchronous Connection Oriented link - 面向链接的同步链路
最近接触了一下音视频开发相关的项目，不同设备间、不同数据形式间的时间同步是一个比较重要的问题。了解这个链路的同步逻辑、实现原理，会有助于需要同步的项目开发。
百度百科：
支持对时延敏感的信息如语音。蓝牙中定义的两种数据链路方式之一。
用保留带宽进行同步通信，即两台设备在LMP层利用保留时隙在物理信道上周期传送传送数据包。这种类型的链接主要用于传送SCO包（语音数据）。SCO 包不包括CRC码，且不进行重传。主要支持传输有时间限制的信息，例如声音。仅仅在ACL链接已经建立之后，才可以建立SCO 链接。
What is SCO in Bluetooth?
SCO (Synchronous Connection Oriented Link) This is a voice data link. While Bluetooth is the technology used to connect devices from different manufacturers without wires, the devices still have to talk to each other while providing what ever service they are designed for.
SCO is a symmetric link, i.e. fixed slots are allocated for each direction. Since fixed slots are reserved, SCO provides a circuit switched connection. SCO radio links are used for time critical data transfer, particularly for voice data.
The Synchronous Connection Oriented link is one of the two possible Bluetooth data link types defined. The SCO link is a symmetric, point-to-point link between the master device and a specific slave device. The SCO link reserves slots between the master and the slave and can therefore be considered to provide a circuit switched connection. The SCO link is usually used to support time critical information, e.g. voice, since time critical SCO packets are never retransmitted. The master device can support up to three SCO links, this might be to the same slave or to different slaves. A slave can support up to a maximum of three SCO links, assuming they are from the same master. If the slave has links from different masters, a maximum of two SCO links are available.
蓝牙物理链路ACL(Asynchronous Connectionless)，另外的一种链路是SCO(Synchronous Connection Oriented)主要用来传输对时间要求很高的数据通信。
蓝牙基带技术支持两种连接类型：同步定向连接(SCO)类型和异步无连接(ACL)类型。前者主要用于同步话音传送，后者主要用于分组数据传送。
SCO连接为对称连接，利用保留时隙传送数据包。连接建立后，主设备和从设备可以不被选中就发送SCO数据包。SCO数据包既可以传送话音，也可以传送数据，但在传送数据时，只用于重发被损坏的那部分的数据。同步定向链接（SCO）是在匹克网中主单元和从单元之间实现 点到点链接。主单元通过有规律的 使用保留时隙来维持SCO 链接。
SCO 链路是通过为传输预留时隙来实现同步的。主设备向从设备发送同步数据包以建立连接。然后，从设备向主设备发回一个数据包，以确认它已收到同步数据包。此后，两个设备同步并可以传输数据。
主单元以有规律的时间间隔来发送分组，所以在保留的主―从时隙里，称到从单元的SCO 间隔为Tsco（记数时隙）。在主―从时隙里SCO从单元总是允许响应SCO分组传输。SCO 链接由主单元发送SCO 建立消息，经链接管理（LM）协议来确立。该消息分组含定时参数（如SCO 间隔Tsco 和规定保留时隙补偿Dsco）等。在 SCO 链接不保留的时隙里，主单元可以与任何属于每个时隙基里的从单元进行分组交换。
所以SCO实现同步的两个核心分别是“间隙”和“回报”。在发送语言等数据时进行主从通信，确定时间同步。
在我的项目中，通过编码压缩的方式提高了数据的传输效率，有“空闲”来进行回报同步。但是目前使用的SPP协议是可以回报的，但是回报与server端接受-处理耗时可能会比较久。之后降低延时可以基于这种方法改进。
AVDTP 协议
音视频分发传输协议
基带是蓝牙堆栈的物理层，用于管理纠错、数据包处理、寻呼和查询以访问蓝牙设备以及蓝牙安全等功能。基带收发器支持时分双工方案。
链路管理器协议 （LMP） 执行链路设置和配置、身份验证、加密管理等。
逻辑链路和控制适配协议 （L2CAP） 隐藏了蓝牙较低层的功能，对较小的基带数据包执行分段和重组操作。
AVDTP 指定使用 ACL 链路通过蓝牙空中接口分发音频和视频以及流式传输的传输协议。
AVDTP 提供规则和程序，为 A/V 数据传输提供高质量的同步通信（传输时钟相关过程所必需的）。
AVDTP provides rules and procedures to provide high quality isochronous communication (required for the transmission of clock dependent processes) for the transfer of A/V data.The transport mechanism and message formats of the AVDTP are based on the Real-time Transport Protocol (RTP).
在 A/V 应用程序通过蓝牙链路传输 A/V 流之前，AVDTP 会执行 A/V 参数协商。根据此协商的结果，应用程序将传输 A/V 内容。
上图显示了 AVDTP 架构（由 AVDTP 规范定义）。我们总结了 AVDTP 组件的主要功能（如图 2 所
- 流管理器：提供流化、媒体成帧、时间戳管理、媒体数据包序号、上报报更高层丢包、抖动计算等功能。
- 恢复组件：不提供前向纠错 （FEC） 和相等的 FEC。
- 适配层：执行报头压缩和多路复用，以允许在一个传输通道上多路复用多个传输会话。
- 信令：提供应用和传输服务能力的发现、流协商、流连接建立、流连接拆解、流暂停和恢复。
AVDTP 的传输服务功能对应于 A/V 传输层内更具体的传输相关“服务”。其中包括成帧和分段、封装、交付性能报告、数据包丢失检测、数据包恢复、强大的标头压缩以及将传输会话多路复用到传输通道。
参考文献
[1] A. Rossholm and B. Lövström, “A robust method for estimating synchronization and delay of audio and video for communication services,” Multimedia Tools and Applications, vol. 75, no. 1, pp. 527-545, Jan. 2016, doi: 10.1007/s11042-014-2306-6
[2] S. Zeadally and A. Kumar, “Design, implementation, and evaluation of the audio/video distribution transport protocol (AVDTP) for high quality audio support over Bluetooth,” Computer Communications, vol. 28, no. 2, pp. 215-223, Feb. 2005, doi: 10.1016/j.comcom.2004.09.007
[3] G. Blakowski and R. Steinmetz, “A media synchronization survey: reference model, specification, and case studies,” in IEEE Journal on Selected Areas in Communications, vol. 14, no. 1, pp. 5-35, Jan. 1996, doi: 10.1109/49.481691.