请教音频渲染缓冲区 audiounit 的一个问题

[sppl]

最近刚做音视频，遇到一个问题，想请教下各位

audiounit 通过 callback，由用户来提供渲染音频的数据给系统

当前在真机上，回调里需要填充的缓冲区数据大小，多于我从流上拉取的数据量，而查阅相关文档，表示并不能够直接控制缓冲区的大小

那么这时候，我是要求服务端提升速率，还是对音频做重采样以填充缓冲区呢？

[wohenyingyu03]

为什么会多，你的流是从网络 socket 来的？采样率在初始化的时候已经确定，怎么可能中途改？ audio unit 多要的数据直接填 0 即可。如果是从网络来的，要建立自己的 jitter buffer，不然填 0 声音没法听。

[sppl]

谢谢，我是从网络读取的 pcm 流数据，直接放入 buffer 中，在模拟器上，是能够正常播放的
在真机上，我延时了 20s 再开始播放，会发现有跳帧现象，我猜测是 pcm 可能模拟器上读取 pcm 数据是以 UInt16 的格式去读取数据，而真机上采用 float 的方式，直接导致我的流有跳帧的现象
如果我的猜测正确，那我下一步是自己对数据进行填充，还是有其他的方案呢？

[sppl]

@wohenyingyu03 不好意思，回复在上面，忘了 @你了

[hgwang1215]

网络上的 pcm，不编码就传输吗？

[wohenyingyu03]

@sppl pcm 数据什么格式没关系……你说的是流数据，难道还用 tcp ？等你握手确认完，audio unit 时间早就过去了，肯定会乱序延时，UDP 了解下？居然直接用 pcm，G711 编码了解下？

[sppl]

@wohenyingyu03 好的，我去查下相关资料，谢谢

[wohenyingyu03]

@sppl 之前说错了，tcp 不会乱序，主要还是其握手消耗的时间导致你的流不能及时收到足够的数据来满足 audio unit，最后导致跳帧，而且你用 pcm 直接传会大大增加网络上数据包的流量导致丢包概率增加。一般用 udp 可以完全避免握手耽误的时间，但是避免不了丢包延时乱序，这部分问题一般叫抖动，也会造成跳帧。一般用编码压缩 pcm 来解决流量过大的问题，并在本地建立 jitter buffer 来解决抖动的问题，现在有很多算法可以动态调整 jitter buffer 大小自动适应不同网络，也有很多算法可以补偿跳帧。一般用 tcp 传输的语音都是用在非实时场景，在数据量不够是会暂停进行缓冲，而实时场景一般用 udp，但是两种方案都需要有本地 buffer 缓冲。不太清楚你的需求，只是一点建议。