AudioLoader and LoadingManager onLoad Race

[seep]

Description of the problem

AudioLoader calls scope.manager.itemEnd (through the file loader) after loading the buffer, but its own onLoad after decoding it. Since decoding the buffer is asynchronous (or at least, has a callback) you can get into a race condition if the audio loader is the last loader in the loading manager's queue, where the manager thinks all of it's items are finished but the individual loaders haven't finished parsing. We noticed this in our preloading situation and had to implement our own loading queue that used the per-item onLoad to tick off complete items.

Unfortunately, looking at FileLoader/AudioLoader source, I'm not sure how to fix this or if it's even a concern; maybe the easiest solution to just clarify in the docs that LoadingManager#onLoad only indicates the network request is finished, and doesn't indicate that the data has been parsed.

Three.js version

• r84

Browser

• All of them

OS

• All of them

[mrdoob]

Hmm, so I guess AudioLoader shouldn't pass the manager to FileLoader and call the functions itself?

[seep]

That would definitely fix it for a custom loading manager. The default loading manager would still ignore the decoding callback, but how many people use the default loading manager in this context?

[richartkeil]

I experienced the same problem. At the moment it's not possible to securely play an audio file after the managers onLoad callback fired.