Enable the volume slider in Ash for windows.

ash/system/win/audio/tray_audio_delegate_win.cc

Index: ash/system/win/audio/tray_audio_delegate_win.cc
diff --git a/ash/system/win/audio/tray_audio_delegate_win.cc b/ash/system/win/audio/tray_audio_delegate_win.cc
new file mode 100644
index 0000000000000000000000000000000000000000..7e1826cdcfc10d568b5ceee860c251bfceeb2bed
--- /dev/null
+++ b/ash/system/win/audio/tray_audio_delegate_win.cc
@@ -0,0 +1,103 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "ash/system/win/audio/tray_audio_delegate_win.h"
+
+#include <audiopolicy.h>
+#include <cmath>
+
+#include "grit/ash_resources.h"
+#include "grit/ash_strings.h"
+#include "media/audio/win/core_audio_util_win.h"
+
+using base::win::ScopedComPtr;
+
+namespace {
+
+// Volume value which should be considered as muted in range [0, 100].
+const int kMuteThresholdPercent = 1;

[henrika (OOO until Aug 14), 2014/02/25 07:56:21]

How do you define muted? When the volume is low or when the user has clicked the
mute button?

+
+// Lowest volume which is considered to be audible in the range [0, 100].
+const int kAudibleOutputVolumeThreshold = 10;
+
+}  // namespace
+
+namespace ash  {
+namespace system {
+
+void TrayAudioDelegateWin::AdjustOutputVolumeToAudibleLevel() {
+  if (GetOutputVolumeLevel() < kAudibleOutputVolumeThreshold)
+    SetOutputVolumeLevel(kAudibleOutputVolumeThreshold);
+}
+
+int TrayAudioDelegateWin::GetOutputDefaultVolumeMuteLevel() {
+  return kMuteThresholdPercent;

[tommi (sloooow) - chröme, 2014/02/25 16:47:38]

nit: do you actually need the constant?  might as well move the comment here and
return 1;

Since there's a method specifically to return this value, I'd guess that having
a constant for it might not be desirable since users shouldn't depend on it.

[zturner, 2014/02/25 17:19:56]

I also used the constant in AdjustOutputVolumeToAudibleLevel (not in this CL,
but that's because I had an oversight, but will be fixed in next upload).  So
it's used both internally and externally

+}
+
+int TrayAudioDelegateWin::GetOutputVolumeLevel() {
+  ScopedComPtr<ISimpleAudioVolume> volume_control =
+      CreateDefaultVolumeControl();
+
+  float level = 0.0f;
+  if (FAILED(volume_control->GetMasterVolume(&level)))
+    return 0;
+
+  return static_cast<int>(std::roundf(level * 100.0f));
+}
+
+int TrayAudioDelegateWin::GetActiveOutputDeviceIconId() {
+  return kNoAudioDeviceIcon;
+}
+

[tommi (sloooow) - chröme, 2014/02/25 16:47:38]

one empty line

+
+bool TrayAudioDelegateWin::HasAlternativeSources() {
+  return false;
+}
+
+bool TrayAudioDelegateWin::IsOutputAudioMuted() {

[tommi (sloooow) - chröme, 2014/02/25 16:47:38]

Would be good to have thread checks for all of these methods since it looks like
they're assuming single threaded usage.

[zturner, 2014/02/25 17:19:56]

Is CoreAudio inherently single-threaded?  CreateDefaultVolumeControl, for
example, creates a new instance every time and doesn't re-use any shared
variables, so I think it should be ok right?

[tommi (sloooow) - chröme, 2014/02/26 11:10:44]

CoreAudio isn't single threaded but not every thread is COM initialized.  There
are some quirks in the implementation on Windows 8 that require the first thread
that accesses an IAudioClient, to be an STA thread.  From there on MTA access is
fine (I'm assuming since the threading model is 'Both').  As is, our threads are
only MTA initialized so we need to fix that.

Given this and that we're already in a position to isolate usage of CoreAudio
routines to a specific thread (although you're not using that particular thread
here), I think we're going to make that change soon in the media code.  The
thread to use will be the AudioManager's thread:
https://code.google.com/p/chromium/codesearch#chromium/src/media/audio/audio_...

So I think it might be a good idea here to avoid having synchronous methods that
use the API such as IsOutputAudioMuted and GetOutputVolumeLevel.  If they could
use a callback to deliver the results and do the actual work on the audio
thread, then that would be best.  (PostTaskAndReply type of thing)

We will then change the AudioManager's thread to be an STA thread and also
initialize our CoreAudio routines in a way that avoids the race I mentioned
earlier.  Furthermore we'll start to add DCHECKs to all CoreAudio related
routines that assert we're on the correct thread.

+  ScopedComPtr<ISimpleAudioVolume> volume_control =
+      CreateDefaultVolumeControl();
+
+  BOOL mute = FALSE;
+  if (FAILED(volume_control->GetMute(&mute)))
+    return false;
+
+  return !!mute;
+}
+
+void TrayAudioDelegateWin::SetOutputAudioIsMuted(bool is_muted) {
+  ScopedComPtr<ISimpleAudioVolume> volume_control =
+      CreateDefaultVolumeControl();
+
+  volume_control->SetMute(is_muted, NULL);
+}
+
+void TrayAudioDelegateWin::SetOutputVolumeLevel(int level) {
+  ScopedComPtr<ISimpleAudioVolume> volume_control =
+      CreateDefaultVolumeControl();
+
+  float volume_level = static_cast<float>(level) / 100.0f;
+  volume_control->SetMasterVolume(volume_level, NULL);
+}
+
+ScopedComPtr<ISimpleAudioVolume>
+TrayAudioDelegateWin::CreateDefaultVolumeControl() {
+  ScopedComPtr<ISimpleAudioVolume> volume_control;
+  ScopedComPtr<IAudioSessionManager> session_manager;

[henrika (OOO until Aug 14), 2014/02/25 07:56:21]

Why are you using the SessionManager here? What is the difference in
functionality compared with using IMMDevice->IAudioClient-> instead?

+
+  ScopedComPtr<IMMDevice> device =
+      media::CoreAudioUtil::CreateDefaultDevice(eRender, eConsole);
+  if (FAILED(device->Activate(__uuidof(IAudioSessionManager), CLSCTX_ALL, NULL,
+             session_manager.ReceiveVoid()))) {
+    return volume_control;
+  }
+
+  session_manager->GetSimpleAudioVolume(NULL, FALSE,
+      volume_control.Receive());
+
+  return volume_control;
+}
+
+}  // namespace system
+}  // namespace ash