Re: AUGraph deadlocks
Re: AUGraph deadlocks
- Subject: Re: AUGraph deadlocks
- From: Brian Willoughby <email@hidden>
- Date: Sat, 03 Dec 2011 20:23:34 -0800
On Dec 3, 2011, at 12:40, patrick machielse wrote:
Op 3 dec. 2011, om 21:02 heeft Kyle Sluder het volgende geschreven:
On Fri, Dec 2, 2011 at 6:04 PM, Brian Willoughby
<email@hidden> wrote:
I would say that the bigger question is why you're trying to change
parameters or manipulate the graph from within the rendering
callback.
This is a chicken-and-egg discussion. It sounds like Patrick is doing
this because nobody told him it was a bad idea, and he's now asking
for clarification on that point. We certainly can't blame him for not
reading the documentation.
At the moment I've changed my code to store references to the
AudioUnit instances instead of AUNodes. This seems to work so far
(no deadlocks) and also simplified the code a bit at the cost of a
bunch of extra ivars.
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.
If the information comes from the audio data somehow, then it seems
like you should be setting internal variables directly rather than
using external parameter change messages. All you really need to do
when changing variables within a render callback is to make the
change in the variable itself, and then post a notification of the
change so that the UI will reflect the new value.
If your AU is really just a graph of other AU plugins, and your
parameter values truly come from audio data, then I guess you have a
unique problem that's certainly not going to be covered in the
documentation.
In other words, either you have a typical problem and you're using a
very strange method to solve it, or you have a very atypical
problem. Either way, I'm not surprised that you don't see a tutorial
in the documentation on how to do this, since it's not standard
practice to set values within the audio render (although it is common
to directly alter values and send out a notification - see the
dynamics processing AU samples when the instantaneous gain is
reflected in a read-only parameter).
Brian Willoughby
Sound Consulting
_______________________________________________
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