On Jun 20, 2006, at 13:58 , Andrew McPherson wrote:
This is a somewhat esoteric question that has to do with threading
in the AU processing code. The short version: can a parameter
change take place between the time the first and last kernels
associated with an AU effect process a particular slice of audio?
The long version:
As I understand it, an AU effect may have multiple instances of the
processing kernel for handling multiple channels of audio.
Presumably, when a slice of audio is processed, the CoreAudio code
calls each kernel in sequence to do its processing.
Now what I want to do is to have each kernel know when a parameter
has been changed. Because my AU uses a lot of parameters, it is
computationally expensive to store all the previous values and
check them on every slice. So what I've done is override the
SetParameter methods in AUEffectBase and AUBase to set a flag
saying something has been changed. (Is this legit?) Then the
kernels call methods in my main AU class to check the value of the
flag, and clear it if necessary.
The problem is that I want each kernel to get the message exactly
once. If I have a kernel check the flag and clear it if it has
been changed, then only the first kernel is going to notice the
change. What I'm thinking of doing instead is having only the last
kernel clear the flag (checked with the IsLastKernel() method of
AUKernelBase).
I could imagine a situation, though, where a parameter change takes
place between the time of the first kernel and the last kernel
processing a slice, where not all of them would get the message.
So can I assume that all parameter changes come between slices of
audio and can never pop up in the middle of a slice? If not, how
would I tell every kernel that a parameter change has taken place?
(Seems like the listener methods are more designed for UI components.)
If the host application cares about consistent and deterministic
responses to parameter changes (as it would in an automation
situation), it will only change parameters from the render thread,
typically right before it asks you to render.
Of course if the user is grabbing a slider in a view, the parameter
changes are coming from another thread and might well happen while
you are rendering.
One way to solve the problem of making sure each kernel sees each
parameter change exactly once would be to add a flag to each kernel.
Whenever a parameter changes, store the new value, then set each
kernel's flag. When rendering each kernel, perform a test-and-clear
on the flag.
Doug
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
