1587872 - call AudioWorkletProcessor.process() even for AudioWorkletNodes without active inputs

Status: RESOLVED FIXED

(Core :: Web Audio, enhancement, P2)

Description

[msabwat]

Attachment: bug.zip

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

=> Click on Start (which is supposed to start an oscillator in the Worklet)

Actual results:

=> context.state evaluates to "running" but without any sound. I could inspect it with the Devtools console.
I could not install audion to get more information, but I can dig more if needed.

Expected results:

=> Hear a 440Hz oscillator

I read here that it is not recommended to use the Audio Worklet this way, but since the sample works in Google Chrome (79), I thought it would be useful

Comment 1

[msabwat]

Tested on Nightly 71.0a1 (2019-10-10) (64-bit)

Comment 2

[Adrian Florinescu [:aflorinescu]]

I cannot reproduce this issue on Ubuntu 16.04 or Ubuntu 18.04. Firefox Nightly 71.0a1 2019-10-10 && Chrome 76.0.3809.100 I'm wondering if I'm not missing some pre-requisites?
The context state is indeed evaluated to running, but no clue atm how to further advance this issue.

Comment 3

[msabwat]

I can provide more information, but I am not sure what for now. Maybe the problem is that the oscillator is not supposed to play and the bug is in Chrome.

I am trying to play the oscillator in the worklet

 document.getElementById('btn_ctx').addEventListener('click', () => {
        context = new AudioContext();
        context.audioWorklet.addModule('worklet-processor.js').then( () => {
            //const osc = new OscillatorNode(context);
            const wp = new AudioWorkletNode(context, 'worklet-processor');
            wp.connect(context.destination);
            //osc.connect(wp).connect(context.destination);
            //osc.start();
        })
    })

the fact that I have sound without having to .start() seems odd no?

Comment 4

[Adrian Florinescu [:aflorinescu]]

Andreas, can you take a look please ?

Comment 5

[Andreas Pehrson [:pehrsons]]

Deferring to Karl.

Comment 6

[Karl Tomlinson (:karlt)]

With prefs at default values, the following is shown in the console:

TypeError: context.audioWorklet is undefined

With prefs set to enable the WIP AudioWorklet, the behavior reported is expected for the current state of Firefox code, but not expected based on the specification.

We can use this bug to track adding support for AudioWorkletNodes without active inputs.

(In reply to msabwat from comment #3)

the fact that I have sound without having to .start() seems odd no?

I'm not sure I follow this comment. In Firefox Nightly, I only observe sound when uncommenting the OscillatorNode JS, including osc.start().
However, sound without the OscillatorNode JS is expected with a spec-compliant AudioWorklet.

Comment 7

[msabwat]

Hello,

Thank you for your reply, and changing the issue title it seems clearer.

(In reply to Karl Tomlinson (back Oct 14 :karlt) from comment #6)

With prefs at default values, the following is shown in the console:

TypeError: context.audioWorklet is undefined

Isn't this because the Worklet API only works in a secure context? I don't have this error in a secure context.

(In reply to msabwat from comment #3)

the fact that I have sound without having to .start() seems odd no?

I'm not sure I follow this comment. In Firefox Nightly, I only observe sound when uncommenting the OscillatorNode JS, including osc.start().
However, sound without the OscillatorNode JS is expected with a spec-compliant AudioWorklet.
You answered by changing the title thanks!

Comment 8

[Karl Tomlinson (:karlt)]

Attachment: Bug 1587872 call process() on active AudioWorkletProcessor even with no active inputs r?padenot

Comment 9

[Karl Tomlinson (:karlt)]

Attachment: Bug 1587872 don't call process() on inactive AudioWorkletProcessor when inputs are null r?padenot

AudioNodeTrack::mIsActive, which determines when ProcessBlocksOnPorts() is
called, differs slightly from "actively processing" in the spec.
"An AudioScheduledSourceNode is actively processing if and only if it is
playing for at least part of the current rendering quantum" but
AudioNodeTrack::mIsActive is set even before the source node has started
playing.
Null input blocks provide a better indication of inputs that are not actively
processing.

Depends on D54663

Comment 10

[Karl Tomlinson (:karlt)]

Attachment: Bug 1587872 ensure one output channel when input is null r?padenot

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4f54a53cd1da
call process() on active AudioWorkletProcessor even with no active inputs r=padenot

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7cfe8f83fb9f
ensure one output channel when input is null r=padenot

Comment 13

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/4f54a53cd1da
https://hg.mozilla.org/mozilla-central/rev/7cfe8f83fb9f