iOS，音频队列：缓冲区大小不一致
我在我的应用程序中使用音频队列服务。分配缓冲区时，我将缓冲区大小设置为 30000 个样本：
AudioQueueAllocateBuffer(mQueue, 30000, &mBuffers[i]);
但是回调的后续调用是使用以下 inNumberPacketDescriptions 进行的：
30000
30000
30000
26928
30000
30000
它们并不总是等于 30000。为什么？< /strong>
记录格式配置（使用CAStreamBasicDescription）：
mRecordFormat.mSampleRate = kSampleRate;
mRecordFormat.mChannelsPerFrame = 1;
mRecordFormat.mFormatID = kAudioFormatLinearPCM;
mRecordFormat.mFormatFlags = kLinearPCMFormatFlagIsSignedInteger | kLinearPCMFormatFlagIsPacked;
mRecordFormat.mBitsPerChannel = 16;
mRecordFormat.mBytesPerPacket = mRecordFormat.mBytesPerFrame = (mRecordFormat.mBitsPerChannel / 8) * mRecordFormat.mChannelsPerFrame;
mRecordFormat.mFramesPerPacket = 1;
使用3 个缓冲区。
I use Audio Queue Services in my application. When allocating the buffer, I set the buffer size to 30000 samples:
AudioQueueAllocateBuffer(mQueue, 30000, &mBuffers[i]);
But the subsequent calls of the callback are made with the following inNumberPacketDescriptions:
30000
30000
30000
26928
30000
30000
They aren't always equal to 30000. Why?
Record format configuration (using CAStreamBasicDescription):
mRecordFormat.mSampleRate = kSampleRate;
mRecordFormat.mChannelsPerFrame = 1;
mRecordFormat.mFormatID = kAudioFormatLinearPCM;
mRecordFormat.mFormatFlags = kLinearPCMFormatFlagIsSignedInteger | kLinearPCMFormatFlagIsPacked;
mRecordFormat.mBitsPerChannel = 16;
mRecordFormat.mBytesPerPacket = mRecordFormat.mBytesPerFrame = (mRecordFormat.mBitsPerChannel / 8) * mRecordFormat.mChannelsPerFrame;
mRecordFormat.mFramesPerPacket = 1;
3 buffers are used.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
编辑：我见过 iOS 在遇到非 2 的幂音频缓冲区时会惊慌失措并自发地更改缓冲区大小。 （另一个SO问题引用了这个）无论如何，
30000是
（a）巨大的缓冲区大小，以及
（b）用于缓冲区的奇怪数字。通常它们是 2 的幂 - 即 64 的
*=2，即 64、128、256、512、1024、2048、4096。我从未见过高于 4096 的数字，我做了很多音频工作。如果您有特殊原因需要使用异常大的缓冲区，您可以使用
nextPowerOfTwo便利函数或自己对数学进行硬编码。Edit: I've seen iOS freak out and spontaneously change buffer sizes when presented with a non-power-of-two audio buffer. (Another SO question references this) Anyway,
30000 is
(a) a HUGE buffer size, and
(b) a weird number to use for a buffer. Usually they're in powers of 2— i.e.
*=2from 64, i.e. 64, 128, 256, 512, 1024, 2048, 4096. I've never seen one higher than 4096, and I do a lot of audio work.If you have a specialized reason to use unusually-large buffers, you could use a
nextPowerOfTwoconvenience function or just hard-code the math yourself.