Remove cast to LocalAudioSource from AudioRtpSender.

talk/app/webrtc/rtpsender.cc

 /*
  * libjingle
  * Copyright 2015 Google Inc.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are met:
  *
  *  1. Redistributions of source code must retain the above copyright notice,
  *     this list of conditions and the following disclaimer.
  *  2. Redistributions in binary form must reproduce the above copyright notice,
@@ skipping 165 matching lines @@
     provider_->SetAudioSend(ssrc_, false, options, nullptr);
     if (stats_) {
       stats_->RemoveLocalAudioTrack(track_.get(), ssrc_);
     }
   }
   stopped_ = true;
 }
 
 void AudioRtpSender::SetAudioSend() {
   RTC_DCHECK(!stopped_ && can_send_track());
-  cricket::AudioOptions options;
-  if (track_->enabled() && track_->GetSource() &&
-      !track_->GetSource()->remote()) {
-    // TODO(xians): Remove this static_cast since we should be able to connect
-    // a remote audio track to a peer connection.
-    options = static_cast<LocalAudioSource*>(track_->GetSource())->options();
-  }
-
   // Use the renderer if the audio track has one, otherwise use the sink
   // adapter owned by this class.
   cricket::AudioRenderer* renderer =
       track_->GetRenderer() ? track_->GetRenderer() : sink_adapter_.get();
   ASSERT(renderer != nullptr);
-  provider_->SetAudioSend(ssrc_, track_->enabled(), options, renderer);
+  provider_->SetAudioSend(ssrc_, track_->enabled(), cricket::AudioOptions(),
+                          renderer);

[the sun, 2016/01/11 14:49:31]

Are you sure these options are always empty? Is there a test you can rely on?

If this holds water, you should be able to drop the AudioOptions from the
SetAudioSend() calls all the way down the stack. (and upwards, since we're now
disregarding any constraints passed to LocalAudioSource::Create()).

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjin...

Options are passed down to WVoMC::SetSendParameters() too, from
WebRtcSession::UpdateSessionState(), but contraints don't appear to be part of
the mix there, so I guess there options are passed in both places. Some here,
some there.

[tommi, 2016/01/14 16:24:11]

In the case of Chrome, these options usually contain a set of default values but
can contain values set by callers via getUserMedia.  However, Chrome handles
those values itself and applies it to its instance of the APM.  In this case,
these options are being applied on a different instance if I understand
correctly and in theory, constaints passed to getUserMedia could be applied to
an unrelated remote audio track.

Dropping the AudioOptions from SetAudioSend sgtm if this is the only call site.

[the sun, 2016/01/18 15:01:32]

Non-Chrome clients use the VoE APM instance, e.g. AppRTC
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc...)
and push constraints down through LocalAudioSource.

 }
 
 VideoRtpSender::VideoRtpSender(VideoTrackInterface* track,
                                const std::string& stream_id,
                                VideoProviderInterface* provider)
     : id_(track->id()),
       stream_id_(stream_id),
       provider_(provider),
       track_(track),
       cached_track_enabled_(track->enabled()) {
@@ skipping 101 matching lines @@
   RTC_DCHECK(!stopped_ && can_send_track());
   const cricket::VideoOptions* options = nullptr;
   VideoSourceInterface* source = track_->GetSource();
   if (track_->enabled() && source) {
     options = source->options();
   }
   provider_->SetVideoSend(ssrc_, track_->enabled(), options);
 }
 
 }  // namespace webrtc