Grok Voice 3.0 语音对话卡顿，先分清是上行采集还是下行播放

Grok Voice 3.0 语音对话卡顿，可以拆成三段来看：麦克风与系统的上行采集、上下行的网络传输、扬声器或耳机的下行播放。先把这三段分开，再谈参数调整，能少走很多弯路。建议的判断顺序是：先用系统录音工具录一段本地原始上行音频，确认采集端是否干净；再关掉回声消除与自动增益复测；然后用网络工具分别看上行与下行的丢包和抖动；最后换播放设备交叉验证。下面每一步都给出可执行的命令或界面路径，跑完就能收敛到一个可复现的结论。

如果本地录音回放就已经断续、吞字，问题基本在采集端：设备、驱动、采样率或回声消除与自动增益；本地录音干净、但对话里自己说话被吞，优先怀疑上行丢包与抖动；只有对方声音断续而本地一切正常，才去查下行抖动和播放设备。每一步都要固定麦克风距离、音量和网络环境，否则前后对比没有意义。蓝牙链路的延迟与断续通常无法靠软件消除，这属于设备侧边界。

用系统录音工具录一段自己的上行音频

这一步的目的是把「模型听不清」和「麦克风没采到」区分开。录音不要通过浏览器，而是直接走系统音频接口，得到的就是未经对话链路处理的原始上行音。

Windows：先看默认输入设备，路径是「设置 > 系统 > 声音 > 输入」，确认「选择用于讲话或录制的设备」；命令行用 ffmpeg 列设备并录十秒：

ffmpeg -list_devices true -f dshow -i dummy
ffmpeg -f dshow -i audio="麦克风阵列 (Realtek(R) Audio)" -t 10 -ac 1 -ar 48000 up_win.wav

macOS：可以用「系统设置 > 声音 > 输入」确认设备，也可以命令行查看并录制，或者用 QuickTime「新建音频录制」录十秒。

system_profiler SPAudioDataType | head -60
ffmpeg -f avfoundation -list_devices true -i ""
ffmpeg -f avfoundation -i ":0" -t 10 -ac 1 -ar 48000 up_mac.wav

Linux：

pactl list sources short
arecord -l
arecord -D plughw:1,0 -f S16_LE -r 48000 -c 1 -d 10 up_linux.wav
aplay up_linux.wav

录制内容要和对话里说的话尽量一致：同一句话、相近语速和音量，录十秒，然后用播放器回放，和对话中「自己声音被吞」的听感逐句对照。判断标准很简单：本地回放也吞字、也有周期性断点或爆音，就先别怀疑网络；本地回放干净，说明采集端至少能拿到完整音频，问题更可能在网络或播放侧。

关掉回声消除与自动增益再试一次

回声消除（AEC）、自动增益（AGC）和降噪（NS）本来是为了通话体验，但它们在安静环境下可能把轻声或句首当成噪声切掉，听感上就像「被吞字」。这一步用来区分：是前处理误判，还是链路本身不行。

浏览器侧：Chrome、Edge 打开 chrome://settings/content/microphone 确认当前使用的输入设备；真正生效的音频处理参数不是设置页能改的，要看 chrome://webrtc-internals 里对应音频流的 track settings 与 constraints。如果页面本身提供了「降噪」「自动增益」「回声消除」开关，先全部关掉复测。自建或接入 WebRTC 时，可以参考这个采集骨架：

navigator.mediaDevices.getUserMedia({
  audio: {
    echoCancellation: false,
    noiseSuppression: false,
    autoGainControl: false,
    channelCount: 1
  }
})

系统侧：Windows 在「声音 > 录制 > 属性」里看「级别」和「高级」，关掉麦克风加强和音频增强，采样率先固定为 48000 Hz；macOS 在「系统设置 > 声音 > 输入」里查看设备是否带环境降噪或自动输入音量。蓝牙耳机自带一套 DSP，系统里通常关不掉，这属于设备限制。

两次对比要控制变量：麦克风离嘴的距离保持一致（建议一臂以内）、说话音量保持一致、说同一句话。关掉后断续消失，基本可判定是前处理过强；关掉后依旧断续，就往下一节的网络分段查。

分别测量上行与下行的网络表现

先按现象分方向：自己说话被吞、对方反馈听不全，先查上行；对方声音断续、延迟忽大忽小，先查下行。两端都要测，因为同一段链路的上传和下载路径不一定对称。

ping -c 30 服务端地址或域名
mtr -rwzc 60 服务端地址或域名

Windows 对应 ping -n 30 目标、pathping 目标，或使用 WinMTR 图形界面。看结果时要盯丢包和抖动的分布，不是只看平均值：丢包是否集中在某一跳、抖动在大包或特定时间段是否突然放大，这比平均延迟更能解释断续。

浏览器侧：F12 的 Network 面板只能看到信令和接口请求，媒体质量要看 chrome://webrtc-internals。上行看 outbound-rtp 的 packetsSent、retransmittedPacketsSent、packetsLost、jitter；下行看 inbound-rtp 的 packetsReceived、packetsLost、fractionLost、jitter。分别截取同一时间段的数值，才能判断卡顿落在哪一侧。

换设备对比的方法：在同一个网络下，用另一台电脑接同一根网线，或让手机分别走同一 Wi-Fi 和蜂窝网络，重复上面的测量。如果换设备后丢包路径一致，问题更可能在路由器或出口；如果只有某台设备出问题，优先怀疑该设备的网卡、驱动或省电策略。

换播放设备交叉验证

播放侧的问题容易被误判成网络问题。用同一段对话、同一网络环境，依次换成有线耳机、蓝牙耳机、内置扬声器，记录哪种组合下断续消失。

有线耳机（3.5mm 或 USB）：链路最短，通常也是判断基准。只有它在时断续消失，说明原播放链路或系统音效处理有问题。
蓝牙耳机：编码加缓冲本身就会带来延迟，射频干扰或编解码协商也会造成断续。这类延迟和断续通常无法通过软件消除，只能换连接方式或换设备。
内置扬声器：受系统音效、采样率转换和麦克风拾音回授影响，也可能让听感更差。

记录时写清楚三项：输出设备名称与连接方式、断续是否消失、延迟是否可感知。如果三种输出下限一出现、另外两种正常，结论就落在播放设备，而不是模型或网络。

把结论写成可复现的最小案例

排查到最后，把过程整理成一份可复现的模板，方便自己复查，也方便交给他人复现。只写能观察到的现象和能验证的配置，不要写未验证的猜测。

设备型号：
系统版本：
输入设备（型号 + 有线/蓝牙/USB）：
输出设备（型号 + 有线/蓝牙/内置）：
客户端与版本：
网络环境（有线/Wi-Fi/蜂窝，可注明路由器型号）：
AEC/AGC/降噪开关状态：
采样率与声道设置：
复现步骤：
  1.
  2.
  3.
听感描述（自己说话/对方说话，说明断续是连续还是间歇）：
本地原始录音回放结论：
上行观察（丢包、抖动表现）：
下行观察（丢包、抖动表现）：
交叉验证结果（哪种输出组合下断续消失）：

填完这份模板，基本能回答最初的问题：卡顿落在采集、网络还是播放。如果同一组合反复复现，就把这份记录原样带上，别人不必再从头问一遍环境。