Make sure we don't call DisableKeyPressMonitoring without calling EnableKeyPressMonit...
commit395f6fd0ad5c1a754c12933ae3a1556ef1b95493
authortommi@chromium.org <tommi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Thu, 27 Feb 2014 12:55:13 +0000 (27 12:55 +0000)
committertommi@chromium.org <tommi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Thu, 27 Feb 2014 12:55:13 +0000 (27 12:55 +0000)
tree2d6bb0d5bda5975210318c81941568d63ed91bc3
parentd0c382d108aea041fc6eb8861f8cda0574c2c0fe
Make sure we don't call DisableKeyPressMonitoring without calling EnableKeyPressMonitoring first.

If we fail to open an audio device, AudioInputDeviceController can call DisableKeyPressMonitoring() and bring the monitoring reference count to below 0.  The state of the AudioInputDeviceController instance will be |kEmpty| in this case but the DoClose() code only checks for kClosed.

The class has 2 states that aren't really necessary.  kError is never used, so I'm just removing it.  kEmpty is only used from construction until successful initialization.  It is this state (kEmpty) that is never checked for and can cause us to call DisableKeyPressMonitoring inside DoClose without having first called EnableKeyPressMonitoring.

Since I'm cleaning up the states, I'm also fixing them as far as Chromium style goes.

BUG=347129
TEST=I ran into this while opening apprtc.appspot.com with a debug build of Chrome on Windows where my 'default communication device' was not the same as the 'default device'.  These two different devices furthermore did not have the same sample rates, which caused opening the communication device with the incorrect parameters to fail.  That's when I hit a DCHECK inside DisableKeyPressMonitoring where key_press_counter_references_ was being set to -1.

Review URL: https://codereview.chromium.org/181553003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@253762 0039d316-1c4b-4281-b951-d872f2087c98
media/audio/audio_input_controller.cc
media/audio/audio_input_controller.h