Subject: [clue] Audio channel format - RE: Note that XY-stereo microphones are commonly available

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 12 May 2014 10:52:31 -0700

Hi John,
Comments below.
Mark

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]]
> Sent: Sunday, May 11, 2014 9:55 PM
> To: Duckworth, Mark
> Cc: [email-masked]
> Subject: Re: [clue] Note that XY-stereo microphones are commonly available
> 
> 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.

[Duckworth, Mark] Not just balk at it, I expect the endpoint that wants to render mono 
would be incapable of receiving a six channel audio encoding format.

>    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.

[Duckworth, Mark] Maybe we're talking about different things, because I think SDP is 
exactly the right thing for this, and is commonly done today, at least with stereo and 
mono.  Endpoints I am familiar with today are capable of encoding their outgoing room audio 
as mono, stereo, and in some cases 3 channel.  If the receiving side (whether middlebox 
or another endpoint) is capable only of mono, then the sender and receiver negotiate 
mono.  This is done with SDP offer/answer today.  And I think it should be done that
way with CLUE also.

>    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...)

[Duckworth, Mark] It isn't about conserving bandwidth.  It is about a receiver selecting
an audio encoding format it is capable of decoding.

> 
> --
> John Leslie <[email-masked]>

---

From: John Leslie <[email-masked]>
Date: Mon, 12 May 2014 21:06:23 -0400

Duckworth, Mark <[email-masked]> wrote:
> [John Leslie wrote:] 

   Alas, the bottom-line, regarding tomorrows design-team call, is that
I won't have time to get into details before mid-week. :^(

>>> different encodings of the same audio capture.

   (Note that there are other cases than whole-room capture that we
should deal with, IMHO.)

>> 5.1 surround, I doubt that SDP is the right conduit for negotiating
>> the number of channels -- offhand that sounds like a middlebox task.
> 
> [Duckworth, Mark] Maybe we're talking about different things, because
> I think SDP is exactly the right thing for this, and is commonly done
> today, at least with stereo and mono.

   No doubt it would help for Mark and me to exchange email as I study
this later this week.

> Endpoints I am familiar with today are capable of encoding their
> outgoing room audio as mono, stereo, and in some cases 3 channel.
> If the receiving side (whether middlebox or another endpoint) is
> capable only of mono, then the sender and receiver negotiate mono.
> This is done with SDP offer/answer today. And I think it should be
> done that way with CLUE also.

   That sounds superficially reasonable. Some details which come to
mind are how to proceed when receiving audio from two or more
sending rooms...

>> of a whole-room feed to fit an incompatible conference room paradigm.

   Well, I was sure yesterday, anyway. ;^)

> [Duckworth, Mark] It isn't about conserving bandwidth. It is about a
> receiver selecting an audio encoding format it is capable of decoding.

   That does sound like an SDP issue.

   I had assumed multi-room teleconferencing systems would be able
to decode at least one multi-channel surround format.