录制音频时 AudioQueueServices 回调出现意外行为
我正在使用 AudioQueueServices 记录连续的数据流。据我了解，只有当缓冲区填满数据时才会调用回调。实际上，第一个回调的缓冲区已满，第二个回调已满 3/4，第三个回调已满，第四个回调已满 3/4，依此类推。这些缓冲区有 8000 个数据包（录制 8khz 音频） - 所以我应该每次都将 1 秒的音频返回给回调。我已经确认我的音频队列缓冲区大小是正确的（并且在某种程度上通过行为得到了确认）。我做错了什么？我应该在 AudioQueueNewInput 中使用不同的 RunLoop 执行某些操作吗？我尝试过，但这似乎没有什么区别...
顺便说一句，如果我在调试器中运行，每个回调都充满了 8000 个样本 - 让我认为这是一个线程/计时事物。
I'm recording a continuous stream of data using AudioQueueServices. It is my understanding that the callback will only be called when the buffer fills with data. In practice, the first callback has a full buffer, the 2nd callback is 3/4 full, the 3rd callback is full, the 4th is 3/4 full, and so on. These buffers are 8000 packets (recording 8khz audio) - so I should be getting back 1s of audio to the callback each time. I've confirmed that my audio queue buffer size is correct (and is somewhat confirmed by the behavior). What am I doing wrong? Should I be doing something in the AudioQueueNewInput with a different RunLoop? I tried but this didn't seem to make a difference...
By the way, if I run in the debugger, each callback is full with 8000 samples - making me think this is a threading / timing thing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
显然，从与其他人的讨论以及缺乏回应来看，这种行为是设计好的（或者被破坏了，但不太可能被修复），即使记录不正确。解决方法是在必要时在回调中适当缓冲样本，并且不要期望缓冲区已满。如果您只是将数据写入文件，那么这根本不是问题，但如果您希望在回调中操作大小一致的音频数据块，则必须自己确保这种一致性。
Apparently, from discussing with others — and the lack of responses, this behavior is as designed (or broken but not likely to be fixed), even if improperly documented. The work around is to buffer your samples appropriately in the callback if necessary and not expect the buffer to be full. This isn't an issue at all if you are just writing the data to a file, but if you expect to operate on consistently sized blocks of audio data in the callback, you will have to assure this consistency yourself.