Inxu escribió:
Entonces por todo lo leído entiendo que el sistema de Waves soungird servers realmente no es un sistema dsp...... es ¿una adaptación a través de un firmware especifico?
No es un sistema DSP en tanto que no corre en chips DSP. Pero es un sistema DSP en tanto a que es un sistema de
Procesamiento Digital de Señales, cuya finalidad es procesar audio digital.
Inxu escribió:
¿como se lo ha montado waves para hacer que los servidores vuelen con una latencia de 0.8ms?
No lo sé. Si los 0.8 ms fuese la medición de tiempo que tarda en enviar y recibir audio sería entendible (incluso con 128 pistas), ya que el audio es digital y no hay conversiones por medio, y siendo el driver liviano y corriendo el mínimo de procesos en el servidor se obtienen esos resultados.
Pero lo que me maravilla es que el 0.8 ms es sumando además el procesamiento de esos 128 canales (o al menos eso dicen) .
Con esto te puedes hacer una idea de la optimización de SoundGrid.
Está claro que, en gran medida, se logra porque en el servidor SoundGrid no existe ningún SO como los que utilizamos en nuestros ordenadores, ni hay que ejecutar ningún DAW, etc., es decir, que el servidor SoundGrid sólo se encarga de procesar el audio.
Lo que no acabo de entender es qué tienen los plugins de Waves (y
algunos más) que son los únicos que se pueden ejecutar en estos servidores por el momento.
Inxu escribió:
después de bastantes años ¿aun compensa el uso de esos procesadores tan especificos frente a las cpu?.
Es que no puedo evitar pensar en que mi i7 de 4 generacion esta tirando de sistema operativo, del Daw, y de una carreta de plugs y ahi esta el puñetero, que me fulmino todo el rendimiento que es capaz de darme el DAW y la cpu sigue marcando que esta trabajando al 50%........
Es que... como se ha comentado, no es la potencia de proceso lo que cuenta en este caso (las CPU's ganan por goleada) sino
la manera en cómo se procesa. (
#85 )
Imagínate una pista de audio a 44.1 kHz la cual ha sido grabada sincronizado con un mal reloj, es decir, que esas 44100 "rebanadas" no están cortadas iguales. No lo notarás, pero ese audio no está "clavado". Hagamos lo mismo pero con un montón de pistas más... muchas... (a 44.1 también) con distintos relojes, nos encontramos con microscópicas variaciones entre todas ellas. Variaciones que no las vamos a notar en un principio. Y digo en un principio porque si esa misma grabación la realizamos sincronizando todo a un mismo reloj y ese reloj es muy preciso ("rebanadas" iguales), entonces la diferencia entre ambas grabaciones saldrá a relucir.
Pongo el ejemplo de las "rebanadas" como si fueran esas instrucciones de reverb en el ejemplo de
#85 , las cuales llegan no siempre dentro del mismo intervalo de tiempo a procesarse en la CPU (por procesarse ésta "en serie" junto con demás procesos internos).
Como he comentado, con poco trabajo (pocas pistas) no se nota, pero si se le mete carga y se aumenta el número de procesos (instrucciones correspondientes a diferentes procesos) es cuando puede salir a la luz el "microscópico descuadre" y perder algo de nitidez.
Si aumentamos el número de "rebanadas" (192 kHz) esas pequeñas micro variaciones se van a hacer menos notorias en el tiempo. La analogía en CPU sería similar a disponer de una moderna CPU multinúcleo, la cual minimiza el tiempo entre instrucciones y la cual, gracias al multihilo es capaz de ejecutar varias en el mismo instante. Pero, aún acercándose al procesamiento DSP (en "paralelo" por el multihilo) cada hilo por sí solo procesa "en serie" con los consiguientes "microscópicos descuadres".
Si además de la propia arquitectura de procesamiento (en "paralelo" y "en serie") tenemos en cuenta la precisión (longitud de palabra o número de bits) tenemos que hay más resolución interna en un DSP (el ejemplo de Scope eran 80 bits) que en una CPU, cuya mantisa son creo 52 bits (en los DAW's cuyo audio engine es a 64 bits).
Son casi 30 bits más de precisión. Nada despreciable (o sí... vete tú a saber
).
Un saludo.