从使用问题出发，把声音进出的整条链路讲清楚。

01 / 使用场景：先明确会遇到什么问题

下表汇总典型使用场景、公开资料描述的常见机制和通用链路分析。公开机制用于解释问题，不代表这些场景都已在某个产品上复现。

02 / 整体设计：完整链路与模块职责

声音经过“设备输入端 → 输入池 → 功能处理 → 输出池 → 设备输出端”。应用调度器安排内部任务；系统音频协调把平台的允许、让位与中断结果交回调度器，两者共同决定链路何时能运行。

输入和输出可以独立工作，录音不必有播放，提示音也不必有收音。其它应用的音乐不进入本应用的池，它通过系统音频和实际播放设备与本应用声音共存。内部请求获准后，还需满足该路线所需的系统与设备条件。

各模块负责什么，怎样相互配合？

一次播放怎样从请求走到真正出声？

1. 功能提出请求：说明要播什么、目的地在哪里，以及需要与音乐共存、压低还是互斥。
2. 应用调度器检查内部冲突：确认当前任务和路线，给请求分配有效身份，再交给系统音频协调检查该路线所需条件。
3. 系统音频协调返回结果：可以开始、需要等待，或无法取得资格。应用不能只因为输出池已有声音就直接开播；等待仍需容量和时间上限。
4. 输出执行器按规则播放：手机和外接路线分别按第 04 章的预填与交接条件运行，系统或设备负责其支持的混音与压低。
5. 运行中接收变化：系统中断、路线变化或设备通话状态交回调度器，再暂停喂声、处理积压或结束；恢复须重查用户意图与任务有效性。
6. 结束时释放影响：清理属于本次请求的声音；相关系统资源和设备压低状态仅在最后一个依赖它们的任务结束后撤销。

这里的“系统条件”按路线判断：普通系统播放与自定义外接语音的数据路径不同，但后者也不能无视采集权限、系统中断或设备通话。平台机制和音乐共存场景在第 06 章展开；音频缓冲与设备输出的细节仍在第 03、04 章。

03 / 输入缓冲：声音存在哪里，多个功能怎样各自读取？

要解决的问题：同一段声音可能同时用于唤醒、录音和对话，但它们需要的起点、读取长度与处理速度不同；对话建连还会耽搁一段时间。既要允许各自读取，又要限制内存，不能让最慢的功能拖住收音或无限留住旧声音。

本方案选择：每个音源有一块共享短实时区，只保存最近一小段声音；每个功能有自己的读取位置。需要完整保留的问题开头和录音内容，及时进入各自有容量限制的保留区或存储队列。先用有界复制把关系讲清楚，测到复制成本明显后，再考虑更复杂的共享引用。

短实时区是什么？就是“只保存最近 N 秒”的滚动窗口

例如暂定保留最近 2 秒：新声音不断写入，窗口也向后移动；超过窗口的旧声音会退出。可以用一块固定容量的循环内存实现，写到末尾后从头复用空间。物理内存位置可以循环，声音的编号仍连续递增，这样能判断某个读取者要的声音是否还在。

“短实时”说的是保留范围短，供当前运行的功能及时使用，不代表声音只允许读一次，也不代表每个功能要先等满 N 秒。2 秒只是解释用的示例；实际长度要覆盖唤醒所需回看与正常读取延误，并满足内存预算。它也不等同于接收端为平滑无线抖动设置的播放缓冲。

多个读取位置是什么？每个功能各有一张“读到哪里”的书签

共享的是声音内容，独立的是读取进度。假设池内保留 400–1100 毫秒的声音：对话还要从 600 毫秒补发，录音转存已经读到 900 毫秒，唤醒检测已读到 1000 毫秒。三个功能可以分别读取自己需要的内容，一个位置前进不会改变另外两个。

为什么不共用一个读取位置？

收益是同一声音可复用、不同进度不绑定、不同读取长度能共存。代价是必须管理读取有效范围、缺口与超限。它本身不保证无锁、不阻塞或永不丢音；只有一个顺序消费者时，一条简单队列通常足够。

为什么还要单独的保留区？公共窗口不能等所有慢功能

本方案不让一个过期读取位置阻止公共窗口前进。需要长保留的内容应在有效窗口内转存出去。若改成直接引用公共片段，必须另加引用释放与总内存预算；不能一面说“窗口固定”，一面又让慢读取者无限固定旧片段。

写入和读取怎样交接？

1. 写入：接收适配器按采样位置追加完整片段，再发布新的写入位置；收音回调不等待磁盘、网络或业务处理。
2. 读取：检查音源、连续段、起点和长度；整个范围仍在池中才交出声音，成功交接后仅推进该功能的位置。
3. 还没收到：保留读取位置，等待后续数据或按实时接口约定返回暂缺；不阻塞设备收音。
4. 已经过期或中间缺音：明确返回缺口；唤醒可重置窗口，实时对话按场景决定重试，完整录音标记缺失。
5. 并发保护：检查范围和取得片段需要一致快照，避免检查后又被覆盖；大范围复制、解码和磁盘写入不放在设备回调或长时间公共锁内。

具体 case：唤醒后紧接问题，连接要等一会儿

1. 待机时短实时区持续滚动保存，唤醒检测按自己的进度读取。
2. 检测到唤醒后，根据声音中的准确位置确定问题起点，校验这段仍在公共窗口内。
3. 在同一个有序交接点登记本次保留区，记录当时的写入边界：保存“问题起点到该边界”的快照，边界之后的新声音按序进入本次保留区。两段用同一采样位置衔接，既不漏也不重。
4. 连接等待期间，本次保留区继续保存；录音转存与唤醒检测仍各自读取，公共短实时区照常滚动。
5. 连接就绪且允许上传，从本次保留区的问题起点发送；在下游允许并能处理快于实时的输入时才按需追赶；追上后继续沿同一读取位置消费新声音，不另开一条容易重复的实时路径。
6. 取消、保留区到界或连续性断裂时，结束本次保留并释放资源；其它功能的读取位置不受影响。

实际实现需保证“取得历史快照”和“开始接收后续声音”的边界一致；可以用有序事件处理或短时间状态同步完成。若复制尚未完成，快照片段必须暂时有效且有明确空间上限，不能任其被滚动窗口覆盖。

输入缓冲让什么变平稳，又不能保证什么？

设备按实际到达写入；需要固定长度的识别接口从池中重组所需长度，需要固定节奏的接口再按其节奏交付。录音与离线处理不必为了“平滑”强行匀速或等待预填。缓冲吸收有限的到达抖动和处理延误，但无法弥补长期处理能力不足，也不能恢复已经丢失的真实原声。

所以第 03 章的设计关系是：短实时区负责共享最近声音，独立读取位置负责各功能进度，专用保留区负责不能丢的长内容，容量与缺口规则负责让慢功能不拖垮整条输入链。

04 / 输出缓冲：回复存在哪里，怎样接成连续播放？

要解决的问题：回复可能成批产生，多个功能可能同时要求播音；手机和外接设备却需要按各自的播放时钟持续取数。必须明确声音先放哪里、谁安排先后、何时开始播，以及没播出的内容怎样结束或清理。

本方案选择：各回复先独立排队，输出执行器按调度规则选择或混音，再为每个目的地形成一条待播序列。手机按播放回调取数；外接设备经过有界发送队列与设备内部缓冲，最终由设备时钟播放。每条队列都有自己的进度与上限，整条路线另算总积压。

先分清：压缩声音与采样声音不是同一种数据

采样声音是按时间排列的声音数值，可以直接用来调整音量、混音和按采样点取数；压缩声音是编码器打包后的内容，通常更省传输空间，需要先解码才能做这些处理。改变采样率、混音与重新压缩是不同操作。

本方案的基础路径不在目的地输出池混存两种形态。服务若已经交付采样声音，无须再解码；若走系统播放器或协议支持的压缩直通路线，可跳过应用解码与重编码，但该路线不能同时假设应用能任意修改或混合其中的声音。解码后短片段也要纳入内存预算，不把整条长回复一次性全部展开。

“输出池”具体存什么？

这里把目的地输出池定义为“已经按规则安排、准备交给某个设备的声音”。建议以可按采样点切分的声音片段存放，压缩与封包放在外接发送侧。若成熟播放器已经提供等价能力，可复用它，不必另造相同的池。

为什么输出不是所有功能共用一个读取位置？

输入通常是一份声音供多个功能分别看；输出则是多个功能争取有限的播放时间。同一个目的地需要明确安排后的播放序列，不能让各功能直接抢同一个播放器，也不能让设备随意从不同回复里各取一段。

同一回复若要送到手机和另一台设备，两条路线分别记录读取进度、格式和延迟；内容适合时可以共享底层存储，但不能共用一个消费位置。需要同步播放时还需共同时间基准与延迟补偿，这是额外设计。

声音到达时写入，设备需要时读取；先留出少量提前量，把短时到达间隔变化与连续播放隔开。图中的固定间隔表示同样时长的声音按顺序出声，不要求系统每次回调都恰好相隔 20 毫秒；回调要按实际要求填够采样点。

池中记录哪些位置，怎样知道还有多少声音？

对于固定格式的采样声音，待交出深度可由“写入位置 − 交出位置”换算；压缩包使用采样时间或包时长换算，不能直接用压缩字节数推断时长。

同一句暂停后继续，和取消后重来，怎样区分？

为了让恢复规则一致，分清三件事：回复编号认内容，播放编号认一次连续的播放任务，连接代次认这次发送所用的连接。播放任务可以包含暂停，暂停不自动变成新任务。

这里的编号不一定都存在于现有线上协议中。本机可以拒绝旧回调，但要让设备拒绝旧包，必须有协议身份、可确认的清空／停止，或干净的新连接边界。

写入、开播、取数和结束怎样配合？

1. 回复到达：校验播放编号、顺序与格式，放入对应回复队列；有界处理重复、缺口和迟到片段。
2. 安排输出：按规则决定排队、打断或混音；输出执行器转换为目的地格式并顺序写池。非必需的提示或背景声音缺席时，不阻止主声音前进。
3. 开始播放：按下节对应路线的预填条件开播；若回复已结束且全部声音比目标更短，也可直接播放，不等一个永远达不到的水位。
4. 持续读取：手机回调从池中取本次需要的采样点；外接发送执行器按传输能力和设备提前量取出并封包。回调不等网络、磁盘、收音或业务锁。
5. 短暂不足：按场景短时修补或补齐静音，实时回调及时返回并记录断供；可等待的完整播报则进入重新预填，避免反复开停。
6. 正常结束：回复结束后停止增加声音，继续消费有效尾音；确认各相关层排空或达到约定结束条件，再报告播放结束。
7. 主动打断：先禁止旧播放继续入池，再按下文“取消边界”处理未混合、已混合和设备已接管的内容；新播放需等旧发送安全退出，不直接拼在未知半包后面。

预填看哪个池？手机与外接路线分别判断

目标按层命名：应用池的目标是“还能交出多少声音”，设备缓冲的目标是“已经收到、还能播多久”。二者可以同时存在，但一起分配延迟预算，不能把一份“100 毫秒”要求在两边各等一遍。

设备若只报告可写额度，应用只能知道能否继续提交，不能据此知道实际预填。没有播放深度反馈时，优先依赖设备明确的自动开播合同或可查询状态；否则按测得的发送与消费情况保守估算，并保留误差与等待上限，不能声称已精确知道设备何时出声。

水位怎么用？容量上限不是开播门槛

具体 case：一次长回复分两批到达

下面只演示池深度变化：假设是手机直接播放，应用输出池的预填目标为 100 毫秒，实际播放保持正常速度；暂不计额外系统缓冲，所有数字都不是实测或通用默认值。这个表不能直接当作外接设备的开播判断。

两批之间并没有新声音持续到达，但第一批的剩余内容让播放不中断。真实系统还必须检查系统与设备的在途尾音；不能看到应用池为零就断定扬声器已经播完。

混音以后，能不能只取消其中一个声音？

不能把已经混成一段的声音，按原播放编号直接减掉一份。基础方案采用保守规则：混音前分别取消；混音后若涉及取消，则停止并清理受影响的目的地输出，不承诺其它声音无缝保留。需要不停其它声音、只移除一个声音时，必须另外支持保留原始片段并重建尚未提交的混音。

例如提示音与对话已经混好，取消对话时，基础方案可能连同这部分提示音一起停止。产品若要求提示音完整不间断，就需要更强的未提交区重混能力，或把提示音安排在独立可控的设备混音通道；这属于明确的能力升级。

应用池与设备缓冲怎样共同维持平滑？

外接路线要一起看：各回复等待量、应用输出池、发送在途量和设备待播量，避免每层都预留一大段。设备有可用空间不代表需要把应用全部积压一次倾倒过去；发送侧保持受控提前量，设备时钟最终决定出声。

短时到达抖动靠缓冲；有证据的细小时钟差异才靠小幅重采样或保音高伸缩；切换突变靠淡入淡出；短丢包可由成熟接收或解码模块修补。它们解决不同问题：长期平均供给不足仍需暂停、降负载或结束，不能靠无限扩容和重复旧声音解决。

完整回复排得很长，不等于时钟漂移

参考 Android 的回调与缓冲说明和 WebRTC 的接收缓冲与时间伸缩机制；具体水位、修补能力和状态反馈以实际音频组件与设备为准。

05 / 调度与播放冲突：多个功能同时使用设备怎么办？

问题：共用声音内容并不代表可以同时占用所有设备能力。多个功能各自开关收音、配置系统或向同一个发送器写数据，会相互覆盖；让全部工作串在一个调度器中，又会互相阻塞。

统一管理使用资格，实际处理分别执行

调度器记录每个请求的编号、所需音源、读取范围、输出位置、优先级和结束状态。它决定谁可以使用哪条路径；各功能与音频执行器按已发布规则运行。启停、打断和故障改变规则，声音片段不必逐个等待调度器审批。

跨应用的音乐、播客和电话不能只靠本章内部调度处理，详见下一章的系统与设备边界。语音增强机制参考 WebRTC 音频处理模块；具体播放参考的取得位置与延迟，需要结合实际输出路线验证。

06 / 系统音乐与其它应用：怎样共存，被打断后怎样恢复？

前面第 04 章管理的是本应用自己的声音。音乐播放器、播客、导航、电话与系统提示有自己的音频处理。本应用通常拿不到它们的原始声音，也不能靠调整自己的输出池决定它们是否暂停或降低音量。

本章场景来自近期讨论归纳和官方音频文档。以下是通用设计建议，不表示所有系统、第三方应用或外接设备已经具备同样能力。

先看声音经过哪里：不是所有音乐都进入我们的输出池

具体会遇到哪些问题？

整体设计中的“系统音频协调”怎样工作？

内部调度决定“哪条回复可以播”；系统音频协调负责“此刻系统是否允许、以什么方式播”。播放器若已代管这部分规则，就复用它，避免两套逻辑反复申请和释放。

Android 和 iOS 怎样对应到这套通用规则？

Android：Audio Focus（系统协调多个应用播放优先级的机制）决定让位关系；临时压低与暂停并不等价，人声内容也未必被自动压低。目标版本为 Android 15／API 35 及以上时，请求资格还受前台应用或前台服务条件约束。申请结果、延迟获准和失去资格都应进入同一播放状态管理。见 Android 官方音频焦点说明。

iOS：AVAudioSession（本应用向系统声明音频用途及共存方式的配置）会影响混音、压低和中断。duckOthers（暂时降低其它音频会话音量）与会话激活时段相关，并非“本应用此刻有声音”就自动精确启停；Apple 建议短暂使用，不应不加判断地贯穿整通长对话。若持续收音，反复停用同一个会话也可能影响输入，需按实际能力设计。见 Apple 的暂时压低说明。

Apple 还提供对其它人声节目的临时中断选项，导航提示是其典型用例，但是否适用取决于音频用途与对方会话配置；中断事件及恢复建议须按部署系统版本处理。通用原则仍是“允许恢复”加上用户与任务检查，而不是收到结束通知就必然续播。见 人声节目共存选项、音频中断处理。本文不规定一组跨版本通用的 API 参数。

手机和设备都能压低音乐时，怎样避免重复控制？

例如：其它应用音乐 → 手机系统 → 蓝牙音乐通道 → 外接设备扬声器；本应用回复通过专用数据通道在设备混入。音乐是同一份，手机系统与设备只是两个控制位置。先选择负责衰减的主要位置，记录它属于哪次有效使用；切路线时先撤销旧位置的影响，再按新路线生效。

建议的产品基线是：短播报尽量短暂让位，电话等强中断优先，长对话的音乐策略单独确认。设备端若根据语音能量压低音乐，应验证停声确认和渐变；手机若仍被系统或音频组件额外压低，要定位并协调实际生效处。不能为了避免双重衰减，就一律跳过系统权限或中断处理。

具体 case：音乐中播一条回复，期间来了电话

1. 先确认音乐从哪里来、回复在哪里混入，确定本次由系统还是设备负责压低。
2. 取得所需资格后播放回复；音乐继续、降低或暂停，应符合该路线支持的策略。
3. 收到实际强中断信号，立即停止本应用继续喂声，并处理设备尚未播出的部分；记录用户意图与可确认的续播位置，限制暂存。
4. 电话结束只提供恢复机会：若用户已取消、选择别的内容或旧回复已失效，就结束本次任务。
5. 确需续播时重新确认资格与路线，按编号规则和缓冲条件恢复；最后释放本次申请，由系统与音乐应用决定音乐怎样继续。

怎样验证共存，而不是只验证“本应用有声音”？

至少组合测试：音乐与人声节目、手机与外接输出、短提示与长对话、前台与后台、电话打断与用户主动取消。分别观察两边声音是否可懂、是否重复衰减、停声间隔是否抽动、退出后是否仍压低音乐，以及中断后是否错误自动续播。标明系统与设备版本；某个通知入口存在不等于所有第三方通话或闹钟都已实测。

场景来源：近期对话归纳中的重复衰减、停声恢复与中断覆盖问题，以及上面链接的 Android／Apple 官方文档，检索于 2026-11-04。工程个别实现不直接转为通用要求，本章没有新增本地工程链接。

07 / 传输与故障恢复：断开、拥塞和设备变化后怎样继续？

具体 case：蓝牙拥塞后，新旧播放怎样隔离？

怎样判断“确实在播放”？

分别记录：① 应用已排队；② 本机系统已接受数据；③ 设备已收到；④ 设备已播放。前一项不能证明后一项。设备若只提供“会话已启动”，也不能据此判断每一段声音都正常出声。

条件允许时，设备报告最近收到与播放的位置、剩余声音时长、播放断供次数；发送端据此调节节奏。短缺时的声音修补可以参考成熟实时语音实现，不能承诺还原丢失内容。设备反馈不够时，用实际录音和参考声音对齐验证。

换设备后，为什么需要重新检查格式？

耳机插拔或输入输出路线改变后，重新读取实际采样率、声道、缓冲时长与延迟；需要时重建格式转换器，清理旧格式残留，并重新预填。是否改用扬声器和是否自动恢复，按用户意图处理，不能只恢复之前的配置。参考 Apple 路由变化说明。

不同蓝牙承载，怎样保留同一套上层规则？

自定义 BLE GATT 传声音，需要应用处理分片、重组和发送流量控制；标准 LE Audio 使用专门的等时传输机制，需要两端共同支持。其它串行或配件通道也可承载压缩声音。方案应把这些差异放在传输适配层，上层统一使用启动、发送、停止、排队情况和失败反馈等接口。

08 / 缓冲预算：需要多少空间，能接受多少延迟？

问题：每层各留一段声音，叠加后可能产生过大延迟；只看容量又无法判断实际积压。输入与输出应分别计账，再计算端到端总预算。

统一四个口径：容量上限以字节计算；待处理声音深度以毫秒计算；包的年龄从约定的起点连续计时；故障超时是控制等待期限。换队列不应把同一声音的年龄清零。

示例一：空间预算

假设声音为每秒 16,000 个采样点、单声道、每点 16 位，则每秒占 32,000 字节。2 秒约 64 KB，200 毫秒约 6.4 KB，320 毫秒约 10.24 KB。若允许保留 120 秒，则仅声音本身约占 3.84 MB。这些是计算示例，不是所有产品的默认值。

每条路径的总内存还要加上格式转换、副本、索引、压缩缓存与音频服务自身的占用。多个读取者共享同一份声音时，只算一次声音内容，但各自的独立保留区仍要计入。

示例二：延迟预算

示例：从回复声音可用到外接设备出声，20 + 40 + 40 + 80 + 20 = 200 毫秒。这是待验证的预算分配，未含云端生成与网络内部缓冲；实际各段可能重叠，应统一测量起止点，避免重复计算。各段“95% 情况下的延迟”相加，也不等于整条路径的同一指标。

示例三：输入积压多久才能追上实时？

假设已经积压 3 秒，新的声音仍以正常速度进入；发送速度始终是正常的 1.6 倍，则理想情况下追赶需要 3 ÷ (1.6 − 1) = 5 秒。这说明“连上了”与“已经跟上实时”是两个状态。前提是语音服务允许并能处理快于实时的输入。网络带宽足够本身不代表接口允许加速；若接口只按实时速度接收，新声音又持续进入，就不能仅靠补发追上。此时需选择有界等待、暂缓接收新输入，或到界后终止并提示，不能擅自丢掉问题开头。倍率是理论演算，不是下游能力承诺。

蓝牙带宽要留出额外空间

假设压缩码率为 24 kbps，每包装 20 毫秒声音，声音数据约 60 字节；再假设自定义包头为 7 字节，则应用层约需 26.8 kbps。还必须加上分片、蓝牙传输开销、重传与其它并行业务。这里的格式和数值仅用于演算，应以实际协议和并发测量替换。

09 / 遇到的问题与一句话解决方案

用下面这张表快速找到处理方向；具体机制、条件与代价见前面的对应章节。