Re: Channels, Busses and I/O Configurations
Re: Channels, Busses and I/O Configurations
- Subject: Re: Channels, Busses and I/O Configurations
- From: William Stewart <email@hidden>
- Date: Sun, 26 Oct 2003 13:54:46 -0800
On 26/10/2003, at 1:10 PM, Marc Poirier wrote:
On Fri, 24 Oct 2003, William Stewart wrote:
- 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.
But I still don't understand, why not just make SupportedNumChannels
bus-aware? I don't think that this is going to break anything since,
given the current state of things, no one is making use of bus
fanciness
yet anyway...
See below...
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...
This is my least favorite of the proposals. The problem with this is
that
hosts identify AUs by their type / subtype / manu combo and also valid
settings dictionaries are recognized by these, too. So a host wouldn't
recognize the alternate config plug as a valid option when restoring a
session and settings couldn't be loaded between the 2 different config
plugs because they would be seen as invalid if created with the other
i/o config version of the plug.
Yes - I don't like this either...
(2) Introduce a new property:
kAudioUnitProperty_I_O_Configuration
and kAudioUnitProperty_I_O_ConfigurationName
and kAudioUnitProperty_I_O_NumConfigurations
This in a way seems nice, although on the other hand, I think that it
starts to make the AU API seem too complicated to newcomers.
True - but this is in response to requests from AU developers (we're
not pushing this), but if AU developers are going to provide this
functionality, then I think we need to formalise how... This was
discussed a few months ago (and we'd had the thought about the I/O
configurations then, but noone was pushing this, so we decided for the
reasons you described, not to either).
There's
already SupportedNumChannels and StreamFormat properties to deal, this
I'm
pretty sure would add quite a bit of confusion for a lot of people.
But
there is something nicer about just setting a configuration all in one
go
rather than input and output stream formats separately, and giving them
names and such. But then it also seems like this is just cluttering
things up with different ways of doing very similar things. And I
guess I
still just think that SupportedNumChannels should be per-element.
I actually think this is a more complex solution... The situation Urs
outlined becomes a nightmare of parsing and estimating channel/element
capabilities.
The thing that has also always bothered me about the DLS Synth (and
Chris has reminded me recently that this is my fault!), is that when
the internal reverb is ON, it has two output elements, but only one is
actually active (and it has two because when internal reverb is off, it
provides you a reverb send mix and a dry mix)
Also in the example of the 5.1 synth, the supported num channels
doesn't really tell you correct information. So, by your scheme you'd
get the following:
0 - {0,2}, {0,6}
1 - {0,2}
2 - {0,1}
3 - {0,1}
Well and good, but now you change the channels of output element 0 and
elements 1-3 are suddenly not really useful at all (ie. those elements
are essentially unused) - same problem as the DLS Synth. So, do you set
the output element count to 1? What if you have have connections to
those elements? What happens when you change element 0 back to 2
channels? There's nothing in the current definition of supported num
chans logic (or other properties for that matter), that states (nor
should it) to a host that the element count can change if channels are
changed.
Yet really, I think this is what we should be doing, so the element
counts really reflect the potential in/out points of an AU (not ones
that are reserved for use, that when used, if the unit isn't configured
just so/so, don't give you anything).
With the kind of configurations Urs was describing, I've no idea how a
host, really makes sense of that using supported num channels...
(especially as a half-dozen or so configurations would do the trick
nicely)
I like the idea of a configuration property - as it I think elegantly
solves this problem by making it explicit and by saying that the
setting of it can radically change the I/O configuration of the AU...
(we can put this in the advanced section of our copious documentation!)
Bill
Anyway, those are just my reactions to these ideas...
Marc
_______________________________________________
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.
--
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.