数字人讲解PPT时，最常见的一类故障是这样的：运行一段时间后，声音开始断续，数字人停在某一帧不动，过几秒又恢复，整个过程反复发生。有意思的是，PPT页面切换一切正常。很多人因此把问题归到渲染引擎或GPU算力上，结果查了半天，利用率没跑满，日志也没有明显报错。但问题依旧。
PPT正常翻页，只能说明控制通道还活着，不能证明音视频链路健康。要定位这类问题，先要把系统拆开看。
数字人讲PPT的业务流程通常是这样：读取当前页备注，把备注拆成多个文本片段，TTS将文本生成语音，唇形模型根据音频生成数字人口型，音频和数字人视频通过WebRTC播放，PPT页面和字幕通过控制消息切换。这中间其实有三条彼此独立的链路：TTS到音频RTP到浏览器扬声器；唇形推理到H264视频RTP到数字人画面；页面和字幕控制消息走DataChannel。三条链路共享一些进程资源，但传输和消费路径完全不同。
所以会出现一些看似矛盾的组合。PPT正常，声音和人物都卡，通常是WebRTC链路拥塞或服务端公共线程阻塞。PPT正常，声音继续但人物停画，往往是H264丢包、解码等待关键帧或视频发送拥塞。PPT正常，人物继续但声音爆音，多半是音频队列丢了PCM帧或者音频RTP丢包。三者同时停止，才更可能指向主事件循环、进程、GPU或业务状态机异常。如果一开始不区分通道，后面的监控和排查很容易跑偏。
整条链路里，最容易出问题的位置有四个。
第一个是TTS的突发输出。PPT备注是一整段长文本。即便TTS接口名义上支持流式返回，实际表现也可能前一段时间没有音频，短时间内突然返回远大于实时播放时长的音频数据。几秒钟的语音可能在几百毫秒内集中进入下游。如果直接写入一个很小的实时播放队列，队列会迅速溢出。对连续PCM音频来说，简单丢帧会形成可听见的缺口。一次丢失可能只有十几或几十毫秒，但连续发生后就会表现为爆音、断字和卡顿。
第二个是音频背压阻塞视频生产。一种常见实现是同一个渲染线程完成视频合成、音频入队、视频入队和录制。如果音频队列满后采用阻塞等待，共享渲染线程就会停下来等队列空间。音频不能丢是对的，但把背压施加在共享渲染线程上，等于把局部拥塞扩大成音视频同时停顿。人物画面冻结，不是因为推理停了，而是渲染线程被音频队列卡住了。
第三个是生产帧率与发送帧率存在微小偏差。服务端推理可能稳定在约25 FPS，而真实WebRTC发送或浏览器消费只有24.x FPS。二者看似非常接近，但缓冲会持续累积。每秒多生产一点，几十秒后队列就逐步灌满，延迟从几百毫秒增长到数秒。判断队列是否健康，不能只看有没有溢出，还要观察队列长度是否长期单调增长。
第四个是TURN链路丢包导致H264停在上一帧。WebRTC需要经TURN中继时，可用带宽和网络质量通常明显低于直连。音频编码容错能力较强，少量丢包时仍可能继续播放；H264视频一旦丢失关键参考数据，浏览器就可能停在上一帧，直到收到新的可解码关键帧。于是出现最容易误判的现象：声音继续但不够流畅，数字人停在一帧，PPT正常翻页，过一会儿数字人恢复。服务端可能仍在稳定推理和发送视频，问题发生在编码、传输或浏览器解码阶段。
排查时不能只盯CPU和GPU。CPU、GPU和内存没有跑满，只能说明系统没有明显算力耗尽，不能证明实时媒体链路健康。需要同时采集三类指标。生产侧：TTS首包时间、每段音频时长与生成耗时、唇形推理FPS、音视频中间队列长度、待发送媒体时长。WebRTC发送侧：音频和视频实际发送包数、实际发送码率、RTT、抖动、累计丢包和区间丢包率、浏览器请求关键帧的频率。消费侧：浏览器实际解码FPS、丢弃帧数量、jitter buffer延迟、当前连接使用直连/STUN/TURN、视频是否在等待关键帧。这些日志只要使用同一时间基准，就能建立时间线：TTS开始、首包、推理、AV入队、RTP发送、浏览器解码、PPT切换。停顿发生在哪一段，一目了然。
优化方案上，有几个常见的误区。
仅扩大队列只能缓解，不能根治。扩大队列可以吸收短时突发，但无法解决长期生产速率高于消费速率的问题。队列过大还会带来副作用：端到端延迟持续增加，PPT和字幕可能早于声音，浏览器一直在播放数秒前的旧画面，断线重连时需要清理更多历史帧。实时讲解场景更适合数百毫秒级缓冲，而不是堆积数秒媒体数据。具体数值应通过压测确定。
音频队列满时丢帧不可取。连续音频不能使用普通消息队列的drop_oldest思路。删除任意PCM片段都会改变声音的连续性。更合理的原则是：音频不主动丢样本，短时突发进入有界缓冲，持续拥塞向上游传播背压，必要时暂停生成下一段TTS，而不是无限堆积。
音频和视频完全分线程仍可能不同步。将音频发送移到独立线程，可以防止音频队列阻塞视频渲染，但如果视频继续无条件前进，就会变成视频继续推进、音频因背压逐渐落后、字幕和PPT已切到后面。正确的解耦不是各发各的，而是推理与发送线程解耦，但音频和视频仍以同一个媒体时钟、同一组时间单元推进。
频繁生成H264关键帧恢复快，但可能放大拥塞。缩短关键帧间隔能减少视频丢包后的最长恢复时间，但关键帧体积远大于普通预测帧。如果链路已经接近带宽上限，关键帧过密会制造码率尖峰，导致更多丢包。正确做法是同时考虑分辨率、平均码率上限、码率缓冲窗口、GOP间隔和TURN链路真实可用带宽。关键帧不是越多越好。
更合理的架构是：有界AV单元加音频主时钟。
一个视频帧通常对应固定数量的音频小帧。在常见配置下，约40ms的媒体可以组成一个逻辑AV单元，包含若干音频片段、一个视频帧和字幕/PPT同步标记。这些数据由一个带上限的队列按FIFO顺序推进。调度逻辑大致是：取出一个单元，等待音频轨道有空间后发送音频，等待视频轨道有空间后发送视频，然后发布同步事件。四条约束必须满足：推理线程不直接等待网络发送；音频和视频不能长期独立前进；媒体队列必须有上限；队列满后限制上游，而不是丢音频。
为什么以音频作为主时钟？讲解场景中，用户对声音缺字和断续非常敏感；视频偶尔保持上一帧，感知通常弱于音频缺失。因此适合以音频播放进度作为演讲时间线：PPT翻页绑定相应音频片段开始播放，字幕切换绑定音频时间戳，视频只允许在一个很小的容差范围内领先或落后，超过容差后视频等待或跳到当前音频时刻对应的画面。
切换页面和中断时必须有代际概念。暂停、重新开始、切换文档或用户插话时，旧音频和旧视频可能仍散落在多个队列里。可为每次播放分配一个递增的generation。调度时检查媒体单元的generation与当前generation是否一致，不一致则作为失效数据丢弃。注意，这里丢弃的是已经失效的整组历史媒体，不是在正常播放中随意删除音频样本。
TTS多片段推进需要遵循“生成可并行、播放必须有序”。文本片段可以提前生成，但必须按页码和片段序号进入播放时间线。每个片段携带页码、片段序号和generation。TTS可有限度预生成下一片段；播放严格按序；待播放时长超过阈值后暂停继续生成；当前页音频真正开始播放时再发送对应PPT和字幕事件；中断后整组清理旧generation数据。这样既能降低片段间的首包空隙，也不会让大量TTS音频瞬间灌满实时队列。
传输层治理的核心是不要让拥塞控制无限抬高码率。网络质量一般或必须使用TURN时，建议采用保守配置：视频长边控制在中等分辨率范围，根据实测链路设置视频码率硬上限，语音场景使用适合VOIP的较低音频码率，设置合理的关键帧间隔避免过密IDR，配置码率缓冲降低关键帧瞬时峰值，在丢包持续升高时主动降级分辨率或帧率。自适应思路可以很简单：连续多个统计窗口丢包率高，就降低视频码率和分辨率；网络稳定较长一段时间，再谨慎上调。不要只依赖平均RTT很低。RTT只有几十到一百多毫秒，只要丢包率高，H264依然可能频繁停画。
推荐的故障判定流程分五步。第一步确认业务进程是否还活着：检查进程、CPU/GPU、推理FPS和最近日志。如果推理FPS稳定，说明人物模型并没有停止工作。第二步观察AV队列趋势：队列为空说明上游产帧不足；队列持续满说明下游消费不足或发送受限；音频满视频空说明音视频输出节奏失衡；两者时长差持续增大说明正在发生音画漂移。第三步查看WebRTC发送统计：若服务端帧率正常但累计丢包快速增加，优先处理网络、码率和关键帧，而不是继续扩大队列。第四步对照PPT控制通道：PPT正常只说明控制消息仍到达，不能据此排除视频RTP故障。第五步分阶段压测：至少覆盖空闲数字人连续播放、单页长备注、多页自动连续讲解、TTS多片段突发、TURN中继、人为限制带宽和注入丢包、暂停继续重播和断线重连。
修复不能只靠“看起来不卡了”，需要设定可量化标准。音频连续性方面，正常播放期间不主动丢PCM帧。AV偏差方面，长时间运行不持续累积，保持在可感知阈值内。媒体积压方面，稳态保持在数百毫秒，而非增长到数秒。视频恢复方面，丢包后能在有限关键帧窗口内恢复。发送码率不超过实测链路的安全带宽。PPT同步方面，翻页和字幕跟随实际音频播放进度。长稳测试方面，连续运行数十分钟无周期性冻结。同时要分别验证“服务端已发送”和“浏览器已解码”，因为这两件事并不等价。
数字人讲PPT的卡顿通常不是单点故障，而是多个实时系统问题叠加：TTS突发生产、音频队列不允许丢帧、共享线程扩大背压影响、生产和消费帧率存在微小偏差、TURN链路带宽有限、H264丢包后依赖关键帧恢复、PPT控制与音视频媒体相互独立。最终有效的方法不是简单加大队列，而是建立完整闭环：有界缓冲吸收短时抖动，背压限制持续过载，音频主时钟保证同步，码率上限保护网络，关键帧负责有限时间恢复，端到端监控负责定位。当系统具备这套机制后，即使再次出现卡顿，也能快速判断究竟是TTS、推理、队列、编码、TURN还是浏览器解码问题，而不再依靠反复调参碰运气。
