Loxinity 里纯语音和带画面的互动，通常不是一套标准：语音把“说完到听见回应”的等待放在第一位，对带宽相对宽容；视频同时吃上行带宽、编码和解码渲染。同一台设备上语音勉强能用、一开视频就崩，往往不是“网络整体不行”，而是视频侧某一环先到瓶颈。可行的做法是先把延迟容忍度拆成语音刻度和视频刻度，用同一段对话分别跑，再决定调画质、换网络，还是只保留语音场景。

把语音和视频当两条独立链路测：语音只记“说完到听见回应”的等待范围，连续五轮取区间；视频在同样流程上加记采集、上传、渲染三个时间点。画面变糊与声音断续同时出现，多半先怀疑带宽；只有画面卡而声音正常，先看设备解码与渲染。降分辨率与帧率后卡顿消失的最低档位，就是这条链路的可用边界，边界之外退到语音场景。所有判断只在本次设备与网络条件下成立。

先只开语音走一轮，记录能接受的最长等待时间

语音场景先关掉摄像头，只保留麦克风和扬声器，跑一段自己熟悉的对话脚本，包含一次长句、一次打断和一次对方追问。等待时间的估算方式可以很朴素：记下“自己说完最后一个字”的时间点，再记下“听到对方开始回应”的时间点，两者之差就是这一轮的等待时间。用手机秒表、系统日志时间戳或页面上的调试时间都可以，关键是同一种记法贯穿五轮，不要中途换算法。

连续五轮记录后，不取平均值，取范围：最短一轮和最长一轮分别是多少，中间三轮大致落在哪一段。超过自己刻度的轮次，要补一句主观表现描述，例如“结尾两个字被吃掉”“对方开始说话时我还在等”“出现重复确认”。这些描述比一个孤立的毫秒数更能帮助判断下一次是网络波动还是设备负载。记录模板可以先用下面的字段，替换成你自己的列名即可：

round,start_speak,end_speak,first_response,wait_ms,note
1,10:02:03.1,10:02:05.4,10:02:06.9,1500,结尾被截断
2,10:02:20.0,10:02:22.3,10:02:23.6,1300,正常
...

语音侧建议同时观察的指标清单：说完到回应的等待、声音是否连续、是否出现重复或吞字、麦克风采集是否被系统降噪打断、设备 CPU 占用是否在对话中持续偏高。这些项目都能通过日志、系统监视器或直接听感确认，不需要额外仪器。

再开视频走同一轮对话，对比差异出现在哪一步

打开视频后不要换对话脚本，仍用同一段话、同一顺序、同一时长。把差异拆成三个记录点：采集，摄像头与麦克风启动到本地预览出现首帧；上传，首帧发出到对端确认收到；渲染，对端收到首帧到画面稳定显示。每一步都记开始与结束时间，并在备注里写清楚当时画面是清晰、变糊还是冻结。两步对比的记录字段可以简化为下面这张表：

判断顺序建议是：先看画面变糊与声音断续是否同时出现。同时出现，优先怀疑上行带宽或拥塞；只有画面变糊而声音连续，优先看设备解码与渲染；只有声音断续而画面正常，回到麦克风采集或上行音频链路。再看差异是否总出现在固定位置，例如每次切换摄像头、每次共享屏幕、每次说到长句时。固定位置重复出现，说明问题跟某个操作或某个资源峰值绑定，而不是随机网络抖动。

调整画面分辨率与帧率，看卡顿是否随之变化

逐档调整时一次只改一个变量。先把帧率固定在当前值，分辨率从高到低一档一档降，每档至少跑一轮完整对话，包含长句、打断和一次画面变化，不要只看预览几秒就下结论。分辨率降到最低仍有卡顿，再把分辨率固定回中间档，逐档降帧率。每档记录：分辨率、帧率、卡顿是否出现、上行占用大致变化、设备 CPU 与 GPU 占用、主观听感。

如果降档后上行占用明显下降、卡顿也随之消失，瓶颈更可能在带宽一侧；如果占用变化不大而卡顿照旧，优先查设备解码与渲染能力。卡顿消失的临界档位这样记录：写清楚“在哪一档分辨率与帧率下，连续一轮对话没有出现画面冻结或声音断续”，并注明这一档的上行占用和 CPU 占用。临界档位不是永久结论，换网络或换设备后需要重新确认。

换 Wi-Fi 与有线各测一次同一段流程

把网络条件作为独立变量分离出来：同一台设备、同一段对话脚本、同一时段、同一分辨率与帧率、关闭相同的后台程序，分别走一次 Wi-Fi 和一次有线。两次测试需要保持一致的项列成清单，逐项打勾，避免一次换了网络又顺手改了画质。数据量变化的观察方式很直接：在每段对话前后读取接口计数，比较接收与发送字节的增量；Linux 下可以读取 /proc/net/dev，手机则看系统流量统计。这个增量只用来判断“这段流程大致传了多少”，不追求精确值。

cat /proc/net/dev
# 对话前后各读一次，记录接收与发送字节差

结论要限定在本次测试条件下：写“本次 Wi-Fi 环境下，该分辨率与帧率出现卡顿；同一设备切有线后同一段流程未出现”，不要写成“Wi-Fi 一定不行”。如果两次差别很小，说明瓶颈可能不在接入方式，而在设备编码、解码或平台侧的媒体处理，需要回到上一节的档位对比继续排查。

把结果写成一条取舍：什么场景留视频、什么场景退到语音

最后把测试结果整理成一条可以直接执行的取舍，而不是一堆零散数字。判定条件建议用三项：语音等待是否在自己的刻度内、视频在临界档位下是否还能辨认关键信息、卡顿是否影响听清对方说话。三项都过，留视频；只有前两项过、第三项不稳，降到临界档位再试；前两项有一项不过，直接退语音，并用文字或截图补充信息。

触发降级的具体信号要写成可观察的动作：同一轮对话里画面冻结两次以上、对方反馈听不清、等待超过自己设定的语音刻度、切换摄像头后卡顿固定出现。出现任一信号就执行降级，不要等到整段对话崩掉。降级后需要复测的项目包括：五轮语音等待范围、声音是否连续、关键信息是否还能通过文字或截图传达，以及下次恢复视频需要满足的网络与档位条件。把这些条件记在同一页记录里，下次遇到同一台设备就不用从头再猜。