Hello,
I don’t know if this is from a recent update, but I’ve noticed that the component “PositionalAudio” makes the performance drop more and more over time. As I have several "PositionalAudio " this becomes relatively noticeable. I tried to isolate the component to make sure that the problem did not come from somewhere else.
<PositionalAudio url={coinSound} listener={audioListener} />
Can you reproduce the issue with three.js webaudio - timing as well?
You have potentially run into: AudioListener browser bug ?! · Issue #17705 · mrdoob/three.js · GitHub
I’ve filed a Chromium bug some time ago here: 1106389 - chromium - An open-source project to help move the web forward. - Monorail
I’m not sure this detail is obvious enough but the performance issue in Chromium based browser happens because the audio context is suspended. A suspended audio context is the result of a wrong usage on app level.
Before using the WebAudio context for any kind of operation (like decoding audio data) it’s required to request a user interaction like a button press. That’s why the issue should not appear in the official example.
The problem also appears and grows even faster with safari.
I’m using mouse movement as an event for playing the audio. I don’t have any warning about user interaction with this. But could this be the problem?
I could imagine that the same issue is present in the WebKit code base since Blink is a fork of WebKit.
Besides, please make sure as mentioned above that the audio context is not suspended. If the context is in its running state and the performance drop still occurs, this might be a different issue.
In any event, the issue probably needs to be reported to WebKit as well.