That is, will my render callback ever be called after AudioOutputUnitStop() returns?
In other words will it be safe to free resources used by the render callback or do I need to add realtime safe communication between the stopping thread and the callback thread?
This question is intended for both macOS HAL Output and iOS Remote IO output units.
hello
Do you have a conclusion on this question
Recently, I often encounter the probability of audionitstop crash,,the operation in main thread
The Audio Unit and its callbacks run in a completely separate real-time thread from any other thread in you app. So any commands given to an Audio Unit should be assumed to be executed asynchronously. And possibly not until many tens of milliseconds after a command is issued.
To be safe, in my apps, I never free any related resources until several seconds after an audio unit is told to stop. And I never stop an audio unit if I plan to immediately (re)start that same unit. I just leave the audio units running, passing silence (zeros) in all the callbacks.
I'm quite sure AudioOutputUnitStop is and always have been synchronous.
Here is a quite old answer:
https://lists.apple.com/archives/coreaudio-api/2005/Dec/msg00042.html
If you call AudioOutputUnitStop from the I/O thread then AudioDeviceStop is called immediately. The I/O proc will not be called again. I believe the current I/O cycle's buffer will be played; i.e. that the stop will actually take effect at the end of the I/O cycle. (If I'm wrong, Jeff Moore will correct me...)
If you call AudioOutputUnitStop from another thread, then it will call AudioDeviceStop and wait for a notification from the HAL that the hardware has actually stopped before returning. In the interim, the I/O proc may continue to be called.
Thus AudioOutputUnitStop is always synchronous; on return, in the absence of an exceptional condition, the I/O proc will not be called again.
--
Doug Wyatt
Core Audio, Apple
I think that macOS 13 has broken this promise. That is, after calling AudioOutputUnitStop from within the I/O proc, the system calls the I/O proc again.
The contract isn't that the I/O Proc won't get called again after AudioOutputUnitStop is called, it is that it won't be called again after AudioOutputUnitStop returns. These aren't the same thing.
If you call AudioOutputUnitStop from the I/O Proc then the I/O Proc will not be called again.