ScriptProcessor vs. AudioWorklet vs. AnalyserNode

[danigb]

Very nice library, thanks!

I have a question: is there a reason not to use an AnalyserNode? From an audio performance point of view, it would be the best option.

If there are any impediments, I guess the next best option is to use AudioWorklet, because ScriptProcessorNode is deprecated. Any plans on this?

[esonderegger]

Thanks! And that's a great question!

To support features like peak holding, or calculations like true-peak metering, this library needs to read sample values. To the best of my knowledge, that means AnalyzerNode is out.

As for ScriptProcessorNode vs AudioWorklet, until relatively recently (Safari 14.1 - a little over a year ago), AudioWorklet hasn't been supported across all major browsers. I wrote most of this code for a hackathon in 2014 and don't use it for any work projects, so I hadn't been following these advancements closely.

I've recently started trying to do a rewrite of this library using AudioWorklet and Typescript. I figured that, since AudioWorklet requires a secure context, it would be a breaking change no matter what. So it would be a good time to rework other parts of the public API too (like initialization being cut from a two-step process to a single one, and making vertical vs horizontal explicit).

It's been a slow process, though (I only have about 30 minutes a day to work on it) so no promises on when this will be ready to be released. I'm hoping some time in February or March.

[suterma]

I was wondering about this too. AnalyzerNode can get the raw samples though, using https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode/getFloatTimeDomainData.

In my use case I also want to support Apple iOS from version 12, so reading @esonderegger 's answer, this would actually be a dealbreaker for me.