| You should do as little as possible on the render callback:
(1) It is a real-time thread, it is running at the exclusion of other activity on the system (2) It is a running to a deadline, you miss the deadline, you glitch
What are you doing that requires the fine granularity of timing that audio runs at? So, if you "wouldn't agree", I'd actually be interested to know why. On Aug 27, 2010, at 12:10 PM, Gregory Wieber wrote: Michael Tyson has written about this at length on his blog and here as well. For GUI changes that must be synched with audio, open gl is probably the best bet, and yes, you should trigger your methods from within a render callback. Also, I wouldn't agree about the render callback only performing audio -- in some cases you must inline your functionality to get the most speed.
On Fri, Aug 27, 2010 at 11:44 AM, Patrick Muringer <email@hidden> wrote:
Hi all,
As the Render callback should only perform audio stuff, in case of an application with timing based on sample time in the callback, what strategy would you recommend to updated the GUI? Event sent by the callback? Variable set in the callback and main thread that checks for variable changes?
Thanks for your appreciated feedback.
Pat
_______________________________________________
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
|