A is definitely out. Your real-time audio thread is not allowed to block (or do anything else “non-deterministic” — i.e. anything that doesn’t ALWAYS complete within a specific deadline).
Usually, you would allocate your buffers before-hand and then re-use them as needed during playback. Why do your need to release them during playback? Dave > On Oct 7, 2015, at 5:44 PM, James Navarro <[email protected]> wrote: > > Hello everyone. > > Ok I'm going to simplify this as much as possible. I have an app where I am > producing audio via a Remote IO callback method. This method needs to play > float samples, by copying them from a buffer. > > The problem is, that buffer needs to be released by the user sometimes. I > cannot find a safe way to do this without: > > A) Using locks/mutexes (bleh) > B) Doing audio processing on a GCD queue (bleh) > C) "Signal" to the remote io thread that this buffer needs to be released, > and let that thread do the work. > > These all seem to be not great solutions. I'm sure that A and C would > actually work out Ok, because these buffers would only need to be released > sometimes, and if the audio slows down... it's not a tragedy. > > But I really don't want to do that, and wondered what people on this list > would recommend. > > Thank you! > > > _______________________________________________ > 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/dave.fernandes%40utoronto.ca > > This email sent to [email protected] _______________________________________________ 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]
