Subject: Re: [AVT] draft-ivov-avt-slic-03

From: Peter Musgrave <[email-masked]>
Date: Wed, 21 Jul 2010 06:30:31 -0400

Hi Emil,

I like the draft and think it's useful.

In section 3 the mapping of CSRC to users via CNAMEs is mentioned.
With the recent work on making CNAMEs unique and opaque
(draft-ietf-avt-rtp-cnames-00) I think this no longer applies. Does
there now need to be some new mechanism which maps users to CSRCs? I
think without a mapping of this kind the audio level indication is far
less useful.

Also, looking at the draft and the references to other docs which
calculate the level I still don't know how to implement the  level
calculation. I suspect there is some unstated knowledge that I have
never learned or forgotten - but it the audio level number the maximum
level in the packet? Total energy? Some kind of average?

Regards,

Peter Musgrave

---

From: Emil Ivov <[email-masked]>
Date: Wed, 21 Jul 2010 13:50:56 +0200

Hey Peter

Thanks for your comments!

(more inline)

На 21.07.10 12:30, Peter Musgrave написа:
> (draft-ietf-avt-rtp-cnames-00) I think this no longer applies.

Well, we've never really considered CNAMEs as the best way to do the the
CSRC to name mappings, but rather as the most RTP-ish. I agree this is
probably confusing and we could stop referring to CNAMEs as a way of
doing that.

> Does

In this same section 3 we actually have a reference to RFC 4575. If any,
then that's what we've considered as a "default" mapping mechanism. This
is also what we implemented in SIP Communicator

> level in the packet? Total energy? Some kind of average?

I see. We were thinking that the reference to calculating comfort noise
levels would have been enough but it's proving not to be. I guess that
in the next iteration of the drafts we could also add an annex
containing sample code. This would probably also help interoperability
issues. How does this sound?

Cheers,
Emil

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 21 Jul 2010 08:30:30 -0400

Inline

Regards,

Peter Musgrave

> probably confusing and we could stop referring to CNAMEs as a way of
Ok.

> is also what we implemented in SIP Communicator
I agree 4575 is a better approach.

> issues. How does this sound?

Sample code might be useful. There is an attempt at a reference w.r.t
G711 waveforms in the docs you reference which baffles me. I would
have thought the audio level in the packet would apply to the linear
data inside independent of how it was coded - so if there is sample
code I assume it is referring to the pre-encoded (linear) data?

I suspect audio level calculation is a field best left to experts
(i.e. not me) who can comment on the relative merits of a peak vs
average value (or some other measurement) for the data in a packet. I
am a bit baffled this was not clear in the references - which makes me
think maybe I have overlooked something.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 21 Jul 2010 14:51:49 +0200

Hey again,

(more inline)

> code I assume it is referring to the pre-encoded (linear) data?

Yes, that was my idea too. All audio levels would be measured over the
raw stream.

> think maybe I have overlooked something.

Well I am far from being an expert here either but I am hoping that once
we put sample code out there, the actual experts would speak up :).

Cheers,
Emil

---

From: Stefan Sayer <[email-masked]>
Date: Thu, 22 Jul 2010 22:42:22 +0200

> code I assume it is referring to the pre-encoded (linear) data?
dBov is defined in G.100.1 5.7. This reference should probably be 
added to the levels draft, as it is (surprisingly) missing in the 
referenced RFC3389.

Quoting G.100.1: "The power of a sampled signal x(n) with a length of 
N samples can be defined by:

           N-1
           ___
P=  1/N * \   x(n)^2
           /
           ---
           n=0

For a digital system which has an overload point xover, the maximum 
signal power will be P0 = 1.0.
In this case, the power level for a digital signal in decibels 
relative to the overload point (dBov, where the characters "ov" 
arbitrarily mean digital overload signal level) is defined by

    Lov = 10 log   ( P / P0 )   [dBov]
                10
The level of the maximum signal power P0 is thus 0 dBov, which is 
chosen to be the reference level."

For example, if the system were transmitting 16 bit signed PCM samples 
(L16), a packet of 32767 -32768 32767 -32768 ... would be at the 
overload point of 0 dBov (likewise a packet full of 32767 32767 32767 
... or -32768 -32768 -32768 values). If we were transmitting 160 
samples in a packet, the maximum power would be P0 = 32767^2 = 1073676289.

To calculate the level of a packet with 160 samples as for sending in 
the audio levels header, we can sum up the squares, divide by 160, 
divide by 1073676289, take the logarithm to base 10, and multiply with 
-10.

Now, the input to a G711 mu-law encoder must be quantized to 14 bits, 
and the highest value at the decoder output is 8031. If I understand 
G.711 correctly, the value at the segment end point (i.e. the highest 
value that a G.711 u-law encoder should be fed with, or, the upper 
limit of the highest quantization step) is 8159. So, if you for 
example have 16 bit samples which are attenuated to 0dB (they go from 
lowest to highest sample value), you would requantize to 14 bit. Then 
you could attenuate the signal such that the highest value is 8159 
(not 8191, what the highest value of a signed 14 bit sample could be). 
In reality, though, I guess you would omit that step, as it only 
accounts for -20dB  (10*log(33/8192)). What is important here is that 
apart from precision it doesn't matter whether the audio level 
relative to overload is calculated with the 16 bit samples, or the 14 
bit samples. And, if the input to a coder has a power reference point 
well below 0, before feeding the audio to the encoder we would have to 
attenuate the signal anyway, such that the calculation of the dBov 
with the uncoded (PCM) signal stays correct. Logically, on the wire, 
we can only refer to the overload point of the coded signal, but still 
we can calculate the power level properly from the uncoded signal.

Please correct me where I'm wrong.

Stefan

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:29:05 -0500

I am confused.

Why are you guys (imprecisely) trying to re-invent wheels long ago
invented, standardized and understood?

Definitions of all this stuff (RMS power, signal power, background noise
power, now to normalize mu-law or a-law to 13 or 14 bit precision, etc.)
is in the ITU-T Software Tools Library (a.k.a., G.191 .... search for it
at ... http://www.itu.int/itu-t/recommendations/index.aspx?ser=G).

In some cases this STL references other standard for more precise
definitions (e.g., speech "power" in P.56).

And C-language tools (code) to generate any power of interest are even
provided in the STL ... so you can verify if your results are within an
acceptable tolerance of what the STL tools produce.

[I say acceptable tolerance because I don't really mind if you are a few
tenths of a dB off ... if you have a particularly efficient way of
generating a power level of interest.]

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Sayer
Sent: Thursday, July 22, 2010 4:42 PM
To: Peter Musgrave
Cc: [email-masked]
Subject: Re: [AVT] draft-ivov-avt-slic-03

           N-1
           ___
P=  1/N * \   x(n)^2
           /
           ---
           n=0

samples in a packet, the maximum power would be P0 = 32767^2 =
1073676289.

Stefan

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

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 24 Jul 2010 08:29:14 +0200

Hi Michael,

I agree that the world does not need a re-invented way to calculate
audio levels.

When reviewing the avt-slic doc I followed the references hoping to
find the description to how to calculate dBov for a packet. I could
not find one. Emil's approach was to put in code to stimulate someone
to point to the right reference. This appears to have worked.

Stefan has pointed to dBov as defined in G.100.1 5.7.

I assume the software tools you point to are an instance of that.
Thanks for those.

Emil, perhaps both references can be added to the draft?

Peter Musgrave

---

From: Emil Ivov <[email-masked]>
Date: Sun, 25 Jul 2010 18:49:26 +0200

Hey all,

> I agree that the world does not need a re-invented way to calculate

Absolutely, and that was never our intention.

> Emil, perhaps both references can be added to the draft?

Indeed. We'll do this in the next iteration. Stefan, thank you for the
pointers and the great explanation!

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