AudioLoader
вызывает scope.manager.itemEnd
(через загрузчик файлов) после загрузки буфера, но свой собственный onLoad
после его декодирования. Поскольку декодирование буфера является асинхронным (или, по крайней мере, имеет обратный вызов), вы можете попасть в состояние гонки, если аудио-загрузчик является последним загрузчиком в очереди диспетчера загрузки, когда диспетчер думает, что все его элементы завершены, но отдельные загрузчики не закончил разбор. Мы заметили это в нашей ситуации с предварительной загрузкой, и нам пришлось реализовать нашу собственную очередь загрузки, которая использовала для каждого элемента onLoad
для отметки полных элементов.
К сожалению, глядя на исходный код FileLoader / AudioLoader, я не уверен, как это исправить, и не вызывает ли это беспокойства; возможно, самое простое решение - просто уточнить в документах, что LoadingManager#onLoad
указывает только на то, что сетевой запрос завершен, и не указывает на то, что данные были проанализированы.
Хм, так что, я полагаю, AudioLoader не должен передавать менеджера FileLoader
и вызывать функции самостоятельно?
Это определенно исправит это для настраиваемого диспетчера загрузки. Диспетчер загрузки по умолчанию все равно игнорирует обратный вызов декодирования, но сколько людей используют диспетчер загрузки по умолчанию в этом контексте?
У меня была такая же проблема. На данный момент невозможно безопасно воспроизвести аудиофайл после срабатывания обратного вызова менеджеров onLoad
.
Самый полезный комментарий
Хм, так что, я полагаю, AudioLoader не должен передавать менеджера
FileLoader
и вызывать функции самостоятельно?