Nice find! Do we not have an audio input test running on bots that would catch such leaks?

Not that I'm aware of. Any suggestions for how we could have caught it? Seems like a general test for number of user objects or heap allocations before and after running a test could potentially catch it, but that would be very hard to do reliably.

Hmm, I guess I thought Dr.Memory would have caught this as a leak if we just had a test which started and stopped capture. Though now that I think about it I don't recall if we even have Dr.Memory bots anymore.

clang-win + lsan might be an option in the future if a test which creates an input stream can run on the bots.

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

commit 3234f6bb6cfd0343aac4755271f2b8697a8cde49
Author: tommi <tommi@chromium.org>
Date: Thu Feb 09 18:37:57 2017

Add UMA stats to track down issues with opening "high latency" (aka linear) audio input streams on Windows and fix memory leak that appears to have been there for a long while.

BUG= 684741 , 689976 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

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

[modify] https://crrev.com/3234f6bb6cfd0343aac4755271f2b8697a8cde49/media/audio/win/audio_low_latency_input_win.cc
[modify] https://crrev.com/3234f6bb6cfd0343aac4755271f2b8697a8cde49/media/audio/win/audio_low_latency_input_win.h
[modify] https://crrev.com/3234f6bb6cfd0343aac4755271f2b8697a8cde49/tools/metrics/histograms/histograms.xml