Godot: Delayed Audio in WASM/HTML export

[Nolkaloid]

Godot version:
3.0 Stable

OS/device including version:
Ubuntu 16.04/Linux
Firefox 57

Issue description:
Projects exported to html have delayed sounds.

Steps to reproduce:
Load up a project that has some sound playing in it (the plat-former demo for example) and export it to HTML. Notice that the sounds are delayed.

[reduz]

Unfortunately nothing much can be done about this due to the problem of
WebAssembly not supporting threads.
This forces audio to be used on the main thread, and it needs to be mixed
with some delay to avoid stuttering. Maybe we could decrease delay a bit
and see how well it works.
This will be solved very soon, as next WebAssembly version will support
threads.

On Wed, Jan 31, 2018 at 6:03 PM, Nobelix [e-mail] wrote:

Godot version:
3.0 Stable

OS/device including version:
Ubuntu 16.04/Linux
Firefox 57

Issue description:
Projects exported to html have delayed sounds.

Steps to reproduce:
Load up a project that has some sound playing in it (the plat-former demo
for example) and export it to HTML. Notice that the sounds are delayed.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/16259, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z243fLl3lJGmvUPaNfHJeu0LbB_8dks5tQNUHgaJpZM4R0pHJ
.

[Nolkaloid]

Yaaaay, but anyways I don't know if it's just my project/ really bad code but in general WASM is pretty much broken for me. :pensive:

[justinluk]

I'm also experiencing this same problem. Audio is very delayed.

[BenjaminNavarro]

I just noticed it also with Firefox but it works just fine with Chromium (Linux). So in the meantime, you can instruct your players to switch browser

[belen-albeza]

This will be solved very soon, as next WebAssembly version will support
threads.

Hi @reduz are there any updates about this? Thanks!

[Silvea12]

Any updates on this?

[Calinou]

WebAssembly threads are supported since Chrome 74 and recent Firefox versions. What about Safari and Edge though? (In other words, will we have to keep a fallback once we implement WebAssembly threads in the HTML5 export?)

[Silvea12]

I'd say it'd be a good idea to keep a fallback for now - at least if you want to work by "web standards" where having fallbacks for compat + JS-based feature detection is the norm.
-------- Original Message --------
On 11 Nov. 2019, 02:56, Hugo Locurcio wrote:

WebAssembly threads are supported since Chrome 74 and recent Firefox versions. What about Safari and Edge though? (In other words, will we have to keep a fallback once we implement WebAssembly threads in the HTML5 export?)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Calinou]

@Silvea12 On the other hand, we have to balance this with the file size (as keeping a fallback will likely increase the .wasm payload size). This is especially true on a platform where every kilobyte counts if you want fast downloads and initialization.

[Silvea12]

@Calinou The standard way to handle that is multiple modules that you can download and pick between, with a preloader that can decide which to download based on feature set. But then that may increase engine complexity a good amount - or at least, the build process. So it may not be worth doing.

[belen-albeza]

In the meantime, is there a workaround for this? Delayed audio kind of breaks the player's experience.

[stdio2016]

I found a workaround
Add this program in AutoLoad singleton:

func _ready():
    # XXX: workaround godot web audio latency issue by recreating script processor
    var jsCode = """
        setTimeout(function () {
            var channelCount = _audioDriver_audioContext.destination.channelCount;
            var bufferSize = _audioDriver_scriptNode.bufferSize;
            var process = _audioDriver_scriptNode.onaudioprocess;
            _audioDriver_scriptNode.disconnect();
            _audioDriver_scriptNode = _audioDriver_audioContext.createScriptProcessor(bufferSize, 2, channelCount);
            _audioDriver_scriptNode.onaudioprocess = process;
            _audioDriver_scriptNode.connect(_audioDriver_audioContext.destination);
        }, 0);
    """
    if OS.get_name() == 'HTML5':
        JavaScript.eval(jsCode)

Tested on Godot 3.2
The latency can still be as large as 0.1 second (4096/44100Hz) because audio is generated from ScriptProcessorNode, whose buffer size is decided by browser heuristics.
On my computer, Firefox creates ScriptProcessorNode with buffer size 4096, where Chrome creates one with buffer size 2048.

[belen-albeza]

Unfortunately nothing much can be done about this due to the problem of WebAssembly not supporting threads.

It looks like thread support was added in this commit https://github.com/godotengine/godot/commit/21c9f37757d564009e9e400142b3b4c70af237d3 Does it provide a way to fix this bug?

If not, would it be feasible to make @stdio2016 workaround to be added automatically to the HTML export?

Thanks!

[Faless]

The buffer size is now (3.2.2) configurable using the audio/output_latency project setting (which was ignored for HTML5 exports in previous releases).
In 3.2.3 the default output latency for web will be 50ms (which seems to be a good trade off on many devices).
See #38816 and #40052
Further improvements might come when we implement audio mixing in threads (browser support seems still limited for this feature).

I'm closing this issue as fixed, since the delay is no longer browser dependent, and can be configured (like on other platforms) but feel free to comment if you think this should be reopen.