Why does the first ~30 seconds of playback from AudioWorklet output toggle Render Capacity from "high" (e.g. 83%) to "low" (e.g. 0%)? about web-audio-api-v2 HOT 5 CLOSED

Found the issue with playback of the file twice.

Still not sure why it takes ~30 seconds for "Render Capacity" to, for lack of an appropriate technical term, "equalize" between the apparent two Worklet instances?

Note the Render Capacity @ ~7 seconds of playback ~83% and at ~19 seconds of playback 0%. Those values toggle between "high" and "low" for the first ~30 seconds of playback. Why? Is that by specification design?

Or, is AudioWorklet being affected by the parallel instance of ReadableStream reading the file being supplied as Float32Array to AudioWorklet (even with Use realtime priority thread for Audio Worklet Run Audio Worklet operation on a realtime priority thread for better audio stream stability. – Mac, Windows, Linux, Chrome OS, Android flag enabled)?

from web-audio-api-v2.

One issue that found is executing ReadableStream in a Worker for preparing input data, and AudioWorklet at the same time - that is, reading the stream and outputting audio at the same time before reading of the entire stream completes, in this case ~35MB completes - the playback will be "choppy".

That "choppy" effect changes to some degree when ReadableStream is piped to a WritableStream and the entire read/write (in this instance the write is posting a transferable Float32Array to AudioWorklet constructor) process is awaited for completion.

It iss not a simple task to determine precisely when the constructor has completed when port is receiving messages during construction and when process() begins in that case?

However, the requirement is to stream a WAV file (for now) and commence playback immediately at the first Uint8Array read at readable/writable, not to await completion of read (parse)/write.

Is executing/running ReadableStream() that supplies AudioWorklet with Float32Arrays in parallel tested by Web Audio API in WPT?

The tests at https://googlechromelabs.github.io/web-audio-samples/audio-worklet/ do not appeaar to be testing points of the design-pattern that are potentially susceptible to breaking, or at least not outputting audio output without undue latency when a parallel processing operation is ongoing.

from web-audio-api-v2.

This is about a Chrome bug, please file it in Chromium's bug tracker (although I'm pretty sure this is known).

from web-audio-api-v2.

@padenot Not necessarily a Chromium bug.

A deficiency in the design of AudioWorklet where the Worklet instances are imbalanced in certain circumstances, for example, where fetch and ReadableStream are being used (high priority) as to resource allocation, one of the Worklet instances appears to not perform its fair share of the work. Looking forward to testing AudioWorklet at Nightly. Until then Chromium is all we have at the front-end.

In any event, was able to resolve the issue late yesterday. The only issue am having now is trying to find a host that will store a 35MB .wav file for other individuals to test the POC version of a WebCodecs connection design-pattern - requesting a WAV file with fetch(), and playing the contents before the entire file is read using ReadableStream and WritableStream without using decodeAudioData(), AudioBuffer or AudioBufferSourceNode. Uploaded the WAV file to *oogle drive and it iss public, though not served with Access-Control-Allow-Origin:* header.

Will post the code anyway at #61 today or tomorrow, with link to the WAV file for testing by individuals other than self at localhost (even though have tested the code hundreds if not thousands of times over the past week). Currently have no way to test at different devices so am relying on only serving the file using php as the evidence for the pattern working. Certainly requires independent verification for a viable design-pattern for a WebCodecs-like connection to Web Audio API.

from web-audio-api-v2.

@padenot https://bugs.chromium.org/p/chromium/issues/detail?id=1055728

from web-audio-api-v2.