Re: bus count and channel info confusion
Re: bus count and channel info confusion
- Subject: Re: bus count and channel info confusion
- From: William Stewart <email@hidden>
- Date: Fri, 23 Jul 2004 12:44:21 -0700
Another case: (more of a usage scenario, and more to do with how
formats might be handled)
13. Spliiter Effect
Input Bus Count: 1, not writeable
Output Bus Count: 2, not writeable
Channel Info: {-1,-1}
In this case the output of the second bus will always have the same
number of channels as the first bus. Its just taking the input and
duplicating this to both outputs.
Question then becomes about setting formats. My inclination is to
disallow setting the format on the second bus and just have the second
bus' format shadow the first bus.
There is a primacy that we've given the in and out element 0 - in
normal usage that's the bus that is used first and foremost.
Hosts typically present an effect to insert in a strip based on
connecting to these elements (and on the channel capabilities) and I'm
sure do not currently set channels on other elements for side-chains
until later.
I'm also concerned that hosts should NOT have to figure out how to
configure alternate outputs until a user decides how they want to use
them - where at the point some UI can be provided to allow the user to
configure those based on a given AU's capabilities.
So, if this type of AU didn't "take care of itself" to some extent here
is what can happen:
AU starts as:
In - 2
Out - 2 2
AU is used in host to do mono to mono on element 0. If the AU doesn't
take care of handling the channels of its second output, you get the
following (and you'd never be able to get it to pass initialization):
In - 1
Out - 1 2
If the AU does handle this by:
Output Element 1's format is never writable by the host
Output Element 1's format shadows element 0
then you get:
In - 1
Out - 1 1
The AU successfully initialises, the host can then see that it has a
second output it can use as a tap. the host also does NOT have to
"guess" at a way to configure these additional outputs (and inputs) on
an initial instantiation of the AU into its processing chain, and can
then present options to the user for reconfiguration.
This is actually how the AUValidation tool does its format tests anyway
- but I thought I should spell this out. By the AU doing something
"reasonable" when it has alternate inputs or outputs, the job of
hosting these can be substantially more intelligible and manageable.
Once again, its probably worth re-iterating that publishing any complex
I/O capabilties using the Dynamic Channel Configuration is by far the
best and most simplest to implement both for the host and for the AU.
Thanks
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.