音视频控制

【AVRCP】规范精讲[25]: 大数据包拆分传输的完整流程与实战在蓝牙音频开发中，相信很多人都遇到过这样的问题：手机连接车载蓝牙后，播放一首名字很长的歌曲，车机屏幕上只显示了前几个字；或者获取专辑信息时，总是少了一部分内容。这背后其实是AVRCP协议的续传机制在起作用。很多开发者对这个机制一知半解，导致出现各种奇怪的兼容性问题。本文就来深入拆解AVRCP中的续传流程，包括RequestContinuingResponse和AbortContinuingResponse的工作原理、规范细节和实战中的坑点。

【LE Audio】CAP精讲[14]: BR/EDR传输连接实战，老设备兼容的核心流程解析在LE Audio生态中，LE传输凭借低功耗、高灵活性成为主流，但BR/EDR（Basic Rate/Enhanced Data Rate）传输并未退出舞台——大量传统蓝牙音频设备（如老式音箱、专业音频设备）仍依赖BR/EDR技术。CAP协议专门定义了BR/EDR/LE双模设备使用BR/EDR传输的连接建立规则，其核心目标是实现新协议与老设备的无缝兼容，让LE Audio设备既能连接现代LE外设，也能对接传统BR/EDR设备。

【AVRCP】规范精讲[20]: 播放器设置全打通，让车载与手机的播放控制完全同步你有没有过这样的经历：开车时想打开随机播放，按了车载方向盘上的随机按钮，手机上的音乐却毫无反应；或者在手机上开启了单曲重复，车载屏幕上却还是显示全部重复。这些看似简单的功能不同步问题，其实都源于AVRCP协议中一个非常重要但经常被忽略的部分——播放器应用设置。

【LE Audio】CAP精讲[9]：全流程操盘手，解锁CAP核心交互工序在前两篇内容里【LE Audio】CAP精讲[7]: 场景为王！Context Type音频协同场景识别全攻略，【LE Audio】CAP精讲[8]：CCID绑定术，打通音频流与控制的任督二脉，我们已经拆解了Context Type这个音频场景的身份证，也搞懂了CCID这个连接音频流与控制服务的唯一密钥。但在实际的LE Audio生态中，光有身份标识和关联密钥还不够——手机如何向耳机发起一次音乐播放？来电时音频流如何无缝切换？多设备协同听音乐时，策略如何同步？网络中断后设备又该如何优雅恢复？

【LE Audio】CAP精讲[8]：CCID绑定术，打通音频流与控制的任督二脉上一篇我们聊完了Context Type【LE Audio】CAP精讲[7]: 场景为王！Context Type音频协同场景识别全攻略，给音频流贴上了场景的身份证。但在实际的LE Audio使用中，光有场景标签还不够——当手机同时推送音乐流和导航流，耳机怎么知道按暂停键该停哪一个？当来电铃声响起，设备如何快速切换到通话控制逻辑？

【LE Audio】CAP精讲[4]: Acceptor合规指南，从程序到协同全流程落地在LE Audio的CAP生态中，Acceptor作为直接面向用户的音频终端（耳机、音箱、麦克风等），是所有协同逻辑的最终执行者。如果把CAP协同比作一场团队协作，Acceptor就是一线执行者，它的操作是否合规、能力是否达标，直接决定了用户能感受到的音频体验。而Acceptor角色要求的核心，就是给这个执行者制定了一份详细的合规操作手册——明确了必须掌握的核心操作、可灵活选择的拓展操作、有前提条件的条件性操作，以及额外的配置要求，确保它能和Initiator、Commander精准配合，不出现能力不匹配

【AVRCP】规范精讲[10]：链路管理器LM互操作规则与场景落地在蓝牙音视频远程控制的完整协议栈里，链路管理器LM是衔接底层基带与上层L2CAP的核心枢纽，负责物理链路的创建、资源调度、功耗管理与链路类型管控。很多开发者会把重心放在L2CAP通道、AVCTP指令这些上层逻辑，却很少关注LM层的互操作约束——而AVRCP对LM的要求看似极简，却是保证控制链路稳定、避免协议冲突的关键前提。

【AVRCP】规范精讲[7]: 打通AVCTP互操作底层，吃透事务标签与分片规则在蓝牙音频/视频控制的整套链路里，AVRCP负责定义我们能用到的播放、暂停、切歌、媒体浏览等控制逻辑，而这些指令真正能在设备之间稳定跑通，全靠下层的AVCTP（Audio/Video Control Transport Protocol）托底。可以说，AVCTP就是AVRCP的传令通道，通道的指令匹配、传输分片、身份标识规则，直接决定两台蓝牙设备能不能正常互通、指令会不会乱序丢包。

我是有底线的