Replace the deprecated ScriptProcessorNode with AudioWorkletNode

[thijstriemstra]

ScriptProcessorNode is deprecated from the specification and replaced with AudioWorklet in Chrome 64. AudioWorklet is enabled by default for Chrome 66 or later. In Chrome 64 and 65, the feature is behind the experimental flag.

See https://developers.google.com/web/updates/2017/12/audio-worklet and even better: https://developers.google.com/web/updates/2018/06/audio-worklet-design-pattern

[thijstriemstra]

There's now also a polyfill available: https://github.com/GoogleChromeLabs/audioworklet-polyfill

[thijstriemstra]

This looks promising as well: https://github.com/chrisguttandin/standardized-audio-context

[sundayz]

I came across AudioWorklets earlier today. From what I understand they could be used to play audio in a separate thread, so audio processing will never cause the UI to lag? I’m definitely going to look into this but I may need some help from people who know the web audio api better than me :)

[thijstriemstra]

From what I understand they could be used to play audio in a separate thread, so audio processing will never cause the UI to lag?

That's also my understanding yea.

[entonbiba]

ScriptProcessorNode
https://developer.mozilla.org/en-US/docs/Web/API/ScriptProcessorNode

AudioWorkletNode
https://developer.mozilla.org/en-US/docs/Web/API/AudioWorkletNode

#2244 #2100 #1689 #2210 #1281

[sundayz]

Hi! iOS 14.5 is now released, which brings unprefixed WebAudio AND AudioWorklet support to Safari. Make sure to check that out. I guess in the future we will focus on AudioWorkletNode and provide ScriptProcessorNode as a fallback for iOS 14.4 and below (detected by webkit perfix WebAudio)

[cameronSlupeiks]

Has any progress been made in regards to adding support for AudioWorkletNode?

[dvantage]

I'm waiting for an update, for music services very important support for AudioWorkletNode

[thijstriemstra]

Please consider sponsoring one of the developers to implement this feature.

[entonbiba]

@dvantage @cameronSlupeiks this will take a bit of time to implement properly.

@sundayz if we do update to audioworkletnode we have to keep in mind using it will require a secure context making wavesurfer only work properly if its from a https resource when using webaudio.

window.isSecureContext is currently being reviewed as a feature candidate to provide a true or false if a page is in a secure context so this would likely have to be implemented when it's available as a way to detect and display a message. For now checking the host url being https would be sufficient.

[TheBoringBOT]

@entonbiba any update on this?

[Yan-vibeit]

Any update on this. This issue has existed for well over a year with seemingly no progress or evidence that Wavesurfer intends to adopt this.

[thijstriemstra]

Please consider sponsoring one of the developers to implement this feature.

I think this would be an excellent opensource or sponsors contribution.

[entonbiba]

@Yan-vibeit I'll have a look at this again in the upcoming weeks see what's possible to implement it.

[Yan-vibeit]

On Sat, 25 Feb 2023 at 19:47, Enton Biba ***@***.***> wrote: @Yan-vibeit <https://github.com/Yan-vibeit> I'll have a look at this again in the upcoming weeks see what's possible to implement it. — Reply to this email directly, view it on GitHub <#1281 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZGDEAREADLFRSF4L3D4HELWZJOVDANCNFSM4EJNOMMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

Thanks, it is much needed as the audio csn then run using a seperate thread increasing performance. I appreciate you! Yan.

[jgentes]

I think this issue was closed accidentally - it should remain open unless tracked elsewhere, no?

[katspaugh]

Feel free to reopen it, but the issue has been there for 5 years w/o any progress made, so I don't see the point of tracking it.
If someone wants to add support for AudioWorklet, they can just open a PR.
Issues are for actionable items that will be definitely worked on, and for bug reports.

Edit: reopened and clarified the title.

[katspaugh]

@jgentes thanks for sponsoring btw! ❤️
I guess you're interested in this particular issue to be worked on?

[jgentes]

You're welcome @katspaugh - this is certainly the one I am most interested in, but no, I just thought it was reasonable to send $1/mo your way for making such a great library. I'm using it for a personal project: https://github.com/jgentes/mixpoint

[katspaugh]

Awesome!

[sandokan815]

So, what is final the solution to remove this warning in wavesurfer.js?

[katspaugh]

@sandokan815 the easiest is to just use backend: “MediaElement” if you don’t need any webaudio features.

Btw, ScriptProcessorNode seems to be used only for tracking the playback position when using the WebAudio backend. Should be fairly straightforward to replace.

[robots4life]

So get rid of the warning it is best to just use backend: “MediaElement” all the time, correct ?

[katspaugh]

This warning will be gone completely in the next release. Edit: it's now live in 6.6.3.

But yeah, backend: “MediaElement” will also get rid of it.

[robots4life]

I can confirm the warning is gone with setting backend: "MediaElement".

webaudio.js:238 [Deprecation] The ScriptProcessorNode is deprecated. Use AudioWorkletNode instead. (https://bit.ly/audio-worklet)