Re: Remote IO thread and concurrency
Re: Remote IO thread and concurrency
- Subject: Re: Remote IO thread and concurrency
- From: Dave Fernandes <email@hidden>
- Date: Wed, 07 Oct 2015 18:37:57 -0400
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@hidden> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden