Adding an interface to allow extention of the audio player for CRD and iOS.

remoting/client/jni/chromoting_jni_instance.h

Index: remoting/client/jni/chromoting_jni_instance.h
diff --git a/remoting/client/jni/chromoting_jni_instance.h b/remoting/client/jni/chromoting_jni_instance.h
index 738f11e1a0c610c730ddd1d5ce9cb90edbd88036..18104b8e356198f072df4b744e42e720e15c4830 100644
--- a/remoting/client/jni/chromoting_jni_instance.h
+++ b/remoting/client/jni/chromoting_jni_instance.h
@@ -2,8 +2,8 @@
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
-#ifndef REMOTING_CLIENT_CHROMOTING_JNI_INSTANCE_H_
-#define REMOTING_CLIENT_CHROMOTING_JNI_INSTANCE_H_
+#ifndef REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_
+#define REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_
 
 #include <memory>
 #include <string>
@@ -30,6 +30,7 @@ class PerformanceTracker;
 class VideoRenderer;
 }  // namespace protocol
 
+class AudioPlayerAndroid;
 class ChromotingJniRuntime;
 class JniClient;
 class JniDisplayHandler;
@@ -179,6 +180,8 @@ class ChromotingJniInstance
   std::unique_ptr<XmppSignalStrategy> signaling_;  // Must outlive client_
   protocol::ThirdPartyTokenFetchedCallback third_party_token_fetched_callback_;
 
+  std::unique_ptr<AudioPlayerAndroid> audio_player_;

[nicholss, 2016/06/09 17:26:39]

So the large change here is that now the chromoting instance objects hold the
master ref for the audio player. It use to be we would just pass the ref down to
the audio decoder and it would hold the ref until it died. Now we pass a pointer
to the decoder. 

[Lambros, 2016/06/09 19:01:05]

I'm not sure about this. What happens after ChromotingJniInstance gets deleted?
How do we make sure the audio decoder doesn't try to use the audio_player
afterwards?

If audio_player is used on another thread, then it should ideally be owned by an
object that runs code on that thread.

[nicholss, 2016/06/09 19:46:30]

For that to happen the chromoting client instance would have to die before the
chromoting client. And in all cases I can see, there is a note that client must
be released before all others in the destructor of client_instance. 

So yes it can happen but only if we change how we use client and client
instance.

[Sergey Ulanov, 2016/06/09 20:23:45]

This may be acceptable, but it is error prone. It's not clear why you need to
change this.

If there is a good reason for this change then please mention it in the comments
for ChromotingClient that the AudioConsumer must outlive the client. Also here
you want to move audio_player_ before client_ to ensure the player destroyed
after the client (class members are destroyed in reverse order).

+
   // Indicates whether to establish a new pairing with this host. This is
   // modified in ProvideSecret(), but thereafter to be used only from the
   // network thread. (This is safe because ProvideSecret() is invoked at most
@@ -209,4 +212,4 @@ class ChromotingJniInstance
 
 }  // namespace remoting
 
-#endif
+#endif  // REMOTING_CLIENT_JNI_CHROMOTING_JNI_INSTANCE_H_