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

From: Roni Even <[email-masked]>
Date: Mon, 10 Aug 2009 12:33:54 +0300

Hi,
I can support Eric's point. I think there is a difference if the value is
part of the codec specification or as a general  RTP layer value.
Roni Even
As Individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Eric Burger
> Sent: Thursday, July 30, 2009 1:21 AM
> To: IETF AVT WG
> Subject: Re: [AVT] Fwd: Sound level indication in RTP
> 
> 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
> >
> > On Wed, Jul 29, 2009 at 4:27 PM, Jonathan Lennox <[email-masked]>
> > wrote:
> > Michael Ramalho writes:
> >
> > > OK, I'll bite. I've watched too many of these emails go by without
> > an
> > > 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]
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> >

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 10 Aug 2009 11:16:43 -0400

Dear All,

I have commented to many individuals (without copying the entire list)
concerning this thread.

What is the goal here?

My post of August 29 petitioned for the correlation of a true SPL type
of "level" (see email for details).

I fully understand that some endpoint implementations (e.g., a discount
store microphone connected to a laptop in which the user has adjusted
the gain on the volume control) renders some of those implementations
clueless concerning any precision of such a SPL level.

I still think we should strive to get there someday (see the arguments
presented in the Aug 29 email).

Most have commented that they would like a -X dBoV level. Fine ... but
what does *that mean*?

Most devices that intend to interconnect to telephony-style conference
bridges recognize the limitations of those bridges and attempt (through
AGC or other companding means) to fit "a meaningful signal" into the
roughly 13 bit dynamic range of telephony systems.

For example, G.711 definitions are fixed at the SPL level of a telephony
mouthpiece. And G.711 (natively) supports a (single frequency) SNR of
approximately 26 dB over about a 25 dB dynamic range. Thus most sending
endpoints (e.g., a conference phone) will amplify/AGC/compand what they
believe are speech sounds into this dynamic range.

So any level proposed here so far has no real basis in the actual sound
level of a person at an endpoint ... and is only indicative of what the
endpoint has done (AGC/companding/etc.) with the sound signal. Yes, you
can then define a speech level (P.56), a RMS noise level, a program
level (TV/radio) - but it has no correlation to what users perceive as
actual level in the recording venue (e.g., the contrast of speech levels
in a particular conference room).

Since each device does this without regard to any standard ... endpoint
A may amplify background noise to a (RMS level) of -25 dBoV and endpoint
B at -32 dBoV. What good is gating the endpoint A signal over endpoint B
signal (neither has speech)? Just because endpoint A reported a louder
"level" (-25 dBoV) it DOES NOT indicate that it is preferred in any
sense over endpoint B.

One can only assume you want these levels to mean something. And
eventually we want to expand our work beyond "telephony like"
conferencing.

If you want "level information" ... there should be some attempt to map
the "level" we define to a perceived "level" in the sending location.

Thus - despite the limitations of some endpoints - we should strive to
correlate the "level information" to perceived sound levels (and you
could define speech, music, and background noise levels).

Lastly, in the absence of those other level measures ... a measure of
how much louder a person's speech is over the background noise (when
speech is present) is also a useful metric. People DO speak louder in
high noise environments when communicating to other humans in the same
environment. Why? Because they know they won't be understood unless they
do! That measure alone would IMHO would be better than a simple dBoV
type measure discussed here.

We still need more thinking before we proceed.

Off Soapbox,

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Monday, August 10, 2009 5:34 AM
To: 'Eric Burger'; 'IETF AVT WG'
Subject: Re: [AVT] Fwd: Sound level indication in RTP

Hi,
I can support Eric's point. I think there is a difference if the value
is
part of the codec specification or as a general  RTP layer value.
Roni Even
As Individual

---

From: Kishan Shenoi <[email-masked]>
Date: Mon, 10 Aug 2009 10:57:08 -0700

Dear All,

Michael makes an important point regarding levels, absolute levels,
perceived levels, etc.

In traditional telephony, the sidetone in 500-type handsets provided a
bio-feedback mechanism to control talker levels.  It was/is very effective,
so effective that it is possible to define the notion of a 0 TLP that is
meaningful.  Each point in the transmission chain has a notion of the
absolute level of a 0 dBm0 "test-tone".  This model is being strained
somewhat with the advent of "hands-free" and "speaker-phone" and mobile
phone and other "4-wire" and "pseudo-4-wire" arrangements but is,
nevertheless, a very nice model to emulate.  Whereas it may not fit
immediately into the current environment, the ideas are nonetheless very
appropriate.  As Michael said, we do indeed need some more thought before
casting anything in concrete (or sand).

Regards,

Kishan Shenoi

---

From: Emil Ivov <[email-masked]>
Date: Mon, 10 Aug 2009 22:36:09 +0200

Hey Michael,

> I have commented to many individuals (without copying the entire list)

The goal of which proposal? There are currently two sound level related
proposals. One tries to make this kind of user interface possibe with
RTP conferences:

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

The other is suggesting a way of optimizing the work of mixers.

Following the discussions here it seems more than clear that both have
very different constraints and should be handled separately.

The former requires only relative sound level and has no need to
distinguish between noise and speech. The situation is different with
the latter.

Therefore, could you please clarify which of the two are the rest of
your questions about?

Cheers
Emil

-- 
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: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Mon, 10 Aug 2009 18:52:13 -0400

>>Item 1
Re: " The former requires only relative sound level and has no need to
distinguish between noise and speech."

If all endpoints used the same capture processing AND the same encoding
methodology - then RELATIVE sound LEVELS from homogeneous endpoints mean
something. This appears to be the case with your png. And this is the
case for PSTN telephony (it was designed to have a sinusoid at 89 dB SPL
at the mouth reference point be -27 dBoV).

However, my email (which you apparently did not read) addresses that
RELATIVE sound levels from endpoints having DIFFERENT capture processing
(e.g., volume control set points, different AGC or companders) mean next
to nothing. Your "display" would need to know the characteristics of the
sending endpoint to display anything meaningful (and you would know that
if you read both my posts).

If you have a system where all the endpoints are homogeneous - then you
can develop your own proprietary level scheme (dBoV is probably adequate
for a homogeneous scheme). Just don't expect "your dBoV" to have much
relevance to sound levels represented by other systems.

As a simple example, consider 16 bit vs a 20 bit input resolution. Four
more bits equals (approximately) 24 dB more dynamic range in a 20 bit
PCM input word relative to a 16 bit PCM word. A conceivable mapping
could split the 24 dB extra as 2 bits more headroom (for capturing
louder sounds) and 2 bits more footroom (capture softer sounds). In this
case a 0dBoV signal in the 16 bit system would be -12dBoV in the 20 bit
system ... but both would represent the same input sound level!

The goal here is (as I understand it) to determine if sound level
indications are worthwhile in the sense of them meaning something useful
to a receiving system. In other words, I am ASSUMING a non-homogeneous
endpoint environment.

>> Item 2
Re: "The situation is different with the latter."

I see a lot of similarities between the problems when you consider that
endpoints have differing capture characteristics - or put another way -
do not correlate with real SPL in a meaningful way.

I think the idea in this endeavor is to agree to standardized ways to
convey "level information". And to do this in a way that accommodates
non-homogeneous sending endpoints.

Please read the above before replying to second sentence ;-).

Michael Ramalho

-----Original Message-----
From: Emil Ivov [mailto:[email-masked]] On Behalf Of Emil
Ivov
Sent: Monday, August 10, 2009 4:36 PM
To: Michael Ramalho (mramalho)
Cc: Roni Even; Eric Burger; IETF AVT WG
Subject: Re: [AVT] Fwd: Sound level indication in RTP

Hey Michael,

Cheers
Emil

---

From: "Jonathan Lennox" <[email-masked]>
Date: Tue, 11 Aug 2009 14:09:34 -0400

It sounds like most of your concerns would be satisfied if there were
some way to specify dB SPL as well as dBoV -- whether this is an offset
between the two, some flag saying "this is actually SPL", a separate dB
SPL value, or whatever.  Obviously this would need to be optional, to
handle the case when all that's available to the application is the
audio handed up by the operating system from (as you say) a
discount-store microphone.

It's not clear to me what the semantics of an SPL value are for mixed or
processed audio, though -- whether from a conference bridge, a TV
program, or whatever -- if the audio hasn't ever actually existed as
sound pressure.

Is there any existing standard in which this type of information is
defined (in a reasonably codec-independent way)?

For "level above background", it's not clear to me how well that can be
defined on an instantaneous basis, since background noise can of course
change over time.  So long as levels are available for both "foreground"
and "background" audio (whether as dBoV or SPL), I imagine a mixer can
compute this just as well as an endpoint can.

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

> From: Michael Ramalho (mramalho) [mailto:[email-masked]]
> Sent: Monday, August 10, 2009 11:17 AM
> To: Roni Even; Eric Burger; IETF AVT WG
> Importance: Low

---

From: Emil Ivov <[email-masked]>
Date: Wed, 12 Aug 2009 10:46:56 +0300

Hey Michael,

I apologize for the lag. I am currently traveling and only have
intermittent access to mail.

(more inline)

> relevance to sound levels represented by other systems.

In the case where the mixer is delivering sound levels to the conference
participants (i.e. "my png") there is one single entity that performs
sound level measurements. This happens after all transcoding has
occurred and right before mixing. Delivered levels are all based on the
same scale (255 in our draft) by that one entity. Whether this entity is
measuring the level of sound pressure, or human perceived loudness, or
something else is, in this case, a purely implementational concern.

In this case again, the only reason why one might need to compare sound
levels produced by different entities would be a scenario involving
cascaded or concurrent mixers in the same conference call. In this
situation one mixer would have to compare levels resulting from its own
measurements to those it receives from another one before sending them
to participants. Even then however, given that these values are only
used to feed a rapidly changing display to a user, a potentially
heterogeneous nature of the levels is probably not that much of an
issue. The whole thing would generally still make sense to users.

The situation of course is completely different in the use case that's
being dealt with in Jonathan's draft. Obviously endpoints in that
scenario would need to be measuring the same thing, the same way, and
using the same units for the whole thing to work.

Therefore, before making additional comments, I wanted to know whether
your concerns were pertaining to both or to only one of the drafts.

> to a receiving system. In other words, I am ASSUMING a non-homogeneous

This is the part that bothered me. I believe that non-homogeneous
environments are only possible/important in the case where the sound
level measurements are used in a precise way and they are significant
enough to determine whether one's input is actually mixed and delivered
to others or not. Inconsistencies in the bars of a conferencing UI would
probably go unnoticed by most users amd be ignored without any
consequences in the rest of the cases (not to mention the fact that
parallel heterogeneous mixers are kind of rare but I agree that this may
change some day).

> do not correlate with real SPL in a meaningful way.

Now, I might be missing something, but again, the differences in
endpoint capture characteristics only matter in the case where the
endpoints are measuring the levels. All differences that are even
perceived by a mixer would be dealt with during transcoding.

> non-homogeneous sending endpoints.

My point is that the differences in the use of the levels and the way
they are obtained are enough to justify separate mechanism/RTP
extensions for handling them. I don't think we need to strive for a
single way of delivering information that serves different purposes.

> Please read the above before replying to second sentence ;-).

I had read both your posts, Michael, I simply needed to hear that you
were regarding this as a problem of both proposals before commenting
further. I apologize if my reply appeared hasty or inconsiderate in any
way ;).

Cheers
Emil