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: Bill Stewart <email@hidden>
- Date: Sat, 21 Jun 2003 14:40:55 -0700
Philippe
On Saturday, June 21, 2003, at 01:32 PM, Philippe Wicker wrote:
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.
I think that is an unreasonable inference.
The overhead of the component dispatch is not that great, but we were
concerned with this overhead for both the rendering and parameter
calls, because these are calls that can be made with a great deal of
frequency... (for parameters you can in some instances expect multiple
parameter calls for each render slice) and rendering of course, as it
happens in the I/O thread - we wanted to circumvent the overhead...
There is nothing to prohibit you from doing the same things for the
property calls if you are using them in such a manner - and maybe we
should do this ourselves in the base classes if this is an issue (and
not an excuse:)
Yes, nothing such as "properties must have a moderate size" is written.
Correct
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.
You could also pass a "token" - here's where the 100MBytes of samples
are... I think we're getting to the point with sample data that loading
it into memory is *not* the most efficient means - think of GigaStudio
for instance and the impact that has had on software based samplers...
I think this is a bit of a stretch, and I'm not sure what your point
is... EVERY C API uses the same kind of semantic - typically any
passing of large data is done by not **copying** it around, but these
values are passed by reference (ie pointers) - or by tokens (like the
FILE types in stdio for instance)...
Despite this - the basic design of a separation and encapsulation of
model/view/controllers have been written with these constraints for how
long in how many different languages in how many different
OS's/kernels/etc?
Bill
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.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.