3、DP音频传输架构：DP主链路与辅助通道、音频数据包的结构、音频时钟恢复机制
3.1 音频传输的两条“路”：主链路与辅助通道
DP接口传输音频，说白了靠的是两条路。一条是“高速公路”——主链路（Main Link），另一条是“乡间小道”——辅助通道（AUX CH）。
主链路负责搬运音频数据本身。它用4条高速差分线，每条速率从1.62Gbps到8.1Gbps不等。音频数据被打包成一个个小数据包，塞进主链路的空白周期里传输。我个人习惯把主链路比作“水管”，音频数据就是水流，视频数据也是水流，它们时分复用同一根水管。
辅助通道呢？它是一条双向低速通道，速率只有1Mbps。它不传音频数据，而是传“控制信息”。比如：
- 源设备告诉接收端：“我要开始传音频了，格式是LPCM 2声道，48kHz采样率。”
- 接收端回复：“收到，我准备好了。”
- 或者，接收端问：“你的音频时钟准不准？我需要校准。”
我在项目中遇到过一个问题：某款显示器播放音频时断断续续。查了半天，发现是AUX通道上的EDID（扩展显示标识数据）读取超时，导致音频格式协商失败。嗯，这种坑往往藏在最不起眼的地方。
核心要点：主链路传数据，辅助通道传控制。两者缺一不可。
3.2 音频数据包的结构：麻雀虽小五脏俱全
音频数据包长什么样？我直接给你看一个简化后的结构：
音频数据包（Audio Data Packet）结构：
+----------------+----------------+----------------+----------------+
| 包头 (Header) | 时间戳 (Timestamp) | 音频样本 (Samples) | 校验 (CRC) |
| 8字节 | 4字节 | 最大128字节 | 4字节 |
+----------------+----------------+----------------+----------------+每个字段都有讲究：
- 包头：标识这是一个音频包，不是视频包。包含包类型、数据长度等信息。
- 时间戳：这是音频时钟恢复的关键。它记录了音频样本的“播放时刻”。
- 音频样本：真正的音频数据。可以是LPCM、Dolby、DTS等格式。每个样本位宽16位、20位或24位。
- CRC校验：保证数据完整性。如果校验失败，接收端可以选择丢弃这个包。
你想想看，为什么需要时间戳？因为音频是连续播放的，但数据包是离散传输的。接收端必须知道每个样本应该在什么时间播放。时间戳就是那个“时间坐标”。
避坑指南：我曾经调试过一个项目，音频偶尔出现“啪”的一声爆音。后来发现是音频包的时间戳出现了跳变，导致接收端时钟恢复紊乱。解决办法是在发送端增加时间戳的平滑处理。
3.3 音频时钟恢复机制：让两端“同步心跳”
音频时钟恢复，说白了就是让发送端和接收端的音频时钟“对齐”。发送端以48kHz采样音频，接收端也必须以48kHz播放。如果两端时钟有偏差，就会出现音调变高或变低，甚至卡顿。
DP接口使用了一种叫“M值/N值”的时钟恢复方法。我画个图帮你理解：
具体怎么恢复？我简单说下流程：
- 发送端在音频数据包中插入时间戳。时间戳基于发送端的音频时钟生成。
- 接收端收到数据包后，提取时间戳，并与自己的本地时钟比较。
- 接收端通过锁相环（PLL）调整本地时钟，使其与发送端时钟同步。
- 辅助通道会定期传输M值和N值。M值是发送端在某个时间段内的音频样本数，N值是接收端在相同时间段内的参考时钟计数。通过这两个值，接收端可以精确计算出播放时钟。
注意：时钟恢复不是一次完成的。它是一个持续的过程。接收端会不断微调时钟，以应对发送端时钟的漂移。我曾经见过一个案例，发送端时钟漂移超过100ppm，导致接收端锁相环失锁，音频完全中断。所以，时钟恢复的鲁棒性非常重要。
3.4 音频传输的“握手”流程
最后，我总结一下音频传输的完整流程。你可以把它看作一次“握手”：
| 步骤 | 动作 | 通道 | 说明 |
|---|---|---|---|
| 1 | 读取EDID | 辅助通道 | 源设备读取显示器的音频能力（支持哪些格式、声道数等） |
| 2 | 协商格式 | 辅助通道 | 源设备选择一种双方都支持的音频格式 |
| 3 | 传输数据 | 主链路 | 源设备发送音频数据包，包含时间戳 |
| 4 | 时钟恢复 | 主链路+辅助通道 | 接收端根据时间戳和M/N值恢复音频时钟 |
| 5 | 持续同步 | 辅助通道 | 定期交换M/N值，保持时钟同步 |
嗯，到这里，DP音频传输的架构就讲清楚了。主链路负责“拉货”，辅助通道负责“指挥”，时钟恢复保证“步调一致”。三者配合，才能让音频流畅播放。
一句话总结：DP音频传输不是简单的数据搬运，而是一场精心编排的“交响乐”。主链路、辅助通道、时钟恢复，每个角色都有自己的谱子。