A modest proposal
A modest proposal
- Subject: A modest proposal
- From: Glenn Olander <email@hidden>
- Date: Sun, 14 Nov 2004 07:27:20 -0800
AU I/O configuration has been a persistent source of trouble with AU's
from the beginning. The list archives contain many posts from
developers who are confused by the topic. After 2 years, nobody has
succeeded in fully implementing the multiple output design proposed in
the spec. Flexible I/O configurations is one of the most significant
advantages AU has over VST, but if this advantage exists only on paper,
then what have we achieved? I humbly suggest that the problem isn't
with developers, but with the spec itself, and the solution is to
change the spec. Since it hasn't yet been fully implemented anyway, now
seems like an opportune time to make such a change. The following is a
proposal for such a change, and is in the spirit of some changes Bill
proposed a while ago, but addresses the complexity problems Marc and
others identified in Bill's suggestion.
I believe the problem with multiple outputs in the current spec is
two-fold:
1) The design proposed in the spec is overly complex.
The byzantine nature of the way a plugin describes its bus
configurations and channel configurations has been a source of trouble
from day one. The lack of coupling between busses and channels, the
negative numbers, the obscure way the supported bus count is described
to the host, etc. have led to a great deal of confusion.
2) The design proposed in the spec does not match the needs of
users/host developers/plugin developers.
Those few people who have overcome the complexity of the spec to
understand I/O configurations, are then confronted with the realization
that
the semantics used by the plugin to published its supported I/O
configurations do not match the way plugin developers think of their
I/O configurations, nor does it match the way users think of their
choices of I/O configurations.
I propose we change the spec as follows:
A) A plugin publishes its supported I/O configuration in a simple and
unambiguous fashion. It should describe:
- The number of supported configurations.
- The number of input and output busses in each configuration.
- The number of channels in each bus.
For example, an output-only plugin which supports 2 configurations, one
with a single stereo out, and second with three stereo outs and one
mono out would publish the following information via GetProperty:
Number of Configurations: 2
Configuration 1 (1 bus):
Output Bus 1: 2 channels
Configuration 2 (4 busses):
Output Bus 1: 2 channels
Output Bus 2: 2 channels
Output Bus 3: 2 channels
Output Bus 4: 1 channel
For example, the AU code would look something like this:
static AUIOConfigInfo info = {2, {1, {2}}, {4, {2, 2, 2, 1}}};
This is much more explicit than the current spec and makes it possible
to understand what configurations are supported, especially when trying
to see how many channels are on each bus. If you have a large/dynamic
set of configurations you can support, the first choice should be to
explicitly list them all. If that is not possible, the spec could be
expanded to include wildcarding (e.g. 0 channels means any number).
B) A host selects from the set of configurations published by the
plugin.
By default, the host/plugin use the first configuration published by
the plugin. However, while the AU is uninitialized, the host may
select, presumably on behalf of the user, any of the published
configurations by simply specifying the configuration index number via
SetProperty.
For example, a new property (for example, call it
kAudioUnitProperty_IOConfig) would have an integer datum. In the above
example, sending 0 to the AU would select the single stereo output
configuration. Send 1 would select the four output configuration. This
gives the AU a clear indication, outside of Render(), of what
configuration the host expects.
I believe this proposal is the best way to jump start support for
multiple outs in AU's. Also, it is easy to transition to this model: if
the AU doesn't support the new configuration property, then the host
can simply fall back to whatever it does now.
- Glenn
_______________________________________________
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