• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: AUGraph and DP macs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AUGraph and DP macs


  • Subject: Re: AUGraph and DP macs
  • From: Glenn Olander <email@hidden>
  • Date: Thu, 31 Jul 2003 10:48:51 -0700

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.

  • Follow-Ups:
    • Re: AUGraph and DP macs
      • From: Bill Stewart <email@hidden>
    • Re: AUGraph and DP macs
      • From: Chris Rogers <email@hidden>
References: 
 >Re: AUGraph and DP macs (From: Robert Grant <email@hidden>)
 >Re: AUGraph and DP macs (From: Glenn Olander <email@hidden>)
 >Re: AUGraph and DP macs (From: David Duncan <email@hidden>)

  • Prev by Date: Re: AUGraph and DP macs
  • Next by Date: Re: of timestamps & midi packets
  • Previous by thread: Re: AUGraph and DP macs
  • Next by thread: Re: AUGraph and DP macs
  • Index(es):
    • Date
    • Thread