Re: Channels, Busses and I/O Configurations
Re: Channels, Busses and I/O Configurations
- Subject: Re: Channels, Busses and I/O Configurations
- From: Marc Poirier <email@hidden>
- Date: Sun, 26 Oct 2003 15:10:08 -0600 (CST)
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...
>
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.
>
(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. 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.
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.