In some rare cases it has been found that Windows returns a sample-rate of 0, even though it's capa…

In some rare cases it has been found that Windows returns a sample-rate of 0, even though it's capable of
rendering audio with WASAPI.

For the Web Audio API, Let's make sure to return a sane fallback sample-rate.

BUG=222718
TEST=none
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=190506

[Chris Rogers, 2013-03-25 21:22:08]

Hopeful fix to:
http://crbug.com/222718

dalecurtis: audio review
jamesr: content OWNER approval

[jamesr, 2013-03-25 21:23:32]

lgtm for content/renderer/, although Dale (or someone else audio-ish) should
review for content.

Is there any other code in the codebase that depends on the sample rate coming
out of this interface being sane or not?

[Chris Rogers, 2013-03-25 21:26:47]

On 2013/03/25 21:23:32, jamesr wrote:
> lgtm for content/renderer/, although Dale (or someone else audio-ish) should
> review for content.
> 
> Is there any other code in the codebase that depends on the sample rate coming
> out of this interface being sane or not?

We already have sanity checks for <audio>, and Flash ignores this value and
always uses 44100

[DaleCurtis, 2013-03-25 21:29:39]

https://codereview.chromium.org/12937017/diff/1/content/renderer/renderer_web...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/12937017/diff/1/content/renderer/renderer_web...
content/renderer/renderer_webkitplatformsupport_impl.cc:642: static const int
kMinSampleRate = 22050;
How about calling GetAudioHardwareConfig()->GetOutputConfig().IsValid() instead?

Otherwise you'll need to duplicate the sample rate check logic using the values
from media/base/limits.h instead of these Min/Max ones you've defined.

Since an invalid hardware sample rate means we're going to fallback to a fake
audio device, it doesn't really matter if you have 44.1kHz or 48kHz here. Just
pick one.

[Chris Rogers, 2013-03-25 22:46:45]

https://codereview.chromium.org/12937017/diff/1/content/renderer/renderer_web...
File content/renderer/renderer_webkitplatformsupport_impl.cc (right):

https://codereview.chromium.org/12937017/diff/1/content/renderer/renderer_web...
content/renderer/renderer_webkitplatformsupport_impl.cc:642: static const int
kMinSampleRate = 22050;
On 2013/03/25 21:29:39, DaleCurtis wrote:
> How about calling GetAudioHardwareConfig()->GetOutputConfig().IsValid()
instead?
> 
> Otherwise you'll need to duplicate the sample rate check logic using the
values
> from media/base/limits.h instead of these Min/Max ones you've defined.

The sample-rate limits of Web Audio aren't necessarily the same as
media/base/limits.h, so since this is glue code into WebKit I'm defining these
limits here.

> 
> Since an invalid hardware sample rate means we're going to fallback to a fake
> audio device, it doesn't really matter if you have 44.1kHz or 48kHz here. Just
> pick one.

I'm seeing the case where the hardware *is* actually good and set to 48KHz, and
Flash and <audio> are playing back fine.  So I wanted to have the highest
probability of guessing the correct sample-rate and have chosen the values
according to the stats we know about these platforms.

[DaleCurtis, 2013-03-25 22:50:25]

Discussed via chat, the sample rates needed here are different than those used
by media/.

For now lgtm since I'm actually surprised this ever worked. WASAPI returns 0 for
systems where no audio device is present, I.e. remote desktop w/o remote audio.

We need to figure out where the 0 sample rate is coming from though. I'm not
sure it's actually coming from WASAPI since the rest of the audio pipeline is
working correctly and there are no logs from
AudioManagerBase::MakeAudiOutputProxy indicating the sample rate is bad.

It'd be interesting to see if the IPC message Send() call where we request the
hardware information from the browser is failing.

[Chris Rogers, 2013-03-25 22:55:44]

Committed patchset #1 manually as r190506 (presubmit successful).