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: Marc Poirier <email@hidden>
- Date: Sat, 21 Jun 2003 16:29:14 -0500 (CDT)
On Sat, 21 Jun 2003, Philippe Wicker wrote:
>
> 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.
Well, in this respect I think that you are just making an assumption.
You are saying that the properties appear to you to be the sort of things
that don't change often, but it is not specified that they can't change
often. Plus, I can see some of those properties changing at any rate,
like latency or tail size, for example, could easily change in response to
a parameter change (like in SFX Machine RT, Scrubby, and Geometer, for
example), which, as you've mentioned, can change at any time or rate.
>
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 don't agree. I think that this only says that you should not set and
get properties in a high priority thread (which has been stated before by
Apple folks). This does not mean that properties can't change as often as
you'd like, and that you can't even post notification of changes, as long
as you can be sure that any listener proc will do very little work. This
is something that was discussed earlier and it was said that the best
solution is to check notification changes in a low priority loop (like
using a dummy parameter and parameter listener) and to do the work of
getting and setting there, if changes to the property will be propagated
from the audio rendering thread.
>
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.
Okay, of course, agreed that copying 100 MB of property data is a bad
idea. ;) But I also can't fathom any practical application that would
need to share a 100 MB sample library between audio and GUI components.
In that case, sure, you have special requirements, but how likely is that
really? Earlier, you mentioned that maybe multiple instances of an audio
component may want to share sample data in memory. That could be a likely
situation for sure. And in that case, I agree, passing a pointer would be
better, if possible. But I also don't think that that example applies to
this topic. First of all, how would share that pointer? I think you
would not do it via properties, whether that property shared pointer value
or the entire data chunk. You wouldn't do that because one instance of an
audio component has no awareness of the ComponentInstance of another audio
component, so you couldn't set and get properties between them anyway.
What you'd probably do is have a static global variable in your component
that is the pointer to the sample data. Well, this will only work within
the same process anyway. So I think, for that example, that's the best
you could get, sharing a global pointer between instances in the same
process. And otherwise, you need to create your own copy of the data in
memory. But anyway, unless I'm misunderstanding, I don't think that this
example is one that applies to AU properties...
But anyway, it would probably be better for someone from Apple to clarify
this all than for us to continue to wittle out our best interpretations...
;-)
Marc
_______________________________________________
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.