DRCoP versión 0.3.4

DRC y todo lo relacionado con el tema
Avatar de Usuario
Yps
Mensajes: 3
Registrado: Mar 30 Oct 2007 , 12:31
Ubicación: Madrid

Mensaje por Yps »

Hola de nuevo y gracias por las bienvenidas :)
marcelo escribió: Ahora bien, con la nueva versión de DRCoP el clipping lo detecta el programa y baja la ganancia automáticamente, reduciendo tantos dBs como sean necesarios para que la señal esté a niveles adecuados, todo esto indicado en la ventana ppal.
Ya, pero ese clipping creo que se corrige después de aplicar el filtro a la señal original, antes de enviarla de vuelta al previo. Si la señal que entra a BruteFIR ya viene sucia por distorsión, con el control de ganancia de DrCop no arreglamos nada. De hecho, creo que Wynton debería añadir un apartado más al manual, tipo FAQ o Troubleshooting, que aclarase estos problemillas ajenos al programa, más que nada porque, por ejemplo en mi caso, la distorsión no era muy evidente pero suficiente para hacer creer que la pérdida de calidad pudiese ser causada por el mismo proceso de convolución.

La verdad es que no tenía ni idea de que existiesen tarjetas de sonido cuyas entradas van 'a capón'. Siendo así, no me queda otra que discrepar contigo en cuanto a la versatilidad de la UCA. ¡Qué menos que un led de detección de saturación! ¿Es problema del driver en Linux o en Windows tampoco tiene control de entrada?
wynton escribió: Extrapolarlo a una VIA EPIA 667 MHz es complicado, pero yo apostaría a que aguanta. Si fuese de 400 MHz ya lo dudaría.
Pues espero por mi bien que hayas apostado sobre seguro, porque ya he encargado una :)
wynton escribió: Tengo en mente preparar una versión en la que se separaría por conexión remota (XMLRPC) el gestor del sistema por un lado y el interfaz por otro, de modo que quizás se podría pensar en ejecutar un gestor con menor consumo en un sistema Mini-itx sin monitor ni teclado ni ratón, que sería el ecualizador, y un interfaz gráfico por otro lado que podría estar en el mismo ordenador o en otro (ambos con conexión de red activa claro), e incluso en un ordenador con Windows. El sistema arrancaría sin interfaz y el interfaz se arrancaría cuando hiciese falta.
Lo de separar la interfaz del motor me parece una idea genial por muchos motivos. De hecho, si alguna vez llega a cuajar esto, mi idea sería crear un plug-in para SlimServer que pudiera manejar DrCop remotamente mostrando todo por la pantallita del SqueezeBox3. Lo único que no me queda claro usando XML-RPC como protocolo es como vas a solucionar los datos que tengan que viajar hacia el interfaz en tiempo real, como las medidas de los vúmetros ¿Quizá mediante sockets UDP?

Por cierto, ya he visto que hay nueva versión. De nuevo, felicidades por el esfuerzo y el buen hacer. Como sugerencia para el manual, ten encuenta lo que le he comentado a marcelo de crear una sección FAQ o Troubleshooting.

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

Mensaje por wynton »

Yps escribió: Ya, pero ese clipping creo que se corrige después de aplicar el filtro a la señal original, antes de enviarla de vuelta al previo. Si la señal que entra a BruteFIR ya viene sucia por distorsión, con el control de ganancia de DrCop no arreglamos nada. De hecho, creo que Wynton debería añadir un apartado más al manual, tipo FAQ o Troubleshooting, que aclarase estos problemillas ajenos al programa, más que nada porque, por ejemplo en mi caso, la distorsión no era muy evidente pero suficiente para hacer creer que la pérdida de calidad pudiese ser causada por el mismo proceso de convolución.
Completamente de acuerdo. Prepararemos un FAQ.

Yps escribió: Pues espero por mi bien que hayas apostado sobre seguro, porque ya he encargado una :)
Ejem ejem, sobre seguro no, pero bueno, si no te va del todo, avisa que hay margen para el ajuste.

Yps escribió: Lo de separar la interfaz del motor me parece una idea genial por muchos motivos. De hecho, si alguna vez llega a cuajar esto, mi idea sería crear un plug-in para SlimServer que pudiera manejar DrCop remotamente mostrando todo por la pantallita del SqueezeBox3. Lo único que no me queda claro usando XML-RPC como protocolo es como vas a solucionar los datos que tengan que viajar hacia el interfaz en tiempo real, como las medidas de los vúmetros ¿Quizá mediante sockets UDP?
Uy uyuyuyuyu, si me prometes por la Gloria del Amarfilamiento que te vas a poner a desarrollar ese plug-in, me pongo yo a mi parte.
¿XML-RPC te va bien? Es que es un protocolo que aunque sobrecarga el flujo con las cabeceras http es muy sencillo y bastante extendido.

Hay dos grupos de datos que tienen que viajar hacia el cliente de alguna manera:

- Eventos de activo/inactivo.
- Niveles del pico-metro. Son diez datos por segundo por canal. Se puede disminuir incluso.

Se puede hacer polling cada cierto tiempo pero se puede implementar otra opción que es un doble enlace cliente-servidor. El cliente XML-RPC a la que se registra activa su propio servidor, y el servidor a la que recibe la conexión del cliente activa su propio cliente con ese servidor.
Incluso se pueden ofrecer ambas formas de enlace, de modo que el cliente decida como se conecta, aún perdiendo ciertas prestaciones.

El API disponible te lo pasaría documentado. Se podría implementar un cliente con funcionalidades reducidas (sin llegar a gestionar la parte de medida).
Avatar de Usuario
Marcelo
Site Admin
Site Admin
Mensajes: 5681
Registrado: Mar 08 Mar 2005 , 18:08
Ubicación: Vigo
Contactar:

Mensaje por Marcelo »

Yps escribió:Ya, pero ese clipping creo que se corrige después de aplicar el filtro a la señal original, antes de enviarla de vuelta al previo. Si la señal que entra a BruteFIR ya viene sucia por distorsión, con el control de ganancia de DrCop no arreglamos nada.
Buena pregunta: habrá que comprobar si atenúa en bypass o solo a través de BruteFir.
Yps escribió:La verdad es que no tenía ni idea de que existiesen tarjetas de sonido cuyas entradas van 'a capón'. Siendo así, no me queda otra que discrepar contigo en cuanto a la versatilidad de la UCA. ¡Qué menos que un led de detección de saturación! ¿Es problema del driver en Linux o en Windows tampoco tiene control de entrada?
Sobre la UCA, una de las primeras cosas que se aclaran es que satura fácilmente, y la otra es que la salida analógica es de bajo nivel.
La solución es utilizar una fuente que sea regulable en nivel de salida, o intercalar un atenuador para evitar que clipee, y utilizar la salida óptica.

Sigo pensando que es un tarjetón por los 35 eur que cuesta. Hablamos de lo mas básico que se pudo encontrar en tarjeta compatible con Linux y que funcione para el DRCoP.

slds, marcelo
"Uno es dueño de lo que está dispuesto a perder. De lo demás es esclavo."
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

Por aclarar el tema del clipping y su control:

Tú solo puedes evitar el clipping que le pases al otro. Es decir, el clipping siempre será en entrada y siempre se controlará en la salida previa.

DRCoP solo puede controlar el clipping que entrega en salida al previo/ampli que le sigue. El clipping que le llega por entrada se lo tiene que arreglar el encargado de hacer entrar esa señal: la fuente (o adaptador interpuesto).

Para saber si esto ocurre está el pico-metro del interfaz principal. Si se registra un pico máximo de 0 dBFS en algún momento, entonces es que hay clip y hay que atenuar en la entrada que le llega a DRCoP. Dentro de DRCoP no es posible.

Voy a revisar el manual para incorporar esta recomendación.
Avatar de Usuario
turkish
Mensajes: 290
Registrado: Mié 17 Dic 2003 , 2:49
Ubicación: ourense
Contactar:

Mensaje por turkish »

wynton escribió:Por aclarar el tema del clipping y su control:

Tú solo puedes evitar el clipping que le pases al otro. Es decir, el clipping siempre será en entrada y siempre se controlará en la salida previa.

DRCoP solo puede controlar el clipping que entrega en salida al previo/ampli que le sigue. El clipping que le llega por entrada se lo tiene que arreglar el encargado de hacer entrar esa señal: la fuente (o adaptador interpuesto).

Para saber si esto ocurre está el pico-metro del interfaz principal. Si se registra un pico máximo de 0 dBFS en algún momento, entonces es que hay clip y hay que atenuar en la entrada que le llega a DRCoP. Dentro de DRCoP no es posible.

Voy a revisar el manual para incorporar esta recomendación.
La edirol UA-25 tiene un limitador, supongo que actuará frente al clipping.
Avatar de Usuario
wynton
Admin
Mensajes: 3065
Registrado: Vie 26 Nov 2004 , 9:05
Ubicación: Madrid

Mensaje por wynton »

turkish escribió: La edirol UA-25 tiene un limitador, supongo que actuará frente al clipping.
Si, pero su actuación es simplemente tratar de salvaguardar el resto del equipo, evitando el recorte salvaje. Lo lógico siempre es que el LED de clip no se encienda nunca. Si se enciende hay que bajar el nivel de entrada, sea por pote en la propia tarjeta o por el medio que sea.

Existe una forma de ajustar niveles "para siempre" dentro de DRCoP y es hacerlo con ruido blanco como señal de entrada. Pero no conviene usarlo porque tendríamos una atenuación final muy alta y el espectro en frecuencia "de la música" se parece bastante más a rudio rosa que a ruido blanco.
Responder