idnits 2.17.1 draft-ietf-avtext-mixer-to-client-audio-level-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 9, 2011) is 4735 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ITU.P56.1993' is defined on line 487, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-06) exists of draft-ietf-avtext-client-to-mixer-audio-level-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Ivov, Ed. 3 Internet-Draft Jitsi 4 Intended status: Informational E. Marocco, Ed. 5 Expires: November 10, 2011 Telecom Italia 6 J. Lennox 7 Vidyo, Inc. 8 May 9, 2011 10 A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- 11 Client Audio Level Indication 12 draft-ietf-avtext-mixer-to-client-audio-level-02 14 Abstract 16 This document describes a mechanism for RTP-level mixers in audio 17 conferences to deliver information about the audio level of 18 individual participants. Such audio level indicators are transported 19 in the same RTP packets as the audio data they pertain to. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 10, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Audio level encoding . . . . . . . . . . . . . . . . . . . . . 6 60 6. Signaling Information . . . . . . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 64 10. Changes From Earlier Versions . . . . . . . . . . . . . . . . 11 65 10.1. Changes From Draft -01 . . . . . . . . . . . . . . . . . 11 66 10.2. Changes From Draft -00 . . . . . . . . . . . . . . . . . 11 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 69 11.2. Informative References . . . . . . . . . . . . . . . . . 11 70 Appendix A. Reference Implementation . . . . . . . . . . . . . . 12 71 A.1. AudioLevelCalculator.java . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 The Framework for Conferencing with the Session Initiation Protocol 77 (SIP) defined in RFC 4353 [RFC4353] presents an overall architecture 78 for multi-party conferencing. Among others, the framework borrows 79 from RTP [RFC3550] and extends the concept of a mixer entity 80 "responsible for combining the media streams that make up a 81 conference, and generating one or more output streams that are 82 delivered to recipients". Every participant would hence receive, in 83 a flat single stream, media originating from all the others. 85 Using such centralized mixer-based architectures simplifies support 86 for conference calls on the client side since they would hardly 87 differ from one-to-one conversations. However, the method also 88 introduces a few limitations. The flat nature of the streams that a 89 mixer would output and send to participants makes it difficult for 90 users to identify the original source of what they are hearing. 92 Mechanisms that allow the mixer to send to participants cues on 93 current speakers (e.g. the CSRC fields in RTP [RFC3550]) only work 94 for speaking/silent binary indications. There are, however, a number 95 of use cases where one would require more detailed information. 96 Possible examples include the presence of background chat/noise/ 97 music/typing, someone breathing noisily in their microphone, or other 98 cases where identifying the source of the disturbance would make it 99 easy to remove it (e.g. by sending a private IM to the concerned 100 party asking them to mute their microphone). A more advanced 101 scenario could involve an intense discussion between multiple 102 participants that the user does not personally know. Audio level 103 information would help better recognize the speakers by associating 104 with them complex (but still human readable) characteristics like 105 loudness and speed for example. 107 One way of presenting such information in a user friendly manner 108 would be for a conferencing client to attach audio level indicators 109 to the corresponding participant related components in the user 110 interface as displayed in Figure 1. 112 ________________________ 113 | | 114 | 00:42 | Weekly Call | 115 |________________________| 116 | | 117 | | 118 | Alice |====== | (S) | 119 | | 120 | Bob |= | | 121 | | 122 | Carol | | (M) | 123 | | 124 | Dave |=== | | 125 | | 126 |________________________| 128 Figure 1: Displaying detailed speaker information to the user by 129 including audio level for every participant. 131 Implementing a user interface like the above requires analysis of the 132 media sent from other participants. In a conventional audio 133 conference this is only possible for the mixer since all other 134 conference participants are generally receiving a single, flat audio 135 stream and have therefore no immediate way of determining individual 136 audio levels. 138 This document specifies an RTP extension header that allows such 139 mixers to deliver audio level information to conference participants 140 by including it directly in the RTP packets transporting the 141 corresponding audio data. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 3. Protocol Operation 151 According to RFC 3550 [RFC3550] a mixer is expected to include in 152 outgoing RTP packets a list of identifiers (CSRC IDs) indicating the 153 sources that contributed to the resulting stream. The presence of 154 such CSRC IDs allows RTP clients to determine, in a binary way, the 155 active speaker(s) in any given moment. RTCP also provides a basic 156 mechanism to map the CSRC IDs to user identities through the CNAME 157 field. More advanced mechanisms, may exist depending on the 158 signaling protocol used to establish and control a conference. In 159 the case of the Session Initiation Protocol [RFC3261] for example, 160 the Event Package for Conference State [RFC4575] defines a 161 tag which binds CSRC IDs to media streams and SIP URIs. 163 This document describes an RTP header extension that allows mixers to 164 indicate the audio-level of every conference participant (CSRC) in 165 addition to simply indicating their on/off status. This new header 166 extension uses "General Mechanism for RTP Header Extensions" 167 described in [RFC5285]. 169 Each instance of this header contains a list of one-octet audio 170 levels expressed in -dBov, with values from 0 to 127 representing 0 171 to -127 dBov(see Section 4 and Section 5). Appendix A provides a 172 reference implementation indicating one way of obtaining such values 173 from raw audio samples. 175 Every audio level value pertains to the CSRC identifier located at 176 the corresponding position in the CSRC list. In other words, the 177 first value would indicate the audio level of the conference 178 participant represented by the first CSRC identifier in that packet 179 and so forth. The number and order of these values MUST therefore 180 match the number and order of the CSRC IDs present in the same 181 packet. 183 When encoding audio level information, a mixer SHOULD include in a 184 packet information that corresponds to the audio data being 185 transported in that same packet. It is important that these values 186 follow the actual stream as closely as possible. Therefore a mixer 187 SHOULD also calculate the values after the original contributing 188 stream has undergone possible processing such as level normalization, 189 and noise reduction for example. 191 Note that in some cases a mixer may be sending an RTP audio stream 192 that only contains audio level information and no actual audio. 193 Updating a (web) interface conference module may be one reason for 194 this to happen. 196 It may sometimes happen that a conference involves more than a single 197 mixer. In such cases each of the mixers MAY choose to relay the CSRC 198 list and audio-level information they receive from peer mixers (as 199 long as the total CSRC count remains below 16). Given that the 200 maximum audio level is not precisely defined by this specification, 201 it is likely that in such situations average audio levels would be 202 perceptibly different for the participants located behind the 203 different mixers. 205 4. Header Format 207 The audio level indicators are delivered to the receivers in-band 208 using the "General Mechanism for RTP Header Extensions" [RFC5285]. 209 The payload of this extension is an ordered sequence of 8-bit audio 210 level indicators encoded as per Section 5. 212 0 1 2 3 213 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | ID | len |0| level 1 |0| level 2 |0| level 3 ... 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 2: Audio level indicators extension format 220 The 4-bit len field is the number minus one of data bytes (i.e. audio 221 level values) transported in this header extension element following 222 the one-byte header. Therefore, the value zero in this field 223 indicates that one byte of data follows. RFC 3550 [RFC3550] only 224 allows RTP packets to carry a maximum of 15 CSRC IDs. Given that 225 audio levels directly refer to CSRC IDs, implementations MUST NOT 226 include more than 15 audio level values. The maximum value allowed 227 in the len field is therefore 14. 229 Note that use of the two-byte header defined in RFC 5285 [RFC5285] 230 follows the same rules the only change being the length of the ID and 231 len fields. 233 5. Audio level encoding 235 The audio level header extension only carries the level of the audio 236 in the RTP payload of the packet it is associated with. This 237 information is carried in an RTP header extension element as defined 238 by [RFC5285]. 240 The audio level is defined in the same manner as is audio noise level 241 in the RTP Payload Comfort Noise specification [RFC3389]. The 242 overall magnitude of the noise level is encoded into the first byte 243 of the payload, with spectral information about the noise in 244 subsequent bytes. This specification's audio level parameter is 245 defined so as to be identical to the comfort noise payload's noise- 246 level byte. 248 The magnitude of the audio level is packed into the seven least 249 significant bits of the single byte of the header extension, shown in 250 Figure 3. The least significant bit of the audio level magnitude is 251 packed into the least significant bit of the byte. The most 252 significant bit of the byte is unused and always set to 0 as shown 253 below in Figure 3. 255 0 1 2 3 4 5 6 7 256 +-+-+-+-+-+-+-+-+ 257 |0| level | 258 +-+-+-+-+-+-+-+-+ 260 Figure 3: Audio Level Encoding 262 The two-byte header defined in RFC 5285 [RFC5285] may also be used. 264 The audio level is expressed in -dBov, with values from 0 to 127 265 representing 0 to -127 dBov. dBov is the level, in decibels, relative 266 to the overload point of the system, i.e. the maximum-amplitude 267 signal that can be handled by the system without clipping.(Note: 268 Representation relative to the overload point of a system is 269 particularly useful for digital implementations, since one does not 270 need to know the relative calibration of the analog circuitry.) For 271 example, in the case of u-law (audio/pcmu) audio [ITU.G.711], the 0 272 dBov reference would be a square wave with values +/- 8031. (This 273 translates to 6.18 dBm0, relative to u-law's dBm0 definition in Table 274 6 of G.711.) 276 The audio level for digital silence, for example for a muted audio 277 source, MAY be represented as 127 (-127 dBov), regardless of the 278 dynamic range of the encoded audio format. 280 Implementations MAY choose to measure audio levels prior to encoding 281 them in the payload carried in the RTP payload, e.g. on raw linear 282 PCM input. 284 The audio level header extension only carries the level of the audio 285 in the RTP payload of the packet it is associated with, with no long- 286 term averaging or smoothing applied. 288 To simplify implementation of the encoding procedures described here, 289 this specification provides a sample Java implementation (Appendix A) 290 of an audio level calculator that helps obtain such values from raw 291 linear PCM audio samples. 293 6. Signaling Information 295 The URI for declaring the audio level header extension in an SDP 296 extmap attribute and mapping it to a local extension header 297 identifier is "urn:ietf:params:rtp-hdrext:csrc-audio-level". There 298 is no additional setup information needed for this extension (i.e. no 299 extensionattributes). 301 An example attribute line in the SDP, for a conference might be: 303 a=extmap:7 urn:ietf:params:rtp-hdrext:csrc-audio-level 305 The above mapping will most often be provided per media stream (in 306 the media-level section(s) of SDP, i.e., after an "m=" line) or 307 globally if there is more than one stream containing audio level 308 indicators in a session. 310 Presence of the above attribute in the SDP description of a media 311 stream indicates that some or all RTP packets in that stream would 312 contain the audio level information RTP extension header. 314 Conferencing clients that support audio level indicators and have no 315 mixing capabilities would not be able to content for this audio level 316 extension and would hence have to always include the direction 317 parameter in the "extmap" attribute with a value of "recvonly". 318 Conference focus entities with mixing capabilities can omit the 319 direction or set it to "sendrecv" in SDP offers. Such entities would 320 need to set it to "sendonly" in SDP answers to offers with a 321 "recvonly" parameter and to "sendrecv" when answering other 322 "sendrecv" offers. 324 This speicification does not define use of the audio level extensions 325 in video streams. Therefore, the extension defined in this document 326 SHOULD NOT be advertised in anything but audio streams. 328 The following Figure 4 and Figure 5 show two example offer/answer 329 exchanges between a conferencing client and a focus, and between two 330 conference focus entities. 332 v=0 333 o=alice 2890844526 2890844526 IN IP6 host.example.com 334 c=IN IP6 host.example.com 335 t=0 0 336 m=audio 49170 RTP/AVP 0 4 337 a=rtpmap:0 PCMU/8000 338 a=rtpmap:4 G723/8000 339 a=extmap:1/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level 341 v=0 342 i=A Seminar on the session description protocol 343 o=conf-focus 2890844730 2890844730 IN IP6 focus.example.net 344 c=IN IP6 focus.example.net 345 t=0 0 346 m=audio 52543 RTP/AVP 0 347 a=rtpmap:0 PCMU/8000 348 a=extmap:1/sendonly urn:ietf:params:rtp-hdrext:csrc-audio-level 350 A client-initiated example SDP offer/answer exchange negotiating an 351 audio stream with one-way flow of of audio level information. 353 Figure 4 355 v=0 356 i=Un seminaire sur le protocole de description des sessions 357 o=fr-focus 2890844730 2890844730 IN IP6 focus.fr.example.net 358 c=IN IP6 focus.fr.example.net 359 t=0 0 360 m=audio 49170 RTP/AVP 0 361 a=rtpmap:0 PCMU/8000 362 a=extmap:1/sendrecv urn:ietf:params:rtp-hdrext:csrc-audio-level 364 v=0 365 i=A Seminar on the session description protocol 366 o=us-focus 2890844526 2890844526 IN IP6 focus.us.example.net 367 c=IN IP6 focus.us.example.net 368 t=0 0 369 m=audio 52543 RTP/AVP 0 370 a=rtpmap:0 PCMU/8000 371 a=extmap:1/sendrecv urn:ietf:params:rtp-hdrext:csrc-audio-level 373 An example SDP offer/answer exchange between two conference focus 374 entities with mixing capabilities negotiating an audio stream with 375 bidirectional flow of audio level information. 377 Figure 5 379 7. Security Considerations 381 1. This document defines a means of attributing audio level to a 382 particular participant in a conference. An attacker may try to 383 modify the content of RTP packets in a way that would make audio 384 activity from one participant appear as coming from another. 385 2. Furthermore, the fact that audio level values would not be 386 protected even in an SRTP session might be of concern in some 387 cases where the activity of a particular participant in a 388 conference is confidential. 389 3. Both of the above are concerns that stem from the design of the 390 RTP protocol itself and they would probably also apply when using 391 CSRC identifiers the way they were specified in RFC 3550 392 [RFC3550]. It is therefore important that according to the needs 393 of a particular scenario, implementors and deployers consider use 394 of header extension encryption 395 [I-D.lennox-avtcore-srtp-encrypted-header-ext] or a lower level 396 security and authentication mechanism. 398 8. IANA Considerations 400 This document defines a new extension URI that, if approved, would 401 need to be added to the RTP Compact Header Extensions sub-registry of 402 the Real-Time Transport Protocol (RTP) Parameters registry, according 403 to the following data: 405 Extension URI: urn:ietf:params:rtp-hdrext:csrc-audio-level 406 Description: Mixer-to-client audio level indicators 407 Contact: emcho@jitsi.org 408 Reference: RFC XXXX 410 Note to the RFC-Editor: please replace "RFC XXXX" by the number of 411 this RFC. 413 9. Acknowledgments 415 Lyubomir Marinov contributed level measurement and rendering code. 417 Roni Even, Keith Drage, Ingemar Johansson, Michael Ramalho and 418 several others provided helpful feedback over the dispatch mailing 419 list. 421 Jitsi's participation in this specification is funded by the NLnet 422 Foundation. 424 10. Changes From Earlier Versions 426 Note to the RFC-Editor: please remove this section prior to 427 publication as an RFC. 429 10.1. Changes From Draft -01 431 o Removed code related the AudioLevelRenderer from "APPENDIX A. 432 Reference Implementation" as it was considered an implementation 433 matter by the working group. 434 o Modified the AudioLevelCalculator in "APPENDIX A. Reference 435 Implementation" to take overload as a parameter. 436 o Clarified non-use of audio levels in video streams 437 o Closed the P.56 open issue. It was agreed on IETF 80 that P.56 is 438 mostly about speech levels and the levels transported by the 439 extension defined here should also be able to serve as an 440 indication for noise. 441 o The Open Issues section has been removed as all issues that were 442 in there are now resolved or clarified. 443 o Editorial changes for consistency with 444 [I-D.ietf-avtext-client-to-mixer-audio-level]. 446 10.2. Changes From Draft -00 448 o Added code for sound pressure calculation and measurement in 449 "APPENDIX A. Reference Implementation". 450 o Changed affiliation for Emil Ivov. 451 o Removed "Appendix: Design choices". 453 11. References 455 11.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 461 Jacobson, "RTP: A Transport Protocol for Real-Time 462 Applications", STD 64, RFC 3550, July 2003. 464 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 465 Header Extensions", RFC 5285, July 2008. 467 11.2. Informative References 469 [I-D.ietf-avtext-client-to-mixer-audio-level] 470 Lennox, J., Ivov, E., and E. Marocco, "A Real-Time 471 Transport Protocol (RTP) Header Extension for Client-to- 472 Mixer Audio Level Indication", 473 draft-ietf-avtext-client-to-mixer-audio-level-01 (work in 474 progress), March 2011. 476 [I-D.lennox-avtcore-srtp-encrypted-header-ext] 477 Lennox, J., "Encryption of Header Extensions in the Secure 478 Real-Time Transport Protocol (SRTP)", 479 draft-lennox-avtcore-srtp-encrypted-header-ext-00 (work in 480 progress), March 2011. 482 [ITU.G.711] 483 International Telecommunications Union, "Pulse Code 484 Modulation (PCM) of Voice Frequencies", ITU- 485 T Recommendation G.711, November 1988. 487 [ITU.P56.1993] 488 International Telecommunications Union, "Objective 489 Measurement of Active Speech Level", ITU-T Recommendation 490 P.56, March 1988. 492 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 493 A., Peterson, J., Sparks, R., Handley, M., and E. 494 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 495 June 2002. 497 [RFC3389] Zopf, R., "Real-time Transport Protocol (RTP) Payload for 498 Comfort Noise (CN)", RFC 3389, September 2002. 500 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 501 Session Initiation Protocol (SIP)", RFC 4353, 502 February 2006. 504 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 505 Initiation Protocol (SIP) Event Package for Conference 506 State", RFC 4575, August 2006. 508 Appendix A. Reference Implementation 510 This appendix contains Java code for a reference implementation of 511 the level calculation and rendering methods.The code is not normative 512 and by no means the only possible implementation. Its purpose is to 513 help implementors add audio level support to mixers and clients. 515 The Java code contains an AudioLevelCalculator class that calculates 516 the sound pressure level of a signal with specific samples. It can 517 be used in mixers to generate values suitable for the level extension 518 headers. 520 The implementation is provided in Java but does not rely on any of 521 the language specific and can be easily ported to another. 523 A.1. AudioLevelCalculator.java 525 /** 526 * Calculates the audio level of specific samples of a singal based on 527 * sound pressure level. 528 */ 529 public class AudioLevelCalculator 530 { 532 /** 533 * Calculates the sound pressure level of a signal with specific 534 * samples. 535 * 536 * @param samples the samples of the signal to calculate the sound 537 * pressure level of. The samples are specified as an int 538 * array starting at offset, extending length 539 * number of elements and each int element in the specified 540 * range representing a sample of the signal to calculate the sound 541 * pressure level of. Though a sample is provided in the form of an 542 * int value, the sample size in bits is determined by the 543 * caller via overload. 544 * 545 * @param offset the offset in samples at which the samples 546 * start 547 * 548 * @param length the length of the signal specified in 549 * samples starting at offset 550 * 551 * @param overload the overload (point) of signal. 552 * For example, overload may be {@link Byte#MAX_VALUE} 553 * for 8-bit signed samples or {@link Short#MAX_VALUE} for 554 * 16-bit signed samples. 555 * 556 * @return the sound pressure level of the specified signal 557 */ 558 public static int calculateSoundPressureLevel( 559 int[] samples, int offset, int length, 560 int overload) 561 { 562 /* 563 * Calcuate the root mean square of the signal i.e. the 564 * effective sound pressure. 566 */ 567 double rms = 0; 569 for (; offset < length; offset++) 570 { 571 double sample = samples[offset]; 573 sample /= overload; 574 rms += sample * sample; 575 } 576 rms = (length == 0) ? 0 : Math.sqrt(rms / length); 578 /* 579 * The sound pressure level is a logarithmic measure of the 580 * effectivesound pressure of a sound relative to a reference 581 * value and is measured in decibels. 582 */ 583 double db; 585 /* 586 * The minimum sound pressure level which matches the maximum 587 * of the sound meter. 588 */ 589 final double MIN_SOUND_PRESSURE_LEVEL = 0; 590 /* 591 * The maximum sound pressure level which matches the maximum 592 * of the sound meter. 593 */ 594 final double MAX_SOUND_PRESSURE_LEVEL 595 = 127 /* HUMAN TINNITUS (RINGING IN THE EARS) BEGINS */; 597 if (rms > 0) 598 { 599 /* 600 * The commonly used "zero" reference sound pressure in air 601 * is 20 uPa RMS, which is usually considered the threshold 602 * of human hearing. 603 */ 604 final double REF_SOUND_PRESSURE = 0.00002; 606 db = 20 * Math.log10(rms / REF_SOUND_PRESSURE); 608 /* 609 * Ensure that the calculated level is within the minimum 610 * and maximum sound pressure level. 611 */ 612 if (db < MIN_SOUND_PRESSURE_LEVEL) 613 db = MIN_SOUND_PRESSURE_LEVEL; 615 else if (db > MAX_SOUND_PRESSURE_LEVEL) 616 db = MAX_SOUND_PRESSURE_LEVEL; 617 } 618 else 619 { 620 db = MIN_SOUND_PRESSURE_LEVEL; 621 } 623 return (int) db; 624 } 625 } 627 AudioLevelCalculator.java 629 Authors' Addresses 631 Emil Ivov (editor) 632 Jitsi 633 Strasbourg 67000 634 France 636 Email: emcho@jitsi.org 638 Enrico Marocco (editor) 639 Telecom Italia 640 Via G. Reiss Romoli, 274 641 Turin 10148 642 Italy 644 Email: enrico.marocco@telecomitalia.it 646 Jonathan Lennox 647 Vidyo, Inc. 648 433 Hackensack Avenue 649 Seventh Floor 650 Hackensack, NJ 07601 651 US 653 Email: jonathan@vidyo.com