[BillyWM]

>There is ScriptProcessorNode but it’s deprecated and performance is not up to audio rendering standards.

On the web, "deprecated" doesn't mean you can't use it. It can take a long time for "officially deprecated by the standards" to become "I can't use it anymore" (obsoleted).

The replacement is the "AudioWorklet" interface and the purpose is to fix those exact synchronization issues. I wouldn't expect ScriptProcessorNode to disappear from the browser until the replacement is actually rolled out.

The Web Audio API started as the Audio Data API in Firefox, which was nothing but a buffer to blast samples into, then the Web Audio API was a refinement/competing standard above that extremely simplistic API (I adapted a Javascript-based .mod player to use AudioData instead of sticking an <audio> tag in the page circa 2011).

You've been able to generate and play back samples in browser (without Flash) for ~6-7 years now, they're simply making official changes to the underlying API in the hopes of improving it. "Deprecated" is just bureaucracy.

[kevingadd]

It's not reasonable to call it a refinement when it removed the central feature of the Audio Data API (feeding samples). Web Audio was a competing API, designed by a former developer of Core Audio (at Apple) once he moved to Google. They shipped it without a standardization process, at which point it became the de-facto audio API for the web.

[BillyWM]

> it removed the central feature of the Audio Data API (feeding samples)

Again, I've written actual code with both. With all due respect, I'm not sure what parallel universe you're from. (Do they spell it Berenstein on your side?)

I can pull up my Github commit from 2014 and look at where I changed my moz-compatible > dynamicAudio.write(modPlayer.getSamples(bufferLength));

to

>var processor = audioContext.createScriptProcessor(bufferSize, 0, 2); > [......] >processor.connect(audioContext.destination);

etc, and it still played sound.

If you're unaware how Amiga .mod/.xm works, it is a REQUIREMENT that you can provide raw samples to the output source, because the samples are embedded into the file.

You can feed samples to the browser and have it play them, right here, right now, just like you've been able to for years. If you don't like the status of ScriptProcessor as deprecated and think AudioWorklet sucks, that's a whole separate issue, but you can feed samples now and you'll STILL be able to feed samples when AudioWorklet obsoletes ScriptProcessor.

>Web Audio was a competing API

I already mentioned it was a competing standard in my comment.

>They shipped it without a standardization process

The Audio Data API was one dude hacking on Firefox (David Humphreys) and then other people got interested. One of the requirements of the standards process is that there are multiple implementations in the wild. You need to throw it in your browser if you want it to ever be standardized.

And they DID standardize it early on. You can go read old copies of the W3C standard submitted by Google.

I was sad to see Mozilla's version go away but browser vendors eventually decided it was the losing implementation - including Mozilla.

Mozilla didn't HAVE to submit to the whims of others, they could have dug in their heels if they thought their version was better (see: The Video tag, and everyone who just so happens to be part of the MPEG-LA patent pool saying no to a patent-unencumbered, open video standard baked in to the browser)