What actions are permitted in an Audio Output Unit's input callback
I am using an Audio Output Unit to capture mic data. I get notified that there is data to read via a callback I have set using the kAudioOutputUnit_SetInputCallback property, and in the callback I read the data by calling AudioUnitRender().
Ultimately, I will be updating the user interface of my app on the basis of some information extracted by analysing this data. I will therefore need at some stage to do a dispatch_async onto the main queue. The analysis is moderately time consuming, and is done in chunks rather larger than those I get from AudioUnitRender(), so the load is bursty.
My question is: what operations are considered acceptable in the implementation of the input callback itself? I've found plenty of sources stating strict restrictions on render callbacks (no memory allocations, no i/o, no synchronisation with other threads, etc), but no information at all about input callbacks.
If I follow the same rules as for render callbacks, I have a bit of a challenge. dispatch_async() itself is undesirable as it allocates memory, and the load is bursty anyway (could easily be longer than one render cycle on some turns, and practically zero on others). It therefore seems necessary to send my data off to a worker thread for processing and for the dispatch_async() calls to be made. However, I still need to manage the passing of the data over to this worker thread. The simplest way (in C++) would be with a circular buffer, plus a mutex and condition variable to signal when data is available. However, that would require the input callback to lock the mutex, which the guidelines on render callbacks explicitly discourage.
Avoiding this mutex lock will take me to lock-free circular buffers, semaphores (POSIX or GCD), spinlocks and the like, and I'm wondering if that is overkill for simply listening to a microphone. There's a shocking lack of documentation for this stuff and I have no idea what's really going on behind the scenes. Do I really need to be concerned about waiting on a mutex (only briefly and rarely locked by another thread) in my input callback implementation?
I use a circular buffer from: https://github.com/michaeltyson/TPCircularBuffer
The description states:
As long as you restrict multithreaded access to just one producer, and just one consumer, this utility should be thread safe.
So you can both render (produce) and process (consume) from the circular buffer safely without worrying about locks.
Update :
Do I really need to be concerned about waiting on a mutex (only briefly and rarely locked by another thread) in my input callback implementation?
To that I say yes. "Rarely locked" is all you need for an input callback to fail. And "briefly" is already too long. I had input callbacks fail simply for NSLogging something.
链接地址: http://www.djcxy.com/p/67030.html上一篇: 如何使用现有数据创建solr内核？
下一篇: 音频输出单元的输入回调中允许采取哪些操作