Re: Audio Unit Properties that are CFStringRef
Re: Audio Unit Properties that are CFStringRef
- Subject: Re: Audio Unit Properties that are CFStringRef
- From: Per Bull Holmen <email@hidden>
- Date: Tue, 06 Mar 2012 17:35:41 +0100
Den 05:35 6. mars 2012 skrev David Duncan <email@hidden> følgende:
> I also misspoke a bit in my last message, as I should have constrained my statement about marshaling specifically to standard (and well known) properties. That probably didn't help things much.
Yes, that must have been the source of some of the confusion.... :)
My original question was that I had read Apple's guidelines that
stated "never assume a common address space", and "always pass data by
value, never by reference" to mean that I could never pass data
between an AU and its view through a pointer, that I'd always have to
copy the data over or serialize/deserialize. Because Apple's
implementations in AUBase seemed to contradict this rule, I thought I
had read Apple's guidelines wrongly or that I had misunderstood
something else. What I wanted to know, which I probably explained
clumsily(!), was how to read it correctly, so I could rest assured
that I'd follow the right principles in my own implementation. I think
we now have arrived at the real answer to my questions: "Yes, you read
Apple's guidelines correctly. On the other hand, standard properties
that are documented to be of pointer types like CFStringRef are
exceptions. Only with these properties, you can pass a pointer to the
data rather than the data itself, you can assume a transport layer
will assure that whatever pointer is received in the other end, will
be valid in the other address space. But you can't manipulate the data
on the other side and expect the changes to be reflected on both
sides."
> The basic rule still applies however - you cannot expect to have access to the counterpart plugin's address space. Thats the biggest, most major rule to keep in mind. If you keep that in mind, you'll be the vast majority of the way there.
I think perhaps your repeated attempts to reconcile the behaviour of
API-defined properties of CF type with Apple's general guidelines for
implementing properties that has also made me a bit confused. I don't
think it is as simple as you suggest, because once I start to assume a
transport layer that marshals complex types that are passed by
reference, I can't know where to stop. Why can't I also assume some
fancy-schmancy mechanism that makes sure any change made in one
address space is propagated through the IPC, network or whatever
boundary to be reflected in the other? In that case, I'm not assuming
a common address space. I think the answer is, as long as Apple
doesn't state it explicitly, no such mechanisms can be assumed to
exist at all, neither for static data, nor for data that can be
changed to be reflected on both sides. Clearly we can make an
exception to this for API-defined properties of CF type, since Apple's
own implementation in AUBase relies on such a layer, and there doesn't
seem to be any other way of passing property data that is documented
to be of pointer types.
Per
_______________________________________________
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