Re: AUGraph and DP macs
Re: AUGraph and DP macs
- Subject: Re: AUGraph and DP macs
- From: Glenn Olander <email@hidden>
- Date: Thu, 31 Jul 2003 14:50:58 -0700
Thanks Bill. It's not a big deal, I just wanted to know.
I'm not sure I follow your comment about an AU with high
priority internal threading causing problems if the host
uses threading. Are you saying there is an AU which
does not permit the host to put the render calls into
threads? Wouldn't such an AU fail to work in Logic (or
digital performer, or cubase if it was to support AU's)?
- Glenn
Bill Stewart wrote:
I was watching with interest...
David is quite correct.
On Thursday, July 31, 2003, at 10:48 AM, Glenn Olander wrote:
Thanks. In that case, I guess my question should be directed to
someone at Apple: is AUGraph multiprocessor-aware/multithreaded?
Not for processing.. The AUGraph is thread-aware for state management
though..
We've talked about how we might work this in, as in many respects I
think you need the work to be done in a mixer unit, but have the graph
tell the mixer which of its groups of inputs are independent (then the
mixer can thread itself). It is something I'd like us to do, but
haven't at this point...
(As such, I also wonder if the graph can really know what the
dependencies are).. thus, it might be something that the mixer for
instance would support, but the client is responsible for knowing the
topology and managing this. As you can see, still half-baked.
Part of the reason that I hold back on this, is that some of the more
complex/interesting AU's are actually threaded internally... So, in
that case you might cause more problems than you solve because the
rendering is done on multiple threads (probably at high priorities),
and these other AU's might be starved as a result of that.
Also, some engines do this threading themselves, by dividing their
processing into layers - thus you could see multiple graphs running in
different layers, in different threads...
Bill
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.
-- mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________ __
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________ __
_______________________________________________
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.