Re: Clipping behaviour of GainNodes (or any other AudioDestinationNode)

The samples *will* get clipped to -1,1 at the output in normal use, at the
output (when you change the bias - the default DC bias of 0 obviously won't
clip).

The problem, though, is that the DC bias isn't working in Chrome at all.
It's not working because Sole creates a buffer of length=1 sample, sets
that sample to 1 and loops it.  This should work, but for some reason
Chrome doesn't like a buffer of length 1; if you even change the code to
have a buffer of length=2 samples, and set them both to 1, it will work.

This version has that change
<https://github.com/cwilso/test_cases/commit/00e6e1ce91c9abb823d96e7599b7e39de95ae032>,
and will work in Chrome too:
http://cwilso.github.io/test_cases/web_audio/bias/.  Change the bias
slider, you'll see what happens.  Note that the SIGNAL is not getting
clipped (if you scaled down the waveform display, you wouldn't see it clip)
but you do HEAR it clip, because it's clipping in the output stage.



On Tue, Oct 7, 2014 at 9:27 AM, Raymond Toy <rtoy@google.com> wrote:

>
>
> On Tue, Oct 7, 2014 at 8:41 AM, Chris Wilson <cwilso@google.com> wrote:
>
>> Moving to public-audio-dev, bccing public-audio.
>>
>> The audio pipeline is all in floating point, and specifically will NOT
>> clip to -1,+1, by design - if we did, that would break a lot of scenarios
>> (e.g. driving frequency from an audio routing source).  Of course, when the
>> output gets to the destination, it is likely clipped - [-1,1] is the
>> nominal range - but even there, it's possible that volume controls would
>> mean clipping doesn't happen.
>>
>> If you WANT clipping, of course, you can use a WaveShaperNode.
>>
>> The problem in Chrome appears to be that we have issues looping a
>> single-sample buffer.  If you even make the buffer 2 samples long, it will
>> work properly.  Not sure why this is, so I'll punt to Raymond. :)
>>
>
> I don't find anything wrong with demo. I hear a nice simple tone. (Chrome
> 38, Linux)
>
> I don't recall what happens to the samples at the destination node when
> they exceed 1.   They are probably clipped to 1.
>
>
>> On Tue, Oct 7, 2014 at 4:58 AM, Soledad Penades <hello@5013.es> wrote:
>>
>>> Sorry, the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1078014
>>>
>>> On Tue, Oct 7, 2014 at 12:57 PM, Soledad Penades <hello@5013.es> wrote:
>>> > Hello!
>>> >
>>> > 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.
>>> >
>>> > Check demo here http://sole.github.io/test_cases/web_audio/bias/ -
>>> > you'll need web components enabled.
>>> >
>>> > In Firefox, although the analyser reports the signal being shifted
>>> > around when the range is changed, there is no audible difference.
>>> >
>>> > In Chrome, the behaviour is weirder--the analyser goes bananas and the
>>> > sound doesn't seem to change substantially either.
>>> >
>>> > I can definitely listen to the difference by generating a signal in
>>> > Audacity and shifting it manually (you can listen to the attachments
>>> > in the bug I opened in Mozilla's Bugzilla)
>>> >
>>> > I wonder if the audio engine is allowing values to go out of range
>>> > temporarily and finally clipping by the time sounds reaches
>>> > audioContext.destination, but I also wonder if this is a behaviour
>>> > that is not explicit in the API (or maybe I oversaw it
>>> > accidentally--would anyone be as nice as to point me to where is this
>>> > behaviour described in the specification?). In other words: I would
>>> > expect the output of each node to be clipped to -1, 1
>>> >
>>> > Thanks!
>>> >
>>> >
>>> >
>>> > --
>>> > http://5013.es
>>>
>>>
>>>
>>> --
>>> http://5013.es
>>>
>>>
>>>
>>
>