Subject: [clue] Note that XY-stereo microphones are commonly available

From: John Leslie <[email-masked]>
Date: Fri, 9 May 2014 10:38:46 -0400

A mediaCapture can refer to a stereo microphone; but the
audioChannelFormat for "stereo" is too generic, IMHO. An XY-stereo
microphone produces two streams which represent ~90 degrees difference
in orientation, but no difference in position.

   This is very useful, but needs to be processed entirely differently
from a stereo pair separated by a significant distance and aimed in
approximately the same direction.

   Clearly, the audioChannelFormat enumeration-list needs to be
expandable, and we should specify how to expand it in the future
(e.g. IANA-FCFS)

--
John Leslie <[email-masked]>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 9 May 2014 14:40:35 -0700

I had a different proposal about the Audio Channel Format attribute.  I think we should consider it along with John's proposals about 5.1 format and XY-stereo.

I'm thinking this "audio channel format" parameter is really a characteristic of a particular audio *encoding*, not an audio *capture*.

So my idea is we should remove this audio capture attribute from the framework and data model.  The format of a particular audio encoding would be described entirely in SDP (not CLUE messages).  And a media provider could advertise one single audio capture for the whole room, which maybe it could encode as mono, or stereo, or 3 channel, or surround sound, or whatever.  Or maybe even offer multiple encodings for simulcast, but these are still all just different encodings of the same audio capture.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of John Leslie
> Sent: Friday, May 09, 2014 10:39 AM
> To: [email-masked]
> Subject: [clue] Note that XY-stereo microphones are commonly available
> 
>    This is very useful, but needs to be processed entirely differently from a
> stereo pair separated by a significant distance and aimed in approximately
> the same direction.
> 
>    Clearly, the audioChannelFormat enumeration-list needs to be expandable,
> and we should specify how to expand it in the future (e.g. IANA-FCFS)
> 
> --
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: John Leslie <[email-masked]>
Date: Sun, 11 May 2014 21:54:45 -0400

Duckworth, Mark <[email-masked]> wrote:
> 
> I had a different proposal about the Audio Channel Format attribute.
> I think we should consider it along with John's proposals about 5.1
> format and XY-stereo.
> 
> I'm thinking this "audio channel format" parameter is really a
> characteristic of a particular audio *encoding*, not an audio *capture*.

   Hmm... That sounds funny...

> So my idea is we should remove this audio capture attribute from the
> framework and data model. The format of a particular audio encoding
> would be described entirely in SDP (not CLUE messages).

   I'm not _opposed_ to that; but there are _so_many_details_...

> And a media provider could advertise one single audio capture for the
> whole room, which maybe it could encode as mono, or stereo, or
> 3 channel, or surround sound, or whatever. Or maybe even offer
> multiple encodings for simulcast, but these are still all just
> different encodings of the same audio capture.

   Mark is correct that a whole-room feed may be appropriate to receive
in different formats: obviously folks who want to render mono might
balk at receiving six channels in order to do so.

   I'm not sure how to manage that, though. If a mix is prepared in
5.1 surround, I doubt that SDP is the right conduit for negotiating
the number of channels -- offhand that sounds like a middlebox task.

   And I'm _sure_ SDP isn't the right conduit for remapping the
components of a whole-room feed to fit an incompatible conference
room paradigm.

   (Nonetheless, there probably should be _some_ consideration of
conserving bandwith for receivers that don't do surround-sound...)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 May 2014 10:50:37 -0400

> approximately the same direction.

ISTM that in case of stereo there are at least two different axis of 
capture values and possibly two point of capture values. We don't have a 
way to represent that in a description of a single unmixed capture.

We could try to expand the definition to allow it, or we could simply 
expect a stereo capture to be described as a mix.

Since I think it can be done as a mix, that seems preferable to me.

	Thanks,
	Paul

---

From: John Leslie <[email-masked]>
Date: Mon, 12 May 2014 11:09:09 -0400

> way to represent that in a description of a single unmixed capture.

   An XY-stereo mike can be nicely represented by a single point of
capture and two axes of capture; but in fact those two have a fixed
relation to each other. Thus, using a single axis of capture, with
the two offsets known, would be a perfect representation.

   (Alternatively, using the same "averaged" axis of capture, the
two channels can be processed as two-dimensioned samples -- and reveal
the actual direction to the source.)

> expect a stereo capture to be described as a mix.

   The trouble with that is that there is no compatibility between
microphone-pair-at-a-distance stereo and XY stereo. So we'd have to
define two kinds of stereo output of a mixer.

   (Obviously, the mix could be reduced to mono; but then there's
really no point in having two transducers at all.)

> Since I think it can be done as a mix, that seems preferable to me.

   I really don't think that makes anything easier.