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 16:50:00 -0600 (CST)
On Sun, 26 Oct 2003, William Stewart wrote:
>
> 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.
<snip>
Hmmm, okay, I guess I was thinking that if you have an array of
AUChannelInfo for one element and an array for another, item 1 in each
array were taken as being part of a set, but I guess that isn't how it
would be, and also maybe couldn't for some cases.
>
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!)
Yeah, I see what you're saying now... Well, I will just then add to some
concern that I have, regarding confusion and complication. I don't have
any proposals to offer, but I just think that you should be careful to try
to make it so that there is not more than one way to do the same thing
with respect to SupporteNumChannels vs. I_O_Configurations. That's just a
recipe for mistakes, I think. I think that it would be best if they each
served their own very distinct and clearly defined and delimited purposes.
What happens if an AU supports both I_O_Configurations and
SupportedNumChannels? Might that have to be the case if some allowable
configs include wildcards (not possible with I_O_Configurations) while
others include inter-bus dependant requirements (requiring
I_O_Configurations)? Is the StreamFormat property ignored if
I_O_Configurations are used? I just think that all of this should be very
clear so that everyone who is implementing AUs knows how to publish their
info, and that there hopefully be only 1 way to do it for any given AU's
requirements, otherwise I fear things getting messy, confusing, and
inconsistent.
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.