Re: Multiple Output Music Device
Re: Multiple Output Music Device
- Subject: Re: Multiple Output Music Device
- From: William Stewart <email@hidden>
- Date: Thu, 16 Oct 2003 22:50:55 -0700
Art,
This is a bit tricky as the num channels property is only really
generally used to describe a common channel capability across all
busses/elements.
On 16/10/2003, at 8:16 PM, Art Gillespie wrote:
Ignoring the hacks I've had to use get multiple output AUs working in
the past,
I'm a bit curious as to whether I've got how it's *supposed* to work
right:
- Audio Unit reports the number of outputs to MusicDeviceBase
constructor, this
number corresponds to the number of output busses (elements on
the output
scope).
Yes
- Audio Unit reports the total number of channels via
SupportedNumChannels().
For example, if I had two stereo pairs and two mono outs, I'd
report 4 as my
number of outputs, and { 0, 6 } in response to
SupportedNumChannels()
This is definitely wrong, as not a single bus can be set to 6 channels.
Part of the motivation of having this property was to describe
alternate settings of channelisations (Which this is not really a case
of). Can I ask this - why are you providing 2 stereo pairs and 2 mono
outputs?
If I had to guess I'd say that you are providing a front stereo pair, a
surround stereo pair, a centre and an LFE channel?
In that case this really should be a single six channel output. We've
defined (and discussed previously) the AudioChannelLayout structure
that provides meta data about the channel ordering where a stream
description only describes the number of channels. This is also
described in the Panther SDK.
If your AU could render both to a 5.1 and a stereo output, then you'd
publish 2 channel configurations { {0, 2), (0, 6} }, then the channel
layout would express the order of the channels when set to either of
these two formats.
I can see that there might be some good uses for providing multiple
busses for different pairs of speakers - and we'd had some discussions
previously about providing a new property that would describe modes of
operations (essentially different element configurations where each
configuration would essentially have a different in/out element
configuration, most likely where the element count for each mode would
be fixed, and the channel numbers on each element would also be fixed)
- perhaps we should resurrect that idea?
I think in this case (and in the case you'd mention), as the stream
format would describe the number of channels (and that this is *not* a
settable property), that there would then be no need to publish any
supported num channels, as the element count/formats would describe
that capability.
- Host interrogates the Audio Unit for number of output busses
via
kAudioUnitProperty_BusCount
Yes
- For *each* output bus (element on the output scope), Host
interrogates the
Audio Unit for the element's StreamFormat via
kAudioUnitProperty_StreamFormat
Yes
- During render, AU calls GetOutput(n) to get the
AudioBufferList for the nth
bus. Each buffer list's mNumberBuffers member should
correspond with the
CAStreamBasicDescription.mChannelsPerFrame member returned by
kAudioUnitProperty_StreamFormat.
Yes
Is this right? Am I missing anything?
Best,
Art
>>0xBA
Bill
_______________________________________________
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.