Yes, the caller expects that you put the audio data in the buffer that it has allocated. I assume that the buffer may be in use by several upstream functions in the graph, which means that changing the pointer would potentially cause lots of trouble in multiple places.
The code would be slower if the caller had to detect changed pointers and copy the data whenever the callee changed the pointer. Besides, I don't think that the API marks the whole structure as in/out, only the contents of the array are the output, not the pointers or other fields of the structure. For example, you can't change the number of buffers in the callback, either. That sort of change has to be handled while the AudioUnits are not initialized.
Keep in mind that CoreAudio has to be real time, and this means pre-allocated buffers and lots of other restrictions. Certain changes can't only happen when the AudioUnits are not active, which is why there is an "initialize" step and Start/Stop for AUGraph, etc.
Brian Willoughby Sound Consulting
On Dec 14, 2016, at 10:39 AM, Baoshan Sheng < email@hidden> wrote: In my audio output prototype, replace below line in the IOProc
memcpy(outOutputData->mBuffers[0].mData, pcm, outOutputData->mBuffers[0].mDataByteSize);
with
outOutputData->mBuffers[0].mData = pcm;
Will lead to digital silence. I have no idea why. The pcm buffer is globally alloced and never freed.
Does that means the caller of the IOProc expects the buffer be filled, rather than the pointer be replaced?
Any help would be appreciated.
|