Procedimientos recomendados para la construcción de flowgraphs de audio de SHAPE

​

Introducción

El motor de procesamiento de audio por hardware escalable (Scalable Hardware Audio Processing Engine, SHAPE) proporciona aceleración por hardware para varios de los bloques de creación más comunes de reproducción y manipulación de audio. El título tiene control total de la configuración y el orden de los bloques de procesamiento de SHAPE, que administra el procesador de control de audio (ACP). El ACP es un componente de hardware. El título crea rutas definidas para encadenar uno o varios componentes de SHAPE desde la entrada hasta la salida. Estas rutas se conocen como flowgraphs. Una vez creado, cada flowgraph se envía como una serie de comandos para que el ACP los procese. En este tema se describen los procedimientos recomendados para crear y enviar flowgraphs que implementen correctamente los escenarios en tiempo de ejecución con los que se encontrará con más frecuencia, así como las configuraciones que debe evitar para maximizar el rendimiento. Este tema trata lo siguiente:

• Componentes y funcionalidades de SHAPE
• Escenarios de bajo rendimiento y casos patológicos
• Planificación y revisión de flowgraphs de SHAPE
• Flowgraphs persistentes frente a no persistentes
• Depuración de problemas de SHAPE

​

Componentes y funcionalidades de SHAPE

Las colas de comandos las administra y rellena automáticamente el ACP cuando los flowgraphs se envían al hardware. En la tabla siguiente se muestra una lista consolidada de los componentes y sus capacidades de creación de instancias. En la tabla siguiente se muestra una lista consolidada de los componentes y sus reglas de enrutamiento de búferes de mezcla. | Componente de SHAPE| Búferes de mezcla de entrada por instancia| Búferes de mezcla de salida por instancia| | --- | --- | --- | --- | --- | --- | --- | --- | --- | | XMA| No aplicable. Lee desde la memoria.| No aplicable. Descodifica a la memoria, normalmente consumida por SRC.| | SRC| 0; lee desde la memoria.| 1 para mono, 2 para estéreo.| | FLT/VOL| 1.| 1.| | EQ/CMP| 1 (o 2, para configuraciones de sidechain).| 1.| | MB| No aplicable. Los búferes de mezcla no pueden leer directamente de otros búferes de mezcla.| No aplicable. Los búferes de mezcla no pueden escribir directamente en otros búferes de mezcla.| | DMA| 1; hasta 32 fotogramas de audio por transferencia.| 1; hasta 32 fotogramas de audio por transferencia.| Para más información sobre los bloques de creación de SHAPE, consulte la charla relacionada de Xfest The Sound of XBOX One (Conference Material > Xfest 2012) y las notas del producto The Sound of the Future (Developer Education Materials > All NDA Whitepapers).

​

Nota sobre los escenarios de uso de flowgraphs

Es posible que muchos títulos nunca implementen flowgraphs directamente. XAudio2 implementa de forma implícita los componentes de SHAPE, y el middleware de audio podría abstraer los flowgraphs de hardware de los desarrolladores de títulos. Sin embargo, la construcción de flowgraphs le permite aprovechar directamente las funcionalidades de aceleración de audio de la consola XBOX One; en concreto, si está desarrollando e implementando su propia solución de representación de audio o si tiene una configuración personalizada que XAudio2 o el middleware no admiten. Para todos los títulos que desarrolle, le resultará valioso comprender las funcionalidades de SHAPE, que se describen más adelante en este tema, y planificar con antelación las posibles topologías de flowgraph.

​

Escenarios de bajo rendimiento y casos patológicos

En las secciones siguientes se describen escenarios comunes que pueden causar problemas de rendimiento. En las secciones también se proporcionan recomendaciones para evitar estos problemas.

​

Flowgraphs con formato incorrecto

Es posible que cree flowgraphs que construyan flujos de señal imposibles o datos que nunca se materialicen en la salida. Estos son algunos de los errores más comunes que se producen en la creación de flowgraphs.

• Referencias a objetos de SHAPE que no se han creado ni asignado
• Comandos o parámetros no válidos
• Precisión del recuento de referencias de entrada/salida de los búferes de mezcla
• Reasignación del identificador virtual de un búfer de mezcla existente
• Omisión de la conexión de búferes de mezcla entre componentes de SHAPE
• Uso de más de un único búfer de mezcla como salida de un componente de SHAPE, con la excepción del bloque SRC, que puede enrutar a dos búferes de mezcla cuando representa contenido estéreo

Además de los errores más evidentes de los flowgraphs (por ejemplo, referencias a objetos de SHAPE que no se han asignado ni creado), los escenarios más comunes de flowgraphs con formato incorrecto incluyen los siguientes:

• Referencias circulares en los búferes de mezcla Un búfer de mezcla no estará disponible hasta que se presenten todas sus entradas y se consuman las salidas. Si hay una referencia circular en un búfer de mezcla, el búfer de mezcla tiene efectivamente entradas infinitas, nunca está disponible y bloquea el grafo.
• Búferes de mezcla huérfanos Un búfer de mezcla sin salidas estará disponible inmediatamente cuando se procese su última entrada. Un búfer de mezcla destinado a la representación en un dispositivo de audio (por ejemplo, altavoces o auriculares) debe terminarse con un bloque de salida DMA. Esto presentará el búfer de mezcla a la memoria principal para la mezcla final.

​

Orden de los comandos

El ACP rellena automáticamente las colas de comandos de cada componente de SHAPE. Al rellenar las colas, el ACP omite los comandos posteriores de un componente determinado hasta que las entradas del componente estén libres. En general, la omisión de comandos representa una penalización de rendimiento insignificante. Sin embargo, en función del orden de los comandos, los títulos podrían crear un orden subóptimo de los componentes de SHAPE. Esto haría que una o varias colas en estado no lleno esperaran a otras colas. Esta espera reduce el número de instancias disponibles por fotograma. En la figura 1 se muestra cómo el orden de los comandos podría afectar al rendimiento. Como procedimiento recomendado, emita los comandos FLT/VOL de arriba abajo, como se muestra en el flowgraph, en lugar de izquierda a derecha, lo que permite completar más voces. Este método permite que un EQ/CMP, mostrado en la parte inferior del flowgraph, se procese en paralelo. Figura 1. Un flowgraph que muestra cómo emitir comandos FLT/VOL de arriba abajo, en lugar de izquierda a derecha, para permitir que un EQ/CMP se procese en paralelo y mejorar el rendimiento. Como procedimiento recomendado para ordenar los flowgraphs entre comandos de un tipo determinado, priorice la profundidad a lo largo de la ruta de procesamiento de una voz, hasta una fase de submezcla o hasta componentes de SHAPE reutilizados. Después, priorice la amplitud para las voces que compartan órdenes de procesamiento comunes. En la figura 1 se muestra que el enfoque óptimo (y típico) es crear primero los comandos FLT/VOL para la columna de FLT/VOL situada más a la izquierda y, a continuación, dinamizar los comandos FLT/VOL restantes para los dos canales de la voz estéreo superior.

​

Asignación de instancias de búferes de mezcla

Los búferes de mezcla se bloquean mientras se escribe en ellos. No se puede leer ninguna salida de ellos hasta que todas las entradas hayan contribuido a la mezcla. Desde la perspectiva de la implementación, los búferes de mezcla usan los campos numIn y numOut para administrar esto. Por lo tanto, es posible construir escenarios que requieran más de 128 búferes de mezcla físicos al mismo tiempo. SHAPE virtualiza los búferes de mezcla de modo que, incluso con una polifonía alta, este escenario normalmente no causará un problema. Sin embargo, se pueden construir flowgraphs que requieran acceder simultáneamente a un gran número de búferes de mezcla. En concreto, los búferes de mezcla que están realizando submezclas o masterización entre varias voces permanecen bloqueados hasta que la última voz se mezcla en ellos y hasta que la última salida de los búferes de mezcla es consumida por un bloque de SHAPE posterior. En un escenario típico (una única voz de masterización 7.1 en la que se mezclan todas las voces de SHAPE), 8 de las 128 voces permanecen bloqueadas durante todo el fotograma. Otros búferes de mezcla podrían bloquearse durante una parte significativa del fotograma (reduciendo la capacidad de los búferes de mezcla virtuales) si hay una submezcla multicanal extensa con cadenas de dependencia de flowgraphs. Como alternativa, se crean voces de masterización adicionales si, por ejemplo, creara tanto una mezcla de altavoz principal como una mezcla de auriculares 7.1 por jugador para un título de cuatro jugadores, lo que podría consumir 40 búferes de mezcla simultáneos. En general, un caso que requiera más de 128 búferes de mezcla físicos simultáneos es patológico. Sin embargo, los búferes de mezcla que están bloqueados innecesariamente durante todo el fotograma reducen la capacidad del título para alcanzar el rendimiento potencial. La figura 2 representa una submezcla innecesaria que podría reducir el número de búferes de mezcla disponibles en un momento determinado. En función del orden de los comandos (figura 2), los 5 búferes de mezcla de masterización 7.1 independientes podrían permanecer bloqueados durante casi todo el fotograma, lo que representa 40 de los 128 búferes de mezcla físicos. Aunque esta ruta solo requiere que haya 2 búferes de mezcla más en uso a la vez (es decir, el par de entrada y salida de un FLT/VOL o EQ/CMP), considere la posibilidad de procesar primero todos los búferes de mezcla que van a los altavoces. A continuación, puede liberar esos búferes de mezcla y procesar los auriculares 1, 2 y siguientes. Figura 2. Un flowgraph que muestra una submezcla innecesaria y el bloqueo de instancias de búferes de mezcla asignadas debido a un orden de comandos deficiente.

​

Selección y equilibrio de los componentes de SHAPE (FLT/VOL frente a EQ/CMP)

Si usa los mismos componentes de SHAPE repetidamente en secuencia, puede reducir la capacidad de alcanzar el rendimiento máximo. En comparación, al alternar componentes diferentes, se asegura de que cada bloque de SHAPE esté realizando un procesamiento paralelo significativo. En la figura 3 se muestra un ejemplo común: no todos los FLT/VOL se pueden procesar en paralelo. El rendimiento podría verse afectado. Figura 3. Un flowgraph que muestra un intento de procesar todos los FLT/VOL en paralelo. El segundo conjunto de FLT/VOL debe esperar a que se complete el primero, posiblemente mientras otros bloques de SHAPE permanecen sin usar. Si cualquiera de los conjuntos se usara exclusivamente para el filtrado, el EQ/CMP podría haber sido una mejor opción para uno de ellos, especialmente si el flowgraph (figura 4) con la misma configuración tuviera más voces. Estas podrían entonces comenzar su FLT/VOL mientras el primer conjunto procesaba sus bloques EQ/CMP. En la figura 4 se muestra un rendimiento que se aproxima más a las capacidades ideales de SHAPE. Este flowgraph reemplaza un conjunto de FLT/VOL, que se presume que se usa solo para el filtrado (consulte la figura 3), por EQ/CMP, lo que permite el procesamiento paralelo de los dos componentes de SHAPE. Figura 4. Un flowgraph que muestra un intento de procesar FLT/VOL y EQ/CMP en paralelo. El equilibrio de los componentes de SHAPE también es relevante cuando se considera el número máximo de instancias de los distintos componentes. Los 2560 componentes FLT/VOL que pueden producirse dentro de un fotograma permiten que el hardware FLT/VOL ejecute aproximadamente cinco veces más cálculos de los que son posibles con los 512 bloques EQ/CMP. Si ejecuta un bloque EQ/CMP en serie con un único FLT/VOL, obtendrá menos rendimiento del que obtendría ejecutando varios componentes FLT/VOL acoplados a un EQ/CMP, porque el procesamiento del primero estará limitado por el consumo del segundo.

​

Demasiados recorridos de ida y vuelta de DMA de bajo valor o demasiado frecuentes

DMA está limitado por el ancho de banda de lectura/escritura disponible para el bus de SHAPE. Si consume todo el ancho de banda disponible (aunque este escenario suele ser patológico), los bloques DMA se detendrán y reducirán el rendimiento. Como se ha descrito anteriormente, todo el procesamiento que se produce después de un bloque de entrada DMA tendrá que esperar hasta que se complete el DMA. Por lo tanto, puede crear flowgraphs con gran parte del flowgraph bloqueado y a la espera de que se complete un DMA antes de que el flowgraph pueda comenzar el procesamiento. También debe evaluar los recorridos de ida y vuelta de DMA en relación con el valor que aportan a la secuencia de audio. La adición mínima de latencia (que puede controlar en términos del número de fotogramas a los que se accede mediante DMA en múltiplos del tamaño de 2,667 ms del fotograma de audio) podría no ser un problema para la mayoría de los escenarios de reproducción de audio. Esto se debe a que los bloques situados a la derecha de un DMA procesarán datos de audio de fotogramas anteriores. En concreto, enviar un DMA de vuelta a SHAPE solo para realizar una mezcla final puede ser innecesario cuando también planea enviar esa mezcla final como DMA de vuelta a la memoria para su presentación en un punto de conexión de audio. En la figura 5 se muestra un ejemplo de un valor potencialmente bajo, en el que una voz enviada mediante DMA a la memoria para su procesamiento en la CPU/GPU se devuelve a SHAPE, solo para aplicarle una panoramización 7.1 en la mezcla de masterización. A continuación, la voz se envía mediante DMA de vuelta a la memoria. En la figura 5 se supone que no se está aplicando ningún filtrado a las voces en los bloques FLT/VOL y que los búferes de mezcla de masterización 7.1 tienen voces adicionales enrutadas a ellos. Figura 5. Un flowgraph que muestra un enrutamiento potencialmente de bajo valor, con componentes FLT/VOL innecesarios y recorridos de ida y vuelta de DMA innecesarios. En la figura 6 se muestra un enrutamiento potencialmente más óptimo de la intención de la figura 5. La voz se envía mediante DMA a la memoria para su procesamiento en la CPU/GPU. Después, la voz puede recibir la panoramización 7.1 y combinarse con el resto de la mezcla 7.1 en la propia CPU sin la sobrecarga de DMA adicionales, latencia adicional de fotogramas de audio o el uso de siete componentes FLT/VOL. Figura 6. Un flowgraph que muestra un enrutamiento más óptimo sin recorridos de ida y vuelta de DMA adicionales ni componentes FLT/VOL innecesarios. Cuando elimine DMA del proceso, asegúrese de no eliminar demasiados. Puede justificar el uso de DMA de ida y vuelta si:

• Tiene previsto realizar una cantidad significativa de procesamiento adicional de SHAPE para una voz determinada.
• Desea aprovechar la medición por hardware y la detección de recortes que proporcionan los búferes de mezcla.

​

Planificación y revisión de flowgraphs de SHAPE

Como ejercicio, antes de la implementación, cree una representación visual de un flowgraph del uso de voces que espera dentro de un fotograma, con las voces categorizadas y cuantificadas, por ejemplo, en términos del número de efectos de sonido y de secuencias simultáneas de música. Capturar esta información visualmente puede ayudarle a comprender cómo evitar algunos de los problemas de rendimiento descritos anteriormente. A continuación se indican algunas de las métricas clave que puede derivar de este tipo de flowgraph.

• El número máximo de cada componente de SHAPE, simultáneo y dentro del fotograma general:
  • Compruebe que este flowgraph queda suficientemente por debajo de los máximos teóricos.
  • Observe el uso insuficiente y excesivo de los componentes. Reequilibre los componentes según sea necesario.
  • Considere la posibilidad de reestructurar el uso de los búferes de mezcla si demasiados deben permanecer bloqueados durante la mayor parte del flowgraph.
• Planificación de la implementación del posicionamiento 3D mediante SHAPE:
  • ¿Todas las voces recibirán panoramización 7.1, o las voces se panoramizarán entre los 2 o los n altavoces más cercanos?
  • ¿Toda la panoramización 7.1 debería hacerse en SHAPE, o las voces que ya se han enviado mediante DMA a la CPU se panoramizan mejor en la propia CPU?
• Número de transiciones de DMA hacia y desde la memoria, y si estas transiciones son asimétricas. Por ejemplo, algunas voces se escriben hacia y desde SHAPE más veces que otras, lo que significa que probablemente tendrán latencia adicional.

La construcción de flowgraphs también puede servir de base para las conversaciones entre los diseñadores de audio y los desarrolladores de motores o middleware de audio, a fin de garantizar que los grafos creados de forma dinámica o estática se creen y enruten correctamente según lo deseado.

​

Flowgraphs persistentes frente a no persistentes

Puede enviar flowgraphs para que se procesen como persistentes o no persistentes. Los flowgraphs persistentes se procesan y luego permanecen residentes para repetir su procesamiento en el siguiente fotograma, después de que los punteros de lectura y escritura hayan avanzado y después de que se actualice otra información de contexto. Use flowgraphs persistentes para cualquiera de los siguientes escenarios.

• Flowgraphs muy complejos: los flowgraphs que requieren una cantidad significativa de procesamiento de CPU para volver a ensamblar cada fotograma
• Flowgraphs muy estáticos: los flowgraphs que mantienen el mismo número y configuración de voces durante un período de tiempo prolongado

Use flowgraphs no persistentes para cualquiera de los siguientes escenarios.

• Las topologías de voces cambian con frecuencia.
• La cadencia de procesamiento del motor de software de audio del título está desacoplada del hardware de SHAPE; es decir, no es un múltiplo de 2,667 ms.
• Desea ejecutar el procesamiento de audio en escenarios más rápidos que el tiempo real; es decir, cuando envía grafos para que se consuman tan pronto como estén disponibles.

​

Depuración de problemas de SHAPE

Se recomienda que, cuando desarrolle flowgraphs, se registre para recibir mensajes que le ayuden a depurar problemas. En concreto, use el parámetro NumMessages del método IAcpHal::Connect. El sistema de mensajería proporciona comentarios detallados sobre una variedad de problemas, incluidos los flowgraphs no válidos (como ACP_FLOWGRAPH_TERMINATED_REASON_INVALID_GRAPH), los comandos bloqueados y los excesos de fotograma provocados por intentos de realizar más procesamiento del que permite el tamaño de fotograma del hardware de 2,667 ms. Este método es útil para la depuración. Sin embargo, antes de que el título se comercialice, intente hacer lo siguiente:

1. Elimine todos los mensajes que indiquen errores de los escenarios en tiempo de ejecución.
2. Compruebe que el procesamiento de flowgraphs se realiza correctamente de forma sistemática examinando los mensajes ACP_MESSAGE_TYPE_FLOWGRAPH_COMPLETED (consulte la enumeración ACP_MESSAGE_TYPE) de cada flowgraph enviado.

​

Mensajes perdidos

Si usa mensajes de ACP para controlar el estado del motor y si administra un gran número de mensajes, debe examinar ACP_MESSAGE::droppedMessageCount durante el desarrollo. Un valor distinto de cero indica que la cola de mensajes estaba llena y que hubo que descartar mensajes. Si se produce este valor, considere la posibilidad de atender la cola más rápido y de aumentar su tamaño.

​

Excesos de fotograma

Durante el desarrollo, debido a un presupuesto excesivo, a flowgraphs subóptimos y a otras razones, es posible que un flowgraph no se complete antes de que se alcance el final de un fotograma de audio (2,667 ms). Este flowgraph incompleto dará lugar a un mensaje ACP_FLOWGRAPH_TERMINATED_TIME_EXCEEDED en el caso de los flowgraphs persistentes. Quedarán incompletos. Por el contrario, un flowgraph no persistente no está limitado de esta manera y se ejecutará hasta que se complete, incluso entre fotogramas.

​

Comandos bloqueados

Los comandos SRC y DMA pueden notificarse como bloqueados (ACP_MESSAGE_TYPE_SRC_BLOCKED y ACP_MESSAGE_TYPE_DMA_BLOCKED (consulte la enumeración ACP_MESSAGE_TYPE)) en varios escenarios, como se muestra en la tabla siguiente. Una vez que se determina que los comandos están bloqueados (lo que puede ocurrir tanto antes de que los elementos se agreguen a una cola de SHAPE para su procesamiento como en tiempo de ejecución), los comandos se expulsan del grafo. Esto podría provocar pérdidas de audio. Durante el desarrollo, use los comandos bloqueados como el primer lugar donde buscar mejoras en el manejo de los flowgraphs. Antes de la comercialización, el título también debe evitar el bloqueo de comandos. Puede evitar el bloqueo de los comandos DMA asegurándose de que el búfer de audio sea lo suficientemente grande y de que los datos se transmitan a intervalos regulares en relación con el tamaño del búfer. Por ejemplo, si está transmitiendo cuatro fotogramas de hardware a la vez, asegúrese de que haya algún múltiplo de esos fotogramas en el búfer (al menos con doble búfer, es decir, ocho) para permitir que el hardware escriba por delante del puntero de lectura del título. Como alternativa, podría forzar el vaciado del búfer antes de enviar el siguiente flowgraph consumiendo, actualizando el puntero de lectura de DMA y, a continuación, enviando el flowgraph. Los comandos SRC tienen los tres modos siguientes (detallados en ShapeSrcContext.h).

• SHAPE_SRC_COMMAND_TYPE_START Úselo para casi todos los comandos SRC de un flowgraph. Procese normalmente y espere que más datos de audio sigan al flowgraph actual.
• SHAPE_SRC_COMMAND_TYPE_STOP_IMMEDIATE Úselo para detener inmediatamente el procesamiento de los datos XMA o PCM de origen. El SRC generará un búfer con ceros para este fotograma.
• SHAPE_SRC_COMMAND_TYPE_STOP_END Úselo para indicar el último paquete de una voz. Si no se envía con STOP_END o STOP_IMMEDIATE, el comando SRC no se completará. Esto hará que el flowgraph activo se detenga. Un flowgraph persistente terminará al final del fotograma de audio, y un flowgraph no persistente nunca se completará.

​

Problemas de sincronización

Pueden surgir varios problemas de sincronización si no se respetan las prácticas de consumo de contextos y comandos del hardware de SHAPE. Aunque los títulos conservan acceso completo a la memoria asignada por el ACP, tenga cuidado de no modificar una estructura de contexto mientras está en uso. Puede enviar comandos (consulte IAcpHal::SubmitCommand) para que se produzcan en un fotograma específico, al principio del siguiente fotograma o lo antes posible. Para el último escenario (comandos que se producen lo antes posible), tenga en cuenta que lo antes posible sigue siendo asíncrono con respecto a cualquier procesamiento de CPU del título. Es posible que algunos comandos no se completen inmediatamente; por ejemplo, si un contexto está en medio de una operación no interrumpible. Espere un mensaje ACP_MESSAGE_TYPE_COMMAND_COMPLETED para comprobar que un comando se ha procesado realmente.