这种慢动作效果大概率是解码参数和实际流不匹配，或者PCM输出的处理逻辑出错导致的，咱们一步步排查：

1. 别硬编码！先确认Opus流的实际参数 #

你创建解码器时直接写死了48000（采样率）和1（单声道），但闭源程序的Opus流可能用的是其他配置（比如24kHz采样率、双声道）。参数不匹配的话，解码出来的音频速率自然会错。

可以先用Opus的API从捕获的数据包里提取实际参数：

// 获取当前数据包的实际采样率和通道数
int actual_sample_rate = opus_packet_get_sample_rate(voicePacketBuffer, voicePacketLength);
int actual_channels = opus_packet_get_nb_channels(voicePacketBuffer, voicePacketLength);

// 用实际参数创建解码器
opusDecoder = opus_decoder_create(actual_sample_rate, actual_channels, &opusResult);

2. 修正opus_decode的帧大小参数 #

你调用opus_decode时传入的第5个参数是9600，这个参数是每通道的最大输出样本数，但Opus的标准帧时长对应的样本数远没有这么大（比如48kHz下，20ms帧对应960样本，40ms帧对应1920样本）。传太大的值可能导致解码器输出异常，或者你混淆了“总样本数”和“每通道样本数”。

改成符合Opus规范的最大帧大小，比如48kHz下用1920（对应40ms帧）：

// 每通道最大输出1920样本（48kHz下40ms帧）
opusResult = opus_decode(opusDecoder, voicePacketBuffer, voicePacketLength, pcm, 1920, 0);

另外注意：opus_decode的返回值是每通道解码出的样本数，所以保存PCM时的字节数要算对：

// 正确字节数 = 每通道样本数 × 通道数 × 2字节（16位PCM）
pcmFile.write(pcm, opusResult * actual_channels * sizeof(int16_t));

你之前的代码里opusResult * sizeof(opu...大概率没乘通道数，这会导致保存的PCM数据量不足，播放时自然变慢。

3. 验证PCM文件的格式 #

Opus解码器默认输出的是**16位有符号小端（s16le）**的PCM数据，如果保存时格式错误（比如用了32位、大端字节序），播放软件会错误解析，出现慢动作。

可以用音频工具快速验证：

ffplay -f s16le -ar [实际采样率] -ac [实际通道数] your_pcm_file.pcm

如果这个命令播放正常，那问题出在你自己的PCM保存/播放逻辑；如果还是慢，回到解码参数的排查。

4. 处理丢包或乱序问题 #

如果捕获的Opus流存在丢包或者包顺序错误，解码器可能会产生异常样本，导致播放卡顿变慢。可以开启Opus的错误隐藏功能，把opus_decode的最后一个参数改成1：

// 开启错误隐藏，掩盖丢包的影响
opusResult = opus_decode(opusDecoder, voicePacketBuffer, voicePacketLength, pcm, 1920, 1);

内容的提问来源于stack exchange，提问作者GuiTeK