Looking for possible difficulty of implementing background thread worker in NW.js

Hello,

I’ve recently been investigating whether it’s possible to make the web version of FMOD work in a background thread, once in a while when I have a free moment.

The reason is that when heavy synchronous work is being handled on the main thread, fmod also stops updating its buffer, causing the sound to loop briefly and then release.

Of course, I’ve checked the documentation and don’t expect official support, but I’m wondering if there might be a workaround if NW.js is a standalone program that doesn’t need to support all web browsers and is a fixed version of Node.

The most effective way would be to build a Node native extension, but I don’t have the skills to do that, so I’ve been looking into other ways and found the following issue, which shows that NW.js can use the native API as is in the web worker. (fs)

Other than this, I’d be interested to hear if anyone else has any techniques for preventing web fmods from being interrupted, and the level of difficulty of the problems you have to solve to do so.

Also is there any updates fmod web on Node.js?
Just curious that is there any key performance wise difference of fmod’s behavior between Node.js and web browsers.
Because I remember when I first tried to put it in NW.js a long time ago, there was a feature to detect the Node.js platform and do something different (which of course didn’t work in these days), what about the latest version?

Apologies for the delayed response.

Investigating NW.js compatibility with FMOD unfortunately falls outside of the scope of forum support, but I can try to provide some pointers on considerations to have in mind when trying to get it working. The key points to note with HTML5 FMOD is that there’s inherent reliance on accessing window and DOM, and on delivering audio via the Web Audio API, the latter of which isn’t supported by Node. As a result, if you’re intent on using a background thread worker to run FMOD, you’ll need to ensure that you’re addressing both of these needs.

An alternative, depending on your needs, would be to use a non-HTML5 version of the FMOD Engine separate from your web application, and pipe the output of that non-HTML5 system to your web application. This is something users have done before - a somewhat recent thread related to the topic can be found here: DSP optimization for accessing FMOD PCM data