Specify rules to determine the output channel count for AudioNodes that have a tail time, when the input channel count changes#1787
Conversation
…at have a tail time, when the input channel count changes. This fixes WebAudio#1719.
|
@karlt, can you have a look at this? |
| <h3 id="channels-tail-time"> | ||
| Implication of tail-time on input and output channel count</h3> | ||
|
|
||
| When an {{AudioNode}} has a non-null <a>tail-time</a>, and an output channel |
There was a problem hiding this comment.
Is non-null a common spec language?
There was a problem hiding this comment.
It's regular English I think?
There was a problem hiding this comment.
So it could be zero, but must be defined. Right?
There was a problem hiding this comment.
"null" is an English word, but it is somewhat unusual.
Most uses of "tail-time" in the spec are for the "tail-time reference".
The exception is https://webaudio.github.io/web-audio-api/#AudioWorkletProcessor-methods which uses the expressions "a tail-time after their inputs are disconnected" and "tail-time interval".
I'd be inclined to avoid using "null" because that sounds like a JS value, which this is not.
Perhaps it would be fine to use "a tail-time reference" here, because that corresponds with "has any internal processing state which has not yet been emitted", but I guess it is more natural and consistent with the text below to use "a non-zero tail-time" or "a non-zero tail-time interval".
|
|
||
| Note: Intuitively, this allows not losing stereo information as part of | ||
| processing: when multiple audio blocks of different channel count contribute to | ||
| an output block, then the output block's channel count is a superset of the |
There was a problem hiding this comment.
What's block here? I believe it's a block of frames produced by the renderer, but It might not be clear for readers.
There was a problem hiding this comment.
Sure, I'll make it clearer.
| <h3 id="channels-tail-time"> | ||
| Implication of tail-time on input and output channel count</h3> | ||
|
|
||
| When an {{AudioNode}} has a non-null <a>tail-time</a>, and an output channel |
There was a problem hiding this comment.
"null" is an English word, but it is somewhat unusual.
Most uses of "tail-time" in the spec are for the "tail-time reference".
The exception is https://webaudio.github.io/web-audio-api/#AudioWorkletProcessor-methods which uses the expressions "a tail-time after their inputs are disconnected" and "tail-time interval".
I'd be inclined to avoid using "null" because that sounds like a JS value, which this is not.
Perhaps it would be fine to use "a tail-time reference" here, because that corresponds with "has any internal processing state which has not yet been emitted", but I guess it is more natural and consistent with the text below to use "a non-zero tail-time" or "a non-zero tail-time interval".
|
|
||
| When an {{AudioNode}} has a non-null <a>tail-time</a>, and an output channel | ||
| count that depends on the input channels count, any change in input channel | ||
| MUST take the {{AudioNode}}'s <a>tail-time</a> into account |
There was a problem hiding this comment.
What do you think about "the AudioNode's tail-time must be taken into account when the input channel count changes"?
The thing (subject of verb) that "must take the AudioNode's tail-time into account" is really the implementation, or implementation of the node, or perhaps loosely the node, not the change in input channel count. Using the passive voice avoids having to say.
|
|
||
| - For a {{ConvolverNode}}, since the number of input channel determines the | ||
| <a href="#Convolution-channel-configurations">audio processing algorithm</a> | ||
| to use, it MUST immediately start outputing two channels. |
There was a problem hiding this comment.
An immediate increase in output channel count is the general case on increase in input channel count, and must also happen on BiquadFilterNode, IIRFilterNode, and WaveShaperNode because the input with greater channel count will affect the immediate output buffer.
I don't think it is necessary to special case ConvolverNode in normative text, but a note seems helpful to indicate that this affects ConvolverNode with only mono response.
There was a problem hiding this comment.
I've move or less reversed the prose, only mentioning ConvolverNode in the informative note.
Co-Authored-By: padenot <paul@paul.cx>
Co-Authored-By: padenot <paul@paul.cx>
Co-Authored-By: padenot <paul@paul.cx>
Co-Authored-By: padenot <paul@paul.cx>
|
I'm trying this github suggestions things out, but had to made adjustments locally, so I'll have to push a merge commit, hopefully everything is still readable. |
|
@hoch, do you want to have a final look at this before merging? |
3 participants
This fixes #1719.
Preview | Diff