Web-audio-api: Should the WaveShaperNode always output a signal if the curve defines a non-zero value in the middle?

[JohnWeisz]

Say we have a WaveShaperNode with the following curve:

[1, 1, 1]

In this case, whatever "playing" source is connected to the WaveShaperNode, it outputs 1. Right.

However, if nothing is connected, it will output 0 (more precisely, nothing). I can accept and understand this logic to a degree, although I'm not sure if it's right.

However, and more importantly, if there _is_ a playing source connected, but an implementation decides it can "pause" processing that branch (e.g. because of a GainNode with a non-automated 0 gain set), the WaveShaperNode will once again output 0.

As a sidenote, I can "sometimes" reproduce this in Chrome, just drop an AudioBufferSourceNode, hook it up to a GainNode with gain 0, then connect it to a WaveShaperNode with the above curve, and we'll get 0 output (tested this by connecting to an AudioParam, so it might behave differently when testing with an AudioNode destination).

I'm wondering if this was intended, or the behavior I'm observing is merely an oversight, or perhaps a straight implementation error.

[rtoy]

I don't see anything in the spec that says the output should be 0 for this curve when the input is not connected (or zero).

I can, however, reproduce this behavior in Chrome. That's a bug in Chrome, probably due to over-eager optimization of zero inputs in this case.

[padenot]

Please file a ticket at http://new.crbug.com/, where you'll be able to followup with @rtoy.

Closing this as a non-spec issue.

[rtoy]

Note that this does have the curious side-effect of being, essentially, a source node that you can never turn off other than be disconnecting the node from the rest of the graph. It basically lives forever.

Not sure if there's anything we want to say about this in the spec.

[rtoy]

Also, I see in Firefox (nightly) that if the waveshaper is connected to a constant source node outputting 0, the waveshaper produces 1. That looks right.

But if the waveshaper has no inputs, it outputs 0. (Chrome does the same)

Not sure if that's right either....

[padenot]

But if the waveshaper has no inputs, it outputs 0. (Chrome does the same)

Not sure if that's right either....

Probably not indeed, thanks for going the extra mile and checking our implementation as well!

[JohnWeisz]

Note that this does have the curious side-effect of being, essentially, a source node that you can never turn off other than be disconnecting the node from the rest of the graph. It basically lives forever.

Not necessarily. The way I'm fixing this in my app is monitoring changes made to the shaping curve, and plugging in a dummy ABSN only if the _output value to which 0 maps_ (middle value of the shaping curve) is _not_ 0 (or alternatively, _far enough_ from 0, e.g. 0.000001).

If it once again becomes 0 (or alternatively, _close enough_ to 0), the ABSN can be disposed without side-effects.

Not sure if there's anything we want to say about this in the spec.

In my opinion, it is really easy to miss this one, at least it wasn't obvious to me until I was trying to trace down a bug in a custom "line switch" object that I've been working on (it uses wave-shapers to switch between inputs using a source signal and gain nodes, and I was surprised when there was a difference between inputting 0 and having no input whatsoever).

So perhaps it should be added/noted that if the "middle" value of the wave shaping curve is not 0, then the WaveShaper must also act as a playing source in that regard?

[rtoy]

Yeah, it seems natural for it to be a source in this case, but I think that's a bit surprising to users. Chrome is certainly wrong in producing zeroes for silent input.

You have an actual use case where you want no inputs to produce non-zero output. We should support that case.

[rtoy]

Since hoch.github.io/canopy works just great in Firefox, it's super easy to
test both Chrome and Firefox.

If Chrome and Firefox did the same thing, we could just say this is how it
works. :-)

On Fri, Feb 2, 2018 at 4:23 AM, Paul Adenot [e-mail]
wrote:

But if the waveshaper has no inputs, it outputs 0. (Chrome does the same)

Not sure if that's right either....

Probably not indeed, thanks for going the extra mile and checking our
implementation as well!

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/1478#issuecomment-362572505,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAofPNBsO-_hYP4CdPmY7OvOpNoDm75dks5tQv48gaJpZM4RyGsr
.

--
Ray

[rtoy]

I'm opposed to adding more magic attributes. But I'm still not sure what the right thing is; adding the attribute might be the right approach. Dunno.

[joeberkovitz]

I think the node should be outputting 1 when the input is silent, and that this is a bug in implementations. The spec is fine.

As an example of why this makes sense, if silent inputs are disconnected and reconnected from such a node, the output should not suddenly glitch from 1 to 0 and back again.

[karlt]

In line with comment from joeberkovitz, silent output is considered a bug in Gecko:
https://bugzilla.mozilla.org/show_bug.cgi?id=1281001

We have a use case reported here for alwaysOn = true, but i don't think there's a need for alwaysOn = false, and so I also would prefer not to have such an attribute.

[rtoy]

I agree; there's no need for alwaysOn.

In addition, I agree with @joeberkovitz that the spec is fine. We may, perhaps, want to add a note about this, but I don't see that as being necessary.

[rtoy]

Let's say you have a WaveShaperNode with a curve [1,1,1]. It was
connected to some source and now either the source has stopped and is
disconnected. I think we all agree that it should continue to output
1.

Now let's say you drop the reference to the wave shaper node. At some
point, it gets collected. What happens now? Does that constant
output of 1 suddenly disappear? While that might cause a glitch, it
seems ok to me since the developer is in control of whether to drop
the reference or not.

[karlt]

Garbage collection is the removal of resources that are no longer required to
produce the specified behavior. If the behavior of the implementation would
be observably different after removal of a WaveShaperNode, then that node is
not available for GC.

If the developer has connected a WaveShaperNode with non-zero output, and has
not explicitly disconnected the node, then, in the same way as with a
ConstantSourceNode, the WaveShaperNode that the developer added should remain
in the graph.

[rtoy]

On Mon, Feb 12, 2018 at 8:35 PM, Karl Tomlinson [e-mail]
wrote:

Garbage collection is the removal of resources that are no longer required
to
produce the specified behavior. If the behavior of the implementation would
be observably different after removal of a WaveShaperNode, then that node
is
not available for GC.

If the developer has connected a WaveShaperNode with non-zero output, and
has
not explicitly disconnected the node, then, in the same way as with a
ConstantSourceNode, the WaveShaperNode that the developer added should
remain
in the graph.

​Yeah. I don't really like this because, unlike a ConstantSourceNode, a
WaveShaperNode isn't (normally) considered a source. But that's the way it
is.

I think this is certainly unexpected behavior and might be worth a note in
the spec. (Or not).​

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/WebAudio/web-audio-api/issues/1478#issuecomment-365148455,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAofPLp66elAvjokvPEIJIEhFUri8QFBks5tUREogaJpZM4RyGsr
.

--
Ray

[mdjp]

Agreed we will add a note to the v1 spec