• 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 deadlocks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AUGraph deadlocks


  • Subject: Re: AUGraph deadlocks
  • From: patrick machielse <email@hidden>
  • Date: Mon, 05 Dec 2011 00:26:59 +0100

Op 4 dec. 2011, om 21:02 heeft Brian Willoughby het volgende geschreven:

> On Dec 3, 2011, at 12:40, patrick machielse wrote:
>
>> To clarify: I'm not _changing_ the Graph (node-structure / layout)
>> itself, I am however accessing and changing parameters on audio
>> units in the graph. For instance, I set mixer and equalization
>> values. I do this on the render thread in my render callback during
>> kAudioUnitRenderAction_PreRender. My assumption is/was that that
>> would be a safe time to do this.
>
> Where does the information for the new mixer and EQ settings come
> from?  Is the user inputting them?  Are you somehow using audio
> waveform analysis to come up with new EQ settings?
>
> If the information is coming from the user with regard to the new
> mixer and EQ values, then there is absolutely no reason to change
> them within the audio rendering callback.  Just maintain the usual
> separation of audio engine and interface.

Brian,

Thanks for your comments. The information is coming from the user, but not through any AudioUnit UI. My custom audio units don't have a UI, and I'm not using the default UI of any other bundled unit.

The user manipulates a document in my application wich is contains the processing information. This is a CoreData persistent document. When I detect edits, a light-weight, read-only, non-CoreData representation of the processing information is created for use on the audio thread. This 'recipe' describes my eq, mixer, etc. settings f(t).

At 'pre-render' time, the render thread first checks if there is a new processing 'recipe' available, and then updates all units in the graph according to the recipe for the current render time, using AUBase API.

There is a clear division between the UI and the audio processing engine. At some point the render settings must be applied to the audio units. kAudioUnitRenderAction_PreRender seemed the best opportunity to me.

patrick
--
Patrick Machielse
Hieper Software

http://www.hieper.nl
email@hidden

 _______________________________________________
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

  • Follow-Ups:
    • Re: AUGraph deadlocks
      • From: Brian Willoughby <email@hidden>
    • Re: AUGraph deadlocks
      • From: Paul Davis <email@hidden>
  • Prev by Date: Re: AUGraph deadlocks
  • Next by Date: Re: AUGraph deadlocks
  • Previous by thread: Re: AUGraph deadlocks
  • Next by thread: Re: AUGraph deadlocks
  • Index(es):
    • Date
    • Thread