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

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

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.

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?

Andreas, can you take a look please ?

Deferring to Karl.

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.

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!

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

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