webrtc/audio/audio_level.h
Henrik Boström d2c336f892 [getStats] Implement "media-source" audio levels, fixing Chrome bug.
Implements RTCAudioSourceStats members:
- audioLevel
- totalAudioEnergy
- totalSamplesDuration
In this CL description these are collectively referred to as the audio
levels.

The audio levels are removed from sending "track" stats (in Chrome,
these are now reported as undefined instead of 0).

Background:
  For sending tracks, audio levels were always reported as 0 in Chrome
(https://crbug.com/736403), while audio levels were correctly reported
for receiving tracks. This problem affected the standard getStats() but
not the legacy getStats(), blocking some people from migrating. This
was likely not a problem in native third_party/webrtc code because the
delivery of audio frames from device to send-stream uses a different
code path outside of chromium.
  A recent PR (https://github.com/w3c/webrtc-stats/pull/451) moved the
send-side audio levels to the RTCAudioSourceStats, while keeping the
receive-side audio levels on the "track" stats. This allows an
implementation to report the audio levels even if samples are not sent
onto the network (such as if an ICE connection has not been established
yet), reflecting some of the current implementation.

Changes:
1. Audio levels are added to RTCAudioSourceStats. Send-side audio
   "track" stats are left undefined. Receive-side audio "track" stats
   are not changed in this CL and continue to work.
2. Audio level computation is moved from the AudioState and
   AudioTransportImpl to the AudioSendStream. This is because a) the
   AudioTransportImpl::RecordedDataIsAvailable() code path is not
   exercised in chromium, and b) audio levels should, per-spec, not be
   calculated on a per-call basis, for which the AudioState is defined.
3. The audio level computation is now performed in
   AudioSendStream::SendAudioData(), a code path used by both native
   and chromium code.
4. Comments are added to document behavior of existing code, such as
   AudioLevel and AudioSendStream::SendAudioData().

Note:
  In this CL, just like before this CL, audio level is only calculated
after an AudioSendStream has been created. This means that before an
O/A negotiation, audio levels are unavailable.
  According to spec, if we have an audio source, we should have audio
levels. An immediate solution to this would have been to calculate the
audio level at pc/rtp_sender.cc. The problem is that the
LocalAudioSinkAdapter::OnData() code path, while exercised in chromium,
is not exercised in native code. The issue of calculating audio levels
on a per-source bases rather than on a per-send stream basis is left to
https://crbug.com/webrtc/10771, an existing "media-source" bug.

This CL can be verified manually in Chrome at:
https://codepen.io/anon/pen/vqRGyq

Bug: chromium:736403, webrtc:10771
Change-Id: I8036cd9984f3b187c3177470a8c0d6670a201a5a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143789
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28480}
2019-07-04 08:13:45 +00:00

75 lines
2.9 KiB
C++

/*
* Copyright (c) 2011 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef AUDIO_AUDIO_LEVEL_H_
#define AUDIO_AUDIO_LEVEL_H_
#include "rtc_base/critical_section.h"
#include "rtc_base/thread_annotations.h"
namespace webrtc {
class AudioFrame;
namespace voe {
// This class is thread-safe. However, TotalEnergy() and TotalDuration() are
// related, so if you call ComputeLevel() on a different thread than you read
// these values, you still need to use lock to read them as a pair.
class AudioLevel {
public:
AudioLevel();
~AudioLevel();
void Reset();
// Returns the current audio level linearly [0,32767], which gets updated
// every "kUpdateFrequency+1" call to ComputeLevel() based on the maximum
// audio level of any audio frame, decaying by a factor of 1/4 each time
// LevelFullRange() gets updated.
// Called on "API thread(s)" from APIs like VoEBase::CreateChannel(),
// VoEBase::StopSend().
int16_t LevelFullRange() const;
void ResetLevelFullRange();
// See the description for "totalAudioEnergy" in the WebRTC stats spec
// (https://w3c.github.io/webrtc-stats/#dom-rtcaudiohandlerstats-totalaudioenergy)
// In our implementation, the total audio energy increases by the
// energy-equivalent of LevelFullRange() at the time of ComputeLevel(), rather
// than the energy of the samples in that specific audio frame. As a result,
// we may report a higher audio energy and audio level than the spec mandates.
// TODO(https://crbug.com/webrtc/10784): We should either do what the spec
// says or update the spec to match our implementation. If we want to have a
// decaying audio level we should probably update both the spec and the
// implementation to reduce the complexity of the definition. If we want to
// continue to have decaying audio we should have unittests covering the
// behavior of the decay.
double TotalEnergy() const;
double TotalDuration() const;
// Called on a native capture audio thread (platform dependent) from the
// AudioTransport::RecordedDataIsAvailable() callback.
// In Chrome, this method is called on the AudioInputDevice thread.
void ComputeLevel(const AudioFrame& audioFrame, double duration);
private:
enum { kUpdateFrequency = 10 };
rtc::CriticalSection crit_sect_;
int16_t abs_max_ RTC_GUARDED_BY(crit_sect_);
int16_t count_ RTC_GUARDED_BY(crit_sect_);
int16_t current_level_full_range_ RTC_GUARDED_BY(crit_sect_);
double total_energy_ RTC_GUARDED_BY(crit_sect_) = 0.0;
double total_duration_ RTC_GUARDED_BY(crit_sect_) = 0.0;
};
} // namespace voe
} // namespace webrtc
#endif // AUDIO_AUDIO_LEVEL_H_