draft-ietf-avtext-mixer-to-client-audio-level-00.txt   draft-ietf-avtext-mixer-to-client-audio-level-01.txt 
Network Working Group E. Ivov, Ed. Network Working Group E. Ivov, Ed.
Internet-Draft SIP Communicator Internet-Draft Jitsi
Intended status: Informational E. Marocco, Ed. Intended status: Informational E. Marocco, Ed.
Expires: August 22, 2011 Telecom Italia Expires: September 15, 2011 Telecom Italia
J. Lennox J. Lennox
Vidyo, Inc. Vidyo, Inc.
February 18, 2011 March 14, 2011
A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to-
Client Audio Level Indication Client Audio Level Indication
draft-ietf-avtext-mixer-to-client-audio-level-00 draft-ietf-avtext-mixer-to-client-audio-level-01
Abstract Abstract
This document describes a mechanism for RTP-level mixers in audio This document describes a mechanism for RTP-level mixers in audio
conferences to deliver information about the audio level of the conferences to deliver information about the audio level of
individual participants. Such audio level indicators are transported individual participants. Such audio level indicators are transported
in the same RTP packets as the audio data they pertain to. in the same RTP packets as the audio data they pertain to.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 22, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4
4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Audio level encoding . . . . . . . . . . . . . . . . . . . . . 6 5. Audio level encoding . . . . . . . . . . . . . . . . . . . . . 6
6. Signaling Information . . . . . . . . . . . . . . . . . . . . 7 6. Signaling Information . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
11. Appendix: Design choices . . . . . . . . . . . . . . . . . . . 10 11. Changes From Earlier Versions . . . . . . . . . . . . . . . . 10
11.1. SIP event package for conference state . . . . . . . . . 10 11.1. Changes From Draft -00 . . . . . . . . . . . . . . . . . 10
11.2. The RTP Control Protocol (RTCP) . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.3. Encoding levels in the payload . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Reference Implementation . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12 A.1. AudioLevelCalculator.java . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 A.2. AudioLevelRenderer.java . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Framework for Conferencing with the Session Initiation Protocol The Framework for Conferencing with the Session Initiation Protocol
(SIP) defined in RFC 4353 [RFC4353] presents an overall architecture (SIP) defined in RFC 4353 [RFC4353] presents an overall architecture
for multi-party conferencing. Among others, the framework borrows for multi-party conferencing. Among others, the framework borrows
from RTP [RFC3550] and extends the concept of a mixer entity from RTP [RFC3550] and extends the concept of a mixer entity
"responsible for combining the media streams that make up a "responsible for combining the media streams that make up a
conference, and generating one or more output streams that are conference, and generating one or more output streams that are
delivered to recipients". Every participant would hence receive, in delivered to recipients". Every participant would hence receive, in
skipping to change at page 4, line 47 skipping to change at page 4, line 47
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Protocol Operation 3. Protocol Operation
According to RFC 3550 [RFC3550] a mixer is expected to include in According to RFC 3550 [RFC3550] a mixer is expected to include in
outgoing RTP packets a list of identifiers (CSRC IDs) indicating the outgoing RTP packets a list of identifiers (CSRC IDs) indicating the
sources that contributed to the resulting stream. The presence of sources that contributed to the resulting stream. The presence of
such CSRC IDs allows an RTP client to determine, in a binary way, the such CSRC IDs allows RTP clients to determine, in a binary way, the
active speaker(s) in any given moment. RTCP also provides a basic active speaker(s) in any given moment. RTCP also provides a basic
mechanism to map the CSRC IDs to user identities through the CNAME mechanism to map the CSRC IDs to user identities through the CNAME
field. More advanced mechanisms, may exist depending on the field. More advanced mechanisms, may exist depending on the
signaling protocol used to establish and control a conference. In signaling protocol used to establish and control a conference. In
the case of the Session Initiation Protocol [RFC3261] for example, the case of the Session Initiation Protocol [RFC3261] for example,
the Event Package for Conference State [RFC4575] defines a <src-id> the Event Package for Conference State [RFC4575] defines a <src-id>
tag which binds CSRC IDs to media streams and SIP URIs. tag which binds CSRC IDs to media streams and SIP URIs.
This document describes an RTP header extension that allows mixers to This document describes an RTP header extension that allows mixers to
indicate the audio-level of every conference participant (CSRC) in indicate the audio-level of every conference participant (CSRC) in
addition to simply indicating their on/off status. This new header addition to simply indicating their on/off status. This new header
extension is based on the "General Mechanism for RTP Header extension is based on the "General Mechanism for RTP Header
Extensions" [RFC5285]. Extensions" [RFC5285].
Each instance of this header contains a list of one-octet audio Each instance of this header contains a list of one-octet audio
levels expressed in -dBov, with values from 0 to 127 representing 0 levels expressed in -dBov, with values from 0 to 127 representing 0
to -127 dBov(see Section 4 and Section 5). to -127 dBov(see Section 4 and Section 5). Appendix A provides a
reference implementation indicating one way of obtaining such values
from raw audio samples.
Every audio level value pertains to the CSRC identifier located at Every audio level value pertains to the CSRC identifier located at
the corresponding position in the CSRC list. In other words, the the corresponding position in the CSRC list. In other words, the
first value would indicate the audio level of the conference first value would indicate the audio level of the conference
participant represented by the first CSRC identifier in that packet participant represented by the first CSRC identifier in that packet
and so forth. The number and order of these values MUST therefore and so forth. The number and order of these values MUST therefore
match the number and order of the CSRC IDs present in the same match the number and order of the CSRC IDs present in the same
packet. packet.
When encoding audio level information, a mixer SHOULD include in a When encoding audio level information, a mixer SHOULD include in a
skipping to change at page 6, line 38 skipping to change at page 6, line 38
Note that use of the two-byte header defined in RFC 5285 [RFC5285] Note that use of the two-byte header defined in RFC 5285 [RFC5285]
follows the same rules the only change being the length of the ID and follows the same rules the only change being the length of the ID and
len fields. len fields.
5. Audio level encoding 5. Audio level encoding
Audio level indicators are encoded in the same manner as audio noise Audio level indicators are encoded in the same manner as audio noise
level in the RTP Payload Comfort Noise specification [RFC3389] and level in the RTP Payload Comfort Noise specification [RFC3389] and
audio level in the RTP Extension Header for Client-to-mixer Audio audio level in the RTP Extension Header for Client-to-mixer Audio
Level Notification [I-D.lennox-avt-rtp-audio-level-exthdr] Level Notification [I-D.ietf-avtext-client-to-mixer-audio-level]
specification. The magnitude of the audio level is packed into the specification. The magnitude of the audio level is packed into the
least significant bits of one audio-level byte with the most least significant bits of one audio-level byte with the most
significant bit unused and always set to 0 as shown below in significant bit unused and always set to 0 as shown below in
Figure 3. Figure 3.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0| level | |0| level |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 7, line 24 skipping to change at page 7, line 24
to the overload point of the system, i.e. the maximum-amplitude to the overload point of the system, i.e. the maximum-amplitude
signal that can be handled by the system without clipping. (Note: signal that can be handled by the system without clipping. (Note:
Representation relative to the overload point of a system is Representation relative to the overload point of a system is
particularly useful for digital implementations, since one does not particularly useful for digital implementations, since one does not
need to know the relative calibration of the analog circuitry.) For need to know the relative calibration of the analog circuitry.) For
example, in the case of u-law (audio/pcmu) audio [ITU.G.711], the 0 example, in the case of u-law (audio/pcmu) audio [ITU.G.711], the 0
dBov reference would be a square wave with values +/- 8031. (This dBov reference would be a square wave with values +/- 8031. (This
translates to 6.18 dBm0, relative to u-law's dBm0 definition in Table translates to 6.18 dBm0, relative to u-law's dBm0 definition in Table
6 of G.711.) 6 of G.711.)
To simplify implementation of the encoding procedures described here,
this specification provides a sample Java implementation (Appendix A)
demonstating one way it can be achieved.
6. Signaling Information 6. Signaling Information
The URI for declaring the audio level header extension in an SDP The URI for declaring the audio level header extension in an SDP
extmap attribute and mapping it to a local extension header extmap attribute and mapping it to a local extension header
identifier is "urn:ietf:params:rtp-hdrext:csrc-audio-level". There identifier is "urn:ietf:params:rtp-hdrext:csrc-audio-level". There
is no additional setup information needed for this extension (i.e. no is no additional setup information needed for this extension (i.e. no
extensionattributes). extensionattributes).
An example attribute line in the SDP, for a conference might be: An example attribute line in the SDP, for a conference might be:
skipping to change at page 10, line 8 skipping to change at page 10, line 8
8. IANA Considerations 8. IANA Considerations
This document defines a new extension URI that, if approved, would This document defines a new extension URI that, if approved, would
need to be added to the RTP Compact Header Extensions sub-registry of need to be added to the RTP Compact Header Extensions sub-registry of
the Real-Time Transport Protocol (RTP) Parameters registry, according the Real-Time Transport Protocol (RTP) Parameters registry, according
to the following data: to the following data:
Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level
Description: Mixer-to-client audio level indicators Description: Mixer-to-client audio level indicators
Contact: emcho@sip-communicator.org Contact: emcho@jitsi.org
Reference: RFC XXXX Reference: RFC XXXX
9. Open Issues 9. Open Issues
At the time of writing of this document the authors have no clear 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 view on how and if the following list of issues should be address
here: here:
1. Audio levels in video streams. This specification allows use of 1. Audio levels in video streams. This specification allows use of
audio level values in "silent" audio streams that don't otherwise audio level values in "silent" audio streams that don't otherwise
carry any payload thus allowing their delivery within systems carry any payload thus allowing their delivery within systems
where the various focus/mixer components communicate with each where the various focus/mixer components communicate with each
other as conference participants. The same train of thought may other as conference participants. The same train of thought may
very well justify audio level transport in video streams. very well justify audio level transport in video streams.
2. It has been suggested to reference ITU P.56 [ITU.P56.1993] for 2. It has been suggested to reference ITU P.56 [ITU.P56.1993] for
level measurement. This needs to be investigated. level measurement. This needs to be investigated.
10. Acknowledgments 10. Acknowledgments
Lyubomir Marinov contributed level measurement and rendering code.
Roni Even, Ingemar Johansson, Michael Ramalho and several others Roni Even, Ingemar Johansson, Michael Ramalho and several others
provided helpful feedback over the dispatch mailing list. provided helpful feedback over the dispatch mailing list.
SIP Communicator's participation in this specification is funded by Jitsi's participation in this specification is funded by the NLnet
the NLnet Foundation. Foundation.
11. Appendix: Design choices
During discussions on the subject of audio levels the decision to
transport audio levels in RTP packets, rather than another protocol
was questioned several times which is why the authors find it worth
explaining here. The following subsections describe alternative
mechanisms for delivering audio levels and the reasons why authors
decided not to use them.
11.1. SIP event package for conference state
RFC 4575 [RFC4575] defines a conference event package for tightly
coupled conferences using the Session Initiation Protocol (SIP)
events framework. It allows for the delivery of various conference
related details such as conference descriptions, participant count
and identity. The document also provides a way of indicating who the
speakers are at any given moment by specifying a mechanism for
mapping conference participants to RTP SSRC/CSRC identifiers. All
these details are dispatched in an asynchronous manner using the SIP
events framework, or, in other words, through NOTIFY SIP requests
following an initial SUBSCRIBE from a participant.
Contrary to "plain" active speaker infomation, where significant
changes only occur once every several seconds, audio level in human
speech is obviously a very time sensitive characteristic which would
require frequent updates (i.e. approximately once every 50-100 ms).
In order for the update of the user interface to appear "natural" to
the user, audio level information would probably have to be delivered
for every one or two RTP packets. Using RFC 4575 [RFC4575] or SIP in
general for this would generate traffic on the (often low-bandwidth)
signalling path comparable to, if not exceeding, the media itself.
It may also prove relatively hard for client developers to
synchronize the information they receive from SIP messages with the
one they obtain from the media flows.
It is probably also worth mentioning that the use of RFC 4575
[RFC4575] for such a feature would make the mechanism incompatible
with non-SIP signaling protocols like, for example, XMPP [RFC3920]
and its Jingle extensions.
11.2. The RTP Control Protocol (RTCP) 11. Changes From Earlier Versions
Similar to using SIP, delivering audio levels through RTCP would Note to the RFC-Editor: please remove this section prior to
cause bandidth and synchronization issues. Furthermore the RTP publication as an RFC.
specification [RFC3550] explicitly recommends that the fraction of
the session bandwidth added for RTCP be fixed at 5% which could not
be sufficient for the transport of audio level indicators.
11.3. Encoding levels in the payload 11.1. Changes From Draft -00
Given the content specific nature of audio levels, it has been o Added code for sound pressure calculation and measurement in
suggested that audio level information be encoded and transmitted as "APPENDIX A. Reference Implementation".
part of the payload. While this is indeed a feasible approach, o Changed affiliation for Emil Ivov.
implementing it would require a substantial effort. In order to o Removed "Appendix: Design choices".
implement support for such a feature, client developers would need to
explicitly handle it in all individual codec modules of their
application. Compared to RTP extensions, the mechanism would
therefore represent a substantial additional effort without offering
any meaningful advantages.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
12.2. Informative References 12.2. Informative References
[I-D.lennox-avt-rtp-audio-level-exthdr] [I-D.ietf-avtext-client-to-mixer-audio-level]
Lennox, J., Ivov, E., and E. Marocco, "A Real-Time Lennox, J., Ivov, E., and E. Marocco, "A Real-Time
Transport Protocol (RTP) Header Extension for Client-to- Transport Protocol (RTP) Header Extension for Client-to-
Mixer Audio Level Indication", Mixer Audio Level Indication",
draft-lennox-avt-rtp-audio-level-exthdr-02 (work in draft-ietf-avtext-client-to-mixer-audio-level-00 (work in
progress), July 2010. progress), February 2011.
[ITU.G.711] [ITU.G.711]
International Telecommunications Union, "Pulse Code International Telecommunications Union, "Pulse Code
Modulation (PCM) of Voice Frequencies", ITU- Modulation (PCM) of Voice Frequencies", ITU-
T Recommendation G.711, November 1988. T Recommendation G.711, November 1988.
[ITU.P56.1993] [ITU.P56.1993]
International Telecommunications Union, "Objective International Telecommunications Union, "Objective
Measurement of Active Speech Level", ITU-T Recommendation Measurement of Active Speech Level", ITU-T Recommendation
P.56, March 1988. P.56, March 1988.
skipping to change at page 13, line 10 skipping to change at page 12, line 10
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353, Session Initiation Protocol (SIP)", RFC 4353,
February 2006. February 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006. State", RFC 4575, August 2006.
Appendix A. Reference Implementation
This appendix contains Java code for a reference implementation of
the level calculation and rendering methods.The code is not normative
and by no means the only possible implementation. Its purpose is to
help implementors add audio level support to mixers and clients.
The Java code consists of the following files and methods:
AudioLevelCalculator.java: Calculates the sound pressure level of a
signal with specific samples. Can be used in mixers to generate
values suitable for the level extension headers.
AudioLevelRenderer.java: Helps adjust a sequence of pressure levels
so that they would appear "natural" to users. Can be used by
clients and applied over the values received in a level extension
header so that displayed levels would change smoothly and
correspond to user experience.
The implementation is provided in Java but does not rely on any of
the language specific and can be easily ported to another.
A.1. AudioLevelCalculator.java
/**
* Calculates the audio level of specific samples of a singal based on
* sound pressure level.
*/
public class AudioLevelCalculator
{
/**
* Calculates the sound pressure level of a signal with specific
* <tt>samples</tt>.
*
* @param samples the samples of the signal to calculate the sound
* pressure level of. The samples are specified as an <tt>int</tt>
* array starting at <tt>offset</tt>, extending <tt>length</tt>
* number of elements and each <tt>int</tt> element in the specified
* range representing a 16-bit sample.
*
* @param offset the offset in <tt>samples</tt> at which the samples
* start
* @param length the length of the signal specified in
* <tt>samples<tt> starting at <tt>offset</tt>
* @return the sound pressure level of the specified signal
*/
public static int calculateSoundPressureLevel(
int[] samples, int offset, int length)
{
/*
* Calcuate the root mean square of the signal i.e. the
* effective sound pressure.
*/
double rms = 0;
for (; offset < length; offset++)
{
double sample = samples[offset];
sample /= Short.MAX_VALUE;
rms += sample * sample;
}
rms = (length == 0) ? 0 : Math.sqrt(rms / length);
/*
* The sound pressure level is a logarithmic measure of the
* effectivesound pressure of a sound relative to a reference
* value and is measured in decibels.
*/
double db;
/*
* The minimum sound pressure level which matches the maximum
* of the sound meter.
*/
final double MIN_SOUND_PRESSURE_LEVEL = 0;
/*
* The maximum sound pressure level which matches the maximum
* of the sound meter.
*/
final double MAX_SOUND_PRESSURE_LEVEL
= 127 /* HUMAN TINNITUS (RINGING IN THE EARS) BEGINS */;
if (rms > 0)
{
/*
* The commonly used "zero" reference sound pressure in air
* is 20 uPa RMS, which is usually considered the threshold
* of human hearing.
*/
final double REF_SOUND_PRESSURE = 0.00002;
db = 20 * Math.log10(rms / REF_SOUND_PRESSURE);
/*
* Ensure that the calculated level is within the minimum
* and maximum sound pressure level.
*/
if (db < MIN_SOUND_PRESSURE_LEVEL)
db = MIN_SOUND_PRESSURE_LEVEL;
else if (db > MAX_SOUND_PRESSURE_LEVEL)
db = MAX_SOUND_PRESSURE_LEVEL;
}
else
{
db = MIN_SOUND_PRESSURE_LEVEL;
}
return (int) db;
}
}
AudioLevelCalculator.java
A.2. AudioLevelRenderer.java
/**
* Helps adjust a sequence of pressure levels so that they would appear
* "natural" to users. Can be used by clients and applied over the
* values received in a level extension header so that displayed levels
* would change smoothly and correspond to user experience..
*/
public class AudioLevelRenderer
{
/**
* The last audio level displayed by
* {@link AudioLevelCalculator#displayAudioLevel(int, int, int)}.
*/
private int lastAudioLevel = 0;
/**
* Returns a specific sound pressure level as an animated (i.e.
* does not jump up and down too much in a single update) audio
* level.
*
* @param spl the sound pressure level to be displayed
* @param minAudioLevel the minimum of the UI range which is used
* to depict audio levels
* @param maxAudioLevel the maximum of the UI range which is used
* to depict audio levels
* @return a sound pressure level that can be displayed to the user.
*/
public int renderAudioLevel(
int spl, int minAudioLevel, int maxAudioLevel)
{
/*
* The minimum sound pressure level that the UI is interested in
* displaying.
*/
final double MIN_SPL_TO_DISPLAY = 40 /* A WHISPER */;
/*
* The maximum sound pressure level that the UI is interested in
* displaying.
*/
final double MAX_SPL_TO_DISPLAY = 85 /* HEARING DAMAGE */;
int audioLevel;
if (spl < MIN_SPL_TO_DISPLAY)
audioLevel = minAudioLevel;
else if (spl > MAX_SPL_TO_DISPLAY)
audioLevel = maxAudioLevel;
else
{
/*
* Depict the range between "A WHISPER" and the beginning of
* "HEARING DAMAGE".
*/
audioLevel
= (int)
(((spl - MIN_SPL_TO_DISPLAY)
/ (MAX_SPL_TO_DISPLAY - MIN_SPL_TO_DISPLAY))
* (maxAudioLevel - minAudioLevel));
if (audioLevel < minAudioLevel)
audioLevel = minAudioLevel;
else if (audioLevel > maxAudioLevel)
audioLevel = maxAudioLevel;
}
/*
* Animate the audio level so that it does not jump up and down
* too fast.
*/
lastAudioLevel
= (int) (lastAudioLevel * 0.8 + audioLevel * 0.2);
/* Return the displayable audio level. */
return lastAudioLevel;
}
}
AudioLevelRenderer.java
Authors' Addresses Authors' Addresses
Emil Ivov (editor) Emil Ivov (editor)
SIP Communicator Jitsi
Strasbourg 67000 Strasbourg 67000
France France
Email: emcho@sip-communicator.org Email: emcho@jitsi.org
Enrico Marocco (editor) Enrico Marocco (editor)
Telecom Italia Telecom Italia
Via G. Reiss Romoli, 274 Via G. Reiss Romoli, 274
Turin 10148 Turin 10148
Italy Italy
Email: enrico.marocco@telecomitalia.it Email: enrico.marocco@telecomitalia.it
Jonathan Lennox Jonathan Lennox
 End of changes. 23 change blocks. 
81 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/