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

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