- From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Date: Tue, 11 Jun 2013 19:44:56 -0400
- To: Chris Wilson <cwilso@google.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CANTur_7z-tRZhybO_hXPWoH=GVWZnHv-o=x81z4UxT1Ks3y-4g@mail.gmail.com>
On Tue, Jun 11, 2013 at 7:30 PM, Chris Wilson <cwilso@google.com> wrote: > Why would passing through the input make more sense to you? > Because that's what many of the other processing nodes (such as GainNode, DelayNode, etc) do by default, so it seems more consistent. > That would mean there's a significant difference between having a null > buffer and having a buffer that contains a single sample of zero, or even a > buffer with zero length (hmm, if I could even create that). > Yes, that is correct. But I don't think that's a problem. If you explicitly set a buffer with a single sample of 0, then presumably you want silence as the output. Note that this is arguably a terrible API. Ideally we would have something like: [Constructor(AudioBuffer buffer)] interface ConvolverNode : AudioNode { boolean normalize; }; And that would eliminate the question of what to do with a null AudioBuffer altogether. > If I was using the convolver as an effects node in a mixer, passing > through the input until I set the buffer would "double up" the original > signal if the effects mix were set to 50%. That seems like odd behavior. > I'm not quite sure what that means... Can you please clarify? Also, does this behavior for other node types surprise you in the same way? Really what's more interesting to me is consitency, one way or another. -- Ehsan <http://ehsanakhgari.org/> > > On Tue, Jun 11, 2013 at 4:01 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: > >> It's not clear what the output of ConvolverNode must be if the buffer >> attribute is null, which is the initial state. In Gecko we just pass >> through the input. WebKit/Blink seem to produce silence. I think the >> Gecko behavior makes more sense, and I believe that's what we should spec. >> >> What do you think? >> >> -- >> Ehsan >> <http://ehsanakhgari.org/> >> > >
Received on Tuesday, 11 June 2013 23:46:03 UTC