> For the complete documentation index, see [llms.txt](https://docs.comdigis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.comdigis.com/i-o/renderizado-sincronizacion.md).

# Renderizado/Sincronización

En **I/O**, el renderizado del grafo de audio se realiza en **bloques** de frames de muestra *(sample-frames)* cuyo tamaño permanece constante durante toda la vida de un `AudioGraph`. A la cantidad de frames en cada bloque se le llama tamaño de **quantum** de renderizado *(render quantum size)*, y al bloque en sí, **quantum** de renderizado *(render quantum).*&#x20;

El valor predeterminado del **render quantum** es 128, aunque puede modificarse.&#x20;

El **hilo de renderizado** de un `AudioGraph` está controlado por un callback a nivel del sistema, que se invoca periódicamente a intervalos regulares. Las operaciones que se ejecutan de forma atómica en un hilo solo pueden realizarse cuando no hay otra operación en curso.

Durante cada llamada, el sistema procesa un **buffer de tamaño variable** medido en **frame de muestra**, que debe calcularse antes de que llegue el siguiente callback. Por cada callback, se calcula un valor de carga dividiendo el tiempo de ejecución entre el tamaño del búfer.

El concepto de *callback* y valor de carga no aplican a `OfflineAudioGraph`.&#x20;

{% hint style="info" %}
El tamaño del **render quantum** determina la latencia y estabilidad del sistema: valores menores reducen el retardo pero aumentan la demanda de **CPU**, mientras que bloques más grandes mejoran la eficiencia a costa de una mayor latencia.
{% endhint %}

#### **Rendimiento**

La calidad de la experiencia depende de la baja latencia y ausencia de interrupciones.

La **latencia** es el retraso entre un evento de entrada y la percepción del sonido, y resulta de la suma de factores como la latencia del dispositivo de entrada, el buffering, el procesamiento, la latencia del dispositivo de salida e incluso la distancia física a los altavoces.&#x20;

Los **glitches de audio** —*chasquidos o pops audibles*— son fallos que interrumpen el flujo continuo de sonido. Pueden originarse por problemas en los hilos de audio *(como latencias)* o por una carga de procesamiento que excede la capacidad de la CPU.&#x20;

Ambos problemas requieren **optimización** para garantizar estabilidad

{% hint style="info" %}
En audio de **tiempo real**, *baja latencia y estabilidad* deben equilibrarse. Reducir la latencia mejora la respuesta, pero aumenta el riesgo de glitches si el procesamiento excede la capacidad del **CPU**. Será importante mantener un balance mediante *planificación* y *control preciso.*
{% endhint %}
