Re: AU Callback on a separate thread ? How ?
Re: AU Callback on a separate thread ? How ?
- Subject: Re: AU Callback on a separate thread ? How ?
- From: Paul Davis <email@hidden>
- Date: Wed, 17 Nov 2010 09:31:06 -0500
On Wed, Nov 17, 2010 at 8:39 AM, Robert Bielik <email@hidden> wrote:
> Pascal skrev 2010-11-17 14:31:
>>
>> Having the AU render callback on a separate should help to do UI updates
>> without any interruption in the audio processing.
>
> These questions popup from time to time, so here goes: ALL rendering should
> be done within the context of the callback. Not in another thread. Generally
> not a good idea. There are no benefits. Zilch. Communication with UI should
> be done through lock-free communication queues.
the first two posts in this thread appear to potentially be about
different questions.
one question could concern running the rendering code for a given AU
in a different thread than the one in which the render callback is
delivered. as noted above, this is generally an incredibly bad idea
unless you really understand what you are doing (and even then its a
bad idea that has some tradeoffs).
another question could concern running an AUGraph as the "host" of the
graph, and wanting to do it in some thread other than the main GUI
thread. in this case, using another thread is likely to be a good
idea, but the details are going to depend a lot on the ultimate
destination of data flowing through the graph. If its going to an
audio interface, then it should probably just be running in the thread
that handles the IOProc callback associated with the the open device.
On the other hand, if you were constructing an offline renderer (i.e.
rendering to a file), then just using a specific thread to run the
graph might make sense.
_______________________________________________
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