Re: Multiple Output Music Device
Re: Multiple Output Music Device
- Subject: Re: Multiple Output Music Device
- From: Art Gillespie <email@hidden>
- Date: Fri, 17 Oct 2003 16:54:09 -0400
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
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
On Friday, October 17, 2003, at 03:53 PM, William Stewart wrote:
OK - I'm just trying to conjure up an example of how to break this and
I can't... Seems like a good idea to do it this way.
This implies a certain channel relationship between in and out
capabilities on the same element ID...
Bill
On 17/10/2003, at 6:04 AM, Marc Poirier wrote:
On Thu, 16 Oct 2003, William Stewart wrote:
Art,
This is a bit tricky as the num channels property is only really
generally used to describe a common channel capability across all
busses/elements.
This still seems like just a mistake in the SDK to me. Will
AUBase::SupportedNumChannels be modified in the next SDK revision to
have
an Element argument so that channel configurations can be queried
per-element?
I have another example that might make more sense to you: Let's say
you
have a vocoder that is designed for stereo carrier input and mono
modulator input. Currently there's no way to describe that setup
unless
you hack the SDK to make SupportedNumChannels() bus-aware.
Marc
-- mailto:email@hidden
tel: +1 408 974 4056
_______________________________________________________________________
___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________
___
_______________________________________________
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.