Re: Speaker setup + possible typo in CoreAudioTypes.h label value?
Re: Speaker setup + possible typo in CoreAudioTypes.h label value?
- Subject: Re: Speaker setup + possible typo in CoreAudioTypes.h label value?
- From: Derk-Jan Hartman <email@hidden>
- Date: Wed, 23 Mar 2005 21:29:05 +0100
OK. I understand it a little better now I think. Has anyone done this
before?
Just to show what I have for the LayoutTags alone so far, in order to
tell VLC what kind of channelmixing it will have to apply.
I'm just saying, it seems like an awful lot of code (and not even
finished) just to figure out which channels I have on my device.
case kAudioChannelLayoutTag_Mono: /* Mono */
p_aout->output.output.i_physical_channels =
AOUT_CHAN_CENTER;
break;
case kAudioChannelLayoutTag_Stereo: /* Stereo */
case kAudioChannelLayoutTag_StereoHeadphones:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT;
break;
case kAudioChannelLayoutTag_DVD_4: /* Stereo/LFE */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_LFE;
break;
case kAudioChannelLayoutTag_ITU_2_1: /* 2F1R */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_REARCENTER;
break;
case kAudioChannelLayoutTag_DVD_5: /* 2F1R/LFE */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_LFE | AOUT_CHAN_REARCENTER;
break;
case kAudioChannelLayoutTag_ITU_2_2: /* 2F2R */
case kAudioChannelLayoutTag_Quadraphonic:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT;
break;
case kAudioChannelLayoutTag_DVD_6: /* 2F2R/LFE */
case kAudioChannelLayoutTag_DVD_18:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT | AOUT_CHAN_LFE;
break;
case kAudioChannelLayoutTag_MPEG_3_0_A: /* 3F */
case kAudioChannelLayoutTag_MPEG_3_0_B:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER;
break;
case kAudioChannelLayoutTag_DVD_10: /* 3F/LFE */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER | AOUT_CHAN_LFE ;
break;
case kAudioChannelLayoutTag_MPEG_4_0_A: /* 3F1R */
case kAudioChannelLayoutTag_MPEG_4_0_B:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER | AOUT_CHAN_REARCENTER;
break;
case kAudioChannelLayoutTag_DVD_11: /* 3F1R/LFE */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_REARCENTER | AOUT_CHAN_LFE;
break;
case kAudioChannelLayoutTag_MPEG_5_0_A: /* 3F2R */
case kAudioChannelLayoutTag_MPEG_5_0_B:
case kAudioChannelLayoutTag_MPEG_5_0_C:
case kAudioChannelLayoutTag_MPEG_5_0_D:
case kAudioChannelLayoutTag_Pentagonal:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT;
break;
case kAudioChannelLayoutTag_MPEG_5_1_A: /* 3F2R/LFE */
case kAudioChannelLayoutTag_MPEG_5_1_B:
case kAudioChannelLayoutTag_MPEG_5_1_C:
case kAudioChannelLayoutTag_MPEG_5_1_D:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT | AOUT_CHAN_LFE;
break;
case kAudioChannelLayoutTag_Hexagonal: /* 3F3R */
case kAudioChannelLayoutTag_AudioUnit_6_0:
case kAudioChannelLayoutTag_AAC_6_0:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT | AOUT_CHAN_REARCENTER;
break;
case kAudioChannelLayoutTag_MPEG_6_1_A: /* 3F3R/LFE */
case kAudioChannelLayoutTag_AAC_6_1:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER | AOUT_CHAN_LFE |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT | AOUT_CHAN_REARCENTER;
break;
case kAudioChannelLayoutTag_AAC_7_0: /* 3F2R2M */
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_MIDDLELEFT | AOUT_CHAN_MIDDLERIGHT |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT;
break;
case kAudioChannelLayoutTag_MPEG_7_1_A: /* 3F2R2M/LFE */
case kAudioChannelLayoutTag_MPEG_7_1_B:
case kAudioChannelLayoutTag_MPEG_7_1_C:
p_aout->output.output.i_physical_channels = AOUT_CHAN_LEFT
| AOUT_CHAN_RIGHT | AOUT_CHAN_CENTER |
AOUT_CHAN_MIDDLELEFT | AOUT_CHAN_MIDDLERIGHT |
AOUT_CHAN_REARLEFT | AOUT_CHAN_REARRIGHT | AOUT_CHAN_LFE;
break;
case kAudioChannelLayoutTag_UseChannelBitmap:
msg_Dbg( p_aout, "bitmap defined channellayout" );
break;
case kAudioChannelLayoutTag_UseChannelDescriptions:
msg_Dbg( p_aout, "channeldescriptions defined
channellayout" );
break;
On 23 mrt 2005, at 20:40, William Stewart wrote:
On 23/03/2005, at 8:51 AM, Derk-Jan Hartman wrote:
I have been looking at the issue of channels, layout, speakers and
mixing.
ACL = defines channel layout trough either ACLT, ACBm or ACB
ACLT = defines a standard speaker setup or says a bitmap or
description is used
ACBm = defines which channels are available trough the use of ACB
ACB = bitlabels for channels defines which speakers are present.
So, lets make a division here.
The layout tag thus must be one of the following three categories
UseBitmap
UseChannelDescription
PredefinedLayout
In the bitmap case the accompanying bitmap describes 2 things:
(1) Which channels are there
(2) The order or those channels
- the order is implied by the order of the channels in the bitmap
This is the scheme used by WAV and USB
A further note is that if you are using a predefined layout, you can
also provide channel descriptions to describe the channels. If there
is a discrepancy between the implied order of the layout and the order
of the channel descriptions, the behaviour is undefined.
ACD = defines for each channel what the speaker setup is with
ACLabels.
AClabel = predefined speaker labels can also set that the channel is
defined in coordinates.
Now as far as I can tell none of this is obligatory to ALWAYS be
present.
Not quite - a layout tag must be specified. In many cases a layout tag
is all that needs to be described as it expresses all of the
information you need. For eg, AU_5_0 says:
There are 5 channels
The channels are: L, R, LS, RS, C
The locations of those channels are predefined.
you can choose what you want to use.
This poses the following problem for VLC. AUHAL does not support
downmixing.
correct
Therefore VLC has to do it.
We provide support with the AudioFormat API to give you matrix
co-efficients to do this.
From AudioFormat.h;
kAudioFormatProperty_MatrixMixMap = 'mmap',
// Returns a matrix of scaling coefficients for converting
audio from one channel map
// to another in a standard way, if one is known. Otherwise
an error is returned.
// The specifier is an array of two pointers to
AudioChannelLayout structures.
// The first points to the input layout, the second to the
output layout.
// The value is a two dimensional array of Float32 where the
first dimension (rows)
// is the input channel and the second dimension (columns) is
the output channel.
But to me it's sheer impossible to find out what channels should be
downmixed to. I mean how am i supposed to know what channel is LFE,
what channel is the Center speaker.
Well, that's all clearly specified either:
(1) In the bitmap
(2) In the channel descriptions
(3) Implied in the layout tag
That's how we implement the above property
If I'm VERY out of luck the things can even be specified by
coordinates.
It seems this system is more designed to account for channel layout
and positioning and not so much for keeping score of speaker presence
and speaker nature.
My sonica theater seems to use ACD with AClabels, but other devices
can simply have the ACLT set and nothing else?
Am I missing something here? Is there an easier way to figure out
which speakers are available for output?
Is it REQUIRED for instance that drivers set a proper ACBmap? If so
than this is not clear from the headers (let alone the documentation
:D ) and should be clarified, if it is not then maybe it would be a
good idea to have that as a requirement?
The requirements are pretty clear I think, but yes, it is complicated
even when dealing with just a few channels like 5.1 for instance.
Also, i spotted the following in my list of ACLabels in the headers:
kAudioChannelLabel_RightCenter = 8,
kAudioChannelLabel_CenterSurround = 10,
kAudioChannelLabel_LeftSurroundDirect = 10,
Thanks - yes, I think we might have caught that as well: This is how
it is now
kAudioChannelLabel_RightCenter = 8,
kAudioChannelLabel_CenterSurround = 9, //
WAVE: "Back Center" or plain "Rear Surround"
kAudioChannelLabel_LeftSurroundDirect = 10, //
WAVE: "Side Left"
Bill
That centersurround value seems a bit strange to me. a value of 9
would seem more logical?
DJ
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
-- 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
_______________________________________________________________________
___
---
Universiteit Twente
Derk-Jan Hartman (d.hartman at student.utwente dot nl)
http://home.student.utwente.nl/d.hartman
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden