Subject: Re: [AVT] Sound level indication in RTP

From: Eric Burger <[email-masked]>
Date: Wed, 29 Jul 2009 13:37:33 +0200

I would offer that (1) is totally unhelpful and most likely  
unavailable. Endpoints will only do sound-level, as opposed to sound  
presence for squelch, if they are using a sound-level-related codec.

The mixer, on the other hand, has to do full analysis of the media to  
do the mix in the first place. Moreover, most advanced mixers (media  
servers) will do level balancing, which means endpoint sound levels  
will not even be relatively correct as a representation of the mix.  
Lastly, advanced mixers will do noise suppression, which means a non- 
talker with an unmuted mobile phone in the wind will have a relatively  
high sound level, yet not be in the mix at all.

On Jul 29, 2009, at 1:12 PM, Enrico Marocco wrote:

>
> -------- Original Message --------
> Subject: 	[AVT] Sound level indication in RTP
> Date: 	Wed, 29 Jul 2009 12:55:48 +0200
> From: 	Roni Even <[email-masked]>
> To: 	[email-masked] <[email-masked]>
>
>
>
> Hi,
>
> During the IETF75 AVT Monday session  the topic of sound level
> indication was presented.
>
> To recap the topic there are two suggestions.
>
> 1.       Provide the sound level indication from the endpoint to the
> mixer, this will help the mixer with selection the candidates to be  
> mixed
>
> 2.       Provide the incoming sound levels of all the participants in
> the mixed as measured by the mixer. This may be displayed to the
> conference participants helping them to know who are the speaker and  
> if
> there is someone causing constant noise like typing.
>
> We did not have enough time to discuss at the session and we are  
> looking
> for feedback in order to see how to continue with this work.
>
>
>
> We want to know if this is a good idea, which of the two proposal is
> interesting (maybe both).
>
> What use cases people see for sound level indications
>
>
>
> Please respond so we can see if there is support for this work and to
> verify the way forward.
>
>
>
> Thanks
>
> Roni Even
>
> AVT co-chair

---

From: "Jonathan Lennox" <[email-masked]>
Date: Wed, 29 Jul 2009 07:50:37 -0400

> presence for squelch, if they are using a sound-level-related codec.

The draft, as written, includes not only the sound level in db, but also
a client-provided flag for voice activity detection.  The algorithm for
VAD is left unspecified, but I agree that knowing voice presence is
essential, for all the reasons you've mentioned.

When we were writing the draft, there was discussion about whether this
flag should be optional, but I think (for the reasons you state) it
shouldn't be -- sound-level without VAD isn't terribly useful to a
mixer.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: Roni Even <[email-masked]>
Date: Wed, 29 Jul 2009 14:51:35 +0300

Eric,
I think I agree with your feedback on the first suggestion,
As for the second one the idea is for the mixer to reflect the value from
the input side. But it can also be from the actual mixed value. It will
still provide some view in for the participants about the relative volume of
the participants in the mix. It may also be helpful since most mixers today
do not suppress keyboard clicks.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eric Burger
> Sent: Wednesday, July 29, 2009 2:38 PM
> To: [email-masked]
> Subject: Re: [AVT] Sound level indication in RTP
> 
> > if there is someone causing constant noise like typing.
> >
> > looking for feedback in order to see how to continue with this work.
> >
> >
> >

---

From: Eric Burger <[email-masked]>
Date: Wed, 29 Jul 2009 14:28:01 +0200

While it sounds good [sic] to use the input sound levels, again they  
will not reflect what people hear on the output side. That would be a  
customer service nightmare:

S: How may I help you?

C: I love the flashing lights on my web interface to the conference  
bridge. However, I can barely hear Fred, yet the web says he is red- 
lined.

S: Well, let me explain to you about RTP, sound level detection,  
discreet cosine transforms, and alchemy...

---

From: Emil Ivov <[email-masked]>
Date: Wed, 29 Jul 2009 15:29:03 +0200

All,

I am trying to make sure that we are all on the same page so here's what
I gather so far:

1. Option 1 (participants sending levels to mixers) and Option 2 (mixers
sending levels to participants) are two different things, that don't
have much in common, and should be handled separately.

2. If Option 1 is to be useful it needs to use speech detection. This is
one more reason to separate it from Option 2 since levels in conf calls
could be used to identify sources of background noise.

3. Option 2 seems to be regarded as helpful and relevant to this
charter, so we may proceed with it.

I am having a slight doubt about "3" so I'd appreciate a clear show of
interest (or lack thereof) in Option 2 and its adoptability as a working
group document.

Cheers
Emil

Eric Burger wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
http://sip-communicator.org                    FAX:   +33.1.77.62.47.31

---

From: Zeev Vax <[email-masked]>
Date: Wed, 29 Jul 2009 16:22:08 +0000

Sound level problem can't be solved only by the transport, it has to start with the encoder and reach the decoder. There are several standard which are dealing with it end to end. We should try to leverage these existing standards instead of creating a new one that would be isolated and won't handle the full chain.

Zeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: Wednesday, July 29, 2009 6:29 AM
To: Eric Burger
Cc: [email-masked]; Roni Even
Subject: Re: [AVT] Sound level indication in RTP

All,

Cheers
Emil

---

From: Enrico Marocco <[email-masked]>
Date: Wed, 29 Jul 2009 18:39:47 +0200

Zeev Vax wrote:
> Sound level problem can't be solved only by the transport, it has to
> start with the encoder and reach the decoder. There are several
> standard which are dealing with it end to end. We should try to
> leverage these existing standards instead of creating a new one that
> would be isolated and won't handle the full chain.

The documents do not have the ambition to tackle the "sound level
problem" at large, whatever it may be. The focus here is about enabling
a mixer to pass the audio level of all the contributing streams to the
clients (and maybe also the other way around, if it makes sense). I'm
not aware of any standards for exchanging such information -- if you are
aware of any, it would be great if you could point them out.

-- 
Ciao,
Enrico

---

From: Emil Ivov <[email-masked]>
Date: Wed, 29 Jul 2009 18:51:33 +0200

Hey Zeev,

Zeev Vax wrote:
> start with the encoder and reach the decoder.

We are not trying to solve the general topic of sound level for all
related use cases.

What we'd like is a simple way of delivering active speaker sound-level
to the UAs participating in a conference call. The point is to allow
them to display it to their users. This is all really.

The extension is not supposed to control level in any way and it has
little relation to codec specifics.

Cheers
Emil

> There are several
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: Wednesday,
> July 29, 2009 6:29 AM To: Eric Burger Cc: [email-masked]; Roni Even 
> I am trying to make sure that we are all on the same page so here's
> what I gather so far:
> 
> 1. Option 1 (participants sending levels to mixers) and Option 2
> (mixers sending levels to participants) are two different things,
> that don't have much in common, and should be handled separately.
> 
> 2. If Option 1 is to be useful it needs to use speech detection. This
> is one more reason to separate it from Option 2 since levels in conf
> calls could be used to identify sources of background noise.
> 
> I am having a slight doubt about "3" so I'd appreciate a clear show
> of interest (or lack thereof) in Option 2 and its adoptability as a
> working group document.
> 
> Cheers Emil
> 
> 
> 
> 
> Eric Burger wrote:
>> While it sounds good [sic] to use the input sound levels, again
>> they will not reflect what people hear on the output side. That
>> would be a customer service nightmare:
>> 
>> S: How may I help you?
>> 
>>  bridge. However, I can barely hear Fred, yet the web says he is
>> red- lined.
>> 
>>> Eric, I think I agree with your feedback on the first suggestion,
>>>  As for the second one the idea is for the mixer to reflect the
>>> value from the input side. But it can also be from the actual
>>> mixed value. It will still provide some view in for the
>>> participants about the relative volume of the participants in the
>>> mix. It may also be helpful since most mixers today do not
>>> suppress keyboard clicks.
>>> 
>>> Roni Even
>>> 
>>>> -----Original Message----- From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Eric Burger Sent:
>>>> Wednesday, July 29, 2009 2:38 PM To: [email-masked] Subject: Re:
>>>> [AVT] Sound level indication in RTP
>>>> 
>>>> unavailable. Endpoints will only do sound-level, as opposed to
>>>> sound presence for squelch, if they are using a
>>>> sound-level-related codec.
>>>> 
>>>> The mixer, on the other hand, has to do full analysis of the
>>>> media to do the mix in the first place. Moreover, most advanced
>>>> mixers (media servers) will do level balancing, which means
>>>> endpoint sound levels will not even be relatively correct as a
>>>> representation of the mix. Lastly, advanced mixers will do
>>>> noise suppression, which means a non- talker with an unmuted
>>>> mobile phone in the wind will have a relatively high sound
>>>> level, yet not be in the mix at all.
>>>> 
>>>>> -------- Original Message -------- Subject:   [AVT] Sound
>>>>> level indication in RTP Date:      Wed, 29 Jul 2009 12:55:48
>>>>> +0200 From:      Roni Even <[email-masked]> To:
>>>>> [email-masked] <[email-masked]>
>>>>> 
>>>>> 
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> During the IETF75 AVT Monday session  the topic of sound
>>>>> level indication was presented.
>>>>> 
>>>>> 1.       Provide the sound level indication from the endpoint
>>>>> to the mixer, this will help the mixer with selection the
>>>>> candidates to be mixed
>>>>> 
>>>>> 2.       Provide the incoming sound levels of all the
>>>>> participants in the mixed as measured by the mixer. This may
>>>>> be displayed to the conference participants helping them to
>>>>> know who are the speaker and if there is someone causing
>>>>> constant noise like typing.
>>>>> 
>>>>> We did not have enough time to discuss at the session and we
>>>>> are looking for feedback in order to see how to continue with
>>>>> this work.
>>>>> 
>>>>> 
>>>>> 
>>>>> We want to know if this is a good idea, which of the two
>>>>> proposal is interesting (maybe both).
>>>>> 
>>>>> Please respond so we can see if there is support for this
>>>>> work and to verify the way forward.
>>>>> 
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> Roni Even
>>>>> 
>>>>> AVT co-chair
>> 
>> _______________________________________________ Audio/Video
>> Transport Working Group [email-masked] 
> -- Emil Ivov, Ph.D.                               67000 Strasbourg, 
> Project Lead                                   France SIP
> Communicator [email-masked]                     PHONE:
> +33.1.77.62.43.30 http://sip-communicator.org                    FAX:
> +33.1.77.62.47.31 _______________________________________________ 
> Audio/Video Transport Working Group [email-masked]

---

From: Zeev Vax <[email-masked]>
Date: Wed, 29 Jul 2009 16:59:19 +0000

The standards are around AC3, E-AC3, AAC, HE-AAC codecs. I guess you can add the draft recommendations how to map the metadata in this codecs to the proposed draft.

Zeev

-----Original Message-----
From: Enrico Marocco [mailto:[email-masked]]
Sent: Wednesday, July 29, 2009 9:40 AM
To: Zeev Vax
Cc: Emil Ivov; Eric Burger; [email-masked]; Roni Even
Subject: Re: [AVT] Sound level indication in RTP

--
Ciao,
Enrico

---

From: stephen botzko <[email-masked]>
Date: Wed, 29 Jul 2009 13:00:41 -0400

Since different codecs have different digital audio reference levels, it
seems to me that their might be a codec-specific component to this problem.

Though I guess I am not completely sure from the thread exactly what
functionality this is expected to deliver.

Regards,
Stephen Botzko

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 29 Jul 2009 13:03:37 -0400

A number in the units defined in ITU-R: Recommendation
BS.1770-1("Algorithms to measure audio programme loudness
and true-peak audio level," International Telecommunications Union,
Geneva, April 2007)
would enable receivers to convert that into whatever they felt was an
appropriate indicator.

Art
Art Allison

Senior Director Advanced Engineering, Science and Technology
 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Emil Ivov
|Sent: Wednesday, July 29, 2009 12:52 PM
|To: Zeev Vax
|Cc: Roni Even; [email-masked]
|Subject: Re: [AVT] Sound level indication in RTP
|
|
|Hey Zeev,
|
|Zeev Vax wrote:
|> Sound level problem can't be solved only by the transport, it has to 
|> start with the encoder and reach the decoder.
|
|We are not trying to solve the general topic of sound level 
|for all related use cases.
|
|What we'd like is a simple way of delivering active speaker 
|sound-level to the UAs participating in a conference call. The 
|point is to allow them to display it to their users. This is 
|all really.
|
|The extension is not supposed to control level in any way and 
|it has little relation to codec specifics.
|
|Cheers
|Emil
|
|> There are several
|> standard which are dealing with it end to end. We should try to 
|> leverage these existing standards instead of creating a new one that 
|> would be isolated and won't handle the full chain.
|> 
|> Zeev
|> 
|> -----Original Message----- From: [email-masked] 
|> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: 
|Wednesday, 
|> July 29, 2009 6:29 AM To: Eric Burger Cc: [email-masked]; Roni Even
|> Subject: Re: [AVT] Sound level indication in RTP
|> 
|> All,
|> 
|> I am trying to make sure that we are all on the same page so here's 
|> what I gather so far:
|> 
|> 1. Option 1 (participants sending levels to mixers) and Option 2 
|> (mixers sending levels to participants) are two different 
|things, that 
|> don't have much in common, and should be handled separately.
|> 
|> 2. If Option 1 is to be useful it needs to use speech 
|detection. This 
|> is one more reason to separate it from Option 2 since levels in conf 
|> calls could be used to identify sources of background noise.
|> 
|> 3. Option 2 seems to be regarded as helpful and relevant to this 
|> charter, so we may proceed with it.
|> 
|> I am having a slight doubt about "3" so I'd appreciate a 
|clear show of 
|> interest (or lack thereof) in Option 2 and its adoptability as a 
|> working group document.
|> 
|> Cheers Emil
|> 
|> 
|> 
|> 
|> Eric Burger wrote:
|>> While it sounds good [sic] to use the input sound levels, 
|again they 
|>> will not reflect what people hear on the output side. That 
|would be a 
|>> customer service nightmare:
|>> 
|>> S: How may I help you?
|>> 
|>> C: I love the flashing lights on my web interface to the 
|conference  
|>> bridge. However, I can barely hear Fred, yet the web says he is
|>> red- lined.
|>> 
|>> S: Well, let me explain to you about RTP, sound level detection, 
|>> discreet cosine transforms, and alchemy...
|>> 
|>> On Jul 29, 2009, at 1:51 PM, Roni Even wrote:
|>> 
|>>> Eric, I think I agree with your feedback on the first suggestion,  
|>>> As for the second one the idea is for the mixer to reflect 
|the value 
|>>> from the input side. But it can also be from the actual 
|mixed value. 
|>>> It will still provide some view in for the participants about the 
|>>> relative volume of the participants in the mix. It may also be 
|>>> helpful since most mixers today do not suppress keyboard clicks.
|>>> 
|>>> Roni Even
|>>> 
|>>>> -----Original Message----- From: [email-masked] 
|>>>> [mailto:[email-masked]] On Behalf Of Eric Burger Sent:
|>>>> Wednesday, July 29, 2009 2:38 PM To: [email-masked] Subject: Re:
|>>>> [AVT] Sound level indication in RTP
|>>>> 
|>>>> I would offer that (1) is totally unhelpful and most likely 
|>>>> unavailable. Endpoints will only do sound-level, as opposed to 
|>>>> sound presence for squelch, if they are using a 
|sound-level-related 
|>>>> codec.
|>>>> 
|>>>> The mixer, on the other hand, has to do full analysis of 
|the media 
|>>>> to do the mix in the first place. Moreover, most advanced mixers 
|>>>> (media servers) will do level balancing, which means 
|endpoint sound 
|>>>> levels will not even be relatively correct as a representation of 
|>>>> the mix. Lastly, advanced mixers will do noise suppression, which 
|>>>> means a non- talker with an unmuted mobile phone in the wind will 
|>>>> have a relatively high sound level, yet not be in the mix at all.
|>>>> 
|>>>> On Jul 29, 2009, at 1:12 PM, Enrico Marocco wrote:
|>>>> 
|>>>>> -------- Original Message -------- Subject:   [AVT] Sound
|>>>>> level indication in RTP Date:      Wed, 29 Jul 2009 12:55:48
|>>>>> +0200 From:      Roni Even <[email-masked]> To:
|>>>>> [email-masked] <[email-masked]>
|>>>>> 
|>>>>> 
|>>>>> 
|>>>>> Hi,
|>>>>> 
|>>>>> During the IETF75 AVT Monday session  the topic of sound level 
|>>>>> indication was presented.
|>>>>> 
|>>>>> To recap the topic there are two suggestions.
|>>>>> 
|>>>>> 1.       Provide the sound level indication from the endpoint
|>>>>> to the mixer, this will help the mixer with selection the 
|>>>>> candidates to be mixed
|>>>>> 
|>>>>> 2.       Provide the incoming sound levels of all the
|>>>>> participants in the mixed as measured by the mixer. This may be 
|>>>>> displayed to the conference participants helping them to 
|know who 
|>>>>> are the speaker and if there is someone causing constant noise 
|>>>>> like typing.
|>>>>> 
|>>>>> We did not have enough time to discuss at the session and we are 
|>>>>> looking for feedback in order to see how to continue with this 
|>>>>> work.
|>>>>> 
|>>>>> 
|>>>>> 
|>>>>> We want to know if this is a good idea, which of the two 
|proposal 
|>>>>> is interesting (maybe both).
|>>>>> 
|>>>>> What use cases people see for sound level indications
|>>>>> 
|>>>>> 
|>>>>> 
|>>>>> Please respond so we can see if there is support for 
|this work and 
|>>>>> to verify the way forward.
|>>>>> 
|>>>>> 
|>>>>> 
|>>>>> Thanks
|>>>>> 
|>>>>> Roni Even
|>>>>> 
|>>>>> AVT co-chair
|>> 
|>> 
|---------------------------------------------------------------------
|>> ---
|>> 
|>> 
|>> _______________________________________________ Audio/Video 
|Transport 
|>> Working Group [email-masked] https://www.ietf.org/mailman/listinfo/avt
|> 
|> -- Emil Ivov, Ph.D.                               67000 Strasbourg, 
|> Project Lead                                   France SIP
|> Communicator [email-masked]                     PHONE:
|> +33.1.77.62.43.30 http://sip-communicator.org                    FAX:
|> +33.1.77.62.47.31 _______________________________________________
|> Audio/Video Transport Working Group [email-masked] 
|> https://www.ietf.org/mailman/listinfo/avt
|> 
|> 
|
|-- 
|Emil Ivov, Ph.D.                               67000 Strasbourg,
|Project Lead                                   France
|SIP Communicator
[email-masked]                     PHONE: +33.1.77.62.43.30
|http://sip-communicator.org                    FAX:   +33.1.77.62.47.31
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: Emil Ivov <[email-masked]>
Date: Wed, 29 Jul 2009 19:10:34 +0200

> functionality this is expected to deliver.

(This answer is about Option 2:the mixer-to-participant level
distribution. Jonathan, I am not sure whether codec specifics would play
a role in the mixer optimization that your draft is about, so you may
want to answer that yourself.)

Stephen, the following image displays a Skype conf call :

http://sip-communicator.org/skypeconf/skypeconf.png

We'd like to make it possible for RTP clients (SIP, XMPP, or others) to
implement the same kind of GUI. We can't do it with standard RTP which
is why we are proposing the extension.

Cheers
Emil

> Regards,
> Stephen Botzko
> 
> On Wed, Jul 29, 2009 at 12:51 PM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     Hey Zeev,
> 
>     Zeev Vax wrote:
>     <mailto:[email-masked]>
>     > [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Emil Ivov Sent: Wednesday,
>     > July 29, 2009 6:29 AM To: Eric Burger Cc: [email-masked]
>     <mailto:[email-masked]>; Roni Even
>     <mailto:[email-masked]>
>     >>>> [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of Eric Burger Sent:
>     >>>> Wednesday, July 29, 2009 2:38 PM To: [email-masked]
>     <mailto:[email-masked]> Subject: Re:
>     >>>>> +0200 From:      Roni Even <[email-masked]
>     <mailto:[email-masked]>> To:
>     >>>>> [email-masked] <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Hi,
>     >>>>>
>     >> Transport Working Group [email-masked] <mailto:[email-masked]>
>     > Communicator [email-masked]
>     <mailto:[email-masked]>                     PHONE:
>     > Audio/Video Transport Working Group [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>      
>                   PHONE: +33.1.77.62.43.30
>     [email-masked] <mailto:[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 29 Jul 2009 19:13:44 +0200

Art, this is a very nice tip! We'll make sure we take it into account if
the working group agrees that the subject is of interest, and we get to
continue.

Thanks,
Emil

---

From: stephen botzko <[email-masked]>
Date: Wed, 29 Jul 2009 14:37:15 -0400

oops - this exchange was meant to be on the list.

Stephen Botzko
Polycom

---------- Forwarded message ----------
From: Emil Ivov <[email-masked]>
Date: Wed, Jul 29, 2009 at 2:29 PM
Subject: Re: [AVT] Sound level indication in RTP
To: stephen botzko <[email-masked]>

Hey Stephen,

stephen botzko wrote:
> Thanks
>
> Are you thinking about reporting the sound level as seen at the mixer
> input, or the sound level as adjusted by the mixer gain for that
> participant?  My guess is that the latter would be more informative.

Indeed. The level needs to what the user is actually hearing so yes, a
mixer would need to measure the levels after processing them and right
before mixing, encoding and sending them to a participant.

Cheers
Emil

>
> Regards,
> Stephen Botzko
> Polycom
>
>
>
> On Wed, Jul 29, 2009 at 1:10 PM, Emil Ivov <[email-masked]
>     > On Wed, Jul 29, 2009 at 12:51 PM, Emil Ivov
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >
>     >
>     >     Hey Zeev,
>     >
>     >     Zeev Vax wrote:
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     > [mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>] On
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>; Roni Even
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >>>> [mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>] On
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>> Subject: Re:
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>> To:
>     >     >>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Hi,
>     >     >>>>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked]
>     <mailto:[email-masked]>>                     PHONE:
>     >     > +33.1.77.62.47.31
>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]
>>
>     >                   PHONE: +33.1.77.62.43.30
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Eric Burger <[email-masked]>
Date: Wed, 29 Jul 2009 20:45:16 +0200

Measuring the post-processed levels is precisely my point.  Perfect!

On Jul 29, 2009, at 8:37 PM, stephen botzko wrote:
> >     > seems to me that their might be a codec-specific component  
> to this
> >     problem.
> >     >
> >     >     > Sound level problem can't be solved only by the  
> transport,
> >     it has to
> >     >     We are not trying to solve the general topic of sound  
> level
> >     for all
> >     >     related use cases.
> >     >
> >     >     What we'd like is a simple way of delivering active  
> speaker
> >     sound-level
> >     >     to the UAs participating in a conference call. The point  
> is to
> >     allow
> >     >     The extension is not supposed to control level in any  
> way and
> >     it has
> >     >     > leverage these existing standards instead of creating  
> a new
> >     one that
> >     >     > [mailto:[email-masked] <mailto:[email-masked] 
> >
> >     >     > I am trying to make sure that we are all on the same  
> page so
> >     here's
> >     >     > what I gather so far:
> >     >     >
> >     >     > (mixers sending levels to participants) are two  
> different
> >     things,
> >     >     > is one more reason to separate it from Option 2 since  
> levels
> >     in conf
> >     >     >> C: I love the flashing lights on my web interface to  
> the
> >     conference
> >     >     >>  bridge. However, I can barely hear Fred, yet the web  
> says
> >     he is
> >     >     >> red- lined.
> >     >     >>
> >     >     >>> participants about the relative volume of the  
> participants
> >     in the
> >     >     >>>> media to do the mix in the first place. Moreover,  
> most
> >     advanced
> >     >     >>>> endpoint sound levels will not even be relatively  
> correct
> >     as a
> >     >     >>>>> are looking for feedback in order to see how to  
> continue
> >     with
> >     >     >>>>> this work.
> >     >     >>>>>
> >     >     >>>>>
> >     >     >>>>>
> >     >     >> Transport Working Group [email-masked] <mailto:[email-masked] 
> >
> SIP
> >     >     [email-masked] <mailto:[email-masked] 
> >

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Wed, 29 Jul 2009 15:29:52 -0400

All,

OK, I'll bite. I've watched too many of these emails go by without an
adequate explanation of "level".

There are various tools to measure "level". For example:

P.56 can be used in telephony to measure "speech" or "rms" (background)
level relative to overload in a 16 bit PCM word (in dBoV).

BS.1770-1 can be used for program loudness (generally broadcasting)
purposes - peak and rms levels, etc. This measure is also relative to an
"overload point".

Both those measures (and others) use the word "level" in the realm of
overload of some quantized range of permissible values.

However, digitized audio sources (usually) come from some source that
has produced a zero-mean acoustic signal (e.g., your voice, a musical
instrument, a signal captured by a microphone in free space, etc.). That
is they are the result of something capturing a physical SOUND PRESSURE
LEVEL (SPL) difference.

In telephony, the overload point of the signal (e.g., the max or min
value of a G.711 sinusoid) corresponds to a specific sound pressure
level present at the "mouth reference point" (MRP) of a telephone
receiver. This stuff is specified really carefully - as G.711 has a
limited useful dynamic range (i.e., you need to get the level right).

Heretofore, I was presuming that the level of interest (be it a
background rms level in P.56 or BS.1770-1 ... or a speech level in P.56)
was the sound pressure level of whatever was captured (i.e., at X cm
from the microphone or other acoustic-to-pcm reference point).

Humans are known to speak more loudly to overcome higher background
noise levels. It is quite common on conferences that some normalization
of the individual bridged sources be made to accommodate the contrast
between inputs to the bridge. So I naively assumed this discussion would
eventually get around to "background" and "source/speech" levels of the
individual sources ... and preferably tied (in some manner to some
accuracy) to the real acoustic sound pressure level.

Given that audio is progressing from (the equivalent of) 13 to 16 to 20
to 24 bit linear PCM (22 bit PCM approximately capturing the dynamic
range of human hearing and 13 bit for today's telephony) ... knowing
where the source is in this (over 100 dB) dynamic range is important.
Especially so if your application desires to render whispers as whispers
and loud sounds as loud sounds (i.e. with equivalent sound pressure
levels being rendered). If your output device has limited dynamic range
(e.g., a telephone handset) - let it decide how to
compand/amplify/expand the signal provided to it. Broadcasters, in
particular, have specific expertise here.

Post-processing levels can be calculated at the endpoint ... so I am
really confused by this thread.

What is the goal or intent of "level information"?

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Eric Burger
Sent: Wednesday, July 29, 2009 2:45 PM
To: IETF AVT WG
Subject: Re: [AVT] Fwd: Sound level indication in RTP

> > On Wed, Jul 29, 2009 at 1:10 PM, Emil Ivov 
> > <[email-masked] <mailto:[email-masked]>>
> >     >     > [mailto:[email-masked]
<mailto:[email-masked] 
> >     >     >>>>> level indication in RTP Date:      Wed, 29 Jul  
<mailto:[email-masked]
> >     >     >>>>> work and to verify the way forward.
<mailto:[email-masked]

---

From: stephen botzko <[email-masked]>
Date: Wed, 29 Jul 2009 16:10:57 -0400

I don't think you can get back to acoustic sound pressure levels, esp. with
software-based PC clients running with off-the-shelf sound cards.
User-adjustable microphone levels (and uncalibrated microphones) would make
that difficult.  I agree it is useful to be very clear on what the level
means (and does not mean).

If I understand this proposal correctly, the receiving endpoint cannot
compute the relative levels of each participant in the mix, because it only
receives the mix.

Possible goals are (1) identify who is speaking by watching the meters, (2)
allow the conference participants to self-diagnose/"solve" audio problems.
("Hey Mike, I'm hearing a huge amount of noise, my meter says its coming
from you.  Are you calling in on your cell phone?" kind of stuff).  It might
be helpful if anyone sees other use cases.

Regards,
Stephen Botzko
Polycom

---

From: "Jonathan Lennox" <[email-masked]>
Date: Wed, 29 Jul 2009 16:27:17 -0400

> adequate explanation of "level".

In draft-lennox-avt-rtp-audio-level-exthdr-00.txt, I define it as
(negative) dBoV.  I took the definition directly from the RTP Comfort
Noise payload (RFC 3389).  If you have some more specific algorithms or
references to define the level that you think would improve the draft,
I'd be glad to include them.

Many systems can't easily know the "real" acoustic sound pressure level,
though -- on a typical PC, all an application knows is what comes out of
the sound card, with no way of knowing how the microphone gain is set
(let alone what the microphone hardware looks like). 

If mixers used the dBoV level naively, it could indeed result in some
unfortunate consequences, but I think some fairly straightforward
postprocessing (to distinguish typical "background" vs. "speech" levels,
etc.) can solve this, while still achieving the goal of not requiring
servers to decode and measure every audio packet from every conference
member.  I don't think the draft needs to (or should) specify how this
is done, but some discussion of it could certainly be helpful.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: stephen botzko <[email-masked]>
Date: Wed, 29 Jul 2009 16:40:34 -0400

What would be more useful (perhaps) is a way to compute something like an
AC3 dialog normalization value in the source device, which can then be
carried along and processed in mixers and other downstream devices (dynamic
range processors, and the like).  This wouldnot be a dBoV meter though, and
everyone would need to agree on the measurement technique in order to get
predictable interoperable results.

Though I admit this would not serve the same purposes as a meter, it might
be worth considering adding at the same time.

Regards,
Stephen Botzko
Polycom

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Jul 2009 00:20:48 +0200

Is it realistic to ask anything of the client? I would offer that  
would push useful adoption out five years, the time for a critical  
mass of clients to have this update such that enough clients feed  
information to the mixers.

On Jul 29, 2009, at 10:40 PM, stephen botzko wrote:

> What would be more useful (perhaps) is a way to compute something  
> like an AC3 dialog normalization value in the source device, which  
> can then be carried along and processed in mixers and other  
> downstream devices (dynamic range processors, and the like).  This  
> wouldnot be a dBoV meter though, and everyone would need to agree on  
> the measurement technique in order to get predictable interoperable  
> results.
>
> Though I admit this would not serve the same purposes as a meter, it  
> might be worth considering adding at the same time.
>
> Regards,
> Stephen Botzko
> Polycom
>

---

From: "Jonathan Lennox" <[email-masked]>
Date: Thu, 30 Jul 2009 16:55:46 -0400

> high sound level, yet not be in the mix at all.

Yes, all this is true, and a mixer is still going to have to do all of
this -- on the streams it chooses to insert into the mix -- in order to
do a high-quality job of mixing.

However, that doesn't obviate the use of the levels sent in the draft.
If a mixer which is receiving fifty audio streams can discard packets
from forty of them, without needing to decode and measure them all
before it processes the remaining few and making the final decision
about which ones it actually wants to mix, the number of conferences it
can support will increase dramatically.

Another important point I raised: for this purpose, a mixer can't just
trust the level carried in a single packet.  Instead, it may need to
watch a source's levels over a period of time, and only decide the
participant is speaking once its elevated levels continue for a while.
(This is to avoid switching someone in on a cough, or when they drop
their microphone, or whatever.)

Another important point -- this one is pointed out in the draft's
security considerations -- is that the mixer also needs to periodically
audit the levels participants are sending; otherwise there's some
incentive to lie and claim that your levels are higher than they
actually are.   (However, I don't off-hand see any motivation to lie by
sending *lower* levels; if you're trying not to get into the mix, why
send audio at all?)

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Fri, 31 Jul 2009 11:24:47 +0200

I agree in principle.  What I would offer is the levels that get  
displayed to the end users are calculated by the mixer. There is no  
value in having non-zero levels for people not in the mix: that could  
be a source of customer confusion.  However, there is no harm in the  
user's endpoint sending level info towards the mixer.  Some mixers can  
use that information for building light-weight, low complexity mixers.  
Really dumb mixers (RTP switches) can forward the selected stream's  
level indication.

Thus, the mixer MUST generate AGC-compensated levels for the 1/3/5/n  
streams in the mix.  Endpoints MAY generate sound level detected.

Of course, that DOES mean one needs to specify endpoint sound levels,  
but that is an exercise for the signal processing guys.