Creación de perfiles de aplicaciones de audio web en Chrome

Aprenda a perfilar el rendimiento de las aplicaciones Web Audio en Chrome usando chrome://tracing y el WebAudio pestaña en DevTools.

4 de mayo de 2020

Ha llegado a esta documentación probablemente porque está desarrollando una aplicación que utiliza la API de audio web
y experimentó algunos fallos inesperados, como ruidos en la salida. Es posible que ya esté involucrado en un crbug.com
discusión y un ingeniero de Chrome le ha pedido que cargue «datos de seguimiento». Esta guía muestra cómo obtener los datos para que pueda ayudar a los ingenieros a clasificar y, finalmente, solucionar el problema.

Hay dos herramientas que le ayudarán a crear perfiles de audio web,
chrome://tracing y el WebAudio pestaña en Chrome DevTools.

Cuando usas chrome://tracing?

Cuando ocurren misteriosos «fallos». La creación de perfiles de la aplicación con las herramientas de seguimiento le brinda información sobre:

• Porciones de tiempo dedicadas a llamadas a funciones específicas en diferentes hilos
• Tiempo de devolución de llamada de audio en la vista de línea de tiempo

Por lo general, muestra las fechas límite incumplidas o las grandes paradas de recolección de basura que pueden causar fallas de audio inesperadas. Esta información es útil para detectar un error. Los ingenieros de Chromium solicitarán datos de seguimiento si no es posible una reproducción local del problema. Ver La herramienta de creación de perfiles de eventos de seguimiento para obtener instrucciones generales sobre cómo rastrear.

¿Cuándo usas el WebAudio ¿lengüeta?

Cuando desee tener una idea del rendimiento de la aplicación en el mundo real. DevTools le muestra una estimación en ejecución de la capacidad de procesamiento, que indica cómo el motor de procesamiento de audio web está manejando las tareas de procesamiento con un presupuesto de procesamiento determinado (por ejemplo, aproximadamente 2.67ms a 48KHz). Si la capacidad se acerca al 100%, eso significa que es probable que su aplicación produzca fallas porque el renderizador no puede terminar el trabajo en el presupuesto de renderizado.

Utilizar chrome://tracing

Cómo capturar datos de rastreo

Las instrucciones a continuación escritas son para Chrome 80 y posteriores.

Para obtener mejores resultados, cierre todas las demás pestañas y ventanas y desactive las extensiones. Alternativamente, puede lanzar una nueva instancia de Chrome
o usa otras compilaciones de diferentes canales de lanzamiento (por ejemplo, Beta o Canary). Una vez que tenga el navegador listo, siga los pasos a continuación:

1. Abra su aplicación (página web) en una pestaña.

2. Abra otra pestaña y vaya a chrome://tracing.

3. presione el Grabar botón y seleccione Seleccionar manualmente la configuración.

4. presione el Ninguna botones en ambos Categorías de registro y
   Deshabilitado por categorías predeterminadas secciones.

5. En el Categorías de registro sección, seleccione lo siguiente:

   • audio
   • blink_gc
   • media
   • v8.execute (si te interesa AudioWorklet Rendimiento del código JS)
   • webaudio

6. En el Deshabilitado por categorías predeterminadas sección, seleccione lo siguiente:

   • audio-worklet (si está interesado en dónde AudioWorklet comienza el hilo)
   • webaudio.audionode (si necesita el seguimiento detallado de cada AudioNode)

7. presione el Grabar botón en la parte inferior.

8. Regrese a la pestaña de su aplicación y vuelva a realizar los pasos que desencadenaron el problema.

9. Cuando tenga suficientes datos de seguimiento, vuelva a la pestaña de seguimiento y presione Detener.

10. La pestaña de seguimiento visualizará el resultado.

    

11. prensa Salvar para guardar los datos de seguimiento.

Cómo analizar los datos de rastreo

Los datos de seguimiento visualizan cómo el motor de audio web de Chrome procesa el audio. El renderizador tiene dos modos de renderizado diferentes: Modo nativo y
Modo worklet. Cada modo utiliza un modelo de subprocesamiento diferente, por lo que los resultados del seguimiento también difieren.

Modo nativo

En modo nativo, el AudioOutputDevice hilo ejecuta todo el código de audio web. los AudioOutputDevice es un hilo de prioridad en tiempo real que se origina en el servicio de audio del navegador y que es impulsado por el reloj del hardware de audio. Si observa una irregularidad en los datos de seguimiento en este carril, significa que el tiempo de devolución de llamada del dispositivo puede estar nervioso. Se sabe que la combinación de Linux y Pulse Audio tiene este problema. Consulta los siguientes problemas de Chromium para obtener más detalles: # 825823,
# 864463.

Modo worklet

En el modo Worklet, que se caracteriza por un salto de hilo desde
AudioOutputDevice al AudioWorklet hilo, debería ver trazos bien alineados en dos líneas de hilo como se muestra a continuación. Cuando el worklet está activado, todas las operaciones de audio web son procesadas por el
AudioWorklet hilo. Este hilo no es actualmente una prioridad en tiempo real. La irregularidad común aquí es un gran bloqueo causado por la recolección de basura o los plazos de procesamiento no cumplidos. Ambos casos provocan fallos en la transmisión de audio.

En ambos casos, los datos de seguimiento ideales se caracterizan por invocaciones de devolución de llamada de dispositivos de audio bien alineadas y tareas de renderizado que se completan dentro del presupuesto de renderizado dado. Las dos capturas de pantalla anteriores son excelentes ejemplos de los datos de rastreo ideales.

Aprender de ejemplos del mundo real

Ejemplo 1: tareas de renderización que van más allá del presupuesto de renderización

La captura de pantalla a continuación (Problema de cromo # 796330) es un ejemplo típico de cuando el código en AudioWorkletProcessor lleva demasiado tiempo y supera un presupuesto de renderizado determinado. El tiempo de devolución de llamada se comporta bien, pero la llamada a la función de procesamiento de audio de la API de Web Audio no pudo completar el trabajo antes de la siguiente devolución de llamada del dispositivo.

Sus opciones:

• Reduzca la carga de trabajo del gráfico de audio utilizando menos AudioNode instancias.
• Reduzca la carga de trabajo de su código en el AudioWorkletProcessor.
• Incrementar la latencia base de AudioContext.

Ejemplo 2: recolección de basura significativa en el subproceso del worklet

A diferencia del hilo de renderizado de audio nativo, la recolección de basura se gestiona en el hilo de worklet. Eso significa que si su código realiza asignación / desasignación de memoria (por ejemplo, nuevas matrices), eventualmente desencadena una recolección de basura que bloquea sincrónicamente el hilo. Si la carga de trabajo de las operaciones de audio web y la recolección de basura es mayor que un presupuesto de renderizado dado, se producen fallas en la transmisión de audio. La siguiente captura de pantalla es un ejemplo extremo de este caso.

Sus opciones:

• Asigne la memoria por adelantado y reutilícela siempre que sea posible.
• Utilice diferentes patrones de diseño basados ​​en SharedArrayBuffer. Aunque esta no es una solución perfecta, varias aplicaciones de audio web utilizan un patrón similar con
  SharedArrayBuffer para ejecutar el código de audio intensivo. Ejemplos:

Ejemplo 3: Devolución de llamada de dispositivo de audio nerviosa desde AudioOutputDevice

La sincronización precisa de la devolución de llamada de audio es lo más importante para el audio web. Este debería ser el reloj más preciso de su sistema. Si el sistema operativo o su subsistema de audio no pueden garantizar un tiempo de devolución de llamada sólido, todas las operaciones posteriores se verán afectadas. La siguiente imagen es un ejemplo de devolución de llamada de audio nerviosa. En comparación con las dos imágenes anteriores, el intervalo entre cada devolución de llamada varía significativamente.

Este es un problema conocido en Linux, que usa Pulse Audio como backend de audio. Esto todavía está bajo investigación (Problema de cromo n. ° 825823).

También puede utilizar la pestaña DevTools diseñada específicamente para audio web. Esto es menos completo en comparación con la herramienta de seguimiento, pero es útil si desea medir el rendimiento de ejecución de su aplicación.

Acceda al panel abriendo el Menú principal de DevTools, luego vaya a Más herramientas > WebAudio.

Esta pestaña muestra información sobre la ejecución de instancias de BaseAudioContext. Úselo para ver el rendimiento del renderizador de audio web en la página.

Dado que una página puede tener múltiples BaseAudioContext instancias, el Selector de contexto
(que es el menú desplegable que dice realtime (4e1073) en la última captura de pantalla), le permite elegir lo que desea inspeccionar. La vista del inspector muestra las propiedades (por ejemplo, frecuencia de muestreo, tamaño del búfer, recuento de canales y estado de contexto) de un BaseAudioContext instancia que seleccione, y cambia dinámicamente cuando cambian las propiedades.

Lo más útil en esta vista es la barra de estado en la parte inferior. Sólo está activo cuando el seleccionado BaseAudioContext es un AudioContext, que se ejecuta en tiempo real. Esta barra muestra la calidad de la transmisión de audio instantánea de un AudioContext y se actualiza cada segundo. Proporciona la siguiente información:

• Intervalo de devolución de llamada (ms): muestra la media ponderada / varianza del intervalo de devolución de llamada. Idealmente, la media debería ser estable y la varianza debería ser cercana a cero. De lo contrario, la infraestructura de audio del sistema operativo podría tener problemas en capas más profundas.
• Capacidad de renderizado (porcentaje): sigue esta fórmula: (tiempo empleado en la representación real / intervalo de devolución de llamada instantáneo) × 100. Cuando la capacidad se acerca al 100 por ciento, significa que el renderizador está haciendo demasiado para un presupuesto de renderizado determinado, por lo que debería considerar hacer menos en el código de audio web.

Puede manullay activar un recolector de basura haciendo clic en el icono de la papelera.

Conclusión

La depuración de audio es difícil. La depuración de audio en el navegador es aún más difícil. Sin embargo, estas herramientas pueden aliviar el dolor al proporcionarle información útil sobre cómo funciona el código de audio web. En algunos casos, es posible que el audio web no se comporte como debería; entonces no tenga miedo de
presentar un error en Chromium Bug Tracker. Mientras completa la información, puede seguir la guía anterior y enviar los datos de rastreo que capturó con un caso de prueba reproducible. Con estos datos, los ingenieros de Chrome podrán corregir su error mucho más rápido.

Foto de Jonathan Velasquez en Unsplash