- From: Raymond Toy <rtoy@google.com>
- Date: Tue, 7 Oct 2014 09:27:13 -0700
- To: Chris Wilson <cwilso@google.com>
- Cc: Soledad Penades <hello@5013.es>, "public-audio-dev@w3.org" <public-audio-dev@w3.org>
- Message-ID: <CAE3TgXE0ZfR0KfxzoibYh2JTv8-xhXJU=y+Sr=zqOpkxsLw7xQ@mail.gmail.com>
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 >> >> >> >
Received on Tuesday, 7 October 2014 16:27:41 UTC