Re: Multiple Output Music Device
Re: Multiple Output Music Device
- Subject: Re: Multiple Output Music Device
- From: Marc Poirier <email@hidden>
- Date: Fri, 17 Oct 2003 16:44:30 -0500 (CDT)
On Fri, 17 Oct 2003, Art Gillespie wrote:
>
I'm not sure I agree completely...
>
>
As you point out, it implies (requires?) an assumption about pairing of
>
input/output scope elements (which, I think, is the real root of the
>
problem now). If I have an audio unit with no inputs and two outputs
>
each with two channels, how would I respond to
>
>
kAudioUnitProperty_SupportedNumChannels, kAudioUnitScope_Input,
>
Element:0
Currently, the response is kAudioUnitErr_InvalidScope (using the AUBase
SDK). I think that one thing that you missed here is that Global is
currently the only valid scope for querying the SupportedNumChannels
property. That's because stream formats are given in in/out pairs. I
think the current way to go about a non-existant input is to just have a
{0, n} response.
The reason why they're paired like this is because I think that usually
the allowable number of inputs is dependent on the number of outputs (and
vice versa). In other words, it's likely that a unit can't just do 1 or 3
inputs and 3 or 9 outputs. It's could be something like 1 in only with 9
out, and 3 in only with 3 out.
But anyway, that doesn't really affect your general request to break
things and take a totally different approach. I'm not really writing to
say whether I think that's a good idea or not, cuz I'm not sure what I
think personally, but I just wanted to clarify the way things work now
because I think your message indicated a little bit of misunderstanding in
one area. I might have just misunderstood you, though, I'm not sure...
Marc
>
In truth, there is no such element, so I'd be a correct little audio
>
unit to return kAudioUnitErr_InvalidElement. However when called with:
>
>
kAudioUnitScope_Output, Element:0, I'd be expected to respond with { 0,
>
2 }. When in actuality, this should probably be { undef, 2 }.
>
>
Likewise, if I have a single stereo input effect device with four
>
auxiliary stereo outputs (say, a band-splitter which can optionally
>
route individual bands to a different output bus), there's no
>
'channelization' for these additional output elements, and again, it
>
seems to me the correct response on one of these auxiliary outputs
>
would be { undef, 2 }.
>
>
My feeling is that instead of overloading the semantics, each element
>
should simply return an array of scalars representing channel
>
configuration. It seems much more like 'negotiation' to me if the host
>
first sets formats (namely, mChannelsPerFrame) on input buses and then
>
queries *all* output buses for the number of outputs given the current
>
input configuration. This scheme also allows for inter-bus
>
dependencies.
>
>
To use my band-splitter example, the number of input channels on the
>
first bus could very well affect the output channels of the auxiliary
>
bus (if the input element is mono, all the aux outputs should be mono,
>
too, etc.), but if we assume/require a 1-to-1 mapping of inputs to
>
outputs, it's not really possible to express that. However, if each
>
element reports its acceptable channel configurations independently,
>
hosts can build a tree like
>
>
- query input element 1 for acceptable number of input channels
>
- for each acceptable input configuration
>
- SetStreamFormat(nChannels)
>
- for each output buss, query number of acceptable channels
>
(given current input settings)
>
>
While this could be seen as needless overhead, in practice it only
>
needs to be done once when the Audio Unit is first installed. The host
>
figures out which of the Audio Unit's configurations it can support,
>
stores those configurations, and presents them to the user at load time.
>
>
I guess the only difference between what I'm describing here and how it
>
works currently if the AU doesn't respond to SupportedNumChannels at
>
all, is that the AU would have an opportunity to limit the amount of
>
querying necessary by the host by saying, "don't even waste my time by
>
trying to set format on this element with n channels".
>
>
Finally, this scheme seems much closer conceptually to the rest of the
>
AU SDK/Spec where inputs and outputs are treated atomically. Of
>
course, I'm aware that Marc's change is a simple matter of modifying
>
the SDK, whilst what I'm proposing would actually break the component
>
contract. Still, I think it's worth considering for a future AU update.
>
>
My .02
>
>
Best,
>
>
Art
>
>>0xBA
_______________________________________________
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.