Remove emphasis/de-emphasis filters from DynamicsCompressor.

Remove emphasis/de-emphasis filters from DynamicsCompressor.

The pre-emphasis and de-emphasis filters are specified in the WebAudio spec, and this causes problems for Chrome OS which is using WebAudio to test speakers.

A discussion on the W3C audio list indicates a consensus to remove the pre-emphasis and de-emphasis filters since they were never specified anyway:

http://lists.w3.org/Archives/Public/public-audio/2014JanMar/0010.html

A simple layout test is added.  Before this CL, the output is compressed; with this CL, the output is no longer compressed.

See also http://webaudiodemos.appspot.com/compressorfreq/ which demonstrates the compression that is happening.  With this CL, the sine wave remains at a constant amplitude.  Previously, the sine wave amplitude decreases as the frequency increases.

BUG=340870
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=166956

[Raymond Toy (Google), 2014-02-04 23:04:23]

PTAL

[Ken Russell (switch to Gerrit), 2014-02-04 23:24:13]

The code changes LGTM, but I think this CL should have an associated bug ID, and
further, that layout tests should be written for the dynamics compressor.

On the whole, I don't think that a potentially useful feature or processing step
should be removed just because of one particular use of the API. A better
approach would be to specify the emphasis and de-emphasis filters in the spec,
and then allow them to be disabled, for this particular use case.

[Raymond Toy (Google), 2014-02-04 23:46:08]

On 2014/02/04 23:24:13, Ken Russell wrote:
> The code changes LGTM, but I think this CL should have an associated bug ID,
and
> further, that layout tests should be written for the dynamics compressor.

I'll file a bug.  Most of the discussion was done over email.  I'll try to write
a simple test
for the dynamics compressor.  It will have to be a basic audio test. The
compressor itself is
underspecified.
> 
> On the whole, I don't think that a potentially useful feature or processing
step
> should be removed just because of one particular use of the API. A better
> approach would be to specify the emphasis and de-emphasis filters in the spec,
> and then allow them to be disabled, for this particular use case.

The pre and post emphasis can be done outside of the compressor, allowing users
to
choose the appropriate scheme. The consensus from the W3C audio group is to
remove
this from the spec, since it was never specified anyway, and because you can do
it separately
from the compressor itself.  (The compressor is the least spec'ed
node in the entire spec. A better specification is being worked on.)

[Raymond Toy (Google), 2014-02-05 20:21:12]

On 2014/02/04 23:24:13, Ken Russell wrote:
> The code changes LGTM, but I think this CL should have an associated bug ID,
and
> further, that layout tests should be written for the dynamics compressor.

Bug filed and linked, and a simple layout test added that demonstrates the
compression
that is no longer happening.  Before this CL, the output from the test would be
compressed.

> 
> On the whole, I don't think that a potentially useful feature or processing
step
> should be removed just because of one particular use of the API. A better
> approach would be to specify the emphasis and de-emphasis filters in the spec,
> and then allow them to be disabled, for this particular use case.

[Ken Russell (switch to Gerrit), 2014-02-05 20:36:05]

On 2014/02/05 20:21:12, rtoy wrote:
> Bug filed and linked, and a simple layout test added that demonstrates the
> compression
> that is no longer happening.  Before this CL, the output from the test would
be
> compressed.

Very nice. Thanks. LGTM again.

[Raymond Toy (Google), 2014-02-11 21:27:37]

On 2014/02/05 20:36:05, Ken Russell wrote:
> On 2014/02/05 20:21:12, rtoy wrote:
> > Bug filed and linked, and a simple layout test added that demonstrates the
> > compression
> > that is no longer happening.  Before this CL, the output from the test would
> be
> > compressed.
> 
> Very nice. Thanks. LGTM again.

PTAL again. I changed the test not to use an audio result. They're hard to
maintain. Instead, I just check that the peak of the output signal is greater
than some threshold. I ran this test with and without this CL applied to
determine the threshold and that without this CL, the output is drastically
reduced to 0.2 instead of 0.8 with this CL is applied.

[Ken Russell (switch to Gerrit), 2014-02-11 21:36:09]

Still LGTM.

[Raymond Toy (Google), 2014-02-11 21:39:14]

On 2014/02/11 21:36:09, Ken Russell wrote:
> Still LGTM.

Thanks!

[Raymond Toy (Google), 2014-02-11 21:39:30]

The CQ bit was checked by rtoy@google.com

[commit-bot: I haz the power, 2014-02-11 21:39:54]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rtoy@google.com/152333003/180001

[commit-bot: I haz the power, 2014-02-12 01:57:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rtoy@google.com/152333003/180001

[commit-bot: I haz the power, 2014-02-12 02:10:26]

Change committed as 166956