Re: Audio Unit Properties that are CFStringRef
Re: Audio Unit Properties that are CFStringRef
- Subject: Re: Audio Unit Properties that are CFStringRef
- From: Kyle Sluder <email@hidden>
- Date: Mon, 05 Mar 2012 10:00:03 -0800
On Mon, Mar 5, 2012, at 07:53 AM, David Duncan wrote:
> I'm not entirely certain if we're on the same page after reading this.
Perhaps it would be helpful to reformulate the original question, if I
may:
It is obvious from the documentation that property values might need to
be marshalled across an IPC boundary (or even a network boundary) from
the audio unit (running in the host's process space) to the view running
in the process space of whatever is displaying it (perhaps another
instance of the host app running on another machine).
The OP notes that the API is misleading: it takes pointers to the values
that need to be marshalled. Clearly the pointer values themselves cannot
be marshalled; it is the data that is pointed to which is marshalled.
Indeed, OP cited the documentation which makes this point clear; the
confusion stems from conflating the semantics of the API
(pass-by-reference) with the semantics of the audio unit specification
(pass-by-value). I'm guessing this is done to avoid needless copying
when passing structs as property values to the API.
For integers, floats, and even many structs, the marshalling is trivial:
just blat the bits, perhaps with a byte-order swap. But for property
list objects like CFString and CFDictionary, it is not. Instances of CF
types are themselves pointers. This is why they can be cast to their
toll-free bridged Foundation equivalents: CFStringRef == NSString *. Yet
some built-in audio units are defined to have values of types like
CFString and CFDictionary.
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?
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?
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?
--Kyle Sluder
_______________________________________________
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