Made AudioReceiveStream a mixer participant.

webrtc/voice_engine/channel_proxy.h

 /*
  *  Copyright (c) 2015 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 WEBRTC_VOICE_ENGINE_CHANNEL_PROXY_H_
 #define WEBRTC_VOICE_ENGINE_CHANNEL_PROXY_H_
 
+#include "webrtc/api/audio/audio_mixer.h"
 #include "webrtc/base/constructormagic.h"
 #include "webrtc/base/thread_checker.h"
 #include "webrtc/voice_engine/channel_manager.h"
 #include "webrtc/voice_engine/include/voe_rtp_rtcp.h"
 
 #include <memory>
 #include <string>
 #include <vector>
 
 namespace webrtc {
@@ skipping 63 matching lines @@
 
   virtual const rtc::scoped_refptr<AudioDecoderFactory>&
       GetAudioDecoderFactory() const;
 
   virtual void SetChannelOutputVolumeScaling(float scaling);
 
   virtual void SetRtcEventLog(RtcEventLog* event_log);
 
   virtual void SetRtcpRttStats(RtcpRttStats* rtcp_rtt_stats);
 
+  virtual AudioMixer::Source::AudioFrameWithInfo GetAudioFrameWithInfo(
+      int sample_rate_hz);
+
  private:
   Channel* channel() const;
 
   rtc::ThreadChecker thread_checker_;
+  rtc::ThreadChecker mixer_callback_thread_checker_;

[the sun, 2016/10/13 12:16:56]

Use an rtc::RaceChecker here instead, and use i.e.
RTC_DCHECK_RUNS_SERIALIZED(audio_render_race_checker_) in the .cc

The reason is there are situations when both the calling capture and render
threads may change and "ownership" of the WebRTC resource is passed on. What we
do want to ensure is non-concurrent access - not necessarily lock to a single
thread *ever* calling these methods.

[aleloi, 2016/10/13 13:34:56]

Then I had an incorrect understanding of the threading model. I thought
previously that AudioMixer::Mix is called from a single thread. With this
assumption I "simplified" the locking scheme in the mixer. When the assumption
turned out to be not entirely correct (two threads asked for audio in Android
OpenSL ES, some tests restarted their audio poll thread) I changed the tests and
asked henrika@ to update OpenSL ES.

This means that a race checker will have to be added to AudioMixerImpl as well.
Depending on the difference between a thread checker and a race checker, locks
may have to be re-introduced to the mixer.

[the sun, 2016/10/13 13:51:33]

Acknowledged.

   ChannelOwner channel_owner_;
 
   RTC_DISALLOW_COPY_AND_ASSIGN(ChannelProxy);
 };
 }  // namespace voe
 }  // namespace webrtc
 
 #endif  // WEBRTC_VOICE_ENGINE_CHANNEL_PROXY_H_