Re: more AU info and plugins (should be "I need to share data")
Re: more AU info and plugins (should be "I need to share data")
- Subject: Re: more AU info and plugins (should be "I need to share data")
- From: Philippe Wicker <email@hidden>
- Date: Sat, 21 Jun 2003 22:32:45 +0200
On Saturday, June 21, 2003, at 08:40 PM, Marc Poirier wrote:
On Sat, 21 Jun 2003, Philippe Wicker wrote:
To say the truth, this mechanism was not designed with these needs in
mind. A parameter may change frequently - it's in a way a real time
data - that must fit in a Float32, while a property is a "moderate"
size data which is not supposed to change frequently. Audio data is
neither one nor the other. In that case, sharing pointers on audio
buffers (or other specific data which makes sense for the couple AU<->
GUI) looks a reasonable way to solve the problem.
Is there some place where it says that property data is "moderate"
sized
(or specifies that any further) and where it says that property values
are not supposed to change frequently? I have never heard or read
anything of the sort...
In /Developer/Documentation/CoreAudio/AudioUnits, chapter Audio Unit
Properties. Have a look at the list of the defined properties. You can
notice that none of them are related to piece of data susceptible to
change frequently. They define the state of the AU. Some of these
properties won't change for the entire life of the AU instance, some
will change only when the graph is modified or when the audio device
has been changed, that is most of the time when the user do some action
on the host or AU UI. So more or less at a "human" speed.
Setting/Getting a property via the Set/GetProperty has a certain cost
from a CPU point of view. Have a look at the paragraph "Performance
Properties" in the same chapter. The doc says: "Dispatching through the
Component API calls has some overhead that can and should be avoided in
the rendering and parameter setting calls where a real-time context is
normally required".
It is not explicitly written that properties may not change frequently
but we can reasonably infer from the doc that they were not foreseen
for that.
Yes, nothing such as "properties must have a moderate size" is written.
But have a look at how a GetProperty works. You pass a pointer to the
memory location where you want the property data to be **copied**, and
the size you are expected. Because of the "copy semantics", It looks
reasonable to use this API for "moderate" size properties. For
instance, if I need to have access to the 100 MBytes of audio samples
used by some instruments in an AU, this "copy semantics" API is clearly
not the good choice. On the other hand, it would be a candidate of
choice to get a **pointer** on the 100 MBytes samples.
Philippe Wicker
email@hidden
_______________________________________________
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.