Adding key press detection in the browser process.

content/renderer/media/webaudio_capturer_source.cc

Index: content/renderer/media/webaudio_capturer_source.cc
diff --git a/content/renderer/media/webaudio_capturer_source.cc b/content/renderer/media/webaudio_capturer_source.cc
index 0ab8dc360e605daf0fb3d6fba63fbacfd3084436..35cd99ce3b03d0b13d38672bf6b1c70b928fa223 100644
--- a/content/renderer/media/webaudio_capturer_source.cc
+++ b/content/renderer/media/webaudio_capturer_source.cc
@@ -96,7 +96,7 @@ void WebAudioCapturerSource::consumeAudio(
   int capture_frames = params_.frames_per_buffer();
   while (fifo_->frames() >= capture_frames) {
     fifo_->Consume(capture_bus_.get(), 0, capture_frames);
-    callback_->Capture(capture_bus_.get(), 0, 1.0);
+    callback_->Capture(capture_bus_.get(), 0, 1.0, false);

[tommi (sloooow) - chröme, 2013/08/06 10:57:47]

Can you add a todo or some comment that explains that this behavior is possibly
wrong?

If keypress detection has been applied at the getUserMedia level and WebAudio is
using (or supposed to be using) that mediastream, then this is disregarding the
constraints, right?

Then again, this will probably go away once audio processing has been moved out
of peerconnection and into chrome or rather the audio track implementation. 
Hmm... I guess there's no action here unless maybe to somehow explain this in a
comment?

related bug: crbug.com/268820

[jiayl, 2013/08/06 17:24:11]

I'm not sure I understand this...the current plan is to report the state of
"overwhelming typing noise detected" back to the JS through peerconnection stats
(i.e. result of getStats),  instead of muting the stream automatically. Then JS
should decide what to do with the stream.
Since webaudio is not associated with a peerconnection, it has no way to get the
stats update anyway. Would we ever want to enable typing detection for webaudio
in this case?

   }
 }