Removed the IsRecordingInProcess check for speech since it is not needed

Removed the IsRecordingInProcess check for speech since it is not needed.
The check is wrong since other clients doing capturing should not prevent speech start recording.

BUG=238800
TEST=goto www.corp.google.com/~dou/audio/audio_speech_crash/speech_input.html, the speech recognizer should work on ChromeOS
R=dalecurtis@chromium.org, joi@chromium.org, primiano@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204260

[no longer working on chromium, 2013-06-04 12:45:42]

Guys, it is mainly removing code.

Joi, please review content/public.
Primiano, please review the speech code.
Dale, media code.

Thanks,
SX

[Primiano Tucci (use gerrit), 2013-06-04 16:08:58]

> Primiano, please review the speech code.

Changes to *speech* LGTM  with one small request (I'm not an owner, though).

It seems to me that with this change the speech recognition APIs (new Web Speech
API [1] + old x-webkit-speech [2] + old experimental speech input extension API
[3]) will always try to capture audio, despite the fact that something else
might be already capturing. If it's supported by the platform this will allow
several components (e.g. Web Speech API and WebRTC) to capture simultaneously
audio, eventually even from the same source.
I've just a question here: has anyone tested what happens in the WebRTC + Web
Speech case on a platform that does not supports concurrent audio capture from
the same source (if any)?

Just for sake of clarity, this change will NOT have any visible impact on
concurrent speech recognition sessions. In other words, in the case a new speech
recognition session is started (via either  [1],[2] or [3]) when an another one
is already running, the old session will be aborted (receiving the corresponding
OnError event) and the new one will start with no errors. This behavior is not
affected by this CL.

Regards,
Primiano

[1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html
[2] http://slides.html5rocks.com/#speech-input
[3] http://developer.chrome.com/extensions/experimental.speechInput.html

[Primiano Tucci (use gerrit), 2013-06-04 16:09:03]

https://codereview.chromium.org/16286010/diff/1/content/browser/speech/speech...
File content/browser/speech/speech_recognizer_impl.cc (left):

https://codereview.chromium.org/16286010/diff/1/content/browser/speech/speech...
content/browser/speech/speech_recognizer_impl.cc:408:
SPEECH_AUDIO_ERROR_DETAILS_IN_USE));
IIRC, this is the only point in which SPEECH_AUDIO_ERROR_DETAILS_IN_USE is
triggered.
Can you please remove SPEECH_AUDIO_ERROR_DETAILS_IN_USE and cleanup the
remaining code (chrome_speech_recognition_manager_delegate.cc and corresponding
resources associated to the error message)?

[DaleCurtis, 2013-06-04 18:28:05]

mechanically lgtm % nit, I defer to others on whether this is okay for speech
input.

https://codereview.chromium.org/16286010/diff/1/media/audio/audio_manager_base.h
File media/audio/audio_manager_base.h (right):

https://codereview.chromium.org/16286010/diff/1/media/audio/audio_manager_bas...
media/audio/audio_manager_base.h:11: #include "base/atomic_ref_count.h"
Cleanup includes.

[Jói, 2013-06-04 22:19:25]

LGTM for //content/public.

[no longer working on chromium, 2013-06-05 09:13:02]

On 2013/06/04 16:08:58, Primiano Tucci wrote:
> > Primiano, please review the speech code.
> 
> Changes to *speech* LGTM  with one small request (I'm not an owner, though).
> 
> It seems to me that with this change the speech recognition APIs (new Web
Speech
> API [1] + old x-webkit-speech [2] + old experimental speech input extension
API
> [3]) will always try to capture audio, despite the fact that something else
> might be already capturing. If it's supported by the platform this will allow
> several components (e.g. Web Speech API and WebRTC) to capture simultaneously
> audio, eventually even from the same source.
> I've just a question here: has anyone tested what happens in the WebRTC + Web
> Speech case on a platform that does not supports concurrent audio capture from
> the same source (if any)?
> 

None of the clients (WebRtc/WebAudio/pepper) opens the soundcard in exclusive
code, so we support concurrent audio capture on all platform.

> Just for sake of clarity, this change will NOT have any visible impact on
> concurrent speech recognition sessions. In other words, in the case a new
speech
> recognition session is started (via either  [1],[2] or [3]) when an another
one
> is already running, the old session will be aborted (receiving the
corresponding
> OnError event) and the new one will start with no errors. This behavior is not
> affected by this CL.
> 

Right, I have already verified this behaviour on Linux, it is the same
with/without this patch.


> Regards,
> Primiano
> 
> [1] https://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html
> [2] http://slides.html5rocks.com/#speech-input
> [3] http://developer.chrome.com/extensions/experimental.speechInput.html

[no longer working on chromium, 2013-06-05 09:30:11]

https://codereview.chromium.org/16286010/diff/1/content/browser/speech/speech...
File content/browser/speech/speech_recognizer_impl.cc (left):

https://codereview.chromium.org/16286010/diff/1/content/browser/speech/speech...
content/browser/speech/speech_recognizer_impl.cc:408:
SPEECH_AUDIO_ERROR_DETAILS_IN_USE));
On 2013/06/04 16:09:03, Primiano Tucci wrote:
> IIRC, this is the only point in which SPEECH_AUDIO_ERROR_DETAILS_IN_USE is
> triggered.
> Can you please remove SPEECH_AUDIO_ERROR_DETAILS_IN_USE and cleanup the
> remaining code (chrome_speech_recognition_manager_delegate.cc and
corresponding
> resources associated to the error message)?

Done.

https://codereview.chromium.org/16286010/diff/1/media/audio/audio_manager_base.h
File media/audio/audio_manager_base.h (right):

https://codereview.chromium.org/16286010/diff/1/media/audio/audio_manager_bas...
media/audio/audio_manager_base.h:11: #include "base/atomic_ref_count.h"
On 2013/06/04 18:28:05, DaleCurtis wrote:
> Cleanup includes.

Done.

[commit-bot: I haz the power, 2013-06-05 09:30:25]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/xians@chromium.org/16286010/7001

[commit-bot: I haz the power, 2013-06-05 09:56:03]

Retried try job too often on linux_chromeos for step(s) app_list_unittests,
ash_unittests, aura_unittests, browser_tests, content_browsertests,
ppapi_unittests, unit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-06-05 11:09:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/xians@chromium.org/16286010/7001

[no longer working on chromium, 2013-06-05 14:56:22]

Committed patchset #2 manually as r204260 (presubmit successful).