Disable low latency audio under remote desktop sessions.

Disable low latency audio under remote desktop sessions.

CoreAudio seems to be the source of a lot of hangs when under a
remote desktop session and we've had past success with moving
these users over to WaveOut, so do so for all remote sessions.

This first queries the SM_REMOTESESSION system metric and then
tries to get the friendly name of the default audio device; if
it can't do that and a remote session is present or it can and
friendly name is "Remote Audio", CoreAudio functions are
disabled.

This change also adds a check to WASAPIAudioOutputStream::Open
to fail when a remote audio stream is requested; which will
trigger fallback in the AudioOutputResampler (if the user
resumes their session locally later they'll get WASAPI again
once streams have been closed for a few seconds).

BUG=422522
TEST=remote desktop session w/ remote audio gets WaveOut; works
with xfreerdp and Microsoft Remote Desktop client for OS; local
session gets WASAPI, connecting and starting a stream remotely
gets WaveOut.

Committed: https://crrev.com/d0d6ea4bbdd431f0b794ae5e8cf353e2e87593ab
Cr-Commit-Position: refs/heads/master@{#324246}

[DaleCurtis, 2015-04-03 19:14:50]

dalecurtis@chromium.org changed reviewers:
+ henrika@chromium.org, tommi@chromium.org

[DaleCurtis, 2015-04-03 19:14:51]

WDYT? I'd rather only do this for users who enable "remote audio" instead of
"local playback" when starting the RDP session, but can't find a way to detect
this. With your stronger windows-fu, know of anything? :)

[henrika (OOO until Aug 14), 2015-04-05 14:41:08]

LGTM. I don't know any alternative way of detecting.

https://codereview.chromium.org/1060673002/diff/1/media/audio/win/core_audio_...
File media/audio/win/core_audio_util_win.cc (right):

https://codereview.chromium.org/1060673002/diff/1/media/audio/win/core_audio_...
media/audio/win/core_audio_util_win.cc:181: if
(GetSystemMetrics(SM_REMOTESESSION))
This is the only detection method I could find as well. I have no better idea.

[henrika (OOO until Aug 14), 2015-04-05 14:47:17]

FYI, https://msdn.microsoft.com/en-us/library/aa383838.aspx

[DaleCurtis, 2015-04-06 19:06:20]

Patchset #2 (id:20001) has been deleted

[DaleCurtis, 2015-04-06 19:10:12]

Thanks for the link Henrik, I wasn't able to find any data structure which even
mentioned remote audio. I dug into the xfreerdp code and the values its sending
over the RDP protocol to enable remote audio don't seem to be exposed anywhere.
Instead I noticed that all remote audio connections use a default device called
"Remote Audio" which we can detect via the friendly name!

PTAL. I've refactored CoreAudioUtil a little bit to remove the
CanCreateDeviceEnumerator in favor of some internal methods for doing similar
things. Notably, this also resolves the issue where we weren't attempting to
reinitialize COM for device enumerator failure.

Locally the remote session check adds about 0.6ms and if a remote session is
present, another 1.5ms on top of that for checking if the device name is "Remote
Audio".

[henrika (OOO until Aug 14), 2015-04-07 07:41:08]

Looks great Dale. Nice work ;-)

LGTM with nits. Tommi may have additional comments as well.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
File media/audio/win/core_audio_util_win.cc (right):

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:181: hr = CoInitializeEx(NULL,
COINIT_MULTITHREADED);
I hope Tommi can comment on this part.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:205: return device_name == "Remote
Audio";
Any reference to how we know that this is always the case?
Skip case sensitive?

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:260: if (FAILED(hr))
Do we need this check? Is it not included in IsRemoteDeviceInternal?

[DaleCurtis, 2015-04-07 22:24:54]

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
File media/audio/win/core_audio_util_win.cc (right):

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:181: hr = CoInitializeEx(NULL,
COINIT_MULTITHREADED);
On 2015/04/07 07:41:08, henrika wrote:
> I hope Tommi can comment on this part.

Can you elaborate on your question? I think it was an error that we weren't
doing this in the CanCreateDeviceEnumerator() code previously.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:205: return device_name == "Remote
Audio";
On 2015/04/07 07:41:08, henrika wrote:
> Any reference to how we know that this is always the case?
> Skip case sensitive?

Couldn't find any reference. I have no idea if "Remote Audio" is the same name
used with a french / japanese / etc installation. It'd be better if we could
compare on device id, but I don't know if those are the same for all windows
installations.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:260: if (FAILED(hr))
On 2015/04/07 07:41:08, henrika wrote:
> Do we need this check? Is it not included in IsRemoteDeviceInternal?

Seems GetDefaultAudioEndpoint could still fail? that check below doesn't see if
device is null.

[henrika (OOO until Aug 14), 2015-04-08 06:57:36]

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
File media/audio/win/core_audio_util_win.cc (right):

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:181: hr = CoInitializeEx(NULL,
COINIT_MULTITHREADED);
I think you are correct but maybe Tommi has a second opinion. He knows this area
very well. That's all I meant.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:205: return device_name == "Remote
Audio";
On 2015/04/07 22:24:54, DaleCurtis wrote:
> On 2015/04/07 07:41:08, henrika wrote:
> > Any reference to how we know that this is always the case?
> > Skip case sensitive?
> 
> Couldn't find any reference. I have no idea if "Remote Audio" is the same name
> used with a french / japanese / etc installation. It'd be better if we could
> compare on device id, but I don't know if those are the same for all windows
> installations.

Acknowledged.

https://codereview.chromium.org/1060673002/diff/40001/media/audio/win/core_au...
media/audio/win/core_audio_util_win.cc:260: if (FAILED(hr))
On 2015/04/07 22:24:54, DaleCurtis wrote:
> On 2015/04/07 07:41:08, henrika wrote:
> > Do we need this check? Is it not included in IsRemoteDeviceInternal?
> 
> Seems GetDefaultAudioEndpoint could still fail? that check below doesn't see
if
> device is null.

Acknowledged.

[DaleCurtis, 2015-04-08 16:16:46]

Crashes are pretty high, so I'm going to land this since tommi@ is out of
vacation and we can soak it on canary for a while to see if it's sufficient.

[DaleCurtis, 2015-04-08 16:16:51]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2015-04-08 16:17:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1060673002/40001

[commit-bot: I haz the power, 2015-04-08 17:21:49]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2015-04-08 17:23:39]

Patchset 2 (id:??) landed as
https://crrev.com/d0d6ea4bbdd431f0b794ae5e8cf353e2e87593ab
Cr-Commit-Position: refs/heads/master@{#324246}