Remove muting for extreme playbackRates.

Remove muting for extreme playbackRates.

Audio was muted below 0.5x and above 4x as the quality degraded
significantly under the crossfade algorithm. The quality is now much
better under the WSLOA algorithm (r220343).

BUG=289354
R=scherkus@chromium.org
R=dalecurtis@chromium.org

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

[scherkus (not reviewing), 2014-03-19 19:44:27]

https://codereview.chromium.org/205093002/diff/1/media/filters/audio_renderer...
File media/filters/audio_renderer_algorithm.cc (left):

https://codereview.chromium.org/205093002/diff/1/media/filters/audio_renderer...
media/filters/audio_renderer_algorithm.cc:51: // Audio at these speeds would
sound better under a frequency domain algorithm.
FYI I don't believe this comment is necessarily true anymore since turajs@
landed the new algorithm as this was added way, waaaay back in
http://src.chromium.org/viewvc/chrome?revision=22974&view=revision

(hence landing this CL)

https://codereview.chromium.org/205093002/diff/1/media/filters/audio_renderer...
File media/filters/audio_renderer_algorithm.cc (right):

https://codereview.chromium.org/205093002/diff/1/media/filters/audio_renderer...
media/filters/audio_renderer_algorithm.cc:197: muted_ = new_rate == 0.0f;
dalecurtis: can we rip out all the |muted_| related code if we always intend to
run the WSOLA algorithm?

AFAIK if the rate == 0 we shouldn't be calling FillBuffer()

sandersd: can you see if that's true?

[sandersd (OOO until July 31), 2014-03-19 20:03:47]

> dalecurtis: can we rip out all the |muted_| related code if we always intend
to
> run the WSOLA algorithm?
> 
> AFAIK if the rate == 0 we shouldn't be calling FillBuffer()
> 
> sandersd: can you see if that's true?

That is correct, and also FillBuffer() would return immediately in that case
anyway.

[DaleCurtis, 2014-03-19 20:25:58]

You should manually evaluate new max and mins for speech, music content to see
how it sounds. I'm not convinced we want to completely remove the limits.

Most people are used to their TiVo/VCR/etc muting at a certain FF level.

[scherkus (not reviewing), 2014-03-19 20:38:29]

On 2014/03/19 20:25:58, DaleCurtis wrote:
> You should manually evaluate new max and mins for speech, music content to see
> how it sounds. I'm not convinced we want to completely remove the limits.

How about we leverage everyone being in KIR today to do a listening test?

> Most people are used to their TiVo/VCR/etc muting at a certain FF level.

Couldn't that be handled by applications? I'm not sure we should bake such a
policy into the platform itself.

[DaleCurtis, 2014-03-19 21:14:33]

On 2014/03/19 20:38:29, scherkus wrote:
> On 2014/03/19 20:25:58, DaleCurtis wrote:
> > You should manually evaluate new max and mins for speech, music content to
see
> > how it sounds. I'm not convinced we want to completely remove the limits.
> 
> How about we leverage everyone being in KIR today to do a listening test?

Sounds good to me :)

> 
> > Most people are used to their TiVo/VCR/etc muting at a certain FF level.
> 
> Couldn't that be handled by applications? I'm not sure we should bake such a
> policy into the platform itself.

Fair enough, but moot if tests show bad audio:
1. What do other browsers do for these playback rates?
2. I imagine YT would like to know if their 0.25x option is suddenly going to
include sound.

[sandersd (OOO until July 31), 2014-03-19 21:41:24]

> You should manually evaluate new max and mins for speech, music content to see
> how it sounds. I'm not convinced we want to completely remove the limits.

Below 0.5x the artifacts do become significant, but they don't prevent me from
following the melody of a song.

Speeds above 4x are not intelligible, but the distortions are not bad.

> Fair enough, but moot if tests show bad audio:
> 1. What do other browsers do for these playback rates?

I tested Firefox, it applies the same limits as Chrome does currently (mute
below 0.5x, above 4x).

[scherkus (not reviewing), 2014-03-19 21:48:45]

On 2014/03/19 21:41:24, Dan Sanders wrote:
> > You should manually evaluate new max and mins for speech, music content to
see
> > how it sounds. I'm not convinced we want to completely remove the limits.
> 
> Below 0.5x the artifacts do become significant, but they don't prevent me from
> following the melody of a song.
> 
> Speeds above 4x are not intelligible, but the distortions are not bad.
> 
> > Fair enough, but moot if tests show bad audio:
> > 1. What do other browsers do for these playback rates?
> 
> I tested Firefox, it applies the same limits as Chrome does currently (mute
> below 0.5x, above 4x).

AFAICT it was mostly arbitrary and I wonder whether they settled on the same
constants as Chromium or if it's pure coincidence.
https://hg.mozilla.org/integration/mozilla-inbound/rev/265233a61624#l2.12

The spec only gives the following guidance:
"When the effective playback rate is so low or so high that the user agent
cannot play audio usefully, the corresponding audio must also be muted."

Of course it's up for debate what useful is :)

[scherkus (not reviewing), 2014-03-19 21:52:17]

On 2014/03/19 21:48:45, scherkus wrote:
> On 2014/03/19 21:41:24, Dan Sanders wrote:
> > > You should manually evaluate new max and mins for speech, music content to
> see
> > > how it sounds. I'm not convinced we want to completely remove the limits.
> > 
> > Below 0.5x the artifacts do become significant, but they don't prevent me
from
> > following the melody of a song.
> > 
> > Speeds above 4x are not intelligible, but the distortions are not bad.
> > 
> > > Fair enough, but moot if tests show bad audio:
> > > 1. What do other browsers do for these playback rates?
> > 
> > I tested Firefox, it applies the same limits as Chrome does currently (mute
> > below 0.5x, above 4x).
> 
> AFAICT it was mostly arbitrary and I wonder whether they settled on the same
> constants as Chromium or if it's pure coincidence.
> https://hg.mozilla.org/integration/mozilla-inbound/rev/265233a61624#l2.12
> 
> The spec only gives the following guidance:
> "When the effective playback rate is so low or so high that the user agent
> cannot play audio usefully, the corresponding audio must also be muted."
> 
> Of course it's up for debate what useful is :)

FWIW I tested on Safari Version 7.0.2 (9537.74.9) and it doesn't impose limits.

[DaleCurtis, 2014-03-19 22:25:49]

lgtm

Sounds fine to me, lets just remove!

[sandersd (OOO until July 31), 2014-03-19 22:27:34]

The CQ bit was checked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:27:35]

The CQ bit was unchecked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:28:33]

The CQ bit was checked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:28:33]

The CQ bit was unchecked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:28:38]

The CQ bit was checked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:28:38]

The CQ bit was unchecked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:28:39]

The CQ bit was checked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:29:02]

The CQ bit was unchecked by sandersd@chromium.org

[sandersd (OOO until July 31), 2014-03-19 22:29:45]

The CQ bit was checked by sandersd@chromium.org

[commit-bot: I haz the power, 2014-03-19 22:31:41]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sandersd@chromium.org/205093002/20001

[commit-bot: I haz the power, 2014-03-19 22:35:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-03-19 22:35:39]

Try jobs failed on following builders:
  tryserver.chromium on linux_chromium_clang_dbg

[scherkus (not reviewing), 2014-03-19 23:54:30]

The CQ bit was checked by scherkus@chromium.org

[commit-bot: I haz the power, 2014-03-19 23:54:43]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/sandersd@chromium.org/205093002/20001

[commit-bot: I haz the power, 2014-03-20 06:08:06]

Change committed as 258215