Re: AUGraph and DP macs
Re: AUGraph and DP macs
- Subject: Re: AUGraph and DP macs
- From: Chris Rogers <email@hidden>
- Date: Thu, 31 Jul 2003 12:14:05 -0700
Glenn,
Currently AUGraph does nothing special to distribute load among multiple
threads. We have thought about this issue, and have considered both
the idea of a "DeferredRenderingAudioUnit" which basically passes through
audio, but does buffering and receives its input from another thread
from the one it was asked to render on. And putting an option in our
mixers, where individual inputs could be assigned to get their input
from another thread (with appropriate buffering and synchronization).
We haven't done either of these yet...
Chris Rogers
Core Audio
Apple Computer
Thanks. In that case, I guess my question should be directed to
someone at Apple: is AUGraph multiprocessor-aware/multithreaded?
As for whether an AU node in the graph could break the assumptions of
the graph analysis or the threading mechanism, that issue is not
specific to AUGraph. Hosts must be able to trust the render callback
to be threadsafe in order to implement multiprocessor support.
This is a well-understood issue in the VST world...I think it's safe
to assume AU developers are aware of this.
- Glenn
David Duncan wrote:
On Thursday, July 31, 2003, at 12:06 PM, Glenn Olander wrote:
Well, yeah...but I was asking does AUGraph perform
multi-threading in order to spread the processing load?
AUGraph certainly could evaluate it's graph and find opporunities
for parallelism. My question is: does it do that?
Dave, your answer sounds like an authoritative "no". But it
isn't clear from your reply if you know for certain, or are
speculating? (Not doubting you, just asking for clarification).
Thanks.
My impression of AUGraph is that it is there to help you manage a
lot of Audio Units and persist their state. So as an outsider
looking in, I would expect the API to take the path of least
resistance and simply connect all the Audio Units together and then
set the head unit to render when asked of it. So I would say that
I'm speculating from an informed position =). Basically for the
AUGraph API to multithread it would either have to connect every AU
via a glue function (ala the kAudioUnitProperty_SetRenderCallback
property) or to insert a glue component between every AU in the
graph (which I haven't seen in the list of system components).
I think that to properly handle multi-threaded rendering would
require either a property that is settable on an AudioUnit (and let
the AU do the threading) or for the developer to do it themselves.
Graph Analysis may be able to find opportunities for parallelism,
but once you hit the Render Callbacks in a graph you can't be
certain what any of them are expecting (from Apple's POV).
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.