Sorry for the late response. I am working on this bug.

This is a code defect in AudioCapturerWin of Windows host.
I have technically reverted following changes,
https://chromium.googlesource.com/chromium/src/+/3ba26c009b0b2583562b695c426391f71b626f33
https://chromium.googlesource.com/chromium/src/+/fc96e4f848fb4cca37e2da244dc873c1831d70c5
https://chromium.googlesource.com/chromium/src/+/b40182aceb9f9ab588a296ace041360fa40bac88
by setting level = 1 @ https://goo.gl/Ug2MwS, but the host still cannot generate audio output, which suggests this as a limitation of current implementation. MSDN (https://goo.gl/UTBo4M) states that, "Not all audio adapters have loopback devices. Thus, applications that depend on them will not work on all systems".
Though I cannot quite tell whether this bug belongs to the issue, it's highly possible we need a different implementation of AudioCapturerWin.

Sorry, it looks like I have misunderstood the statements on MSDN.
WASAPI loopback recording, which is the APIs we are now using, does not use hardware loopback devices.

But AudioCapturerWin fails on certain types of hardware. There are several interesting parameters in AudioCapturerWin we may try.
1. GetDefaultAudioEndpoint(..., Role, ...). Now we are always using eConsole, but we may need to capture eConsole, eMultimedia, eCommunications altogether.
2. We only support 16-bit samples and 44.1 kHz or 48 kHz, and 2 channels. But 7.1 definitely has 8 channels.

Any Update at all it is really annoying I had to disable razor virtual surround since it only supports 5.1.

I have confirmed this is a non-supported scenario in Chrome Remote Desktop, i.e. only two channels are supported.
We do not have a plan to support more channels, but I am working on a change to merge more channels into two. It should be able to be released with M60.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/00c53fe4b76655f083d3cf25e25154467ffbe675

commit 00c53fe4b76655f083d3cf25e25154467ffbe675
Author: zijiehe <zijiehe@chromium.org>
Date: Mon Apr 24 23:33:05 2017

[Chromoting] Move DefaultAudioDeviceChangeDetector out of AudioCapturerWin

This is a trivial change to move IMMNotificationClient implementation out of
AudioCapturerWin. Now the new DefaultAudioDeviceChangeDetector can unregister
itself from IMMDeviceEnumerator in destructor.

BUG= 669070 

Review-Url: https://codereview.chromium.org/2809293006
Cr-Commit-Position: refs/heads/master@{#466824}

[modify] https://crrev.com/00c53fe4b76655f083d3cf25e25154467ffbe675/remoting/host/audio_capturer_win.cc
[modify] https://crrev.com/00c53fe4b76655f083d3cf25e25154467ffbe675/remoting/host/audio_capturer_win.h
[modify] https://crrev.com/00c53fe4b76655f083d3cf25e25154467ffbe675/remoting/host/win/BUILD.gn
[add] https://crrev.com/00c53fe4b76655f083d3cf25e25154467ffbe675/remoting/host/win/default_audio_device_change_detector.cc
[add] https://crrev.com/00c53fe4b76655f083d3cf25e25154467ffbe675/remoting/host/win/default_audio_device_change_detector.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e

commit 26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e
Author: zijiehe <zijiehe@chromium.org>
Date: Tue May 23 04:34:11 2017

[Chromoting] Add AudioVolumeApplier to reduce the complexity and the dependency of kChannels

AudioVolumeApplier is a component to apply audio level to the samples, it also
has an AudioSilenceDetector internally to detect whether the samples are silent
before or after applying the level.

It does not rely on a fixed kChannels, which is good to support 5.1 / 7.1
channels.

BUG= 669070 

Review-Url: https://codereview.chromium.org/2840773004
Cr-Commit-Position: refs/heads/master@{#473809}

[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/BUILD.gn
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_capturer_linux.cc
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_capturer_win.cc
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_capturer_win.h
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_silence_detector.cc
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_silence_detector.h
[add] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_volume_filter.cc
[add] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_volume_filter.h
[add] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/audio_volume_filter_unittest.cc
[modify] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/win/BUILD.gn
[add] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/win/audio_volume_filter_win.cc
[add] https://crrev.com/26fe0dac88cb99bc94ce4d5f1ed9bc6cfff2f88e/remoting/host/win/audio_volume_filter_win.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c331598675bb5e25fd8bf064d161e05e4b1b6477

commit c331598675bb5e25fd8bf064d161e05e4b1b6477
Author: zijiehe <zijiehe@chromium.org>
Date: Sat Jun 10 01:22:24 2017

[Chromoting] Implement down mixing in AudioPump

This change implements down mixing logic in AudioPump.

It adds 3 / 4 / 5 / 6 / 7 / 8 channels support in AudioPacket and down mixes the
packet into stereo before encoding. The newly added logic will only be executed
once multichannel output is returned by Windows API.

R=SergeyU@chromium.org, JoeDow@chromium.org
BUG= 669070 

Review-Url: https://codereview.chromium.org/2903153004
Cr-Commit-Position: refs/heads/master@{#478488}

[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/host/BUILD.gn
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/host/audio_capturer_win.cc
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/host/audio_capturer_win.h
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/proto/audio.proto
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/protocol/DEPS
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/protocol/audio_pump.cc
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/protocol/audio_pump.h
[modify] https://crrev.com/c331598675bb5e25fd8bf064d161e05e4b1b6477/remoting/protocol/audio_pump_unittest.cc

Hi, AJ. This issue has been fixed. I have a 7.1 headset, you can use it to verify this change.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2fc3d053221101434dcb5049c3cc90dd9c15d73a

commit 2fc3d053221101434dcb5049c3cc90dd9c15d73a
Author: zijiehe <zijiehe@chromium.org>
Date: Tue Jun 13 03:27:42 2017

[Chromoting] Update comments in AudioCapturerWin

In change http://codereview.chromium.org/2903153004/, Chris (ChCunningham@)
suggested to update the comments. But I forgot to publish the updated version.

BUG= 669070 

Review-Url: https://codereview.chromium.org/2934983002
Cr-Commit-Position: refs/heads/master@{#478887}

[modify] https://crrev.com/2fc3d053221101434dcb5049c3cc90dd9c15d73a/remoting/host/audio_capturer_win.cc

Verified Fixed in 61.0.3142.0. playback works when using 5.1 sound mode on the windows host.