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

Ah, I see what you mean now. I'll see what's wrong with single-sample audio
buffers. They should work!

I'll file a bug about this.

On Tue, Oct 7, 2014 at 9:36 AM, Chris Wilson <cwilso@google.com> wrote:

> 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
>>>>
>>>>
>>>>
>>>
>>
>