AudioLoader
llama a scope.manager.itemEnd
(a través del cargador de archivos) después de cargar el búfer, pero su propio onLoad
después de decodificarlo. Dado que la decodificación del búfer es asincrónica (o al menos, tiene una devolución de llamada), puede entrar en una condición de carrera si el cargador de audio es el último cargador en la cola del administrador de carga, donde el administrador cree que todos sus elementos están terminados, pero los cargadores individuales no ha terminado de analizar. Notamos esto en nuestra situación de precarga y tuvimos que implementar nuestra propia cola de carga que usaba el onLoad
por artículo para marcar los artículos completos.
Desafortunadamente, mirando la fuente FileLoader / AudioLoader, no estoy seguro de cómo solucionar esto o si es una preocupación; tal vez la solución más fácil de aclarar en los documentos que LoadingManager#onLoad
solo indica que la solicitud de red ha finalizado y no indica que los datos se hayan analizado.
Hmm, entonces supongo que AudioLoader no debería pasar el administrador a FileLoader
y llamar a las funciones en sí.
Eso definitivamente lo arreglaría para un administrador de carga personalizado. El administrador de carga predeterminado aún ignoraría la devolución de llamada de decodificación, pero ¿cuántas personas usan el administrador de carga predeterminado en este contexto?
Experimenté el mismo problema. Por el momento, no es posible reproducir de forma segura un archivo de audio después de que los gerentes onLoad
devolvieran la llamada.
Comentario más útil
Hmm, entonces supongo que AudioLoader no debería pasar el administrador a
FileLoader
y llamar a las funciones en sí.