1078014 - No audible clipping despite analyser showing there *should* be clipping

Status: RESOLVED INVALID

(Core :: Web Audio, defect, P3)

Description

[Soledad Penades [:sole] [:spenades]]

Attachment: 2 seconds 440Hz sine tone

I'm trying to simulate applying a DC signal to an existing signal. Since the signal is already in [-1, 1] and I'm applying a variable [-2, 2] value, the output should be quite clipped.

But although the analyser reports the signal being shifted around when the range is changed, there is no audible difference.

I can definitely listen to the difference by generating a signal in Audacity and shifting it manually (listen to the attachments to experience the difference)

Did I understand the API wrong, or is Firefox trying to prevent me from clipping on purpose?

For the record, Chrome's behaviour is weirder--the analyser goes bananas and the sound doesn't seem to change substantially.

Check demo here http://sole.github.io/test_cases/web_audio/bias/

Comment 1

[Soledad Penades [:sole] [:spenades]]

Attachment: 2 seconds 440Hz sine tone with +1 DC signal (effectively clipped, shifted upwards)

Comment 2

[Karl Tomlinson (:karlt)]

I'm getting JS errors on the demo, but if you see the shift in the analyser, then I think you have the API use correct.

JavaScript error: http://sole.github.io/test_cases/web_audio/bias/Oscilloscope.js, line 80: TypeError: document.registerElement is not a function
JavaScript error: http://sole.github.io/test_cases/web_audio/bias/demo.js, line 21: TypeError: oscilloscope.attachTo is not a function

I don't know of any clip protection in Firefox, but end-stage native platform APIs might provide this, even if just through applying volume to the signal.

Comment 3

[Karl Tomlinson (:karlt)]

WaveShaperNode could be used if you'd like to force the clipping.

Otherwise, I'm not finding anything in the API draft to specify how AudioDestinationNode should interpret values.

Comment 4

[Soledad Penades [:sole] [:spenades]]

Karl, thanks for looking into this. The demo uses web components so you should have dom.webcomponents.enabled = true in about:config (doesn't need reloading/restarting the browser). Sorry about that, should have made it explicit.

This seems like maybe the API is trying to avoid clipping early in the graph by allowing the values to go out of the [-1, 1] range, and clipping only in the last stage, but Chrome's behaviour is different (the oscilloscope doesn't display the shift).

I think I'll ask in the web audio list about this. Thanks!

Comment 5

[Chris Wilson]

The API *should* allow values to be outside [-1,+1] range.  The output will likely clip if you let the audio connection to the destination go outside that range, but a connection inside the graph certainly can without clipping.  That's one of the major benefits of using floating point representation.

Chrome's behavior issue here is a totally separate issue - we aren't currently working with single-sample buffers.  https://code.google.com/p/chromium/issues/detail?id=421121.  The analyser isn't going bananas (unless you mean that we aren't sync'ed to the waveform quite the same) - we just aren't applying a DC bias.

I DO hear the clipping and DC bias effect - because it's clipping in the output stage - but not in Chrome, unless you change the code to do a two-sample or more buffer.

This should get closed by design.

Comment 6

[Soledad Penades [:sole] [:spenades]]

Discussion in the w3 list here:
http://lists.w3.org/Archives/Public/public-audio-dev/2014Oct/0003.html

Thanks for answering/clarifying, Chris. I wonder if we could have a note about the not clipping unless in the destination, somewhere, in the spec. Will file a bug there.

Closing as non-issue then =)