X
¡No te pierdas nuestro Especial Black Friday!

Pro tools y linux

  • 2
rumbe
#16 por rumbe el 03/03/2004
AEnema escribió:
Vamos a ver. Con respecto a tus tasas de transferencia, has de saber que serial ata tiene una tasa de transferencia de 150 mega BYTES por segundo, mientras que Gigabit tiene una tasa de transferencia de 1 Giga BIT por segundo = 125 mega BYTES por segundo.


Ya que veo que te gusta utilizar las mayúsculas creo que en mi comentario quedaba bien claro:
rumbera escribió:
..... 150MB/s, un SCSI(UW) de 160MB/s y ahora mismo tenemos tarjetas de red de 1 GBit/sg...

MB corresponde a megabyte, por lo menos en mis libros de la “Ingenieria”. Por eso después al hablar de la tarjeta de red expecifiqué G”bit”. Para poder diferenciarlos. También compruebo que sabes dividir entre 8. ¡ Enhorabuena!.

AEnema escribió:

Lo segundo, permiteme comentarte que las comunicaciones por red necesitan protocolos, y que esos protocolos consumen ancho de banda. Ni que decir tiene que un protocolo orientado a conexión (es decir que no falle, porque por si no lo sabías hay un porcentaje MUUUUY elevado de paquetes que se pierden) tiene un coste en reenvíos de paquetes aún más elevado.

¿ De verdad que las comunicaciones de red necesitan protocolos y que consumen ancho de banda ? De aquí te nominan para el Novel. Los disco duros ¿ no consumen ancho de banda ? .
Veo que alguna vez te has estudiado el TCP/IP y te han demonizado el TCP. Según tu teoría Internet es una mierda de red porque se pierden MUUUCHHHOOS paquetes. Vamos haz tu tesis sobre lo malo que es TCP. Se lo contamos a los ingenieros que llevan años desarrollando aplicaciones sobre TCP o protocolos superiores que son lo peor. Sus paquetes se pierden. Es más voy a escribir una carta a los señores de Cisco para decirles que sus routers no valen para nada. Si no que se pasen por hispasonic y se lo cuentas.
Ya si en vez de internet uso un Switch para unir mi cluster en mi miniLAN se perderan tambien paquetes. Es más, se perderan muchos más debido a la ley de Aenema. Es más si cogo 2 tarjetas de gigabit(para que no nos confundamos) y hago bounce en el nodo maestro para optimizar ancho de banda, no optimizo sino !!!! pesimizo !!!!. Joder, joder esto se pone feo. Voy a hacer un anuncio como el de las fotos perdidas pero para los paquetes.
AEnema escribió:

...... creo que con los datos que he dado antes queda claro que aún estamos muy lejos de conseguir unas tasas de transferencia mantenidas como para correr 32 pistas.

Según parece tu teoría de cluster es pasar todo el audio a las nodos. ¿ einnn ?. El nodo principal puede realizar gran parte del trabajo y trasladar a los restantes nodos el trabajo que su “procesador” no puede realizar. Lo que creo es que no acabas de entender es como se estructura la programación de este tipo de sistemas. Si el desarrollador es capaz de que su software migre procesos a otros nodos del cluster de manera preventiva, como por ejemplo adelantarse al tratamiento de una reverb en 2 segundos a su salida por el interface de audio, el sistema podrá procesar más información por lo que nuestra potencia de cálculo aumentará. Pero esto no me lo invento yo, es pura teoría que se pone en práctica con programación paralela.
Por un lado está el disco duro que se encuentra el “nodo maestro” con su lectura y escritura a través de este y por otro lado el calculo realizado por el procesador que puede ser realizado en el nodo maestro o en otros. Lo que trasferimos a los nodos no es audio en si sino procesos de cálculo. No confundamos churros con meninas.
AEnema escribió:

En la informática hay un tipo de sistemas denominados "sistemas de tiempo real" que se caracterizan por tener que cumplir unos plazos de tiempo. Pues bien. Una mezcla en un cluster podríamos considerarla algo parecido: cada nodo del cluster tiene que tener lista su pista con sus efectos procesados etc. en un tiempo suficiente para que no se produzcan saltos en el audio.

Te remito a lo que comentábamos anteriormente sobre migración de procesos preventiva. Insistes en pensar que un proceso debe saber lo que es una pista o un efecto.
La latencia con tarjetas ethernet y un switch no deben de superar los 5 ms.
AEnema escribió:

Permiteme decirte que hoy por hoy un cluster TAN rápido supondría utilizar conexiones con tecnologías como mirinet o similares, con lo cual nos gastamos más en comunicaciones que en comprar hardware real.


Seguimos. Evidentemente si usamos “myrinet” sería un sistema casi perfecto. Pero la lógica que yo quería exponer es que montar un cluster con un nodo maestro con buen procesador y memoria y montar 4 nodos con por ejemplo P-III comprados de segunda mano te sale muy barato en comparación a un sistema multiprocesador. Evidentemente hoy en día no hay software que pueda utilizar un cluster para el audio pero mola teorizar.

AEnema escribió:

Por otra parte, en los sistemas paralelos siempre existe una parte secuencial, que es lo que nos impide obtener mayor rendimiento al aumentar el número de nodos, es decir, por tener más ordenadores no vamos a ir más rápido, porque hay cosas que tienen que hacerse en un determinado orden, de manera que hasta que uno no termina el otro no puede seguir.
Bueno, lo dicho.

Mira, en esto estamos absolutamente de acuerdo. ¿ Pero en que procesador del cluster se van a realizar ?

Bueno, a ver si seguimos discutiendo sobre el tema que es muy interesante.

Saludos cordiales
Subir
--13211--
#17 por --13211-- el 03/03/2004
dejaros de tonterías... a linux le quedan uno o dos años para ser un SO para audio... cada día hay más soft, sintes y secuenciadores para el sistema... incluso algunos vst ya empiezan a funcionar con "vstserver" que no es más que una versión de wine específica para eso... todo es cuestión de tiempo... claro que también las compañías lo pueden estropear metiendo dinero de por medio... ojalá que todos tengamos a un pingüino con auriculares en nuestro pc!! :)
Subir
danner
#18 por danner el 03/03/2004
A cuento del tema de redes,

Sólo apuntar, por un lado, que creo que LADSPA (o JackIt? Menuda memoria de pez) ya tiene un conector para redes, con lo que no hace falta ni siquiera crear un sistema nuevo para enlazar audio, desde YA se pueden poder plugins en un PC y el secuenciador en otro.

Ah, y para redes, sobre todo de estas características, nadie ha pensado en usar red FireWire? Tiene una velicidad más que aceptable (sino, no se usaría en el estándar mLan), y, a pesar de que personalmente no la he probado, hay software de granjas (o clusters) que usan FireWire (bajo coste y buen rendimiento)
Subir
--13211--
#19 por --13211-- el 03/03/2004
ummm mLan... alguien me puede contar algo sobre eso?
Subir
danner
#20 por danner el 03/03/2004
Es una iniciativa que empezó Yamaha y luego se han ido uniendo varios fabricantes. Se basa en la arquitectura FireWire (si ya tienes un estándar de transmisión de datos por un cable, ¿para qué reinventar la rueda? ;) Creamware parece estar de acuerdo con esto, con sus módulos externos).

El estándar mLan surgió del siguiente problema: después de 20 años, se ha conseguido que todo funcione mediante MIDI, y ha dado gran flexibilidad de control de los equipos con un sólo cable. Si MIDI ha aportado tantas ventajas, por qué no extrapolar su funcionalidad no sólo a datos de control, sino también al audio? Al fin y al cabo, por qué mi sinte necesita 1 cable IN, 1 OUT, 1 THRU, 1 entrada estéreo para el vocoder, una para guitarra para los efectos, una salida de auriculares, y dos salidas estéreo, si al final todo acaba en el ordenador (o en la misma mesa de mezclas)?

mLan pretende ser una especie de MIDI pero no sólo para control sino también para audio. Con un sólo bus, un sólo cable por elemento hardware, circularán todos los canales de audio y midi de todos los equipos, y todo esto sin salir del dominio digital.

Se entiende o me he enrollado mucho?

Un par de enlaces:
mLan Alliance Home Page: http://www.mlancentral.com/

mLan en Yamaha: http://www.yamaha.co.jp/tech/1394mLAN/english/
Subir
danner
#21 por danner el 03/03/2004
:arrow:
Subir
--13211--
#22 por --13211-- el 03/03/2004
se entiende perfectamente, muchas gracias danner... ;)

de hecho estoy mirando el tema por inet, porque veo que mi sampler es compatible con mlan, y eso me da que pensar...

tu lo has probado?
Subir
danner
#23 por danner el 03/03/2004
La verdad es que no :oops: No he tenido tampoco oportunidad de comprar ningún equipo relacionado ni he hecho crecer mi 'estudio' como para renovar equipos... Pero me ofrezco voluntario para hacer el I+D si alguien me regala el equipo :mrgreen:
Subir
rumbe
#24 por rumbe el 03/03/2004
Seguiendo con la buena explicacion de danner comentar que firewire y mlan ofrecen ventajas sobre otro tipo de interfaces para el audio ya que teoricamente garantiza la trasferencia de datos en intervalos de 125 microsegundos. En USB las pruebas que por aqui hemos hecho la latencia se acerca a los 2 milisegundos.

Según tengo entendido en mlan los aparatos se enchufan secuencialemente, osea de equipo1 a equipo2 a equipon pudiendo comunicarse el equipon con el equipo1 sin problemas. Por ponerle algun defecto la tasa actual de trasferencia es de 200 mbs en comparación con firewire 400/800 mbs.

Saludos
Subir
Antonio Escobar
#25 por Antonio Escobar el 03/03/2004
24bit escribió:
Hola,
Estamos con AF, (...y no por la amistad que nos une...),
para que montar una máquina e un sistema que no acepta...
Protools, este sistema solo funciona en Mac OS 9.2.2, Mac X o Windows XP
no te compliques..., la versión de Cubase SX para linux es beta y no
funciona correctamente, creeme.
Salu2,
24bit.


Hay un port para Linux?

Saludos,

Yoshi.
Subir
Antonio Escobar
#26 por Antonio Escobar el 03/03/2004
Ziryab escribió:
Para escépticos en el asunto linux-audio, recomiendo encarecidamente que le echen un vistacillo a la forma de trabajar de http://www.multitrack.us . Es un pasón, uno de los mejores estudios de grabación, mezcla y masterización de los EEUU.... currando sólo con Linux.


Me parece loable el esfuerzo... pero yo no diría que es uno de los mejores, de hecho, es "tipo medio-bajo"...
Subir

Hilos similares

Respuesta rápida

Regístrate o para poder postear en este hilo