AudioDeviceIOProc返回后播放Mac Core Audio输出缓冲区？(Mac Core Audio output buffer played after AudioDeviceIOPr

AudioDeviceIOProc返回后播放Mac Core Audio输出缓冲区？(Mac Core Audio output buffer played after AudioDeviceIOProc returns?)

我的应用程序（仅适用于macOS）使用低级CoreAudio功能（AudioDevice-low，而非AudioUnit）。

我的问题是：输出缓冲区是在我的AudioDeviceIOProc返回之后立即播出还是需要一个额外的周期？

让我通过一个例子解释问题的来源。 考虑一个输入监视应用程序，它对输入进行一些处理并立即播放，为简单起见考虑输入和输出的相同设备。

我通过AudioObjectSetPropertyData将缓冲区大小设置为480帧（10ms @ 48kHz），寻址属性kAudioDevicePropertyBufferFrameSize 。 当我的AudioDeviceIOProc被调用时，我有10ms的输入数据，我处理然后在我的AudioDeviceIOProc返回之前写入输出缓冲区。

在这一点上，我需要理解（一劳永逸）以下两个案例中哪一个是正确的：

A）在我刚刚设置的输出缓冲区可以播放之前需要传递10毫秒 B）在回调返回后立即播放缓冲区。 这似乎不可能，因为它要求回调在每个周期完全相同的时间。 实际上，如果我们考虑第二次调用ioproc的例子，处理比前一个周期多20微秒，这将导致差距接近1个样本（ 0.02 * 48000/1000 samples = 0.96 samples ）。

我总是假设A）是正确的答案，这符合经验法则，用于计算监控往返延迟为2*I/O buffersize （例如，如此处所述https://support.apple.com/en-om/ HT201530 ），但最近我一直在阅读关于它的录音信息。 任何人都可以为我清除这个吗？ 谢谢

My application (for macOS only) uses low level CoreAudio features (AudioDevice-low, not AudioUnit).

My question is: is the output buffer played out immediately after my AudioDeviceIOProc returns or an additional cycle is needed?

Let me explain where the question comes from with an example. Consider an input monitoring app that does some processing on the input and plays it back right away, for simplicity considering the same device for both input and output.

I set the buffer size to 480 frames (10ms @ 48kHz) through AudioObjectSetPropertyData addressing the property kAudioDevicePropertyBufferFrameSize. When my AudioDeviceIOProc is called, I have 10ms of input data which I process and then write to the output buffer before my AudioDeviceIOProc returns.

At this point I need to understand (once and for all) which of the two following cases is the correct one:

A) 10 more milliseconds need to pass before the output buffer that I just set can be played out B) the buffer is played immediately after the callback returns. This doesn't seem to be possible because it would require that the callback takes exactly the same time at every cycle. In fact, if we consider as an example that the second time the ioproc is called the processing takes 20 microseconds more than it took the previous cycle, this would result in a gap of almost 1 sample (0.02 * 48000/1000 samples = 0.96 samples).

I always assumed A) to be correct answer, which would fit with the rule of thumb for calculating the monitoring roundtrip latency as 2*I/O buffersize (e.g. as explained here https://support.apple.com/en-om/HT201530), but lately I've been reading discording info about it. Can anyone clear this up for me? Thank you

最满意答案

当coreaudiod调用IO Proc时，它会填充内部缓冲区以输出到音频设备。 由于Core Audio需要时间处理您的数据并可能将其与来自其他应用程序的流混合，因此输出不会立即发生。 实际上，甚至还有一个属性允许您控制准备样本所需的IO周期时间， kAudioDevicePropertyIOCycleUsage 。

一旦Core Audio拥有您的数据，它可能不会立即将其发送到设备进行播放。 AudioDevice和AudioStream对象都具有可配置的延迟。 对于AudioStream您可以阅读kAudioStreamPropertyLatency 。

鉴于这种复杂性， AudioDeviceIOProc为您提供了一个参数，用于确定何时将样本写入设备。 查看倒数第二个参数， const AudioTimeStamp* inOutputTime 。

When coreaudiod calls your IO Proc, it is filling an internal buffer for output to the audio device. The output won't occur immediately since Core Audio needs time to process your data and potentially mix it with streams from other applications. In fact there's even a property that allows you to control how much time in the IO cycle you need to prepare your samples, kAudioDevicePropertyIOCycleUsage.

Once Core Audio has your data, it may not immediately send it to the device for playback. Both AudioDevice and AudioStream objects have configurable latency. For AudioStream you can read up on kAudioStreamPropertyLatency.

Given this complexity, the AudioDeviceIOProc gives you a parameter to determine when the samples will be written to the device. Look at second to last parameter, const AudioTimeStamp* inOutputTime.