Re: Audio Unit Properties that are CFStringRef
Re: Audio Unit Properties that are CFStringRef
- Subject: Re: Audio Unit Properties that are CFStringRef
- From: David Duncan <email@hidden>
- Date: Mon, 05 Mar 2012 20:35:18 -0800
On Mar 5, 2012, at 10:00 AM, Kyle Sluder wrote:
> So we arrive at the real outstanding questions:
>
> 1. Who marshalls property values across the boundary from view to audio
> unit? Is this the responsibility of the host, the view, or the Audio
> Unit API?
It can't be the audio unit or the view, because as neither has enough information to do this correctly (minimally, neither component can directly connect themselves with their counter part).
Therefore the only obvious choice is that its the responsibility of the host. This makes sense, as only the host could conceivably determine the situations under which this is reasonable, as well as the only element that can reasonably setup this configuration.
> 2. How are complex types like CFString marshalled? Are they even
> supported? Or do the endpoints need to convert them to a simpler type
> like an integer or a plain old data type like a struct? If so, how does
> this jibe with the AU properties whose values are documented to be of
> type CFStringRef?
This is going to depend on the host itself. Presumably hosts that implement remote AUs will use the same method Logic does, in which case AudioUnit/LogicAUProperties.h has more information. If not, you would probably need to consult those hosts for specific details.
If they don't even have a specification, then they would have to fall back to the declared types of existing documented properties and treating everything else as a plain old bucket of bits.
> 3. If AudioUnitSetProperty can in fact automatically marshall complex
> types like CFString, how does it know that the property value being set
> is of a nontrivial type like CFString? How does it marshall those
> values?
There's a built in assumption in the phrasing that the Core Audio API does the marshaling - it doesn't, the host does. If you follow the basic rules for AUs, then the host can treat all standard properties in a way that allows for marshaling, and other properties as buckets of bits. If you follow additional rules (such as the Logic rules above) then both the host and the AUs can do more sophisticated things.
But either way, its the host's responsibility to marshal the data. Cooperation from the AU can help, but that corporation is more likely to take a form similar to what Logic does (which is to augment the standard configuration with a property that provides more information than the base API provides).
I'll note that I didn't discover the LogicAUProperties.h header until this evening (I knew of Logic's implementation generically, but no specifics and didn't think to look in the AudioUnit framework for it!). I would highly recommend reading it, as it explains a lot.
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. 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.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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