Edirol UA-25+VMWARE+MacMini (para Wynton y otros...)

DRC y todo lo relacionado con el tema
jotap_66
Mensajes: 98
Registrado: Mar 08 Ene 2008 , 18:41

Mensaje por jotap_66 »

mou escribió:El problema de poner la latencia en high es que aumentas la latencia (perogruyada al canto).
No...no...Sin saber como esta hecho el DRCOP, me ateavo a aventurar que lo que dices no es correcto....

Cuando tocas ese parametro en el Jackd, lo que haces es decirle al Jackd que tu equipo tiene una latencia alta, pero en nigun caso aumentas la latencia...TU no decides la latencia...sino que esta es la que es, en funcion de una serie de factores...Hard, soft...etc....



Respecto lo del DVD..que comentas Marcelo......Me he perdido..No entiendo muy bien la pregunta ¿La latencia del DVD es alta o baja pero respecto a que?

Respecto de poner una latencia alta al DRCOP...Si antes con la media te iba bien, hacerlo con la alta no tiene ninguna ventaja...Bueno, mas bien desventaja (aunque no mucha)...Va a gastar algo mas de memoria para los buffers...pero nada mas....

La gracia de la posibilidad de ajustar en DRCOP ese parametro, es poder poner una latencia alta, en equipos que sean lentos....

Saludos

JP


Saludos

JP
Avatar de Usuario
Klaatu
Mensajes: 2323
Registrado: Mié 23 Ene 2008 , 12:36
Ubicación: En la trinchera, pasando revista

Mensaje por Klaatu »

Hola otra vez, Nacho. Justamente ayer comentaba con el técnico que eso es lo único que nos quedaría por probar una vez cambiada la pasta térmica, pero no me encaja porque el lapso de tiempo en que jackdaemon cae se repite casi milimétricamente (por lo que sigo pensando en temperatura)

Por cierto me comentó que a su modo de ver el montaje del disipador no estaba bien resuelto. Bueno, también es cierto que los otros que se trajeron desde los USA no poblemo, así que tampoco debe ser el problema.

Ahora bien, si no hay cambios con la Quata y el problema persiste, lo siguiente - y ya último- será probar con otro módulo de memoria. Y de ahí en adelante, pues nada, carpetazo al asunto y buscar otro barebone o portátil.

Saludos, gracias
Barada Nikto
http://www.youtube.com/watch?v=sIaxSxEq ... re=related

Que se jodan Andrea Fabra y todos ellos
Avatar de Usuario
Alf
Site Admin
Site Admin
Mensajes: 5730
Registrado: Jue 23 Oct 2003 , 12:08
Contactar:

Mensaje por Alf »

Klaatu escribió:Hola otra vez, Nacho. Justamente ayer comentaba con el técnico que eso es lo único que nos quedaría por probar una vez cambiada la pasta térmica, pero no me encaja porque el lapso de tiempo en que jackdaemon cae se repite casi milimétricamente (por lo que sigo pensando en temperatura)


Saludos, gracias
¿y si pones un ventilador?, aunque sea externo, de los de toda la vida cuando hace calorcillo. Aunque sólo sea para probar y descartar, o no, que sea la temperatura el origen de tus problemas.

Saludos

Alf
Avatar de Usuario
Klaatu
Mensajes: 2323
Registrado: Mié 23 Ene 2008 , 12:36
Ubicación: En la trinchera, pasando revista

Mensaje por Klaatu »

Hola Alf. No te pienses que es ninguna tontería, también estaba en la lista de cosas "para probar por probar".

Pero es más efectivo regularlo en la Bios, y, efectivamente, al regular el corte por temperatura más abajo ( 60 º) se ha notado, vamos, que al meterle el torture test con el corte a 60 º se apagaba antes que con él a 70º.

De hecho, al instalarlo en el rack jackdaemon ha caído antes que cuando estaba con más espacio para respirar. Blanco y en botella.

Y de ahí lo de probar con otra tarjeta, así se descartan incompatibilidades y probando con otra memoria volvemos al mismo punto (temperatura) En fin, como ya se dijo, poco a poco y sin correr. Ya queda menos.

Saludos
Barada Nikto
http://www.youtube.com/watch?v=sIaxSxEq ... re=related

Que se jodan Andrea Fabra y todos ellos
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

Más o menos los comentarios que haceis sobre latencia van enfocados pero hay cosas que puntualizar.

¿Qué es un entrecortado de sonido? Una "rotura de stock". Tú me pides y yo no tengo nada que darte. Como no me puedes esperar te vas sin nada.

¿Qué tiene que ver la "latencia" en todo esto? pues cómo dice jotap, en términos prácticos latencia equivale a buffer. Y el buffer es el stock, a más buffer, menos riesgo de "rotura de stock". Pero más latencia.

Imaginemos un bus de datos como una cadena humana que se pasa los datos de mano en mano. El óptimo de esta cadena es que todos trabajen al mismo ritmo, pasándose los datos de mano en mano a golpes del mismo reloj.

Supongamos una placa de PC como un sistema de cadena humanas conectadas todas entre si en una persona que es capaz de recoger y enviar datos a una velocidad más alta que la de cada una de las cadenas.
De esta forma, esa persona (la CPU) puede ir trasegando datos atendiendo a todas las cadenas. Pero..... por muy rápido que sea el procesador, nada te garantiza que no se "rompa stock" en una cadena en un momento dado. Lo vemos...

¿Cómo hace el trasegador central de datos? Pues se gira a recoger el dato del que le llama (eso son las interrupciones de sistema, IRQ's) mira para que otro bus es y se lo entrega al otro. ¿Qué ocurre si dos personas le llaman a la vez? Pues solo podrá atender a uno, el primero en una lista, el más cercano, el más guapo.... el criterio puede ser cualquiera.

No hay problema porque este procesador central recoge a una velocidad muy alta y le daría tiempo... salvo que vea que ese dato es para una cadena humana que acaba de recoger otro dato y que va a tardar un rato en darse la vuelta y recoger el nuevo, porque va más lento que el procesador y a lo mejor incluso que el resto de cadenas.

En esta situación el procesador se queda clavado con el dato en la mano esperando que la persona a quien se lo tiene que entregar se de la vuelta y lo recoja. ¿qué pasa con la segunda entrega pendiente? Qué se retrasa, porque nuestro procesador es muy rápido, pero su cesta solo permite llevar un paquete de un sitio a otro y solo le llaman para entregar, el no puede llamar a nadie a recoger, no le van a hacer caso.

Supongamos que esta segunda entrega es para una cadena que no puede esperar (un flujo multimedia) y su cadencia de entregas es fija, no es muy rápida pero es fija. Si se le acumulan retrasos, llega un momento en que no hay nada que entregar al final de la cadena. Rotura de stock.

Bueno, pues imaginemos ahora que organizamos que la cadena humana de multimedia haga una cosa: que pueda trabajar a doble capacidad, con un deposito de dos datos cada golpe de reloj. Aunque la entrega final será de uno en uno.

¿Cómo trabaja esa cadena? En origen estará capacitada para entregar dos datos cada vez: si el depósito de entrega tiene libres la dos posiciones, entregará dos, si solo tiene una entregará una. Generalmente entregará solo una y solo habrá dos huecos cuando haya habido un retraso. De esta forma, esta cadena entrega datos a cadencia esperada y soporta retrasos iguales a esa cadencia de tiempo, puesto que tiene una reserva de ese tamaño.

La CPU no tiene problema, ella trabaja de uno en uno pero muy rápido, no es el cuello de botella por si misma si no por ser punto de cruce de otras cadenas.

¿Cual es el precio a pagar? Pues que el retraso en la entrega de datos crece porque le sumamos esa citada cadencia de tiempo.

Eso es lo que hace jackd, gestiona, para todos los elementos enganchados a servicio de sonido, un sistema de intercambio de datos a base de depositos y, además, con tamaño de datos variables. Nosotros lo configuramos de acuerdo a nuestras necesidades.

De esta forma el DAC de la tarjeta de sonido, que va a piñon con la frecuencia de muestreo, tendrá menor probabilidad de tener la cesta de datos vacia.

¿Cuando es importante la latencia? Pues en entornos profesionales de grabación cuando la señal de entrada/salida de la tarjeta de sonido tiene que ir sincrónizada con el sonido directo. Por ejemplo, cuando graban a un grupo donde se escuchan los unos a los otros a través del retorno por auriculares. Ese retorno tiene que tener un retraso mínimo o los músicos perderían el compás, literalmente.

¿Por qué en linux hay que "tunizar" el kernel para poder ir a latencia baja (buffers pequeños) sin cortes de sonido? Pues por el problema del criterio con el cual la CPU va a atender a dos llamadas simultaneas de dos buses. El tunning consiste en que podemos dar prioridades arbitrarias a las llamadas (IRQ's) en función de nuestras necesidades. Le podemos obligar a la CPU a que atienda preferentemente al bus (PCI, USB, firewire) donde tenemos nuestra tarjeta. En DRCoP, aunque está preparado para ello, no ha hecho falta pasar a ejecutar ese "tunning".

¿Por qué VMWare necesita más latencia? porque las "cadenas" de los buses en su caso (máquina virtual) no son reales (hardware) si no virtuales (software) y eso les hace perder velocidad. Una vez más, cómo puede desprenderse de la analogía, no es crítica la velocidad de la CPU en este caso, un bus muy lento hace lento a un ordenador. O lento y con un uso excesivo (por ejemplo cuando ocupamos toda la memoria física y pasamos a necesitar memoria virtual en disco, la velocidad del sistema cae en picado).

Marcelo, la latencia de un DVD es "cero" porque no tiene entrada, solo salida. Latencia es la diferencia de tiempo entre entrada y salida (en promedio). El jitter es la desviación estadística de esa latencia.
El DAC del DVD si tiene latencia y jitter. Nosotros, desde fuera, solo vemos el jitter (desviación estadística sobre latencia "cero").
Avatar de Usuario
Klaatu
Mensajes: 2323
Registrado: Mié 23 Ene 2008 , 12:36
Ubicación: En la trinchera, pasando revista

Mensaje por Klaatu »

No quiero ser el que anda poniendo el último punto, pero no puedo reprimirme. No basta con saber, hay que saber explicar. Soberbio. De verdad.

Saludos
Barada Nikto
http://www.youtube.com/watch?v=sIaxSxEq ... re=related

Que se jodan Andrea Fabra y todos ellos
jotap_66
Mensajes: 98
Registrado: Mar 08 Ene 2008 , 18:41

Mensaje por jotap_66 »

Hola:

Chapeau

Es imposible explicarlo mejor Wynton....


En el caso del VMWARE FUSION....el problema es mas de la cantidad de capas hard y soft...que de capas de emulacion...En realidad por poner un ejemplo con la CPU, esta no es emulada, ya que es la misma, en ambos casos es Intel....

Es decir, el hardware fisicamente es el mismo, pero claro, todo el tema de adaptar una unica aplicacion Mac (el VMWARE) para que funcione como si fuera un PC de verdad, es lo que hace que la latencia sea tan alta....

Lastima, porque todo lo demas funciona perfectamente...Incluso, tengo ya los filtros generados con VMWARE....Para abreviar el proceso, pedire un portatil por aqui...y cuando tenga mi configuracion ya afinada...usare un convolver en Mac (que he visto por ahi alguno)...

Saludos

JP
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

Ah! Coño que lo del DVD era de cachondeo. :? :?
mou
Mensajes: 108
Registrado: Dom 27 Nov 2005 , 18:47

Mensaje por mou »

Lo del dvd si, pero lo de las latencias no, y creo que lo has aclarado bastante bien.

Lo que no me acaba de quedar claro es si aún aumentando la latencia en jackd, al ejecutarse en la máquina virtual, afectará al proceso de medición (supongo que durante la ejecución del sweep y su grabación simultánea sería ideal una latencia 0, y aunque no se aprecie a oido, cualquier pequeño retardo afectaría después a la generación de los filtros, con lo que los resultados pueden ser... regulares :lol: ).

Evidentemente, sólo son suposiciones mías, que de esto ni idea. Por suerte en este foro hay gente que entiende mucho... Un saludo,

Nacho
Avatar de Usuario
Marcelo
Site Admin
Site Admin
Mensajes: 5681
Registrado: Mar 08 Mar 2005 , 18:08
Ubicación: Vigo
Contactar:

Mensaje por Marcelo »

wynton escribió:Ah! Coño que lo del DVD era de cachondeo. :? :?
Claro, estaba entre la solución "latencia" y la tradicional (con un par de ostias los crios se callan también).... :lol:

nuevamente, gracias por la explicación. Quedó claro el tema, aún así, me queda (si ya lo explicastes, lo siento, ya me conoces) por entender si poner la latencia en "high" en DRCoP puede incidir sobre los cuelgues ocasionales. Sigo probando en "high" y pinta cojonudamente bien. No hay cortes de momento. Si tiene o no que ver, es lo que o no entendí o no concretastes.

slds, marcelo
"Uno es dueño de lo que está dispuesto a perder. De lo demás es esclavo."
mou
Mensajes: 108
Registrado: Dom 27 Nov 2005 , 18:47

Mensaje por mou »

Pues en general, no hay que tocar para nada ahí. Si te va bien en normal (como debe ser con cualquier equipo medianamente moderno), déjalo estar. No creo que vayas a notar ninguna diferencia.

Ya sabes, si funciona, no lo toques (regla de oro :D )

Por cierto, la solución tradicional puede acabar con el cuándo llegamos, pero después vienen los llantos desconsolados, no sé que será peor... :twisted:
jotap_66
Mensajes: 98
Registrado: Mar 08 Ene 2008 , 18:41

Mensaje por jotap_66 »

mou escribió:L

Lo que no me acaba de quedar claro es si aún aumentando la latencia en jackd, al ejecutarse en la máquina virtual, afectará al proceso de medición (supongo que durante la ejecución del sweep y su grabación simultánea sería ideal una latencia 0, y aunque no se aprecie a oido, cualquier pequeño retardo afectaría después a la generación de los filtros, con lo que los resultados pueden ser... regulares :lol: ).

Evidentemente, sólo son suposiciones mías, que de esto ni idea. Por suerte en este foro hay gente que entiende mucho... Un saludo,

Nacho
Pues no estoy seguro, tendria que medir con PC y Mac a la vez...pero al menos la curva que ha salido es normal...Yo creo que no influye porque el sweep es tan corto que no se llega a vaciar el buffer...Al menos yo no lo oigo entrecortado...como el sonido de test (el de las trompetas que a veces lo oigo entrecortado y a veces no...)....

Saludos

JP
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

La explicación anterior, como todos los símiles (especialmente los de coches) tienen un margen de validez pequeño. Básicamente se trata de entender el concepto de buffer y latencia y su necesidad.
Luego en realidad un PC, una IRQ y un bus son algo bastante más complejo. Sobre todo su gestión.
mou escribió: Lo que no me acaba de quedar claro es si aún aumentando la latencia en jackd, al ejecutarse en la máquina virtual, afectará al proceso de medición (supongo que durante la ejecución del sweep y su grabación simultánea sería ideal una latencia 0, y aunque no se aprecie a oido, cualquier pequeño retardo afectaría después a la generación de los filtros, con lo que los resultados pueden ser... regulares :lol: ).
Ahí cambiamos de nivel. Digamos que en DRCoP estamos en tres niveles:

1- El hardware y su gestión para tener flujos de audio continuos.

2- El software y su gestión para interconectar los programas que usamos y disponer, entre ellos, un intercambio fluido de audio ("buffers" software). Luego comentaré algo al respecto.

3- El sentido (psico)acústico de lo que hacemos con los citados programas. Ahí entramos en el terreno de las medidas, la creación de filtros y su aplicación por convolución. Esta parte es la que no depende del Sistema Operativo.

¿Cuantos retardos tenemos en el proceso de medida? Pues hay uno por cada paso salida a entrada. Contemos:

1- El que va desde que el programa de emisión del sweep envia la señal al gestor jackd. Configurable.

2- El que va desde que jackd envia la señal al controlador de la tarjeta de sonido. Configurable e idéntico al 1.

3- El interno de la tarjeta hasta que el sonido sale al amplificador por salida de línea. Incontrolable por nosotros.

4- El paso de la salida de la tarjeta hasta los altavoces. Intrascendente.

5- El camino (distancia) que hay desde los altavoces hasta el micrófono que recoge la señal.

6- El tiempo de vuelta desde el micrófono hasta la entrada de la tarjeta de sonido. Intrascendente.

7- Retardo interno de la tarjeta de sonido (el ADC, el controlador). Incontrolable.

8- El tiempo que tarda jackd en recoger el sonido entregado por el bus al que se conecta la tarjeta. Configurable e igual al de 1.

9- El tiempo que tarda jackd en pasar la señal al programa que registra lo grabado. Configurable e igual al de 1.

1, 2, 8 y 9 son del nivel 2 (software).
3, 4, 6 y 7 son del nivel 1 (hardware)
5 es de nivel 3 (posición del micrófono adecuado al uso que hacemos de DRCoP).

El método de medida es insensible a los retardos tal cual luego calculamos los filtros. Me explico:

Una medida de retardo cero entre salida/entrada nos producirá (tras el procesado) un impulso con su pico máximo a T/2 exáctamente, siendo T el tamaño del sweep.

A partir de ahí, a la aparición de un retardo t, se alejará el pico del impulso de T/2 exactamente ese retardo. Pero la información del impulso será la misma, puesto que el método de medida (hasta donde nos interesa) es LTI (linear e INVARIANTE CON EL TIEMPO[*]).

Si en el proceso se mide simultaneamente un bucle de salida/entrada de la tarjeta (algún purista pone el bucle en la salida de altavoces del ampli), que no presenta el retardo 5, hay formas de eliminar de la medida acústica todos los retardos menos el 5 y de esta forma poder conocer la distancia altavoz a micrófono (tiempo multiplicado por la velocidad del sonido).

[*] Un proceso LTI es aquel que ante la entrada de una combinación lineal (sumas y multiplicaciones por constantes) de varias señales, produce una salida que es combinación lineal de las salidas producidas por cada señal de entrada individualmente. No hay interferencias entre ellas.

Y que ante el retraso en la entrada de una señal, la salida es idéntica salvo que se retrasa ese mismo tiempo.
jotap_66
Mensajes: 98
Registrado: Mar 08 Ene 2008 , 18:41

Mensaje por jotap_66 »

Hola:

Evidentemente...tal y como lo expones el metodo de medida es insensible a los retardos, pero la emision del sweep podria ser que no lo fuera (creo que es el paso 2)...Me explico:

La emision del sonido, por ejemplo el de los test..con la trompeta...es sensible (o al menos yo lo noto) porque el sonido sale entrecortado (pero no siempre, me imagino que esta en el limite)...Supongo que todo el sonido no cabe en la tarjeta de sonido, y se corta....Se producen menos cortes cuando coloco la latencia del Jackd a HIGH....

En cambio, parece (o al menos eso me dicen mis oidos) que el sweep, es tan sumamente rapido, que si cabe, y no es necesario el uso del buffer No noto nigun corte... De todas formas, tal y como he comentado...voy a pedir un portatil PC, para ver si realmente las medidas que hice con el VMWARE son correctas...

Saludos

JP
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

jotap, jotap.... :evil:

El método de medida es insensible al retardo, pero no a las "roturas de stock". No me confundas los términos.

A mayor tamaño de la señal de medida mayor probabilidad de "rotura de stock", pero no porque quepa entero o no en el buffer;que no cabe, tú calcula, serían varios segundos de retardo.
jotap_66
Mensajes: 98
Registrado: Mar 08 Ene 2008 , 18:41

Mensaje por jotap_66 »

wynton escribió:jotap, jotap.... :evil:

El método de medida es insensible al retardo, pero no a las "roturas de stock". No me confundas los términos.
Tienes razon.. :oops: no es lo mismo....aunque son terminos, que tal y como yo lo entiendo estan intimamente relacionados....

wynton escribió: A mayor tamaño de la señal de medida mayor probabilidad de "rotura de stock", pero no porque quepa entero o no en el buffer;que no cabe, tú calcula, serían varios segundos de retardo.
Tal y como yo lo veo,...El que haya una "rotura de stock", de x tiempo, no quiere decir, que se pierdan x segundos de sonido...Dependiendo del soft usado, lo que se puede hacer es que de esos x segundos se pierdan algunos (salteados)....Esto es muy habitual en ciertos drivers de perifericos...Ignoro como funciona en el caso del tema del sonido...

Saludos

JP
Avatar de Usuario
Klaatu
Mensajes: 2323
Registrado: Mié 23 Ene 2008 , 12:36
Ubicación: En la trinchera, pasando revista

Mensaje por Klaatu »

Seguid, seguid con el debate, que esto está muy interesante. Creo que el que la latencia esté en high no conlleva mejoras en cuanto a los cortes.

A mi desde luego no me solucionó nada. Pero porque mi problema era otro, por cierto que este finde he hecho grandes avances con el barebone. El problema está detectado y prácticamente neutralizado, la solución está al caer. Bueno, ya lo contaré cuando pueda en el hilo suyo, que aquí se habla de otra cosa, pero confirmado que es un asunto de temperatura, lo que no está tan claro el origen del fallo.

Saludetes
Barada Nikto
http://www.youtube.com/watch?v=sIaxSxEq ... re=related

Que se jodan Andrea Fabra y todos ellos
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

Klaatu escribió:Pero porque mi problema era otro, por cierto que este finde he hecho grandes avances con el barebone. El problema está detectado y prácticamente neutralizado, la solución está al caer. Bueno, ya lo contaré cuando pueda en el hilo suyo, que aquí se habla de otra cosa, pero confirmado que es un asunto de temperatura, lo que no está tan claro el origen del fallo.
Klaatu,

la nueva versión de DRCoP (la 0.4), que tengo ahora en pruebas, permite configurar el ecualizador para que la carga de CPU pueda disminuir a menos de la mitad sin perdidas de prestación/calidad en el proceso.

Y en el barebone eso se nota, especialmente en la temperatura que alcanza.
Avatar de Usuario
Klaatu
Mensajes: 2323
Registrado: Mié 23 Ene 2008 , 12:36
Ubicación: En la trinchera, pasando revista

Mensaje por Klaatu »

:P

Es importante lo que comentas porque he podido comprobar que el punto crítico ( para que jackdaemon caiga o no) se alcanza con un incremento en la temperatura más bien moderado ( no sé medir cúanto exactamente) tal vez se trate de tan sólo unas décimas de grado.

He conseguido neutralizar el problema simplemente haciendo funcionar el barebone sin una de las tapas. A toro pasado la solución era bien fácil ¿verdad?

Todo esto, insisto,referido a MI barebone, sabemos que con los vuestros ( tú, Gustavo, Alf, etc... ) no hay problemas.

Saludetes
Barada Nikto
http://www.youtube.com/watch?v=sIaxSxEq ... re=related

Que se jodan Andrea Fabra y todos ellos
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

Para aquellos interesados en la tripas de DRCoP, voy a explicar qué leches pinta ahí un tal jackdaemon.

http://jackaudio.org/

¿Para que sirve jackaudio? Pues, simple y llanamente, convierte un PC con Linux en una DAW (Digital Audio Workstation) con Linux. Sin necesidad de harware específico. Nos proporciona lo siguiente:

- Un control de latencias entre aplicaciones de sonido y hardware audio conectados a este servicio. Garantiza que los flujos de audio E/S entre todos los elementos conectados a nuestra DAW vaya sincronizados. Este es un aspecto muy importante cuando, por ejemplo, no conectas directamente tu reproductor mp3 a la tarjeta de sonido, si no que lo haces pasar por un ecualizador externo y luego por un reverb. A mayor número de elementos en la cadena de sonido, más importante es el control de sincronización y latencia.

- Un entorno en el que "todo se puede conectar con todo". Tanto cada programa como la tarjeta de sonido se presentan de la misma forma: anuncian cómo se llaman (clientes) y qué entradas y salidas ofrecen (canales). Cualquier entrada puede conectarse con cualquier salida, sea cual sea el nombre del "cliente" (software o hardware). La conexión puede hacerse internamente desde alguno de los dos clientes (el de la entrada o el de la salida) o desde alguna aplicación externa de control (qjackctl).

En resumen, es un patchbay E/S que ofrece un reloj interno de sincronización de los elementos que se conectan. Casi nada.

Software que se puede conectar: un reproductor, un convolver, un RTA, un gestor de plugins VST, LADSPA,..., un ecualizador, un reverb, un editor... Una aplicación completa de grabación/mezcla:

http://es.wikipedia.org/wiki/Ardour

Para los que aún tengan más interés:

Jackaudio se compone de dos elementos:

- La librería de programación (canal de comunicación y reglas de conexión) para los "clientes". Es la manera de que se cumpla que todos vean a todos dentro de jackaudio.
- El daemon (jackd) que hace de servidor central de la DAW.

¿Cómo hace jackaudio para controlar latencias y E/S? Pues porque el control de flujo del programa que diseñemos es externo a dicho programa. Se "exporta" a través de la librería a un sistema en el cual el servidor le dice a cada programa que tiene "algo para ti".
Esto se implementa por memoria compartida (los famosos buferes) y callbacks ("tengo algo para ti").

El control de la memoria compartida lo hace jackd, colocando cada flujo de salida en cada entrada que corresponda (realmente las aplicaciones no saben a donde están conectadas, o si están desconectadas o conectadas a más de un cliente).

Por último decir que cada aplicación de audio tiene un tiempo limitado para efectuar el proceso que corresponda con el flujo recogido y lo entregue a la salida. Cuando jackd va a ver que se ha puesto en cada buffer de salida tiene que haber algo, y eso ocurre con una cadencia controlada (latencia).

Un ejemplo gráfico:

Imagen

Aquí vemos un diagrama de conexión semejante a DRCoP para jackaudio empleando la ESI Quatafire (6 entradas, 10 salidas). La señal entra por SPDIF a brutefir (el ecualizador) y brutefir saca cuatro canales conectados a cuatro salidas analógicas.

Jackd está ejecutándose con prioridad realtime (RT), y el tamaño de buffer son 256 frames ( <=> 256 samples).
Responder