Nuevo Software a seguir: FreeADSP
Nuevo Software a seguir: FreeADSP
Atentos a esto, puede ser una alternativa al BruteFIR para proceso digital:
http://freeadsp.sourceforge.net/
http://freeadsp.sourceforge.net/
R 
No tengo nada que decir sobre este asunto. Pero nada.

No tengo nada que decir sobre este asunto. Pero nada.
Y otra implementación de lo Log-Sweeps, como Sweep-Scope (o "El programa que vino del frío"):
http://gaydenko.com/qloud/
http://gaydenko.com/qloud/
R 
No tengo nada que decir sobre este asunto. Pero nada.

No tengo nada que decir sobre este asunto. Pero nada.
Re: Nuevo Software a seguir: FreeADSP
Mi opinión personal sobre esta propuesta:RR escribió:Atentos a esto, puede ser una alternativa al BruteFIR para proceso digital:
http://freeadsp.sourceforge.net/
quiere abarcar tanto que es anti-unix en su concepto. Es mejor tener "pequeñas" rutinas que hacen de PM una sola cosa que una que lo incluya todo.
Brutefir es un convolver de rendimiento genial. Jackd es un servidor de streams de audio en RT excelente. La arquitectura LADSPA de plugins funciona bien, solo hay que animarse a programar más efectos. Ecasound ( http://eca.cx/ecasound/ ) es un mixer, aplicador de plugins flipante. Además lo que para unos puede ser su gran inconveniente (funciona solo desde linea de comandos) para otros es precisamente su gran baza:
http://www.ftrain.com/archive_ftraintwo_19.html
Y todo ello interconectado entre si.
Con fst y vst-server funcionan bastantes plugins de VST, y los que fallan es por problemas con la libreria wine.
http://quicktoots.linuxaudio.org/toots/vst-plugins/
Hablando de fst, yo he probado un convolver muy bueno (peor rendimiento que brutefir pero con otras prestaciones curiosas) para probar reverbs:
http://www.knufinke.de/sir/index_en.html
Con las liberias de impulsos:
http://www.echochamber.ch/responses/index.html
se puede pasar un rato realmente entretenido. Incluye los reverbs del Lexicom 960 que me han parecido muy buenos (aplicados con moderación, que esto del reverb es como el vino).
La experiencia vuelve a ser toda una enculada al concepto "sagrado" de la señal musical y su respeto escrupuloso.
Ya sé que estos temas son bastante minoritario, pero bueno, lo dejo escrito por si a alguien le interesa.
Saludos Roberto.
Bueno, estoy de acuerdo, pero parece que la crudeza del brutefir desanima a muchos. Pensaba también en la posibilidad de hacer filtros sin latencia, para cine, tal vez como una "segunda personalidad" del FIRtro.
Creo recordar que hay un host para plugins que se enchofa a jack sin parafernalia gráfica (pero por eso mismo más difícil de manejar).
En fin, ahí queda la información.
Por cierto, he estado probando el FIRtro con cine. Ayayay, medio segundo de latencia es divertido un rato, pero inadmisible a la larga.
Creo recordar que hay un host para plugins que se enchofa a jack sin parafernalia gráfica (pero por eso mismo más difícil de manejar).
En fin, ahí queda la información.
Por cierto, he estado probando el FIRtro con cine. Ayayay, medio segundo de latencia es divertido un rato, pero inadmisible a la larga.
R 
No tengo nada que decir sobre este asunto. Pero nada.

No tengo nada que decir sobre este asunto. Pero nada.
- Luismax
- Site Admin
- Mensajes: 7086
- Registrado: Lun 03 Nov 2003 , 18:44
- Ubicación: MatrixHell
- Contactar:
Una pequeña matización.
Лидером продаж сентября в Салоне FosterGroup по направлению «Акустические системы» стал комплект акустики для домашнего кинотеатра Audica CS system 5, состоящий из двух напольных АС, двух саттелитов, инновационной комбинированной АС центрального канала CS-LCR и сабвуфера. Система окружит вас комфортным насыщенным звучанием, а футуристический вид стройных, алюминиевых корпусов украсит любой интерьер в стиле Hi-Tech
Ценители звука и профессионалы редакции журнала Stereo&Video сравнили акустические системы Bolzano Villetri BV HF 3005 Torre со знаменитой фреской Леонардо да Винчи «Тайная вечеря», написанной в технике сфумато…..
Fostergroup объявляет о смене логотипа и фирменного стиля.
Por si sirve.
Лидером продаж сентября в Салоне FosterGroup по направлению «Акустические системы» стал комплект акустики для домашнего кинотеатра Audica CS system 5, состоящий из двух напольных АС, двух саттелитов, инновационной комбинированной АС центрального канала CS-LCR и сабвуфера. Система окружит вас комфортным насыщенным звучанием, а футуристический вид стройных, алюминиевых корпусов украсит любой интерьер в стиле Hi-Tech
Ценители звука и профессионалы редакции журнала Stereo&Video сравнили акустические системы Bolzano Villetri BV HF 3005 Torre со знаменитой фреской Леонардо да Винчи «Тайная вечеря», написанной в технике сфумато…..
Fostergroup объявляет о смене логотипа и фирменного стиля.
Por si sirve.
“No es señal de buena salud estar bien adaptado a una sociedad profundamente enferma”
Ajá... Hay que leer entre líneas, está claro.L.U.I.S.M.A.X. escribió: Ценители звука и профессионалы редакции журнала Stereo&Video сравнили акустические системы Bolzano Villetri BV HF 3005 Torre со знаменитой фреской Леонардо да Винчи «Тайная вечеря», написанной в технике сфумато…..
Por si sirve.
Spasiva,
R 
No tengo nada que decir sobre este asunto. Pero nada.

No tengo nada que decir sobre este asunto. Pero nada.
Otra opción de configuración muy simple es jace:RR escribió:Bueno, estoy de acuerdo, pero parece que la crudeza del brutefir desanima a muchos. Pensaba también en la posibilidad de hacer filtros sin latencia, para cine, tal vez como una "segunda personalidad" del FIRtro.
http://users.skynet.be/solaris/linuxaudio/
Quizás sea tan rápido o más que brutefir. No admite filtros en cascada pero, con jack como servidor de audio se pueden ejecutar varias copias con diferentes nombres y conectarlas entre si. Los filtros van en wav's. El FFT lo realiza mediante la librería fftw3. No creo que funcione a 64 bits. Todo esto lo digo para que lo comente Luismax.
Lo de la latencia no tiene otro remedio que introducir la misma latencia en la señal de video.
Ya me respondo yo. No hay color: en rendimiento el brutefir le pega una soberana paliza de más del triple al jace.wynton escribió: Otra opción de configuración muy simple es jace:
http://users.skynet.be/solaris/linuxaudio/
Quizás sea tan rápido o más que brutefir.
Así que de momento la única ventaja de jace es que es más fácil de configurar.
Yo tengo filtros de 65536 taps y el desfase en torno a 60 milisegundos. ¿Cómo? Pues hay dos puntos de toqueteo necesarios:RR escribió:Bueno, con FIR muy cortos o con IIR en un host quizá fuera aceptable, piensa que yo estoy ahora en cosa de medio segundo, que solo vale para hacer chistes con el desfase en tre imagen y sonido.
1- Si se configura brutefir para que trabaje con muchas particiones de poca longitud, baja la latencia:
http://www.ludd.luth.se/~torger/brutefir.html#lowdelay
El parámetro donde esto se ajusta es:
filter_length: 65536;
y ponemos:
filter_length: 2048,32;
Por ejemplo y pasamos a 2048*2 taps de latencia. Esto supone un coste en consumo de CPU.
Es imprescindible que la longitud de cada partición del filtro sea mayor o igual al tamaño de buffer de audio del servidor jack. Lógico, no se puede convolucionar a latencia menor que la que permite el software de gestión del hardware audio.
2- Si se trabaja con filtros lo más cerca posible de fase mínima la latencia disminuye. En fase mínima la latencia introducida por el filtro es cero. En fase lineal (ahí le has dao) la latencia es (nº taps/2) independientemente de la gestión de la convolución particionada.
Última edición por wynton el Mar 10 Oct 2006 , 10:15, editado 1 vez en total.
Yo estaba muy interesado en el FirTRO pero lo de la latencia me tira un poco para atrás porque me gustaría compartir los frontales con el HT.
Soy presidente fundador y único miembro del club "Todos contra Linux" por lo que no estoy muy al día de las opciones que ofrece.
Bromás aparte, aunque hubo un tiempo que controlaba bastante Unix y lo he utilizado en la mayoría de los proyectos en los que he participado, nunca me interesó Linux (ni cuando era estudiante) por lo que, aunque ofrece un interfaz y filosofía semejante a Unix, no estoy familiarizado con paquetes distribuciones, versiones...
En cualquier caso, ¿existe alguna versión de Linux en tiempo real que, de alguna manera, nos permitiera controlar la latencia del FirTRO?
Por otra parte,¿el FirTRO (BruteFIR) está optimizado en cuanto a opciónes de compilación? ¿Se podría sacar partido de PCs con varias CPUs para reducir la latencia al mínimo posible?
Saludos
Saludos
Soy presidente fundador y único miembro del club "Todos contra Linux" por lo que no estoy muy al día de las opciones que ofrece.
Bromás aparte, aunque hubo un tiempo que controlaba bastante Unix y lo he utilizado en la mayoría de los proyectos en los que he participado, nunca me interesó Linux (ni cuando era estudiante) por lo que, aunque ofrece un interfaz y filosofía semejante a Unix, no estoy familiarizado con paquetes distribuciones, versiones...
En cualquier caso, ¿existe alguna versión de Linux en tiempo real que, de alguna manera, nos permitiera controlar la latencia del FirTRO?
Por otra parte,¿el FirTRO (BruteFIR) está optimizado en cuanto a opciónes de compilación? ¿Se podría sacar partido de PCs con varias CPUs para reducir la latencia al mínimo posible?
Saludos
Saludos
Me respondo en parte a mi mismo:
Existe RTLinux. Es un recubrimiento de Linux pero me da la sensación que utilizarlo no es algo trivial. Además no permite el uso de llamadas al sistema con lo cual habría que reestructutrar el BruteFir para convertir en tareas de tiempo real sólo aquellas que consumen más CPU y además de forma variable, cosa que requiere meterse en el código y eso requiere tiempo.
También existe una versión multiprocesador que permite repartir las tareas en tiempo real entre varios procesadores.
Existe RTLinux. Es un recubrimiento de Linux pero me da la sensación que utilizarlo no es algo trivial. Además no permite el uso de llamadas al sistema con lo cual habría que reestructutrar el BruteFir para convertir en tareas de tiempo real sólo aquellas que consumen más CPU y además de forma variable, cosa que requiere meterse en el código y eso requiere tiempo.
También existe una versión multiprocesador que permite repartir las tareas en tiempo real entre varios procesadores.
Pero vaya lío que te estás montando.
No tiene nada que ver el tiempo real (ni siquiera en gestión del hardware) con la latencia de la convolución.
Ni tampoco lo tiene la capacidad de proceso, que generalmente en un PC o portatil de la "era moderna" es suficiente para lo que empleamos brutefir (y si no consulta la página web de brutefir donde da referencias de "performancia", con la latencia de la convolución.
La latencia de la convolución es inherente al algoritmo elegido y al diseño del filtro. En convolución particionada puedes bajar a latencias de 10 ms tranquilamente. Pero solo para filtros de fase mínima: un filtro de fase lineal de 65536 taps supone introducir un retardo inherente de la mitad de taps lo convoluciones como lo convoluciones. Si o si, por propia definición de fase lineal:
http://www.matrixhifi.com/foro/viewtopic.php?t=1255
El otro elemento que introduce latencia a la señal es la tarjeta de sonido. En linux empleando jack se puede controlar esta latencia a traves de la definición de los buffers de I/O. A menor tamaño menor latencia, pero mayor riesgo de interrupciones de señal por problemas en la gestión de IRQ. Bajar de 10 ms no es una azaña, dependerá de qué tarjeta sea, pero se hace.
Para disponer de un kernel linux optimizado para gestión de IRQ con priorización hay que parchear el kernel con:
http://people.redhat.com/mingo/realtime-preempt/
EL RTlinux es para otras cosas.
Y por último como opción está windows. Anda que no habrá convolvers para linux, ni tarjetas con drivers ASIO.
No tiene nada que ver el tiempo real (ni siquiera en gestión del hardware) con la latencia de la convolución.
Ni tampoco lo tiene la capacidad de proceso, que generalmente en un PC o portatil de la "era moderna" es suficiente para lo que empleamos brutefir (y si no consulta la página web de brutefir donde da referencias de "performancia", con la latencia de la convolución.
La latencia de la convolución es inherente al algoritmo elegido y al diseño del filtro. En convolución particionada puedes bajar a latencias de 10 ms tranquilamente. Pero solo para filtros de fase mínima: un filtro de fase lineal de 65536 taps supone introducir un retardo inherente de la mitad de taps lo convoluciones como lo convoluciones. Si o si, por propia definición de fase lineal:
http://www.matrixhifi.com/foro/viewtopic.php?t=1255
El otro elemento que introduce latencia a la señal es la tarjeta de sonido. En linux empleando jack se puede controlar esta latencia a traves de la definición de los buffers de I/O. A menor tamaño menor latencia, pero mayor riesgo de interrupciones de señal por problemas en la gestión de IRQ. Bajar de 10 ms no es una azaña, dependerá de qué tarjeta sea, pero se hace.
Para disponer de un kernel linux optimizado para gestión de IRQ con priorización hay que parchear el kernel con:
http://people.redhat.com/mingo/realtime-preempt/
EL RTlinux es para otras cosas.
Y por último como opción está windows. Anda que no habrá convolvers para linux, ni tarjetas con drivers ASIO.
Perdona pero creo que no me estoy montando ningún lío. El problema no es reducir la latencia, el problema es controlar la latencia. Es decir, que no supere un máximo. Mediante un Sistema en tiempo real lo que garantizas es que una determinada tarea se tiene que ejecutar en un tiempo menor que uno dado. Claro, esto siempre que sea posible porque si es imposible, por mucho que le impongas una restricción de tiempo la tarea siempre va a durar más.wynton escribió:Pero vaya lío que te estás montando.
No tiene nada que ver el tiempo real (ni siquiera en gestión del hardware) con la latencia de la convolución.
Ni tampoco lo tiene la capacidad de proceso, que generalmente en un PC o portatil de la "era moderna" es suficiente para lo que empleamos brutefir (y si no consulta la página web de brutefir donde da referencias de "performancia", con la latencia de la convolución.
La latencia de la convolución es inherente al algoritmo elegido y al diseño del filtro. En convolución particionada puedes bajar a latencias de 10 ms tranquilamente. Pero solo para filtros de fase mínima: un filtro de fase lineal de 65536 taps supone introducir un retardo inherente de la mitad de taps lo convoluciones como lo convoluciones. Si o si, por propia definición de fase lineal:
http://www.matrixhifi.com/foro/viewtopic.php?t=1255
El otro elemento que introduce latencia a la señal es la tarjeta de sonido. En linux empleando jack se puede controlar esta latencia a traves de la definición de los buffers de I/O. A menor tamaño menor latencia, pero mayor riesgo de interrupciones de señal por problemas en la gestión de IRQ. Bajar de 10 ms no es una azaña, dependerá de qué tarjeta sea, pero se hace.
Para disponer de un kernel linux optimizado para gestión de IRQ con priorización hay que parchear el kernel con:
http://people.redhat.com/mingo/realtime-preempt/
EL RTlinux es para otras cosas.
Y por último como opción está windows. Anda que no habrá convolvers para linux, ni tarjetas con drivers ASIO.
En cualquier caso, por ser prácticos, ¿Cómo harías tu para poder utilizar el FirTRO en un sistema de AV sin que haya desfase percibible entre A y V (ni siquiera en momentos puntuales?
Gracias y saludos
Bueno pues nada, que tengas suerte en tu periplo gestor de latencias y tennos informados de los avances, que seguramente serán primicia mundial para infinidad de desarrolladores de software para tratamiento de sonido.DrFunk escribió:Perdona pero creo que no me estoy montando ningún lío. El problema no es reducir la latencia, el problema es controlar la latencia. Es decir, que no supere un máximo.
¿Por ser prácticos? Pues está claro, retrasaría la señal de video el tiempo suficiente. La señal de video no nos la ha entregado Dios todopoderoso intocable e intratable.DrFunk escribió: En cualquier caso, por ser prácticos, ¿Cómo harías tu para poder utilizar el FirTRO en un sistema de AV sin que haya desfase percibible entre A y V (ni siquiera en momentos puntuales?
Evidentemente eso obligaría a disponer de un HTPC que integrará la gestión de A/V. Como es de esperar, eso ya está inventado.
Luego está el asunto de si filtrar cada via del sistema activo con filtros de fase lineal o ir a filtros de menor retardo INHERENTE. No he probado nada en este aspecto, así que, lógicamente, no dispongo de criterio.