Channels, Busses and I/O Configurations
Channels, Busses and I/O Configurations
- Subject: Channels, Busses and I/O Configurations
- From: William Stewart <email@hidden>
- Date: Fri, 24 Oct 2003 13:17:28 -0700
This is a follow on to previous posts on multi-bussed/different channel
configuration capabilities in AU. I thought it might be useful to
review some of the logic of how this works in today's world, then
present a proposal for a resolution or at least a point to continue
discussions....
Firstly SupportedNumChannels:
Describes the I/O channel capabilities of an AU. The way this property
(which is defined to be global scope, el==0) works is to describe
channel capabilities *regardless* of which element ID on in or out
scope we are considering.
Thus:
Stage 1
- today's usage (lets call this the simple usage)
An AU Effect with 1 in, 1 out element, uses this property to describe
its channel capabilities. As many effects by default will only deal
with the same number of channels in to out (and that num channels is
"irrelevant"), we assume that if an aufx unit doesn't support this
property, then it can do exactly that. The AU can of course publish
this as a {-1,-1} config... (ie. same number of channels on in and out,
can be any number of channels)
The DLS Synth that we ship publishes a { 0,2 } capability. It has
either 1 or 2 active output elements (though it always publishes 2) and
takes no input (its input element count is zero). The value of the
InternalReverb property determines if there is one or two active
elements on its output.
Both the Converter and MatrixMixer units can take any number of
channels in and out - the converter only has a single in and out
element, the MM can have any number of in or out elements, with each
element being any number of channels. Both AU's publish {-1, -2} - and
the element count for in or out scope's writable property can be used
to determine say the difference between the converter and the MM...
The problem is when you have more than one in or out element, and the
different elements have constraints on their number of channels. (Urs
presented a rather complex example, but I'm going to present a simpler
one as the second stage to solving this problem!)
Stage 2
- proposed modification of common usage that I think has no
ramifications for today's hosts.
Lets say we have a Synth that can do 5.1 and it publishes 4 output
elements where the channels are 2/2/1/1 respectively (L,R/SL,SR/C/LFE
perhaps).
The problem is trying to publish this channel capability using the
SupportedNumChannels property - because some of the elements (the first
2) will *only* be stereo, the last 2 *only* mono.
In this case, I think the cleanest resolution is to *not* support the
property at all.
If the property is not supported the following behaviours/assumptions
can be made by hosts:
(1) An AU is an effect type of unit (this essentially covers AU's of
type 'aufx', 'aufm' and 'auol' (offline units))
- assumption is today's practise (host assumes unit can do {-1,-1}
config
(2) An AU Panner unit will be expected to support this property (as it
is currently specified, this is a single in to out I/O path)
(3) A Synth unit ('aumu')
- Doesn't publish property, then it is assumed that its initial
configuration represents its channel and I/O possibilities.
Thus for the 5.1 synth above, its initial config would be 4 output
elements, with channel counts of 2,2,1,1 - It would be good to give
those elements names! (for instance, front pair, surround pair, centre
(note correct spelling:), LFE)
We also expect that in this case, these elements could also publish
AudioChannelLayouts where the tag is use channel descriptions, and the
channel labels would be
Element 0:
desc==2
desc[0] = left
desc[1] = right
Element 1:
desc=2
desc[0]=surround left
desc[1]=surround right, etc...
In this case as well, we could feasibly not publish the {0,2}
NumChannels property of the DLS Music Device (as it can only be
configured to have stereo outputs.
Stage 3
- Additional I/O Configurations.
Lets extend the example above, and say that I have 2 ways that I can
publish my 5.1 synth. The way described above, and another way, which
is a single mixed element of 6 channels - my 5.1 output.
I can't use the SupportedNumChannels for the same reason - some
elements in one of these configurations would only be mono, some
stereo.
There's two ways to do this I think. One will work with existing hosts,
one would need additional host support.
(1) Publish 2 different AU's for these configurations - these both work
as described above, and the AU code can be more or less the same for
both AU types (we have the same code that deals with version 1
(interleaved) and version 2 (non-int) for our DLS Music Device and
other AU's.... The AU determines which way (the muxed or separated) its
been opened, and configures its format handling and rendering
appropriately - most of the code can be shared between the two AU's...
(2) Introduce a new property:
kAudioUnitProperty_I_O_Configuration
and kAudioUnitProperty_I_O_ConfigurationName
and kAudioUnitProperty_I_O_NumConfigurations
In this synth example, the single AU would support this property. It
would have 2 I/O configs:
(a) Muxed Mode
(b) Multiple Output Mode
kAudioUnitProperty_I_O_Configuration - value is UInt32 (read/write)
kAudioUnitProperty_I_O_NumConfigurations - value is a variable num of
UInt32 (read only)
kAudioUnitProperty_I_O_ConfigurationName - value is a CFStringRef -
(released by caller:) (read only)
The host sees that the AU supports this property. Finds out that there
is 2 (by calling GetPropertyInfo on
kAudioUnitProperty_I_O_NumConfigurations)
The Host then iterates through the number of configurations, setting
the AU -(AND THE AU MUST NOT BE INITIALIZED!!!!!) - using SetProperty -
kAudioUnitProperty_I_O_Configuration. (ie.
kAudioUnitProperty_I_O_Configuration is ONLY settable if the AU is not
initialized)
As the host does this, the AU configures itself, including:
Number of Input and Output Elements
Formats on each of its Input and Output Elements
(ie. once an AU is in a configuration, it behaves as in stage 2 above)
A configuration's name can be retrieved
Another Example:
The DLSMusicDevice could publish 2 configurations:
(a) Mix Mode - 1 output element of 2 channels
(b) Reverb Send Mode =- 2 output elements of 2 channels each.
I think for some minimal work on the AU's part and the host's part,
this is an elegant way to deal with this problem. However, in many
usage scenario's it would only be used in the creation of a track or
set of tracks, so the idea of publishing different AU types is also not
too unreasonable, though I think I prefer the I_O_Configuration
methodology.
One other thing that is interesting about configurations is the ability
to express different modes of operation - for instance some configs
would take input, some wouldn't, some might generate output elements
for parameterized (or MIDI) streams.
An additional feature of some modes would be the ability to have the
element count be writable - in that case you'd either:
(1) Get All say stereo output busses (and SupportedNumChannels in that
config would be implemented and report {0,2}
(2) Have additional elements where the format is set when the element
is created (ie., the num channels or if its MIDI etc, is "not
writable")
In these cases as in the DLSMusicDevice - Sample Rate would be set as
GlobalScope, ElementID == 0 - and that would set the sample rate for
the entire unit.
Bill
--
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.