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: Mon, 05 Mar 2012 06:32:55 +0100
Den 04:27 5. mars 2012 skrev David Duncan <email@hidden> følgende:
> Your assumption is that because you receive a pointer type, that the pointer must be valid in both address spaces.
No, my assumption is that if I pass a pointer type one address space,
then that pointer would be invalid in another address space. I also
make the assumption that therefore, if the plugin and view exist in
separate address spaces, it would be invalid to the view when passed
from the plugin, and that there is no point in passing a pointer that
might be invalid to whoever receives it.
> If you were dealing with a plugin that exists in a foreign address space, then part of the communication would involve serializing and deserializing data to pass between the address spaces.
Yes, that's what I thought too. What I don't understand is, I can't
find anywhere in Apple's own implementations they actually do this
with properties of type CFStringRef. It just looks like they copy the
pointer over raw.
Like here, in AUBase::DispatchGetProperty()
case kAudioUnitProperty_ElementName:
{
AUElement * element = GetElement(inScope, inElement);
if (element->HasName()) {
*(CFStringRef *)outData = element->GetName();
CFRetain (element->GetName());
result = noErr;
} else
result = kAudioUnitErr_InvalidPropertyValue;
}
break;
And AUElement::GetName()
CFStringRef GetName () const { return mElementName; }
Is there somewhere in the implementation where they make sure the
contents of the CFStringRef is also copied over? How should I myself
implement properties of type CFStringRef, according to standards? I
have't dug properly into the code, I'm fairly new to Audio Units.
>
> The warning is really more to do with passing a pointer from one plugin to another and to then use that pointer as further communication between plugins, as doing that assumes that both plugins are in the same address space. The key to the distinction is if you would expect changes in one plugin to appear immediately in the other without another API call - if you do, you've violated the rule.
But if that is the only requirement, it wouldn't really work in
separate address spaces, would it? Or on a separate machine, which
Apple says it should?
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