Sonido en vivo

Latencia: el enemigo oculto en tus directos

Mesa de mezclas audio

Latencia es tiempo. Cuando debemos escuchar algo pero lo hacemos más tarde, tenemos latencia, así de simple. La latencia es un no tan nuevo pero desconocido, casi invisible y peligroso actor que se ha hecho protagonista con la inclusión de las tecnologías digitales. Nuestros compañeros del estudio de grabación dicen que lo conocen y bien, tratan de controlarlo de todas las maneras posibles: tienen tiempo. En realidad, invierten grandes cantidades de dinero en hardware específico que, justamente, abandera la baja latencia como claro elemento de juicio de compra, pero ¿qué pasa en el mundo del directo? ¿Es que no tenemos latencia? Claro que sí.

Existe latencia (o retardo) en toda conversión A/D y D/A: en toda. En los estudios el principal quebradero de cabeza es conseguir que si hay diferentes convertidores con latencias distintas, las señales lleguen exactamente en el mismo momento —difícil, pero no imposible—. Hay que elegir y, normalmente, supeditar los resultados a los límites que justamente la latencia impone (por ejemplo, utilizar diferentes previos analógicos pero un mismo convertidor A/D multicanal, retardarlo todo al valor más crítico o ajustarlo manualmente tras cada grabación). En directo este problema queda más o menos resuelto al utilizar exactamente el mismo convertidor en todos los canales de entrada y salida, por lo que la latencia será exactamente la misma para absolutamente todos los canales… en principio.

La latencia se suele medir en muestras (samples). Así, si sabemos que los convertidores de nuestro equipo presentan una latencia de 512 samples, podemos saber que, en el mejor de los casos, el retardo será de 0,023 s (multiplicamos por 2 esos 512 samples -entrada y salida- y dividimos el resultado por la frecuencia de muestreo que se utilice; por ejemplo, 44,1 kHz). 0,023 s o 23 ms ¿Son muchos o soportables? Depende.

Si realizamos una simple mezcla básica con ese dispositivo ya sabemos que lo que entre en la consola en analógico ‘saldrá’ 23 ms más tarde por su salida analógica. De ahí a un recinto acústico normal. 23 ms podríamos traducirlos como 9 metros, es decir, es como si comparándolo con una configuración analógica al 100 %, tuviéramos las cajas 9 metros por detrás. ¿Podemos mejorar esta latencia tan exagerada? Claro.

Los 512 samples que he utilizado en el ejemplo anterior suelen ser para ordenadores normales que se utilizan en un estudio de sonido. En realidad nuestra consola de audio para directo no es más que un ordenador pero específico para tareas de audio, por lo que las latencias de sus convertidores A/D y D/A son mucho menores. Como ejemplo, una simple medición nos permite comprobar que una Digico SD presenta sólo 0,09 ms de latencia entre SD Rack y local, mientras que en una CL5 la latencia alcanza unos nada menospreciables 1,98 ms en la propia consola (entrada/salida). ¿Problema resuelto? Claro que no.

Cada vez que entra en concurso un DSP o una parte de él, siempre, absolutamente siempre, se realizará con precisión la orden matemática a realizar, pero tal perfección tendrá como precio un nuevo retardo, una nueva latencia. Por ejemplo, en el caso de una Avid S3L-X, cada plugin que insertamos en cualquier canal añadirá, de facto, 2 samples de retardo por el simple hecho de ‘activar’ el rack de efectos, y 3 samples adicionales por cada uno de los slots utilizados. De hecho no son sólo 5 samples la latencia o retardo que se añadirá al canal, sino que cada plugin, en función de su cometido, tendrá un nuevo valor de latencia. Por ejemplo, el plugin Time Adjuster (aplica retardos de señal) añade 7 samples más. Eso quiere decir que si mi intención es retardar la señal 20 samples, en realidad tendré que ajustar el plugin para que sólo retarde 8 samples (8+7+2+3=20). Dichoso manual de usuario.

Pero, ¿qué ocurre si lo que quiero es hacer una compresión paralela de, por ejemplo, un bombo? Cojo el canal 1 que, procesado, lo envío a la salida máster, mientras que en el canal 2 añado el mismo bombo pero procesado diferente con el concurso de un plugin determinado. Como que es más complejo que el Time Adjuster anterior, su latencia es superior y, añadiendo los 5 samples que antes he mencionado, hacen que la señal una vez procesada me llegue al bus de salida máster 20 samples más tarde. Si la mesa trabaja a 48 kHz, esos 20 samples significan un retardo de 0,4 ms, es decir, 13,88 cm que podríamos traducir como la mitad de la longitud de onda de un tono de 1.250 Hz. ¿Lo véis? La suma de los dos canales provocará que, como mínimo, toda frecuencia de 1.250 Hz desaparezca. ¿Quién mezcla aquí: tú o la latencia? Teniendo en cuenta que tras el procesado ambas señales ya no son idénticas, los problemas que aparecen lo hacen en forma de phasing, atacando a más de una simple frecuencia.

Hay tres maneras de solucionar este problema. La primera es recurriendo a plugins que incorporen una opción de procesado paralelo, como el Pro Compressor de Avid. Tras ajustar la señal comprimida podemos sumarle al mismo tiempo la señal limpia y conseguir el mismo efecto de compresión paralela utilizando una combinación de señales coherentes en el tiempo. La segunda es utilizando la función de compensación de retardo (delay compensation), una prestación que no todas las mesas incorporan pero cuyo cometido es estar atentos a todos estos procesos que pueden provocar phasing y retardar (insisto: retardar) los canales correspondientes, pero sólo los canales correspondientes. A veces aceptaremos que el bombo y su compresión paralela (la suma de los dos canales) nos llegue 0,4 ms más tarde que la caja que no tiene compresión paralela (no dejan de ser sonidos diferentes), en vez de recurrir a la tercera opción: retardarlo todo, absolutamente todo, para que nos llegue tarde pero al mismo tiempo. Recordad que a esos 0,4 ms tendremos que sumarle los retardos correspondientes a las conversiones y otros procesados.

Esto es lo único que podríamos hacer, por ejemplo, con la Yamaha CL5. Recordemos que presenta una latencia media entre entrada y salida de 1,98 ms medidos en la misma mesa (no en un RIO, que alcanza retardos entre 3,06 y 4,06 ms según configuremos la red DANTE). El problema de esta consola es que no tiene compensación de retardo. Si nos sigue interesando insertar en el bombo en paralelo un compresor de su serie Portico tendremos un retardo añadido de 0,27 ms. Aunque es casi un 33% menos que en el caso de la S3L-X de Avid, lo único que tenemos es que el problema de phasing lo tendremos en una frecuencia más alta. Quizá no será un problema para un bombo al que no busquemos patada, pero imaginad una caja o, peor aún, las voces. Al no tener la posibilidad de poder mezclar ambas señales ni opción de Delay Compensation existe un truco muy viejo que es lo único que podemos hacer en este caso: utilizar un segundo slot e insertando el mismo plugin pero sin que actue y donde enviaremos todas las otras señales (o, como mínimo, el bombo que no tendrá compresión pero que deberemos mezclar con el comprimido). Puede parecer una buena noticia porque en realidad el tiempo perdido incluso es menor que en el ejemplo anterior, pero supone duplicar los recursos.

Las mediciones de latencia no son datos que habitualmente el fabricante ofrezca en sus especificaciones técnicas. Manteniéndonos en la CL5, cada vez que recurrimos a alguna de sus prestaciones añadimos más retardo a la señal (por ejemplo utilizar matrices o subgrupos). La inserción de un rack externo analógico sin duda alguna implica el concurso de dos convertidores digitales más (un primero D/A y un segundo A/D), lo que suma a nuestro canal unos vertiginosos 3,73 ms más de retardo. Si, además, lo que queremos insertar es algo como un Waves sin hardware específico, deberemos sumar la latencia de la conversión A/D y D/A de la tarjeta que utilicemos y, atención, todo el retardo de procesado que se añadirá en el rack virtual de Waves. Por algo será que Waves ofrece convertidores más rápidos y servidores específicos (más potentes y más rápidos). Aún sin el concurso de Waves, volvemos a lo de siempre: ¿son muchos esos 3,73 ms? Debes saberlo, calcularlo y empezar a entender el porqué a veces una mesa suena más “brillante” que otras: normalmente porque has realizado un procesado que, con esa mesa, no deberías realizar o, como mínimo, solucionar con antelación.

Pensemos, además, que esto mismo ocurre cuando después atacamos procesadores digitales: hay nuevos convertidores y nuevas latencias que van sumándose a nuestra cadena. Por eso empieza a ser relevante la interconexión digital que, aunque tampoco es la panacea, reduce no sólo los problemas de pérdida en las conversiones sino las latencias asociadas a conversiones D/A y A/D ya innecesarias.

R. Sendra
EL AUTOR

Con más de 20 años de experiencia en los escenarios, es técnico de sonido especializado en FOH. Trabaja para bandas nacionales e internacionales como técnico de mesa, y es productor técnico para diferentes festivales y grandes eventos. Kinosonik es su estudio de sonido basado en plataforma digital. Le gusta compartir y le encanta aprender.

¿Te gustó este artículo?
16
Comentarios
  • casquinha
    #1 por casquinha el 21/08/2017
    " ¿Quién mezcla aquí: tú o la latencia? "

    Genial.
    3
  • Miguel Muñoz
    #2 por Miguel Muñoz el 21/08/2017
    Nunca había pensado en eso! Muchas gracias, muy buen artículo!!
    1
  • AnthonyClass
    #3 por AnthonyClass el 21/08/2017
    del directo y lo que no es directo....
  • incluso
    #4 por incluso el 21/08/2017
    Great !
  • Inxu
    #5 por Inxu el 21/08/2017
    Buenísimo
  • Guille McDugan
    #6 por Guille McDugan el 21/08/2017
    Me resulta muy sorprendente que algunas consolas de esas características no cuenten con compensación de latencia sobre todo cuando hablamos de cadenas de plugins del propio sistema. Menudo despropósito.
    1
  • ivoR
    #7 por ivoR el 21/08/2017
    alguna alternativa software en lenguaje ensamblador que con los adecuados interfaces (RME Raydat p.ej.) entregan unas latencias mínimas, gestionando adecuadamente los plugins vst's:

    http://www.mixerinabox.com/index.php
    2
  • Alejandro
    #8 por Alejandro el 22/08/2017
    #7 por mucho ensamblador que se use o potencia de computación, si un efecto/plugin/x necesita leer 500 muestras para realizar su cálculo y entregarlas modificadas, aunque se mejore el tiempo de cálculo, sigue siendo imposible mejorar el de lectura porque es físicamente imposible. Sólo quedaría la opción de intentar encontrar un algoritmo que emplee menos muestras, pero esto puede ser imposible o puede afectar a la calidad del resultado.
    1
  • PFL
    #9 por PFL el 22/08/2017
    Parece que en cuestión de mesas digitales en directo no hay marcha atrás, tendrá que ser algo que mejorará con el tiempo cuando vayan saliendo procesadores más rápidos o quien sabe alguna otra tecnología superior. La versatilidad de una mesa digital en directo en incuestionable y aunque es un enemigo oculto como bien dice nuestro compañero Raúl, será cuestión de paciencia y al menos tenerla controlada.
  • R. Sendra
    #10 por R. Sendra el 22/08/2017
    Alguien escribió:
    Me resulta muy sorprendente que algunas consolas de esas características no cuenten con compensación de latencia sobre todo cuando hablamos de cadenas de plugins del propio sistema. Menudo despropósito.


    No es despropósito, sino solución de mercado. La compensación de latencia automática no es, de momento, económica o algo que pueda implementarse en todas las consolas. Para empezar, es necesario que exista bastante potencia de cálculo sin pérdida de otras prestaciones. En el caso de la CL5 (que es la que utilizo en este ejemplo), no deja de ser una consola de medio rango a la que le falta esta opción, mientras que la serie PM ya la incluye de serie. Las primeras AVID no tenían compensación completa.
  • R. Sendra
    #11 por R. Sendra el 22/08/2017
    Alguien escribió:
    aunque es un enemigo oculto como bien dice nuestro compañero Raúl, será cuestión de paciencia y al menos tenerla controlada.


    Ramon, no Raúl :)

    El uso de la tecnología numérica o digital presenta ventajas e impone inconvenientes, siendo la latencia una de ellas. Es así. El problema no es simplemente "saber" que hay latencia, sino convertirlo en un problema ya que de esta manera se sobreentiende que hay una solución (sino, sería simplemente un hecho). Es fácil calcular la latencia de nuestros canales y ponerle remedio. Nuestra formación como técnicos debe dar buenos resultados siempre.
    1
  • Andaluz De Este Pone
    #12 por Andaluz De Este Pone el 23/08/2017
    Sumamente interesante; pero, a la espera de que el autor o cualquier otro me enmiende, dudo que los convertidores ofrezcan latencias de tanta magnitud, no creo que llegan a magnitudes de milisegundos; serán los dispositivos de audio al conectarse con ordenadores, los propios equipos de directo digitales, sus añadidos (desconocía que se fueran sumando las latencias de los programas y procesos, aunque era de esperar).
    Pero los convertidores, que son vulnerables a muchos factores, al jitter, sobre todo hace años, no creo que puedan tener retardos tan largos; si no, equipos de muy baja latencia; pero convertidores, simplemente decentes, buenos; pero no excelsos, como las Pcie de RME, tendrían un cuello de botella en los convertidores que llevan para tareas secundarias o incluso más que eso .

    Y en el directo será igual, imagino.
  • abrahamsonido
    #13 por abrahamsonido el 23/08/2017
    ¡Hola! Como está escrito el artículo, da a entender que al usar cualquier compresor, ecualizador o puerta en un canal de la Yamaha , se produce un retardo, y esto no es cierto. En los compresores puertas y ecualizadores que incluye cada canal, no existe retardo al emplearlos, o si existe la mesa los compensa.
    Otra cosa es cuando utilizamos PLUGINS y los insertamos en un canal, ahí si se produce latencia. (0,29 ms me sale a mi) pero si no se emplea como en el ejemplo (compresión paralela) no supone un problema. Todos los canales de la Yamaha incluyen la posibilidad de añadir retardo, no es necesario emplear Slots ni agotar los recursos de la mesa. Se produce mucho más desfase por los diferentes tiempos de llegada de diferentes fuentes a un micro (monitores, side Fills, amplis a tope...) que por los 0,29 ms de un plugin. El empleo de cualquier ecualizador analógico produce un desfase más que notable. El desfase es algo del mundo del audio que ya existía en el audio analógico. El mundo digital arrastra esa característica, pero no debe suponer un problema si se conoce y se emplea correctamente. Aunque se comente que la CL es una "mesa de medio rango" por no poder compensar el retardo del uso de plugins (discutir esto seria muy largo) veo mucho peor las cientos de veces que se han colgado las Digico (sobre todo al principio, funcionaban sobre un Windows) costando 3 veces más Yamaha.
  • R. Sendra
    #14 por R. Sendra el 23/08/2017
    Alguien escribió:
    Como está escrito el artículo, da a entender que al usar cualquier compresor, ecualizador o puerta en un canal de la Yamaha , se produce un retardo,


    Exacto. Más aún: como está escrito el artículo, en toda mesa digital (sea o no Yamaha), hay latencia producida por el procesado digital de la señal y, si se utiliza, por la conversión A/D y D/A realizada. Hasta aquí vas bien. Lástima que luego dices que no es cierto, por que lo es. A diferencia de tus afirmaciones falsas, tendré que recurrir a hechos para demostrarlo y en el artículo está escrito: en el caso de una CL5 midiendo local el retardo in-out es de 1,98 ms. Esta latencia es la que puedo medir y comprende la suma de la latencia producida por los dos conversores (A/D y D/A), más todo el procesado implícito de un canal (ecualización, dinámica, etc.). En el artículo se aportan datos.

    Alguien escribió:
    o si existe la mesa los compensa.
    ¿En qué quedamos? ¿Hay o no retardos? Evidentemente que los hay pero en el caso de la Yamaha CL5 no se compensan. Aquí los datos a los que puedes hacer referencia son los propios que Yamaha informa en su (atención) ¡manual de usuario! Donde en ningún caso habla de compensar latencia alguna.

    Alguien escribió:
    Otra cosa es cuando utilizamos PLUGINS y los insertamos en un canal, ahí si se produce latencia. (0,29 ms me sale a mi) pero si no se emplea como en el ejemplo (compresión paralela) no supone un problema
    .

    Primer punto: sí, como dice el artículo, la inserción de cualquier plugin implica, no sólo en la Yamaha sino implícitamente en casi cualquier consola digital, una nueva latencia. Cada plugin en función de su cometido tendrá más o menos retardo por lo que en tu caso los 0,29 ms serán causados por el tipo/modelo de pluguin utilizado. También en el artículo creo (y sólo creo) que se explica bien que si un canal llega, por ejemplo, 0,29 ms tarde y no hay compresión paralela, quizá no ocurra nada, amén, evidentemente, que ese canal nos llegue 0,29 ms más tarde que el resto. El quid era encontrar una solución EFICAZ cuando necesitamos realizar ese tipo de procesados paralelos.

    Alguien escribió:
    Todos los canales de la Yamaha incluyen la posibilidad de añadir retardo, no es necesario emplear Slots ni agotar los recursos de la mesa.


    Es una solución, claro, pero bajo mi perspectiva algo ineficaz. Primero porque tendrás que calcular (y eso resulta tedioso) por cada plugin el retardo de cada canal; siempre y cuando no utilices un canal para compresión paralela enviando la señal desde un BUS, ya que entonces lo que harás es retardar ambas señales y no "compensar" el canal retardado. No he visto (lo que no quiere decir que no exista) a ningún técnico de PA medir ni en las pruebas ni aún menos a medio bolo las latencias de cualquier plugin insertado.

    Alguien escribió:
    El desfase es algo del mundo del audio que ya existía en el audio analógico.


    Sí, pero aquí hablamos de ... LATENCIA. Ya hablaremos algún día de la fase. Te contaré otra cosa: incluso cuando utilizas algún plugin de ecualización gráfica tienes desfases. Más aún: no sólo tienes problemas de fase con la contaminación de audio en diferentes micrófonos sino también problemas de .... exacto ... ¡retardo!

    La última parte la omito siendo simplemente una opinión tuya que, sinceramente, criticar las Digico por algo que no tiene que ver con esto...

    Un saludo
  • R. Sendra
    #15 por R. Sendra el 23/08/2017
    Alguien escribió:
    Pero los convertidores, que son vulnerables a muchos factores, al jitter, sobre todo hace años, no creo que puedan tener retardos tan largos; si no, equipos de muy baja latencia; pero convertidores, simplemente decentes, buenos; pero no excelsos, como las Pcie de RME, tendrían un cuello de botella en los convertidores que llevan para tareas secundarias o incluso más que eso .


    Carmelo, no he medido el retardo exacto de un solo convertidor (sería una tarea mucho más arduosa) sino el compendio entre el conjunto que forma un canal procesado: AD-procesado digital-DA. No conozco los futuribles, pero sí algunos actuales. Lo que es fácil de ver es que hay modelos más lentos que otros y que la tecnología avanza a un ritmo competitivo. Repito algunas de las mediciones realizadas:

    - Yamaha CL5 en local: 1,98 ms
    - Yamaha CL5 OMNI IN a RIO Out (Dante 0,5): 2,5 ms (añade 0,52)
    - Yamaha RIO IN a RIO OUT (Dante 0,5): 3,06 ms (añade 1,08)
    - Yamaha RIO IN a RIO OUT (Dante 1): 4,06 ms (añade 2,08)
    - Digico SD9 en local: 2,23 ms
    - Digico SD9 IN local salida Digirack: 2,35 ms
    - Digico SD9 IN/OUT en Digirack: 2,44 ms
    - Digico SD12 local vs rack (48 kHz): 0,04 ms
    - Digico SD12 local vs rack (96 kHz): 0,06 ms

    Aquí es fácil ver cómo hay un salto significativo entre el procesado de la SD12 contra la de la SD9, lo que en cierta manera confirma tus comentarios: cada vez es más fácil encontrar valores de latencia mucho más bajos. ¡Perfecto! Pero mientras creo que es algo que debamos tener en cuenta y convivir con ello.

    Un saludo
  • Andaluz De Este Pone
    #16 por Andaluz De Este Pone el 23/08/2017
    ¿Pero puro de los convertidores o del conjunto audio convertido/ proceso digital posterior?, es que pensaba que un convertidor podía tener nanosegundos de retraso; pero, según esto, ya sean lavry, o lo que sean, son retrasados a carta cabal.

    He alucinado bastante con las estrategias que usáis para compensar.
  • Andaluz De Este Pone
    #17 por Andaluz De Este Pone el 23/08/2017
    Ah, que también señalas que es la suma de todos los convertidores
  • R. Sendra
    #18 por R. Sendra el 23/08/2017
    Alguien escribió:
    ¿Pero puro de los convertidores o del conjunto audio convertido/ proceso digital posterior?, es que pensaba que un convertidor podía tener nanosegundos de retraso; pero, según esto, ya sean lavry, o lo que sean, son retrasados a carta cabal.


    Del conjunto que forma el previo, convertidor, todo el procesado de canal y vuelta a otro convertidor y previo. Es muy difícil medir sólo el convertidor sin desmontar la mesa, pero el cálculo de otros parámetros (que no he publicado) como puede ser el retardo que aparece cuando, además, incluimos el paso de la señal a través de una matriz (0,12 ms más) nos induce a pensar que efectivamente los convertidores, aunque poco, pero multiplicado por dos, ofrecen latencia. En realidad, como operadores de mesa nos importa el conjunto, no la particularidad.

    Alguien escribió:
    He alucinado bastante con las estrategias que usáis para compensar.


    Los problemas existen porque hay soluciones, sino serían simples hechos :)

    Un saludo
  • Andaluz De Este Pone
    #19 por Andaluz De Este Pone el 23/08/2017
    Qué bien escribes Sendra.
    1
  • abrahamsonido
    #20 por abrahamsonido el 23/08/2017
    A lo que me refería con el comentario (seguramente me expresé muy mal) es que al activar los procesadores de cada canal , estos no suman más retardo del que ya tiene la mesa en cuestión (en este caso la Yamaha, que es con la que hice la prueba). Es decir, como bien comentas hay un retardo por las conversiones de salida y entrada siempre, pero quizá alguien puede entender que al activar el compresor de un canal se añade más todavía. La latencia que comentas (desde la entrada a la salida) es la misma este o no activado el proceso del canal (eso es lo que yo medí).
    Ahora bien, los plugins de la Yamaha en concreto, añaden más retardo al canal en cuestión en el que estén insertados.

    Tienes razón en cuanto a que una cosa es la latencia, y otra cosa es la fase.
    Pero en el ejemplo que mostrabas, nos hacías ver que debido a la latencia que produce el plugin en cuestión, genera cancelaciones al sumar dos señales iguales en diferente tiempo.Y eso es un problema de fase que produce un filtro peine, o así lo entiendo yo.

    Gracias por el artículo , ya que me ha llevado a cacharrear un rato y conocer mejor los aparatos con los que trabajamos todos los días, y creo que no hay nada más provechoso, divertido y útil.

    Un saludo y feliz verano (o lo poco que queda).
  • ivoR
    #21 por ivoR el 31/08/2017
    #8 por mucho ensamblador que se use o potencia de computación, si un efecto/plugin/x necesita leer 500 muestras para realizar su cálculo y entregarlas modificadas, aunque se mejore el tiempo de cálculo, sigue siendo imposible mejorar el de lectura porque es físicamente imposible. Sólo quedaría la opción de intentar encontrar un algoritmo que emplee menos muestras, pero esto puede ser imposible o puede afectar a la calidad del resultado.

    Desde luego que el número de muestras que necesite leer el plugin influirá en la latencia final pero no todos los plugins necesitan la misma cantidad, (fabricantes como waves dan información sobre la latencia de sus plugins: en algunos declaran 0 samples!. Además de ese "tiempo de lectura" que según dices es imposible de mejorar supongo que ya cuentas con un ajuste óptimo de buffer y frecuencia de muestreo del DAW. Pregunto: En qué medida influye la programación del DAW, el tipo de interface, el driver (controlador) del mismo, el procesador del ordenador..... ademas del tipo y número de plugins que tengamos insertados?

    El sistema SAC que menciono sólamente utiliza aquellos vst's que arrojan una latencia 0 (o próxima a 0 sospecho) descartando los otros. Las pruebas que he podido realizar con este sistema (con interface digiface de RME), varios canales (entre 16 y 24) con proc dinámico (el nativo) en todos ellos y en varios con plugs de waves y sonnox, entregaba una latencia en monitores entre 4 y 4,6 ms (dependiendo del ajuste de buffers), medida con smaart. Otros usuarios con mayor experiencia y equipo, relatan latencias próximas a los 3 ms. Algunos músicos pueden estar afectados por ese "desfase" que con la dosis adecuada de reverb se aminorará bastante...

    Desconozco el comportamiento de sistemas como Digigrid+Soundgrid (DSP`S) de waves (que anuncia 0,8 ms de latencia), Qsys, Sysnet, o las interfaces UAD. La plataforma creamware pulsar (ahora Sonic Core) tb con dsp's también tiene unas latencias muy bajas pero todos ellos son sistemas "cerrados" con sus plugs (como las mesas digitales). La "gracia" de sistemas como el SAC o el AMP es que pueden utilizar VST's...