Subject: [avtext] New versions for the audio level drafts

From: Emil Ivov <[email-masked]>
Date: Mon, 14 Mar 2011 22:44:30 +0100

Hey folks,

We have just posted new versions of the audio level drafts and wanted to
discuss some of the changes before the meeting.

The most significant change consists in the addition of sample code that
shows how audio levels can be measured and rendered. The code was added
to the mixer-to-client draft but they both reference it since it can
also be used in client-to-mixer implementations.

We felt it was important to have actual code in there because:

* We did not find satisfactory examples in the ITU recommendations that
we are referencing.
* We would like to encourage implementation and this pretty much lifts
any audio processing background requirement from implementors.
* Although the implementation section is only informative, we still hope
it would help clear doubts during implementation and help improve
interoperability.

The code is available in two classes: an AudioLevelCalculator and an
AudioLevelRenderer. The calculator takes raw audio samples and produces
values that can then be sent with the level extensions defined in the
two drafts.

The renderer helps implementors display levels in a way that feels more
natural to users. This makes it suitable primarily to implementors of
the mixer-to-client draft. It basically cuts off values below "whisper"
and above "hearing damage" and it also ensures that level changes would
be rendered smoothly. There are of course millions of ways this part can
be improved which is why it appears separately. We felt however that it
was important to have at least a few crumbs in.

Feedback is of course most welcome and we'd love to hear from you on the
following:

* Does it make sense for you to have the code in there?
* Do you agree that the calculator and the renderer should be split the
way they are?
* Does it make sense to have the renderer code in the drafts at all?
* Do you feel the code should be improved in any way?

Cheers,
Emil

-- 
Emil Ivov                              67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
http://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 15 Mar 2011 07:46:34 -0400

Hi Emil, 

> * Does it make sense for you to have the code in there?
I think having a clear statement of the dbov algorithm in code or pseudo-code is fine. It will save a lot of people a lot of time looking up the very detailed references and making sense of them.

> * Does it make sense to have the renderer code in the drafts at all?
No. I view this as the kind of thing an implementation should decide. 

> * Do you feel the code should be improved in any way?

I find the code confusing, since it makes reference to sound pressure whereas section 5 talks about dbov with respect to the overload point of the system. I expected this overload point to be an input to the code but did not see it. Also if this is general code I would expect it to be clear how to generalize to 8 bit samples (or it should handle both cases). 

I do agree that the technical details of dbov are difficult to find and making a clear statement with example code is useful. I would skip the renderer - since I think implementation of that is very much a matter of taste. I think there are many choices for averaging here....

Regards, 

Peter Musgrave

---

From: Emil Ivov <[email-masked]>
Date: Tue, 15 Mar 2011 22:06:37 +0100

Hey Peter,

Thanks for the feedback. A few quick comments inline,

На 15.03.11 12:46, Peter Musgrave написа:
>> Feedback is of course most welcome and we'd love to hear from you
>> on the following:
>> 
> I think having a clear statement of the dbov algorithm in code or
> pseudo-code is fine. It will save a lot of people a lot of time
> looking up the very detailed references and making sense of them.
> 
>> * Do you agree that the calculator and the renderer should be split
>> the way they are? * Does it make sense to have the renderer code in
>> the drafts at all?
>

Well, it can still decide not to implement it the way it's in the draft,
right? Having the code as an example however, would also allow people
not to decide if it doesn't want anything fancy in there.

> I find the code confusing, since it makes reference to sound pressure
> whereas section 5 talks about dbov with respect to the overload point
> of the system. I expected this overload point to be an input to the
> code but did not see it.

Indeed not, it's hard coded right now. We'll make sure it is available
as an input param.

> Also if this is general code I would expect
> it to be clear how to generalize to 8 bit samples (or it should
> handle both cases).

Right, we'll make sure it handles both.

> I do agree that the technical details of dbov are difficult to find
> and making a clear statement with example code is useful. I would
> skip the renderer - since I think implementation of that is very much
> a matter of taste. I think there are many choices for averaging
> here....

Well, personally, I don't feel that strongly for the renderer either.
The thinking was that, if no choice is made for the averaging, the
result would look bad, so posting an example made sense to us.

Of course if people feel this is unnecessary then we can maybe simply
mention in the body that some averaging/smoothing mechanism needs to be
applied for user comfort.

Cheers,
Emil

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 17 Mar 2011 17:29:17 +0100

(As WG chair)

(Please respond to both calls below by Monday 28th March 2011)

My preference is that such additional material is discussed on the mailing list or by submission as a separate draft before inclusion in a draft under working group control.

That way we have more a more explicit view over what purports to have WG consensus and what does not.

I would therefore like to make a working group consensus call on the additional material. Please answer yes or no to this question, although other comments are also welcome.

WG Call
--------

Does the WG consider the additional material added in Appendix A of draft-ietf-avtext-mixer-to-client-audio-level-01 (and also referenced from draft-ietf-avtext-client-to-mixer-audio-level-01) form the basis of an improvement to the WG task on audio levels, and should therefore be retained in the document?

Other changes that have taken place are the removal of the existing section 11 (Design choices) from draft-ietf-avtext-mixer-to-client-audio-level. Sometimes such material has been retained as an annex, and sometimes it is discarded. 

WG call
-------

Is the WG happy with this deletion?

Please note that section 9 of draft-ietf-avtext-mixer-to-client-audio-level-01 contains a list of open issues:

9.  Open Issues

   At the time of writing of this document the authors have no clear
   view on how and if the following list of issues should be address
   here:
   1.  Audio levels in video streams.  This specification allows use of
       audio level values in "silent" audio streams that don't otherwise
       carry any payload thus allowing their delivery within systems
       where the various focus/mixer components communicate with each
       other as conference participants.  The same train of thought may
       very well justify audio level transport in video streams.
   2.  It has been suggested to reference ITU P.56 [ITU.P56.1993] for
       level measurement.  This needs to be investigated.

And for draft-ietf-avtext-client-to-mixer-audio-level-01

Appendix A.  Open issues

   o  In order to more accurately determine signal-to-noise ratio, it
      would be useful for a sender to also send its estimate of its
      current audio noise floor.  If so, it's unclear whether this would
      be better as a separate header extension element, or added to this
      header extension element.
   o  It has been suggested to reference ITU P.56 [ITU.P56.1993] for
      level measurement.  This needs to be investigated.

I would ask the working group to provide comments to close these.

Finally I notice that the summary of changes since the previous version has been restricted to the last version. Could I ask that this material is reinstated, and we will delete it at the publication stage. In pursuance of this, please add a note to the RFC editor to delete this material during final editing.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Emil Ivov
> Sent: 14 March 2011 21:45
> To: [email-masked]
> Subject: [avtext] New versions for the audio level drafts
> 
> Hey folks,
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 17 Mar 2011 12:53:04 -0500

>        header extension element.

I think this is an excellent idea, and it makes sense to me for it to be 
included in the same header element, since it is providing a reference 
point (of sorts) for the existing level indication.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 18 Mar 2011 12:30:48 +0100

На 17.03.11 17:29, DRAGE, Keith (Keith) написа:
> Finally I notice that the summary of changes since the previous
> version has been restricted to the last version. Could I ask that
> this material is reinstated, and we will delete it at the publication
> stage. In pursuance of this, please add a note to the RFC editor to
> delete this material during final editing.

OK, will do as soon as draft submission opens again.

Cheers,
Emil

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 18 Mar 2011 12:32:56 +0100

It is not urgent, this stuff disappears eventually. Wait until there are other changes identified by the working group.

Regards

Keith

> From: Emil Ivov [mailto:[email-masked]]
> Sent: 18 March 2011 11:31
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [avtext] New versions for the audio level drafts
>