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.
Hmm, so I guess AudioLoader shouldn't pass the manager to FileLoader
and call the functions itself?
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?
I experienced the same problem. At the moment it's not possible to securely play an audio file after the managers onLoad
callback fired.
Most helpful comment
Hmm, so I guess AudioLoader shouldn't pass the manager to
FileLoader
and call the functions itself?