Redesign the copresence audio handlers.

components/copresence/public/copresence_constants.h

Index: components/copresence/public/copresence_constants.h
diff --git a/components/copresence/public/copresence_constants.h b/components/copresence/public/copresence_constants.h
index 1c2499d7e5cb11d2b27e93b2a6f5f797384ad4ee..cbde5fc08ab39b4150c37cc87ca453a0b36dccdd 100644
--- a/components/copresence/public/copresence_constants.h
+++ b/components/copresence/public/copresence_constants.h
@@ -27,6 +27,17 @@ extern const float kDefaultCarrierFrequency;
 extern const int kDefaultChannels;
 extern const media::ChannelLayout kDefaultChannelLayout;
 
+// These constants are used from everywhere.
+// Particularly, these are used to index the directive lists in the
+// audio manager, so do not change these enums without changing
+// audio_directive_list.[h|cc].
+enum AudioType {
+  AUDIBLE = 0,
+  INAUDIBLE = 1,
+  BOTH = 2,
+  UNKNOWN = 3,

[Daniel Erat, 2014/10/22 16:34:35]

might've mentioned this already, but "UNKNOWN" seems like an overly-vague value
to put at the top level of the copresence namespace. i think it'd be better to
rename these to AUDIO_AUDIBLE, AUDIO_INAUDIBLE, AUDIO_BOTH, and AUDIO_UNKNOWN
(or AUDIO_TYPE_*).

[rkc, 2014/10/22 18:21:48]

So the enum name is the documentation that this is an audio type. If it isn't
clear at places due to using the enum directly, we can just add
AudioType::UNKNOWN or AudioType::AUDIBLE to achieve the same effect? I believe
this is now legal in C++11?

[Daniel Erat, 2014/10/22 18:32:40]

ah, i didn't know about the c++11 angle. my main concern was just that using
UNKNOWN here would make it difficult to figure out the types of arguments passed
by callers and prevent other enums in the namespace from using UNKNOWN.

[rkc, 2014/10/22 19:28:46]

Ah yes, that would still be a problem even despite scoping. C++ won't let us
declare two different values, despite the fact that people can scope enums
(since unscoped enums are still allowed anyway).

Okay so at least renaming UNKNOWN makes sense since it _is a common type that we
may conflict. AUDIBLE/INAUDIBLE and BOTH are fairly unlikely to develop
conflicts in this namespace.

+};
+
 }  // namespace copresence
 
 #endif  // COMPONENTS_COPRESENCE_PUBLIC_COPRESENCE_CONSTANTS_