OpenAL updateSourceSpace performance issue

[nathhB]

Hi.

I'm using emscripten 3.0.1 to compile my game and I use the OpenAL implementation for audio.

I update a bunch of sources and the listener every frame and I noticed that the performance of my game would drastically decrease over time. I tracked down the issue using Google Chrome's profiler and noticed that it was coming from the updateSourceSpace.

I went a little further analyzing the issue and realized that it was more precisely coming from the updating of the panner's property (here for instance). I edited the library_openal.js to comment out those lines and I noticed no performance issue. I also compiled using OPENAL_DEBUG, no warning or errors.

In addition, I made sure that the problem wasn't coming from a ridiculous amount of audio sources, it's not the case, I have a bunch of sources and this number does not increase.

I'd be glad to look into it further but I'm kind of stuck at this point. Does this issue ring a bell to anyone? could someone point me in a direction so I can keep investigating?

EDIT: Something else I noticed, it's a bit hard to put into words: it seems that when my simulation performance starts deteriorating, playing sounds will make it go back up like it cleared some hanging state or something...

Thank you very much!

Nathan.

[erymin]

Hi @nathhB , yes, it seems the same problem! Well at least that proves that I'm not alone with this problem! I've uploaded the gif demo: https://gifyu.com/image/SSIWX

15848

[erymin]

Have you tried to check this isuue on WebAssembly VM like wasmtime or wasmer?

[nathhB]

@erymin no, I don't even know what it is, I will check it out. It seems though that it might be browser-related because a friend of fine does not seem to have the problem with Firefox. Have you tried with other browsers?

[erymin]

@nathhB Yes I could run may app on Opera and experinced the same problem.

[sbc100]

Could it by that its not actually the assignment of panner.positionX.value = posX; itself that is causing the slowdown but the calculation of posX, etc? And then you comment out the assignment the compiler can completely remove the poxX variable and all associated calculations?

Regarding wasmtime or wasmer it probably wouldn't make any sense to run this code there.. since its JS code and those engines don't support JS at all.

Presumably if you don't set a panner at all then the issue would also go away (e.g. if you disable specializing.. does your application rely on this?)

[nathhB]

@sbc100 not sure. Does not really matter though, the only thing that matters is that updating the panner slow down the application. I cannot disable specializing, my game relies on it. But once again, that's not really the point, the point is the issue with emscripten OpenAL itself. I have yet to continue my investigation to try to understand it better.

[sbc100]

I agree this seems to be a performance issue with openAL in emscripten, I'm just trying to narrow it down the precise cause, and also to find workarounds in the interim.

It does seem like there is a fair bit of math in the function in question, but looked like egregious to me. If you have any more insight. or a repro case that would be most welcome. Also patches are of course welcome too!

[kripken]

When you say "commented out those lines", are those these three, and nothing else?

https://github.com/emscripten-core/emscripten/blob/8e1e305519e1027726a48861a1fec5662f7e18a2/src/library_openal.js#L612-L614

If those lines are slow then it's likely a slowdown in the browser's DOM API here. Perhaps updating the position of the node causes an update to the rest of the graph, for example. You say the number of sources is not that high, though, so maybe it isn't that. But just to check, would updating only on change help, like this:

if (posX != panner.positionX.value) panner.positionX.value = posX;
..

If that's not it, it may just be a browser bug. If you can also test in Firefox and Safari those numbers could be interesting, and if one browser is particularly slow we can file a bug for them.

[nathhB]

@kripken well, it seems it was that. I have to test it further but so far, adding those conditions fixes the issue. I don't notice the ridiculous FPS drops anymore but it seems however that updating the panner position is an expensive operation, maybe I have too many sources updated at the same time.

[kripken]

Sounds good to me, if adding those conditions fixes the issue then a PR would be great!

[nathhB]

@kripken @erymin here is the PR: https://github.com/emscripten-core/emscripten/pull/16000

[erymin]

@nathhB Thank you, I'll test it soon!

[jeremiahar]

It seems there's an open Chromium bug for this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1133233