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 protected]> 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.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
