viernes, 17 de diciembre de 2010

Configuración del servidor de audio Jack. Segunda parte

#########################
Notas de revisiones:
Rev 0: 19 diciembre 2010. Publicado.
Rev 1: 25 mayo 2011. Edición de mantenimiento.

#########################


Segunda parte. Dispositivos de entrada y de salida. Jack sobre varias tarjetas de audio

Si estás perdido en la tarea de configurar el servidor de audio jack, no empieces por aquí. Lee antes la primera y más importante parte.

Lo normal es que jack trabaje sobre una única tarjeta (el "interfaz") en la cual tendremos entradas y salidas suficientes para capturar y reproducir sonido. Sin embargo, se puede configurar jack para que utilice diferentes dispositivos de entrada y de salida.

También presentamos las utilidades alsa_in y alsa_out.

En las faq de jackaudio hay escrito algo sobre esto, yo intentaré elaborarlo un poquito más aun a riesgo de meter la pata.

Tarjetas y dispositivos

Alsa maneja los conceptos de "Tarjeta" (Card), "Dispositivo" (Device) y "Subdispositivo" (Subdevice). Cada tarjeta puede tener varios "dispositivos" y éstos a su vez, varios "subdispositivos". Jack necesita saber qué tarjeta y qué dispositivo usar así que dejamos de lado el "subdispositivo" (menos mal).

En general, una tarjeta soportada por alsa, se denomina numéricamente "hw:x,y", donde "x" es el número de tarjeta e "y" es el número de dispositivo, comenzando ambos desde cero. Muchas tarjetas tienen un dispositivo único y no hace falta especificarlo. Así, hw:0 es lo mismo que hw:0,0. Sin embargo hay otras tarjetas que tienen varios dispositivos, típicamente, las tarjetas "de consumo". Veamos esta imagen:



"arecord -l" muestra las tarjetas y dispositivos que sirven para captura y "aplay -l" los que se pueden usar para reproducción (he filtrado las líneas que contienen la palabra "subdispositivo"). En cada tarjeta puede haber dispositivos únicamente de captura, únicamente de reproducción, o dúplex. Los dispositivos dúplex (capaces de captura y reproducción simultánea) aparecen en la salida de ambos comandos.

Veis que la tarjeta 0, en este caso la M Audio Audiophile 24/96 (hw:M2496) nos lo pone fácil; sólo tiene un dispositivo y es válido tanto para captura como para reproducción.

La tarjeta 1 es la integrada, hw:Intel. Tiene dos dispositivos, uno para los puertos analógicos y otro para el puerto digital. Ambos son utilizables tanto para captura como para reproducción.

La tarjeta 2 es una tarjeta virtual. Paso palabra.

Con la tarjeta 3, la mítica SB Live!, la cosa se lía un poco. Si elegimos la interfaz "hw:Live" la cosa va bien pero nos encontramos con que sólo tenemos dos puertos de captura y dos puertos de reproducción. hw:Live es equivalente a hw:Live,0 y por tanto se usa el dispositivo que corresponde a "ADC Capture/Standard PCM Playback", que, por lo que se ve, enseña solamente estos 2 + 2 puertos.

¿Qué pasa con el resto de salidas del sistema surround? Pues que están en otro "dispositivo".

Para acceder a estos puertos podemos usar "hw:Live,0" para captura (es decir, "dispositivo de entrada" y "hw:Live,3" para reproducción (dispositivo de salida). Eso sí, tendremos que ir descubriendo qué "puerto escribible" de jack corresponde a qué salida física y, por supuesto, el mezclador interno y los niveles de los canales deberán de estar configurados correctamente en alsamixer.

En el pantallazo se puede observar cómo el menú desplegable en los dispositivos de entrada y salida se corresponden con las salidas de arecord -l y aplay -l respectivamente.



Por supuesto, también podemos intentar usar dispositivos de entrada y salida de tarjetas diferentes, pero no es muy recomendable. Para eso es mejor usar alsa_in y alsa_out.

alsa_in y alsa_out


Ejemplo de uso:

Jack está ejecutándose sobre el interfaz hw:M2496 pero nos vendría bien un canal estéreo de la SB Live! para monitorización. Podríamos usar:

alsa_out -jSBlive -dhw:Live,0

La opción -j es opcional. Ver: man alsa_out

Otras opciones

En el archivo ~/.asoundrc podemos crear dispositivos virtuales aunque esto es algo que supera mis conocimientos y mi experiencia. Ver el clásico "el cheapo howto" http://quicktoots.linuxaudio.org/toots/el-cheapo/ y la documentación de alsa para algunos ejemplos.

sábado, 4 de diciembre de 2010

Configuración del servidor de audio Jack. Primera parte

#########################
Notas de revisiones:
Rev 0: diciembre 2010. Publicado.
Rev 1: 17 diciembre 2010. Actualizado.
Rev 2. 22 enero 2011. Retocado texto de introducción.
Rev 3. 27 enero 2011. Añadidas referencias y enlaces (al final).
REv 4. 24 mayo 2011. Añadidas notas sobre el soporte del hardware y página de referencia de Jack1 vs Jack2

#########################



Primera parte. La ruta del servidor, el driver, el interfaz y el modo realtime



Introducción


Como es sabido, el servidor o demonio jackd permite baja latencia y una gran flexibilidad en las conexiones entre los puertos de audio y midi de sus clientes. Su configuración es también muy flexible y depende por completo de nuestro hardware y software de bajo nivel. NO hay una configuración universal. Por eso es importante entender al menos los conceptos básicos.

Hay que tener en cuenta que Jack se comunica directamente con el driver de la tarjeta de audio que nosotros elijamos. Además, necesita que el sistema operativo le deje hacer "sus cosas".

Eso sí, si conseguimos que el servidor Jack esté a gusto en nuestro sistema habremos recorrido un buen trecho del camino hacia el objetivo de hacer música con Linux.

qjackctl, o Jack Control es una interfaz gráfica que, entre otras cosas, nos permite configurar el servidor jackd, a través del botón Setup, pestaña "Configuraciones".

Al que le gusta experimentar sólo un consejo: Los valores por defecto son lo más universales posible, así que, si no funciona a la primera es buena idea hacer un solo cambio cada vez y volver a probar en lugar de poner todo en duda y querer entenderlo a la primera. En muchas ocasiones, un pequeño cambio arregla las cosas.

Como dijo Einstein, "Haz las cosas lo más simple posible". Aunque después añade: "Pero no más simple". Supongo que esto último fue lo que inspiró al gran Rui Nuno Capela para meter en una única ventana de configuración lo importante y lo menos importante, lo esencial y lo inútil, pero eso sí, todos los argumentos posibles que se le pueden pasar a jackd (bueno, casi todos).

Así que para simplificar, en esta serie de entradas vamos a ver la configuración de jack con sus opciones y parámetros en orden (no estricto) de importancia. Como dijo el otro Jack (el destripador), vamos por partes.

La ventana principal de qjackctl, indicando que el servidor jackd está iniciado. Ojo, "Detenido" se refiere al "transporte de jack", el cual sirve para sincronizar diferentes aplicaciones con un transporte común. El transporte de jack no se trata en esta entrada.


Jack1 y Jack2


Antes de seguir adelante, una explicación que considero importante. Jack1 es el jack original, escrito en C y desarrollado por Paul Davies. Stephan Letz reescribió jack en otro lenguaje de programación (C++), para soportar multiprocesadores. Por ello, jack2 es también llamado jackmp. Ambas implementaciones de jack tratan de mantenerse compatibles en sus argumentos de línea de comandos (aunque hay alguna pequeña diferencia como veremos) y qjackctl sirve perfectamente para ambos.

En todo caso, se debe tener en cuenta que:

- jack2 no es un reemplazo de jack1. Simplemente es diferente. Ambos se desarrollan en paralelo.

- Aunque jack2 tiene cosas buenas que jack1 no tiene, en general, jack1 está más probado y tiende a ser más robusto, especialmente con ardour.

- Normalmente, no podemos tener instalados los dos jacks al mismo tiempo. Tenemos que elegir. En ubuntu, hasta lucid lynx tendremos jack1 por defecto y, a partir de maverick (10.10 y posteriores), jack2. Podemos cambiar a jack1 instalando el paquete "jackd1" (que, por supuesto, desinstalará jackd2).

- Para saber cuál de los dos jacks tenemos instalado usamos el comando: "jackd -V". Las versiones que comienzan por 0, por ejemplo, 0.119.0, son jack1. Las que comienzan por 1, por ejempo 1.9.6, son jack2.

En la sección "Para saber más" hay una explicación más técnica y mejor informada acerca de las diferencias entre jack1 y jack2.

La ruta del servidor, el driver, el interfaz y el modo realtime



1. Ruta del servidor

Es el comando básico con el que lanzamos el servidor jack. Normalmente, la ruta completa del ejecutable es /usr/bin/jackd aunque también sirve jackd a secas.

Modo síncrono o asíncrono en jack2

jack2 funciona por defecto en modo asíncrono. Me parece que el modo asíncrono permite conectar y desconectar clientes sin provocar xruns pero lo malo es que añade un periodo de latencia (que qjackctl no reporta). jack1 simplemente no tiene modo asíncrono así que si queremos un jack2 que se parezca a jack1 lo lanzamos en modo síncrono añadiendo "-S" (precedido de un espacio y sin las comillas) al comando jackd, es decir, /usr/bin/jackd -S


Como veis en el pantallazo en la parte de abajo a la derecha, yo tengo instalado jack1 así que no me preocupo por esto. Sin embargo, si estáis con jack2, os recomiendo que lo lancéis en modo síncrono.

2. Driver

Usaremos el driver alsa si nuestra tarjeta es PCI o USB. Si tenemos una tarjeta firewire, usaremos el driver firewire. El resto de opciones, o están obsoletas o son para otros sistemas operativos, o para tarjetas soportadas por drivers alternativos y rara vez útiles. Aquí hacemos otro inciso obligatorio....


Soporte de tarjetas de audio


El soporte de tarjetas de audio en Linux está lejos de ser ideal, por lo que es importantísimo informarse antes de comprar. No me voy a extender porque es un tema que no controlo demasiado. Solo unas ideas:

Las tarjetas firewire están soportadas por los drivers del proyecto ffado, mientras que las USB y las PCI, por el proyecto ALSA. En sus páginas oficiales, se puede ver un listado de las tarjetas soportadas. Tener en cuenta que no todas están soportadas igual de bien.

Además, no sólo hay que tener en cuenta la propia tarjeta, sino también los controladores de los puertos USB y firewire.

Lo mejor es preguntar en sus páginas oficiales o en sus listas de correos, o en su defecto, en foros de usuarios, como el de hispasonic GNU/Linux o el superforo de ardour, ambos en castellano.

En inglés, las listas de usuarios de Linux Audio, de ALSA, de ffado, el foro de linuxmusicians, el foro de ardour... Además, algunos canales de IRC en freenode.net como #ffado, #alsa, #jack, #ardour, #opensourcemusicians, #ubuntustudio, etc, son recursos de ayuda en tiempo real que, con un poco de educación, suerte y paciencia, nos pueden ahorrar mucho tiempo y quebraderos de cabeza.

Ver también What audio interfaces should I use with Ardour?

3. Interfaz

Aquí indicamos la tarjeta de audio que va a utilizar Jack. Lo mejor es identificarla por su nombre en lugar de por su número.

Una forma para saber el nombre es usando el comando "cat /proc/asound/cards". Lo vemos entre corchetes. Como podéis observar en el pantallazo, linux-alsa está viendo 4 "tarjetas"; una m-audio 2496, la hda-intel integrada, snd_aloop y un teclado midi hardware, KeyRig 49. Por supuesto, quiero que jack trabaje sobre la m-audio que se identifica como "hw:M2496" y esto es lo que escribo en el campo "Interfaz". No importa que no aparezca en el menú desplegable; en este ejemplo hw:0 es lo mismo que hw:M2496. Es mejor poner hw:M2496 porque la numeración podría cambiar en diferentes arranques del ordenador pero el nombre no.

No con todas las tarjetas es tan fácil y tan directo. En la segunda parte desarrollamos un poco más todo esto y explicamos cómo usar un dispositivo para captura y otro diferente para reproducción.

4. Tiempo real

La casilla Tiempo Real da a jack privilegios de "real-time scheduling", es decir le "da derecho" a disponer de mayor prioridad que otros procesos. Esto es necesario para que jack pueda funcionar de forma estable a baja latencia. A veces se confunde la opción realtime con la necesidad de funcionar con un kernel 'rt'. No es que no tenga nada que ver, pero no es necesario un kernel realtime (con el parche PREEMPT_RT) para poder lanzar jackd con prioridad realtime.

Para que un usuario (es decir, no el administrador del sistema) pueda arrancar jack con la opción 'RealTime' es necesario que el usuario tenga asignada "prioridad de realtime" en el archivo de configuración del sistema '/etc/security/limits.conf' o cualquier otro archivo dentro del directorio /etc/security/limits.d/. En la práctica, esto se consigue haciendo que el usuario pertenezca a un grupo (en Debian/ubuntu, típicamente el grupo 'audio') y declarando el "privilegio" para este grupo, mediante una línea como '@audio - rtprio 99'. Además, debemos añadir otra línea como '@audio - memlock xxxxxx' donde xxxxxx es un número en kbytes relativamente alto. Algunos recomiendan que sea alrededor del 75% de la memoria RAM total. Otros directamente ponen el valor 'unlimited'. Según las advertencias de jack, el valor "unlimited" es peligroso para entornos multiusuario pero para un ordenador personal de usuario único tengo entendido que es aceptable.

En Debian testing y en ubuntu a partir de lucid, la forma más sencilla de darse prioridades de rtprio y memlock unlimted es con el comando:

sudo dpkg-reconfigure -p high jackd

(esto funciona en ubuntu lucid por ejemplo). En ubuntu maverick y probablemente en debian testing y derivadas, hay que especificar jackd1 o jackd2. Por ejemplo, desde una instalación limpia de ubuntu maverick, habría que hacer:

sudo dpkg-reconfigure -p high jackd2

Después, debemos asegurarnos que estamos en el grupo audio con el comando:

groups

Y si no es así, debemos añadir nuestro usuario al grupo audio. Se puede hacer de varias formas, por ejemplo con el comando:

sudo adduser nuestro_nombre_de_usuario audio

Estos cambios requieren reiniciar el ordenador.

Antes de lanzar jack viene bien comprobar que realmente nuestro usuario tiene los privilegios rtprio y memlock. Podemos usar el comando ulimit:

ulimit -r -l

Si la respuesta es algo parecido a:

real-time priority (-r) 99
max locked memory (kbytes, -l) unlimited


ya tenemos el sistema preparado para jack en modo realtime.

Entonces, ¿Cuando es necesario un kernel realtime?

Básicamente y que yo sepa, cuando los dispositivos hardware (tarjeta de audio, controlador firewire) comparten número de IRQ con otros dispositivos. Si recibimos muchos xruns sin motivo aparente (por ejemplo, con solamente jackd activo) a una latencia no excesivamente baja (por ejemplo, con 512 cuadros por periodo) merece la pena intentarlo con el kernel rt. No olvidemos que necesitamos levantar las prioridades de estos dispositivos, lo cual lo podemos hacer de forma automática con el script rtirq. Otro motivo para instalar el kernel rt es que, incluso cuando tenemos un sistema estable con una latencia lo suficientemente baja, queramos participar en una carrera para presumir de latencia. Yo creo que la latencia, cuanta más mejor, siempre que no nos impida interactuar cómodamente, es decir, siempre que no fastidie. Recordemos que el sonido tarda 2,9 ms en viajar a un metro de distancia... A alguien le molesta la latencia real de casi 9 ms cuando se pone a tocar o a cantar a 3 metros de un monitor? Bastante más te puedes alejar y seguirás igual de bien. Claro que se puede argumentar que todo suma, así que en software, cuanta menos latencia mejor. También es verdad, pero sin pasarse...


Para saber más


FAQ de jackaudio.org
Knowing jack, por Dave Philips
Diferencias entre Jack1 y Jack2

sábado, 6 de noviembre de 2010

Qué NO hacer para que funcione jack (y otros pensamientos)

Qué no hacer para que funcione Jack


1. Pensar que el modo realtime de jack y el kernel realtime están relacionados.

2. Elegir un valor de cuadros de periodo excesivamente bajo.

3. Volverse loco con el valor de periodos por buffer.

4. Echarle las culpas de todo, especialmente cuando tratamos de tener audio a través de jack en programas no jack-friendly.

5. Elegir una configuración muy exigente para después lanzar programas a los que no haces ningún favor con estas exigencias, poniendo velas al diablo en lugar de actuar con prudencia.

A mayor latencia mejor respuesta gráfica, entre otras cosas.

Muchas cosas de la vida son similares a la termodinámica: Todo cuesta energía y todo tiene su sitio y su momento y hay que intentar ver las cosas en la escala espacio-temporal adecuada. Por eso muchas veces intentas buscar algo y no lo encuentras. La causa puede ser una de dos, o bien no aportas la suficiente "energía que cuesta" (en forma de trabajo) o bien estás violando la segunda ley, deseando imposibles.

Lo malo es que la frontera entre las dos situaciones es difícil de observar desde dentro de uno mismo y en general es más estrecha y estricta de lo que pensamos al principio, aunque esto sólo lo ves cuando empiezas a envejecer. Entonces es posible que te hagas más consciente de tus limitaciones y no le des tanta importancia si algo te sale mal.

Las cosas van a mejor pero con sus altibajos y sobretodo, con sus enemigos. Y creo que ahora es una época de un bajón en la ilusión de mejorar, lo veo en mí y lo veo a mi alrededor, por culpa de... bueno la culpa está en todas partes, sólo que a algunos nos dan rabia algunas cosas y a otros les parece mal otras y sobretodo, no miramos demasiado hacia dentro. Una vez tenía un jefe que me caía mal hasta que un día me dijo "Pablo, a todos nos gustan más o menos las mismas cosas". Entonces me hizo pensar y consiguió lo que quería, que tuviera un poco de más confianza con él, porque la confianza es la base más importante del trabajo en equipo. Yo no sabía ceder en mi forma de ver las cosas y no quería comprender algunos comportamientos que simplemente no me gustaban. No es que desde ese día me guste la prepotencia y la estupidez pero me doy cuenta de que todos somos humanos.

También, hablar con personas mayores y con niños es muy educativo y nos ayuda a conocernos a nosotros mismos. De todas maneras, si alguien te dice alguna vez que eres un viejo, respóndele: "Yo no soy viejo, lo que ocurre es que he nacido antes que tú".

La próxima entrada irá sobre la configuración de jack pero me está llevando mucho tiempo. Siento ser tan repetitivo y escribir tan poco últimamente de las cosas que importan al que empieza con la música en Linux. No es un camino de rosas pero hay información disponible para empezar al menos.

Eso sí, cada uno/a debe hacer lo que crea mejor y usar las herramientas que mejor le parezcan. Yo aquí intento ayudar en el lado linuxero.

Si encuentro alguien con un Windows me dará corte pedirle que me deje trastear con jack2 pero esta es una prueba que tengo pendiente hacer:

Lanzar un secuenciador midi en un ordenador con linux (A), transmitir el midi a través de una red cableada local a un ordenador con Windows XP (B) en el que tenemos un sampler o un instrumento virtual, de forma que el secuenciador del ordenador A lo haga sonar y, finalmente, transmitir el audio de salida del sampler de vuelta por el cable de red al ordenador A, en el cual está conectada la tarjeta de audio buena por la que suena el sampler sin latencia aparente.

Sé que se puede hacer y estoy deseando probarlo. A ver si alguien se adelanta y nos cuenta algo, porque por aquí estoy sin ventanas.

Saludos y que lo paséis bien estos días.

Ah, gracias a Luis Garrido por su post en hispasonic sobre los kernels, los cajeros y los clientes que están en la cola del supermercado. Por fin lo he entendido, creo.

domingo, 24 de octubre de 2010

GNUGitarINUX. Instrucciones básicas.

He regalado un Live CD de GNUGuitarINUX v0.04 a un amigo guitarrista interesado en Linux pero usuario de Windows a la hora de hacer música. Estas son las instrucciones que he escrito para él y para todo guitarrista que quiera tener su primer contacto con Linux y algunas de sus aplicaciones, especialmente rackarrack y guitarix, a través de esta distribución. Si algo de esto te suena a chino no te preocupes, pasa por alto lo que no entiendas y sigue leyendo.


¿Qué es GNUGuitarINUX?

Es un Live CD basado en Linux 2.6.31 realtime y PAE, con un entorno gráfico de escritorio ligero (fluxbox) y unas pocas aplicaciones orientadas a guitarristas, con la idea de ser usado como una caja de efectos para guitarra aunque puede hacer más cosas.

Un Live CD se puede ejecutar desde el lector de CDROM del ordenador sin que afecte para nada al disco duro y a los sistemas operativos instalados en él.

Esta distro la ha preparado todoesverso y la anunció en este post, donde también da unas instrucciones básicas de uso y más explicaciones.

Lista de aplicaciones

(Pestaña Audio)

Jack Control. Ver abajo
Volumen. Ver abajo.
JACK EQ. Un ecualizador . http://jackeq.sourceforge.net/
JACK Capture. Captura a un archivo de audio lo que escuchas por los altavoces.
Sooperlooper. Un super-looper. http://www.essej.net/sooperlooper/
Hydrogen. Una caja de ritmos. http://www.hydrogen-music.org/
Audacity. Un editor de audio. http://audacity.sourceforge.net/
Aqualung. Un reproductor de audio. http://aqualung.factorial.hu/

(Pestaña GNUGuitarINUX)

Rackarrack. Una rack de efectos virtual para guitarra. http://rakarrack.sourceforge.net/
Guitarix. Un ampli de guitarra virtual para sonidos rock, blues, metal... http://guitarix.sourceforge.net/
Tuxguitar. Un editor de notación en tablatura para guitarra. http://tuxguitar.herac.com.ar/
Jack Rack. Un sencillo host de plugins LADSPA. http://jack-rack.sourceforge.net/

(Pestaña Extras)

PCmanFM. Un gestor de archivos ligero.
Midori. Un navegador web ligero.
Consola. Terminal de línea de comandos.
X Windows Snapshot.
Xclipboard. Para tomar notas.
Xkill, Para matar procesos gráficos (ventanas colgadas).
Xrefresh
Xvidtune
Htop. Monitorización de procesos. http://htop.sourceforge.net/index.php?page=main

Fluxbox es un entorno ligero de escritorio. http://www.fluxbox.org/

El sistema operativo y las aplicaciones que contiene este CD son software libre, lo que significa que pueden ser estudiadas, modificadas y redistribuidas libremente. Ver http://es.wikipedia.org/wiki/Software_libre

Para más información ver http://gnuguitarinux.sourceforge.net/

¿Qué es Jack Control?

Jack Control o qjackctl (http://qjackctl.sourceforge.net/) es una aplicación gráfica para configurar y controlar el servidor de audio (o demonio) jackd. JACK (http://jackaudio.org) es un acrónimo recursivo que significa "Jack Audio Connection Kit". El demonio de JACK, jackd, es un sistema de audio orientado a la producción profesional que permite latencia baja y previsible en la interacción entre las aplicaciones jackficadas y la tarjeta de audio. Además permite conectar los puertos de audio (y MIDI) de las aplicaciones y de la tarjeta de audio de una forma superflexible.

Jack utiliza el driver alsa (para las tarjetas PCI, PCmcia y USB) y el driver firewire (para las tarjetas firewire).

¿Qué es ALSA?

ALSA, Advanced Linux Sound Architecture (http://www.alsa-project.org/main/index.php/Main_Page), es un proyecto que, entre otras cosas, provee una serie de drivers que hacen funcionar las tarjetas de audio PCI, PCmcia y USB en Linux. Estos drivers están integrados en el kernel como módulos. El módulo correcto para cada tarjeta se cargará automáticamente al arrancar el ordenador si la tarjeta está soportada. No todas las tarjetas están soportadas. Ver http://www.alsa-project.org/main/index.php/Main_Page

¿Qué es FFADO?

FFADO, Free Firewire Audio Drivers (http://www.ffado.org) es el proyecto que hace posible que las tarjetas de audio Firewire puedan funcionar en Linux. No todas las tarjetas están soportadas. Para comprobar la situación del soporte de las tarjetas de audio firewire disponibles en el mercado, ver http://www.ffado.org/?q=devicesupport/list

Preparar el Live CD

Descargar desde http://sourceforge.net/projects/gnuguitarinux/files/
Quemar a CD con tu herramienta favorita.

Usar el Live CD

Apuntar estos pasos:

La BIOS debe de estar configurada para que arranque primero desde el lector de CD.
Arrancar el ordenador con el CD insertado.
En la primera pausa no hacer nada y dejar que siga con la opción por defecto.
Después de un rato, si todo va bien, se verá el fondo de escritorio, con una foto de una guitarra.
Pulsar con botón derecho sobre el escritorio para que aparezca el menú principal de fluxbox.
Lanzar con botón izquierdo: Extras -> Consolas -> Bash
Esto abrirá una terminal, donde introducimos lo siguiente:

setxkbmap es

Y pulsamos ENTER. Esto es para que el teclado responda al layout español.
Ahora, también en el menú Extras, lanzamos Internet (navegador Midori).
Para acceder a las ventanas minimizadas llevar el ratón a la parte inferior de la pantalla.
Si tienes conexión a Internet, no hace falta apuntar más. Puedes seguir estas instrucciones
desde tu buzón de correo o desde semicorchux.

**** Un rato más tarde, ya desde GNUguitarINUX y después de haber lanzado el navegador *****

Lanzar Audio -> Volumen

Es una herramienta que da acceso al mezclador interno de la tarjeta de audio, si existe. Comprobar que los canales de salida y de captura están activados y a un nivel suficiente.

Lanzar Audio -> Jack Control

Si inicia, genial. (Si no, ver más abajo) Pulsar el botón Setup. En el campo Interfaz, flecha derecha, comprobar en el menú desplegable que hemos elegido la tarjeta de audio correcta, en caso de que tengamos más de una. En este caso, asegurarnos que es la tarjeta a la que hemos conectado la guitarra y los altavoces.

Pulsar el botón Conexiones. Aquí se pueden establecer las conexiones virtuales entre clientes de jack. System representa la tarjeta de audio. Normalmente el primer puerto de captura se corresponde con la primera entrada analógica y los dos primeros de reproducción corresponden a la salida estéreo frontal, o a las dos primeras salidas analógicas en el caso de una tarjeta profesional.

A partir de aquí podemos seguir experimentado con las aplicaciones. No te pierdas rackarrack.

Las conexiones físicas y virtuales típicas pueden ser:

Físicamente, de la guitarra a la primera entrada analógica de la tarjeta y de las dos primeras salidas analógicas de la tarjeta al equipo de sonido.
Por software, del system:capture_1 a una entrada de rakarrack y de las salidas de rakarrack a los system:playbacks_1 y _2.

Si hay problemas...

Si no llegas al entorno gráfico, vuélvelo a intentar. Si vuelve a fallar... sigue las sugerencias de José GDF en su comentario. De todas formas, hay un montón de distribuciones Linux con mejor soporte para este tipo de problemas, en las cuales también podrás instalar rakarrack y guitarix.

Si jack no arranca, da la información contenida en la ventana Mensajes y además, la salida de este comando de consola, para ver qué tarjetas de audio tienes conectadas:

aplay -l (ele minúscula)

Para copiar / pegar desde terminal a terminal, usa el truco del ratón-grúa: Seleccionar de la forma normal (arrastrar con botón izquierdo) y soltar el texto con el botón central. (No usar Control + C)

Créditos y agradecimientos

Gracias a José GDF por recordarnos que GNUGuitarINUX existe.

GNUGuitarINUX es un proyecto de todoesverso. Su post original en Taringa!
http://taringa.net/posts/linux/5374468/GNUGuitarINUX---Live-CD-pedalera-de-guitarra.html
Y su actualización a la versión de referencia de este manual, v0.04:
http://www.taringa.net/posts/linux/6131905/GNUGuitarINUX-v0_04.html

AVLinux pone el kernel. Yo diría que es el hermano mayor de GNUGuitarINUX. Tiene un Live DVD instalable a disco duro con un escritorio más manejable y mucho más software orientado al estudio profesional. No todo el contenido de AVLinux es software libre y el DVD no es libremente distribuible. Más información y descargas en:
http://www.bandshed.net/AVLinux.html

Por supuesto, todos los proyectos mencionados tienen el crédito y los agradecimientos.

lunes, 27 de septiembre de 2010

Cómo lanzar aplicaciones sueltas en el idioma original

El cual es el inglés en la gran mayoría de los casos.

Esto es útil para buscar ayuda googleando, entender mejor los manuales de referencia o simplemente porque nos da la gana. Sin embargo, no queremos que afecte al idioma del resto de programas ni al del entorno de escritorio.

Para ello podemos usar el prefijo:

LANG=en.UTF-8

Al menos sirve en muchos casos.

Por ejemplo:

LANG=en.UTF-8 qjackctl

o

LANG=en.UTF-8 ardour2

sábado, 25 de septiembre de 2010

Desvaríos

Mucha gente se rinde con Linux porque recibe muchos xruns. La verdad es los xruns son una mierda. Lo bueno es que al menos jack lo reconoce honestamente. Eso te da pié a investigar e intentar mejorar el "sistema". Nadie lo sabe todo en el mundo GNU/Linux por lo que a veces hay que dar varias vueltas hasta que das con el truco o equivocación que arregla el problema o que estabas cometiendo sin darte cuenta, respectivamente. Todo es así en la vida real también. Nada es perfecto, muy lejos de ello.

Mirar qué video de xiph.org, A_Digital_Media_Primer_For_Geeks. Como comenta alguien, la lección de universidad a la que te hubiera gustado asistir. He empezado a traducirlo. Se explican las bases del audio y del video digital. Necesito ayuda, no hace falta saber mucho inglés, pero que suene natural en castellano. Está muy bien explicado pero el lenguaje es a veces bastante informal. Me podéis escribir a pablo-fbus en gmmil punto com. El nombre del servidor está mal escrito y en mi nombre hay un punto en lugar de un guión. Lo pongo así para protegerme de los robots malos.

Me cuesta escribir, creo que escribo entradas demasiado largas e innecesariamente complicadas. De hecho, muchas de las cosas que he explicado se pueden hacer de forma bastante más sencilla ahora mismo. Voy a empezar a ser más breve y menos estricto. Este el segundo post que no va a ir al índice general de entradas. Voy a copiar a José, que es el maestro en esto de no complicarse. Me encanta su blog. Lees el insulto del título y te asustas un poco, pero es muy majo. Sin embargo, pienso que hay que cuidar el vocabulario.

Me da pereza volver atrás para corregir cosas o simplificarlas radicalmente pero es lo que debería hacer de una vez. En realidad es todo bastante más fácil de lo que parece, tengo que corregir todo.

Los linuxeros somos unos incomprendidos, tristemente, pero qué vas a hacer. Todo el mundo se equivoca, que por cierto es lo que más me gusta de GNU/Linux, que te das cuenta que la vida virtual es tan real como la vida de cada día, con una mayoría de gente maja y normal.

Todo el mundo se equivoca. La mayoría sigue el camino que cree más fácil. Yo prefiero quedarme con el recuerdo del éxito y olvidarme de los fracasos pero me cuesta mucho estar seguro del todo de algo y siempre tengo que volver atrás, a corregir cosas y así no acabo nunca.

A todos y sobretodo a Igny, ¡Gracias por comentar! :)

Seguiré escribiendo, pero con menos frecuencia.

domingo, 22 de agosto de 2010

Scripts en Jack Control

Aquí tenemos el índice general de entradas de semicorchux

#########################
Notas de revisiones:
Revisión 0: 22 agosto 2010. Publicado.
Revisión 1: 16 octubre 2010. Corregido error en línea marcada con Rev. 1. Añadida advertencia respecto a /etc/sudoers

#########################

Qjackctl tiene una opción muy útil para ejecutar scripts en 4 momentos diferentes alrededor del servidor de audio jack; antes de iniciarlo, después de iniciarlo, antes de detenerlo y después de detenerlo.



Veis que he preparado 4 scripts. Vamos a verlos, pero antes recomiendo lo siguiente:

Evitar la resurrección de pulseaudio

En distribuciones más especializadas, pulseaudio no es el servidor por defecto y algunos recomiendan desinstalarlo del todo en ubuntu. Otros consiguen que aplicaciones no jackificadas que suenan a través de pulseaudio se puedan conectar con clientes de jack por medio del plugin pulse-jack. Yo actualmente prefiero que todo vaya a través de jack cuando estoy con jack y a través de pulseaudio cuando no estoy con jack.

En ubuntu, al menos en karmic, cuando se lanza qjackctl (Jack Control) pulseaudio se suspende (pasuspender). Esto funciona bien en muchos casos pero no es lo ideal y además la coexistencia de pulseaudio y jack es aún problemática en ordenadores con poca memoria RAM. Creo que es mejor matarlo y limpiar algo de basura, como vemos más adelante. El caso es que si matamos pulseaudio, éste se relanza automáticamente a los pocos segundos si no lo impedimos.

Veamos cómo evitar la resurrección de pulseaudio.

En una terminal de usuario en la localización por defecto:

Rev. 1
$ gedit .pulse/client.conf

Copiamos las líneas:

#pulseaudio, no resucites:
autospawn = no

Y guardamos el archivo.

Así podremos matar pulseaudio sin remordimientos y para toda la sesión, sin necesidad de desinstalar nada.

Comprobar que tenemos una versión reciente de patchage

Hacer las conexiones a través de Jack Control puede llegar a aburrir bastante. Mucho mejor un patchbay cómodo e intuitivo como es Patchage. Las versiones en karmic y en lucid están anticuadas. Recomiendo la versión 0.4.4 que se puede conseguir tanto en lucid como en karmic desde el repositorio ppa:philip5/extra. De paso, (re)instalamos a2jmidid, gracias al cual se pueden hacer conexiones entre puertos alsa midi y jack midi, incluido el hardware midi (opción -e).

$ sudo add-apt-repository ppa:philip5/extra
$ sudo apt-get update
$ sudo apt-get install patchage a2jmidid

En esta entrada hablamos de los PPA's y del repositorio de Philip Johnson, tres hurras por él.

Permitir la selección de la frecuencia de la cpu sin necesidad de contraseña

Resulta que si ponemos la frecuencia de la cpu a "ondemand" (comportamiento por defecto) ésta cambia repentinamente según la carga que tenga el ordenador. Esto es motivo de xruns y hay que evitarlo. Cuando trabajamos con jackd, la recomendación es ponerla a "performance" o al menos fijarla en un valor más bajo pero evitar que salte.

Se puede hacer de varias maneras, incluido añadir un applet en el panel de gnome, que nos exige contraseña.

Lo incluyo como propuesta en el script de "antes de iniciar jackd" pero para ello hay que hacer que el sistema nos permita lanzar el comando "sudo cpufreq-set" sin contraseña. (Ojo con esto. Es peligroso. Ver los comentarios de desesperado. Si no estás seguro, mejor déjalo y ya usarás el applet de gnome para cambiar el modo de frecuencia de la CPU).

Para ello, en una terminal lanzamos:

$ sudo visudo

Esto edita el archivo /etc/sudoers. El editor es vi y no se puede editar de otra forma, que yo sepa. Si no estamos familiarizados con vi, lo mejor es darle a la tecla i, y se comportará más o menos como lo que esperamos. Nos movemos con los cursores y al final del archivo escribimos la siguiente línea, cambiando "usuario" por vuestro nombre de usuario:

usuario ALL=NOPASSWD: /usr/bin/cpufreq-set

Ahora damos a escape y guardamos con:

:wq

Los scripts

Son archivos de texto sencillo que coloco en el directorio /home/usuario/bin. Por supuesto, después de crearlos y guardarlos, hay que darles permiso de ejecución. Lo podemos hacer de forma gráfica, con botón derecho, propiedades, pestaña permisos.

Estos son:

/home/pablo/bin/antes-de-iniciar-jackd

#!/bin/bash
#Obligo mis dos cpus a modo performance
#Tu caso puede ser diferente. Mira "cat /proc/cpuinfo |grep processor"
#para ver cuantas CPU's tienes o mejor, mira las posibilidades que
#te da el applet de monitor de frecuencia de CPU
#Borrar estas líneas si no modificamos el archivo /etc/sudoers
sudo cpufreq-set -c 0 -g performance
sudo cpufreq-set -c 1 -g performance
#mato pulseaudio y espero un segundo
pulseaudio -k
sleep 1
#limpio /dev/shm
rm -f /dev/shm/pulse*

Lo de limpiar /dev/shm de la porquería que haya podido dejar pulseaudio es muy importante para ordenadores de poca memoria RAM pues a veces se dan problemas por causa de este bug:

https://bugs.launchpad.net/ubuntu/+source/jack-audio-connection-kit/+bug/491329

/home/pablo/bin/despues-de-iniciar-jackd

#!/bin/bash
#Lanzo a2jmidid con la opción -e para poder conectar mi teclado midi a clientes jack midi
a2jmidid -e &
sleep 1
#Lanzo patchage para hacer las conexiones entre los puertos de clientes de jack
patchage &

/home/pablo/bin/antes-de-detener-jackd

#!/bin/bash
# mato todos los clientes de jack. Ampliar/Modificar lista en caso necesario.
killall mplayer gmplayer vlc amarok ardour-2.8.11 hydrogen qsynth stretchplayer tuneit fst.exe.so guitarix rakarrack patchage a2jmidid

De esta forma, con el botón "Detener" de Jack Control se matan todos los clientes de jack. Al menos, esta es la idea. Ampliar la lista según necesidades. Para ver los nombres de los procesos de los clientes de jack, podemos usar top o htop. No pasa nada porque sobren entradas.

/home/pablo/bin/despues-de-detener-jackd

#!/bin/bash
# mato jackd
killall jackd
sleep 1
# vuelvo a poner las dos cpus a "ondemand"
#Borrar estas líneas si no modificamos /etc/sudoers
sudo cpufreq-set -c 0 -g ondemand
sudo cpufreq-set -c 1 -g ondemand
sleep 1
# arranco pulseaudio
pulseaudio --start


A tener en cuenta:

1) Si en el setup de qjackctl, pestaña "Otras", marcamos "Iniciar el sevidor JACK al cargar qjackctl", nos ahorramos un click.

2) En este caso, hay que evitar a toda costa que si alsa ve más de un interface de audio pueda hacer que jack se equivoque de tarjeta. Para esto, la mejor forma que conozco es empleando la identificación alfanumérica de la tarjeta de audio "buena". Es decir, en lugar de seleccionar el interface hw:0, por ejemplo, mejor escribir en el campo interface "hw:TARJETA" (como se llame, entre corchetes, según la salida de "cat /proc/asound/cards") como propusimos en esta entrada.

Créditos y para saber más

http://www.rncbc.org/drupal/
ubuntustudio forum
linuxmusicians.org

jueves, 19 de agosto de 2010

OT: Cómo personalizar los iconos de los lanzadores en gnome (Dedicado a David y a Noa)

En este sencillo tutorial explico la forma de crear tus propios iconos infantiles para los lanzadores gráficos. Es completamente off-topic, ya perdonaréis. Lo he escrito pensando en mis sobrinos. Aunque no creo que lo lean en poco tiempo, aquí queda, para cuando sean un poco más mayores y, con esperanza, estudien GNU/Linux en clases de iniciación a la informática.

Éste lo usaba hasta hace poco para lanzar a2jmidid (no interesante para no músicos):

Mi super-icono de a2jmidid

Éste para poner la frecuencia de la/s CPU/s en "performance" (interesante para otra entrada)

Tux con una mano señalando arriba

Éste para que vuelva a ajustarse automáticamente según la carga de trabajo, "ondemand":

Tux con una mano en puño

Éste para matar todos los procesos relacionados con jack (también para otra entrada). Es lo que hago cuando no estoy inspirado (la mayoría de las veces) y pienso que mejor me dedico a otra cosa:

Tux decepcionado consigo mismo

Y éste para apagar el ordenador inmediatamente con un click , cuando "ya huele" y me decido a levantarme de la silla. Lo usaré como ejemplo hasta el final.

Tux tapándose la nariz

Si no los tenemos instalados, instalamos Tuxpaint (más los sellos) y GIMP. En la terminal:

$ sudo apt-get install tuxpaint tuxpaint-stamp-defaults gimp

En Tuxpaint seleccionamos un fondo. Yo he elegido el blanco. Ahora vamos a herramientas, sellos, y entre éstos buscamos el que nos guste. O varios a la vez. O algo más sofisticado. Y después pulsamos guardar.

Ahora lanzamos el gimp y abrimos imagen con 'Ctrl+O'. Ahora, con 'Ctrl+H' mostramos los archivos ocultos y buscamos (en nuestro home) ".tuxpaint/saved".

Elegimos la imagen y la abrimos. Después recortamos la parte visible con el bisturí de la caja de herramientas.



Si estamos de acuerdo con el recorte, pulsamos con el ratón en dentro de el mismo y si no, fuera para empezar de nuevo y ajustarlo mejor. Dentro de nuestro home creamos un directorio llamado "iconos". Y desde el menú "Archivo" guardamos una copia, seleccionando el tipo de archivo por extensión (abajo a la izquierda), por ejemplo, PNG en:

/home/usuario/iconos

Ahora, con botón derecho sobre el panel de gnome, añadimos un lanzador de aplicación personalizado y en el campo "comando" pego el texto:

sudo shutdown -h now

Pulsamos el icono y navegamos a /home/usuario/iconos para elegir el nuevo.

Si no funciona, probar con otro comando que no necesite privilegios de administrador. El truco para que funcione un lanzador con sudo está en el archivo /etc/sudoers pero eso no forma parte de este tutorial.

sábado, 17 de julio de 2010

Compensación de latencia de captura en Ardour

#########################
Notas de revisiones:
Revisión 0: 17 julio 2010. Publicado.
#########################

En este tutorial vamos a mostrar cómo se puede compensar la latencia de captura en Ardour2 cuando hacemos overdubbing, es decir, cuando capturamos audio al tiempo que escuchamos una pista grabada anteriormente.

Antes de nada, vamos a hacer una distinción entre dos formas de monitorizar (escuchar lo que estamos grabando al mismo tiempo); por software y por hardware.

La monitorización por hardware tiene una serie de ventajas. No consume CPU, podemos reducir drásticamente la probabilidad de xruns y la latencia es inexistente ("latencia cero"). Para monitorizar usamos la mesa de mezclas o la propia tarjeta de audio, si lo permite. En este caso, conviene elegir un valor de cuadros por periodo alto en Jack. No sólo no necesitamos baja latencia en software; además, subirla va a dar mejor rendimiento y estabilidad.

La monitorización por software es posible si tenemos un sistema ajustado para una latencia aceptablemente baja. Requiere menos hardware y permite monitorizar con procesado de señal por software (efectos y amplificadores virtuales). Creo que este es el caso más común en estudios caseros. La configuración de jack, para encontrar un buen equilibrio entre latencia y rendimiento, es esencial en este caso.

En el tutorial que sigue he trabajado con una latencia bastante baja. Normalmente lo tengo así porque suelo tocar la guitarra con rakarrack y con algún otro ampli virtual. Cuando grabo en ardour, también, siempre, hago monitorización por software. A 128 cuadros por periodo y 48.000 Hz, con 2 periodos por buffer, la latencia teórica de bucle completo es 256 cuadros ó 5,3 ms. La latencia real será un poquito mayor, como vimos en la entrada acerca de jack_delay.

En todo caso, con una latencia tan baja, no tengo claro si merece la pena compensar la latencia de captura en overdubbing. Con monitorización por hardware y latencia en Jack alta, es esencial. Al final de la entrada elaboro un poco más esta idea.

Procedimiento


En ardour, añadimos tres pistas mono y en el mezclador asignamos sus entradas al puerto de captura correspondiente a la entrada donde tenemos conectado un micrófono. En el caso del pantallazo, el segundo puerto de captura, in 2.



Ahora grabamos un par de notas en la primera pista. Yo lo hecho con la guitarra acústica. Dejo la segunda pista armada para grabar...



Colocamos el micrófono entre los auriculares de monitorización y grabamos en la segunda pista lo que teníamos grabado en la primera, que suena por los auriculares.



Se supone que cuando hagamos overdubbing con una segunda guitarra o con la voz vamos a tocar o cantar sincronizados con la música grabada, de forma natural. Queremos que lo que capturamos por el micro vaya perfectamente sincronizado con la pista grabada.

En el pantallazo de arriba no se observa desplazamiento porque el zoom está muy alejado. Pero existe y vamos a medirlo.

Con botón derecho sobre los relojes, los configuramos para que muestren los cuadros o muestras (samples)...



y en "opciones misceláneas", que el reloj secundario muestre la diferencia al punto de edición.



Ahora, nos aseguramos que el modo de edición es "Deslizar" (slide) y que la rejilla no está activa. Ponemos "marca" como punto de edición (también lo podemos hacer con "ratón") y configuramos el display de "empujar" en muestras.



Elegimos el cursor como foco del zoom...



Un truco (no está en los pantallazos):

Para hacer muy rápido los zooms sobre el cursor podemos hacer lo siguiente: Voy a Transporte -> Cursor -> Centrar cursor y pulso la tecla "," (coma). Esta es la forma rápida de asignar los atajos de teclado... Y sobre Ver -> Zoom -> Acercar, elijo la tecla "." (punto). Así tenemos tres dedos contiguos para centrar el cursor, acercar y alejar. ¡La tecla para acercar por defecto, "=", viene muy a desmano en un teclado español!

Otro truco es hacer zoom con la rueda del ratón, con la tecla Control pulsada.

En cualquier caso, acercamos (zoom in) y desplazamos el cursor hasta que lo tengamos al comienzo de una señal de audio (una de las notas que hemos grabado) en una de las pistas, más o menos. Además, creamos una marca, con botón derecho y la desplazamos al comienzo de la señal en la otra pista.

ADVERTENCIA: Hay un bug en ardour2 (hasta revisión 7387 por lo menos, #2798) que hace que el segundo paso de zoom, en el sentido de más cercano a más lejano, muestre incorrectamente la posición de las regiones. ¡Evitarlo! Propongo trabajar con el tercer paso.

Observamos la diferencia en muestras en el reloj secundario y escribimos ese número en el display de "empujar", como muestra la imagen.



Empujamos hacia atrás la segunda pista.





De esta forma hemos sincronizado la pista capturada en overdubbing. Si ahora hacemos una grabación real sabemos que la pista grabada va atrasada en el tiempo el mismo número de samples que hemos medido en la prueba. En la imagen está delante y debemos empujarla hacia atrás.

Para una determinada configuración de jack sobre una determinada tarjeta de audio, el número de muestras a "empujar hacia atrás" será siempre el mismo y será algo mayor que la cantidad de cuadros por periodo. En el caso seguido en este tutorial, tengo aproximadamente 195 cuadros o muestras de desfase y el tamaño del periodo (cuadros por periodo) y, por lo tanto, la latencia teórica de entrada, es de 128 muestras.

Como se ve en el último pantallazo, también tenemos la posibilidad de "empujar atrás por compensación de captura". Esto empuja hacia atrás, precisamente, la cantidad de cuadros por periodo que hemos configurado en jack (lo podéis comprobar). Se observa que la compensación no es perfecta pues no tiene en cuenta la latencia de captura propia de la tarjeta de audio.


Podemos hacer algo para no tener que desplazar manualmente cada pista después de grabar: Declarar en la configuración de Jack la latencia de entrada. Guardamos y cerramos ardour y vamos al setup de qjackctl.



El resultado al grabar la tercera pista es éste:




Sin embargo, como apuntamos al principio, 195 muestras de desfase es realmente muy poco y el desfase producido por la propia tarjeta, del orden de 65 muestras en mi caso, aún menos.

Dependerá de cada caso y de cada persona, pero como norma general, si tenemos una latencia lo bastante baja como para permitirnos la monitorización por software, el desfase será muy pequeño y es muy probable que no lo notemos. Si en cambio, monitorizamos por hardware y tenemos en jack un valor de cuadros por periodo elevado, la compensación es necesaria, aunque probablemente nos conformemos con empujar hacia atrás (o bien declarar en jack) la compensación teórica, igual al tamaño del periodo.

miércoles, 26 de mayo de 2010

Cómo medir la latencia real del sistema jack-hardware de audio

###################################
Notas de revisiones:
Revisión 0: 12 junio 2010. Publicado.
Revisión 1: 16 junio 2010. Añadidos créditos.
###################################


En la anterior entrada vimos cómo configurar el script rtirq para que nos levante automáticamente la prioridad de la tarjeta de audio (y de otros "kernel threads" importantes para el trabajo con MIDI). De esta forma, podemos conseguir en jack latencias teóricas asombrosamente bajas sin recibir xruns.

Con esto y M-audio Audiophile 2496 (PCI), consigo mantener jack (antes de lanzar ninguna aplicación, eso sí) funcionando durante un buen rato con 0 xruns a 96000 Hz, 16 cuadros por periodo y 2 periodos por buffer, con un consumo de CPU de alrededor de 20 % según marca el display de Jack Control. Sólo el conseguir que jack llegue a arrancar con estos parámetros es ya una señal de que tenemos un sistema al menos aceptablemente bien ajustado para el trabajo con audio en tiempo real, a baja latencia y libre de xruns.

El valor de latencia que aparece en el setup de qjackctl (abajo a la derecha) es la latencia de bucle completo (entrada + salida) calculada a partir de la fórmula:

(p·n / r) x 1000

Donde p es el valor de cuadros por periodo, n son los periodos por buffer y r la frecuencia de muestreo. Se multiplica por 1000 para que el resultado final salga en milisegundos.

Con p=16, n=2 y r = 96000, tenemos una latencia calculada de 0,333 ms.

¿Significa esto que si arrancamos jack con estos parámetros, conectamos virtualmente en jack el capture_1 al playback_1 y conectamos físicamente una fuente de sonido (por ejemplo, una guitarra) a la primera entrada analógica, habrá un "retardo" de 0,333 ms desde que pulsamos una cuerda hasta que escuchamos el sonido por los altavoces?

No. La indicación de jack no es una medida real de latencia. Para medir la latencia real de bucle completo podemos usar una herramienta llamada jack_delay o jdelay. Copio la descripción original:

"This is a small command line JACK app you can use to measure the latency of your sound card. It uses a phase measurements on a set of tones to measure the delay from the output to the input. Accuracy is about 1/1000 of a sample".

Instalación...

Está en los repositorios de Debian y ubuntu, con el nombre "jdelay".

Sin embargo, mejor compilar para obtener la última versión ya que en ésta aparece el valor de la latencia en milisegundos, no solamente en cuadros como probablemente encontraremos si instalamos el paquete. Tampoco pasa nada, pues podemos calcular la latencia en milisegundos diviendo los cuadros entre la frecuencia a la que esté trabajando jack.

Podemos descargar las fuentes desde:

http://www.kokkinizita.net/linuxaudio/downloads/index.html

La compilación es sencilla. Creo que sólo hacen falta las librerías de desarrollo de alsa y de jack, libasound2-dev y libjack-dev.


Uso

Advertencia: Hacer esto con el volumen de vuestro equipo de música completamente a cero. Si os confundís y conectáis la salida de jack_delay a los system_playbacks, el ruido es muy desagradable!

Si habéis compilado, el comando es "jack_delay". Si habéis instalado el paquete, "jdelay" (creo).

La salida de jack_delay se conecta a través de jack al system:playback_1 que representa la primera salida analógica. Desde ésta llevamos un cable a la primera entrada analógica que en jack aparece como system:capture_1, la cual conectamos a través de jack a la entrada de jack_delay, cerrando el bucle. En el pantallazo lo vemos más claro. La línea roja gruesa representa el cable físico.



En la salida de terminal de jack_delay, observamos que hay diferencia entre la latencia calculada y la latencia real del sistema hardware-software (tarjeta de audio + alsa-jack). Por ejemplo con:

p = 64
n = 2
r = 48000

tengo una latencia de 188,6 cuadros, que es mayor que la teórica 128 (64 x 2). En milisegundos, el valor resulta de 3,93 frente al 2,67 calculado. Esa latencia añadida es la que ocurre en los convertidores DA y AD.

No es buena idea llevar el sistema a la menor latencia posible en todas las circunstancias. De hecho, es muy mala idea. Cuando estemos editando, mezclando y masterizando subir los cuadros por periodo.

Utilizar un valor de cuadros por periodo bajo solamente cuando sea necesario. Por ejemplo, para capturar audio mientras hacemos monitorización por software.

Créditos

Jack_delay es una utilidad escrita por Fons Adriaensen, ingeniero de sonido y desarrollador de excelentes herramientas de software para Linux.
http://www.kokkinizita.net/linuxaudio/

domingo, 9 de mayo de 2010

Configuración del script rtirq para muy baja latencia

###################################
Notas de revisiones:
Revisión 0: 8 mayo 2010. Publicado.
Revisión 1: 15 mayo 2010. Retocado.
Revisión 2: 26 mayo 2010. Añadida nota sobre los sirq-timers y la prioridad de jackd
Revisión 3: 28 mayo 2010. Actualizada la explicación sobre los sirq-timers, reordenado y modificado título
Revisión 4: 26 noviembre 2010. Añadida advertencia "sólo funciona con kernel rt"
Revisión 5: 8 enero 2011. Actualizado: Funciona con cualquier kernel >= 2.6.39 con threadirqs habilitado.
###################################


El script rtirq-init está empaquetado y disponible en la mayoría de las distros. En Debian/ubuntu el paquete se llama "rtirq-init".

A partir de la versión del kernel 2.6.39, el script funciona en kernels precompilados como "generic" o "low-latency", siempre y cuando tengan habilitada la opción de arranque "threadirqs". Es decir, ya no es necesario un kernel modificado con el parche realtime para que este script funcione.

Si usamos grub2 como gestor de arranque, una forma de habilitar "threadirqs" es editar el archivo /etc/default/grub.

$ sudo gedit /etc/default/grub

Buscamos la línea

GRUB_CMDLINE_LINUX=""

y la modificamos a:

GRUB_CMDLINE_LINUX="threadirqs"

Para que el cambio tenga efecto, debemos actualizar grub:

$ sudo update-grub

Y reiniciar



Este script levanta las prioridades de los "kernel threads" más importantes para el trabajo con audio y MIDI en tiempo real y a baja latencia, automáticamente al arrancar el ordenador. Este script no es necesario en todos los casos, pero a veces ayuda.

Si escribimos en la terminal:

$ sudo updatedb
$ locate rtirq

Entre otros debería dar:
/etc/default/rtirq
/etc/init.d/rtirq

/etc/init.d/rtirq es el script, que lee el archivo de configuración /etc/default/rtirq.
Es este el archivo que debemos editar para conseguir el objetivo.

El objetivo depende de cada caso, pero normalmente será levantar las prioridades de:

1º El reloj y los temporizadores del sistema (para precisión con MIDI)
2º La tarjeta de audio (para baja latencia de audio)

Todo lo indicado en esta entrada lo vamos a hacer en línea de comandos y vamos a usar htop como monitor del sistema. Propongo terminator como emulador de terminal.

$ sudo apt-get install terminator htop

Ahora vamos a lanzar terminator y lo vamos a maximizar. Botón derecho sobre la pantalla y dividimos verticalmente. En la ventana de la derecha, botón derecho y dividimos horizontalmente. Tenemos 3 terminales.

En la de la izquierda lanzamos:

$ htop

htop nos da un montón de información sobre los procesos y el consumo de recursos de nuestra máquina. Hacemos:

F2 --> Display options --> Desmarcar "hide kernel threads" --> F10
F6 --> Sort by: PRI

Así vemos los procesos, incluidos los "kernel threads", ordenados por prioridad. Al menos en mi caso, los kernel threads cuya prioridad no ha sido levantada automáticamente al iniciar el ordenador por rtirq, toman la prioridad (omitiendo el signo) 51 ó 50. Los que están por encima es que han sido levantados por rtirq.

En una terminal de la derecha vamos a ver los "interrupts" con el comando:

$ cat /proc/interrupts

En la columna de la derecha tendremos que adivinar cuál es nuestra tarjeta de audio. Con una m-audio Audiophile 2496 veo que ICE1712 está en el número 22. Esto será diferente para cada sistema hardware-software, pero lo pongo como ejemplo. Si tu tarjeta es usb, debes fijarte en el número de bus, por ejemplo ehci_hcd:usbx o uhci_hcd:usbx. Con el comando lsusb puedes ver el número de bus usb en la primera columna. Si nos fijamos ahora en htop, vemos en la columna "Command" el número de irq seguido por su identificación. En mi caso, en la prioridad 51 veo irq/22-ICE1712, y también el irq/8-rtc0. Precisamente los dos kernel threads que se pretendían levantar se han quedado en 51, mientras que los ehci_hcd y uhci_ehcd, así como el i8042 (para el ratón y teclado PS/2, en mi caso inexistente) tienen las prioridades levantadas. Esto no es lo que quería conseguir.

¿Cómo arreglarlo? Modificando el archivo de configuración de rtirq.
En la terminal libre de la derecha escribimos:

$ sudo cp /etc/default/rtirq /etc/default/rtirq.copia (copia por si acaso)
$ sudo nano /etc/default/rtirq

Hay una serie de variables escritas en mayúsculas que son las que debemos tener en cuenta. El resto son comentarios. En nano guardamos los cambios con [Control-O] y salimos con [Control-X]. Bueno, usar el editor que os parezca mejor.

La variable más importante es RTIRQ_NAME_LIST. La encontramos así:

RTIRQ_NAME_LIST="rtc snd usb i8042"

Esta me está fastidiando. Cambio a:

RTIRQ_NAME_LIST="rtc0 ICE1712"

Que es lo que leo en la columna derecha de cat /proc/interrupts. Creo que lo que Rui quiere dar a entender es: "1º reloj, 2º tarjeta PCI, 3º tarjeta usb, 4º teclado/ratón PS2". Las distribuciones tienen algunas diferencias, por eso es genérico.

(Me parece que en lucid funciona a la primera con las designaciones genéricas, pero habría que comprobarlo).

He dejado fuera de RTIRQ_NAME_LIST "usb" e "i8042" pues no tengo tarjetas usb ni teclado/ratón PS2.

Si tenemos una tarjeta firewire, habrá que levantar la prioridad de ohci1394 en lugar de la de la tarjeta PCI y posiblemente también la del controlador firewire. Comprobar con htop. Más información en el enlace de ffado de abajo.

Hay otra variable:

RTIRQ_NON_THREADED=

Habría que cambiarla de todas maneras (otra vez, rtc y snd que al menos en mi caso no significan nada) pero creo que la puedo deshabilitar tranquilamente, "comentándola" con una almohadilla delante.

Por probar, voy a dar 98 a RTIRQ_PRIO_HIGH y pongo un paso de 10
en RTIRQ_PRIO_DECR.

Por otro lado, en el lowlatency howto de alsa y en el blog de SounDebian hablan de levantar las prioridades de los soft irq timers. Esto es mucho más fácil con rtirq. Sólo tenemos que descomentar la línea:

# RTIRQ_HIGH_LIST="timer"
Es decir, dejarla en:
RTIRQ_HIGH_LIST="timer"
Y tendremos los sirq-timers con la máxima prioridad.

Los temporizadores no afectan a la tarjeta de audio, que tiene su propio reloj. Sin embargo, son importantes para la reproducción de MIDI.

Una vez modificado el archivo de configuración, vamos a lanzarlo manualmente sin tener que reiniciar. Desde otra terminal:

$ sudo /etc/init.d/rtirq start

Florian (tercer enlace, entrada "Linux Audio/MIDI System") y Soundebian explican cómo hacer todo esto de forma manual (con el comando chrt). Florian propone levantar las prioridades de los secuenciadores y sintetizadores de software por encima de la de la tarjeta de audio y jackd. Por eso elijo un paso grande entre rtc0 y la tarjeta, para tener sitio entre medias, por si acaso, aunque sinceramente nunca me preocupo de levantar manualmente prioridades de otros procesos.

Cuando arrancamos manualmente el script vemos que se levantan las prioridades de los "kernel threads" que hemos configurado pero las que estaban levantadas no "bajan". (A veces tengo que terminar htop con F10 y volver a lanzarlo para asegurarme, pues el efecto no se ve de inmediato). Cuando reiniciemos el ordenador volvemos a comprobar con htop si rtirq ha hecho su función. Los kernels threads no levantados los dejará con prioridad 51 ó 50.

Con esto se consiguen latencias bajísimas sin xruns, como vemos en la siguiente entrada, donde además realizamos algunas mediciones.

Créditos y para saber más, además de nuestro buscador favorito:

http://subversion.ffado.org/wiki/IrqPriorities
http://www.rncbc.org/drupal/node/107
http://tapas.affenbande.org/wordpress/ (linux audio pages)
http://bugtrack.alsa-project.org/main/index.php/Low_latency_howto
http://www.soundebian.com.ar/2009/10/configurando-verdaderamente-el-real-time-para-audio/

sábado, 24 de abril de 2010

Grabadores sencillos. JACK Timemachine y jack_capture

###################################
Notas de revisiones:
Revisión 0: 25 abril 2010. Publicado.
###################################

JACK Timemachine y jack_capture son sencillos grabadores de audio clientes de jack. Cada uno tiene una característica que lo hace especial y atractivo a su manera.

Timemachine


Con Timemachine podemos grabar el pasado. Muy útil si, por ejemplo estamos improvisando y nos sale algo bonito que nos gustaría haber grabado. Pues no se ha perdido. Si pulsamos el botón nos habrá grabado desde (por defecto) 10 segundos antes, hasta que volvemos a pulsarlo.

Otra utilidad que le podemos dar es grabar la radio. Uso VLC para escuchar la radio a través de internet. Si empiezan a hablar de algo que me interesa viajo en el tiempo con timemachine para no perderme el principio.

Podemos ver las opciones que tiene con
timemachine -h

Por defecto graba en formato w64 (que no es reconocido por la mayoría de reproductores)
y desde 10 segundos antes de pulsar el botón de grabación.

Si por ejemplo, queremos grabar desde 15 segundos antes y en formato wav, debemos dar el comando:
timemachine -t 15 -f wav

Está en los repositorios de ubuntu, así que instalarlo es muy fácil. Si lo arrastramos al panel y editamos sus propiedades podemos lanzarlo con el comando de arriba
(o precedido por /usr/bin/ como está por defecto).

Eso sí, timemachine no se autoconecta a ningún puerto, por lo que antes de nada, debemos conectar la fuente de audio que tengamos previsto grabar a sus entradas. Por defecto, los archivos se crean en /home/usuario/ con el nombre tm- seguido de la fecha y la hora del comienzo de la grabación.


Timemachine conectado a una fuente de audio, en espera.

Jack_capture

Lo más atractivo de Jack_capture es que autoconecta a sus entradas de captura todo lo que esté conectado a las salidas de la tarjeta de sonido (system:playbacks), de forma que graba todo lo que sale por los altavoces sin tener que preocuparnos de hacer ninguna conexión manualmente. Se puede configurar de otra forma, pero esta es la opción por defecto. Además, el audio de salida puede estar en wav, flac, ogg o mp3.

Jack_capture no está en los repositorios de ubuntu pero lo podemos instalar desde synaptic o apt-get si añadimos un repositorio adecuado, Por ejemplo, para karmic está en el de Philip Johnson

También lo podemos compilar si descargamos las fuentes desde aquí

En linux AV se hizo una presentación de este programa, con sus características completas aunque no se hizo referencia a la interfaz gráfica que facilita mucho las cosas. Ésta se invoca con el comando "jack_capture_gui2". Grabar es tan simple como apretar el botón rojo. Las opciones se despliegan clicando en la flechita de settings.


Jack_capture_gui2

sábado, 17 de abril de 2010

Tuneit, afinando la guitarra con la terminal de comandos

###################################
Notas de revisiones:
Revisión 0: 16 abril 2010. Publicado.
Revisión 1: 22 abril 2010. Completado.
###################################

Tuneit es un fabuloso afinador de línea de comandos. Preciso, estable y sencillo a más no poder.

Compilarlo es muy sencillo. Ya que hablamos de la terminal, lo haremos todo desde terminal. Estos son los pasos.

Instalamos las herramientas básicas de compilación y las bibliotecas de desarrollo necesarias. En ubuntu:
$sudo apt-get install build-essential libasound2-dev libfftw3-dev libjack-dev

Si no lo tenemos ya, recomiendo crear un directorio para el código fuente de los programas que instalemos al margen del sistema de paquetes. Yo le llamo "fuentes".
&mkdir fuentes

Nos situamos en este directorio
$cd fuentes

Obtenemos el archivo comprimido con las fuentes desde internet
$wget -c http://delysid.org/tuneit-0.3.tar.gz

Descomprimimos
$tar xf tuneit-0.3.tar.gz

Ingresamos a la carpeta creada
$cd tuneit-0.3

Configurar, compilar e instalar
$./configure
$make
$sudo make install

Un vistazo al manual
$man tuneit


tuneit en acción

Si preferimos que las notas salgan con la nomenclatura Do-Re-Mi...tenemos que modificar el código y volver a compilar ya que es opción no está expuesta al usuario, o al menos no aparece en el manual.

Editamos el archivo ~/fuentes/tuneit-03/src/tuneit.c

Más o menos en la línea 32, podemos cambiar:

static const char **notes = englishNotes;

por:

static const char **notes = frenchNotes;

Y también quitamos la tilde de Rè y Rè#

Borramos los archivos binarios con
$make clean

Y volvemos a compilar e instalar:
$make
$sudo make install

Créditos:


Gracias a Mario Lang por este fantástico y práctico afinador.
http://delysid.org/tuneit.html

lunes, 5 de abril de 2010

GNU Solfege y TuxGuitar (con sonido a través de Jack)

###################################
Notas de revisiones:
Revisión 0: 16 abril 2010. Publicado.
###################################

Sinceramente, no suelo utilizar ninguno de estos programas pero quería escribir esto pensando en Unai y en otros guitarristas interesados en la didáctica. Con una tarjeta de audio firewire, jack es imprescindible para tener sonido en Linux y en cualquier caso es bueno por la flexibilidad y las posibilidades que permite.

Contenido

Breve presentación de GNU/Solfege
Breve presentación de TuxGuitar
Estos programas no suenan
Una opción: Timidity
Nuestra propuesta: pmidi, qsynth, jack
El sintetizador
Obtener un archivo soundfont
Primero Jack, luego qsynth
El reproductor de midi
GNU/Solfege, ahora sí suena :)
Tuxguitar, ahora sí suena :)
Otra vez la flexibilidad
Créditos



Breve presentación de GNU/Solfege


GNU Solfege es un programa de educación musical. Entre otras cosas, se puede utilizar para entrenar el oído en ritmos, intervalos, escalas y acordes.

Es una aplicación libre, licenciada bajo la GPL y también funciona en otros sistemas operativos.

En su página oficial podéis ver algunos pantallazos con algunos de los ejercicios que se pueden hacer. En cualquier caso, la interfaz gráfica es sencilla e intuitiva.

Está en el repositorio universe de ubuntu, así que los ubunteros lo podemos instalar desde synaptic, apt-get, aptitude o el centro de software. El paquete se llama "solfege". En gnome, aparece en el menú Aplicaciones -> Educación.


Breve presentación de TuxGuitar


TuxGuitar es un programa educativo para guitarra, con edición de partitura y tablatura. Puede importar archivos de guitar-pro (GP3, GP4 y GP5, de momento)

Como GNU/Solfege, es una aplicación libre, licenciada bajo la LGPL y también funciona en otros sistemas operativos.

También está en universe. Aquí instalaremos dos paquetes, tuxguitar y tuxguitar-alsa. En gnome, aparece en el menú Aplicaciones -> Sonido y Video.

Estos programas no suenan

Pues es verdad, no suenan porque no manejan audio digital sino MIDI. En el caso de GNU/Solfege ni siquiera eso, pues necesita un programa externo para reproducir el MIDI. Y éste necesita "algo" que interprete los mensajes MIDI y los convierta immediatamente a audio digital, que es lo que entiende la tarjeta de sonido. Este "algo" es un sintetizador, sea software o hardware. Además debemos saber qué sistema de audio utiliza este sintetizador. El camino será, para GNU/Solfege:

Solfege -> Reproductor de midi (conectado al puerto de entrada alsa midi del) -> sintetizador (cuya salida de audio digital va a) -> manejador de audio (cuya salida de audio digital va a) -> Tarjeta de audio (cuya salida de audio analógico va a) -> Altavoces

Para tuxguitar será similar, pero en este caso no hace falta un reproductor de midi externo; la conexión al sintetizador es más directa.

Una opción: Timidity

GNU/Solfege nos obliga a instalar timidity (al menos, en ubuntu 9.10 es una dependencia) un reproductor MIDI-sintetizador cuyo audio puede salir directamente hacia la tarjeta. Dicho así, parece que sería lo más directo y fácil. Sin embargo, en esta guía, timidity es como si no existiera. Lo comento sólo para que conste.

Nuestra propuesta: pmidi, qsynth, jack

Para el caso de esta guía y de forma simplificada, el camino a seguir será:

Solfege -> pmidi -> qsynth -> Jack -> Tarjeta audio-> Altavoces

o

Tuxguitar -> qsynth -> Jack -> Tarjeta audio -> Altavoces


El sintetizador

Necesitamos un sintetizador con salidas de audio a través de jack. Hay muchas posibilidades. Para simplificar y por ser quizás el más conocido y muy sencillo de configurar, voy a centrarme en qsynth como ya he adelantado.

Qsynth es un front-end gráfico para fluidsynth, que a su vez es un sintetizador basado en la especificación soundfont. Lo podemos instalar desde synaptic si no lo tenemos ya.

Lo primero será cargar una soundfont. Para ello lo lanzamos desde las aplicaciones de Sonido y Video y vamos a la configuración o setup. Pulsamos la pestaña Soundfonts y le damos a Abrir para cargar un archivo de soundfont (extensión sf2 o SF2). Podemos cargar cualquier archivo sf2 pero sólo los "General Midi" tendrán un mapeado de instrumentos estándar, de forma que podamos elegir el instrumento desde el propio Solfege. Si no tenemos ninguno disponible en el disco duro, lo tendremos que conseguir...

Obtener un archivo soundfont


Por ejemplo, en esta página tenemos cientos de archivos sf2 gratuitos. Os propongo la mítica Fluid Release 3 que se puede descargar desde este enlace. Suena muy bien y es General Midi. El "problemilla" es que viene comprimida con sfark y en los repos no tenemos un programa que nos sirva para descomprimir este formato. En este caso debemos ir a melodymachine para descargar el programa sfArk. Ahorramos tiempo si bajamos el programa para Windows, ya que el de Linux funciona con una librería que se ha quedado obsoleta. De alguna forma se puede atajar (ver entrada en hispasonic en los créditos) pero quizás sea más sencillo descargar el programa para Windows e instalarlo con wine (botón derecho). Wine está en los repos y se instala fácilmente con apt-get o Synaptic.

Primero Jack, luego qsynth

Iniciamos nuestro amigo Jack y después qsynth. Con éste no hemos terminado. En la configuración MIDI debemos tener habilitada la entrada MIDI con el controlador alsa-seq y en la pestaña Audio elegir Jack. También es importante que la frecuencia de muestreo coincida con la que hemos configurado en Jack.

En la ventana de conexiones debemos ver las salidas de qsynth en la pestaña audio y la entrada de
Fluid Synth en la pestaña ALSA (alsa midi).

El reproductor de MIDI

Es necesario para GNU/Solfege. Usaremos pmidi. Lo instalamos con apt-get o synaptic. Ahora vamos a ver qué puertos midi hay disponibles. En una terminal, podemos hacer:

$pmidi -l

En una de las líneas veremos algo similar a:

129:0 FLUID Synth ...

En este caso, el puerto alsa midi es el 129:0

(esto también se puede ver en la ventana de conexiones de Jack Control)

GNU/Solfege, ahora sí suena

Abrimos GNU/Solfege y vamos a Archivo -> Preferencias -> External Programs y en Audio File Players, MIDI ponemos en el campo de la izquierda:

/usr/bin/pmidi

Y en el de la derecha:

-p 129:0

o el número de puerto que tome Fluid Synth.

Damos al botón de prueba y... tirirín tintintín. Y si no, comprobar que las salidas de audio de qsynth estén conectadas a los system:playbacks.

Es posible que cada vez que lanzemos GNU/Solfege (por supuesto después de haber iniciado jack y qsynth) debamos volver a escribir el puerto.

Tux Guitar, ahora sí suena

Llegados hasta aquí, ya tenemos todo para disfrutar también de TuxGuitar a través de Jack.
Lo lanzamos desde Aplicaciones -> Sonido y Video. Vamos a Herramientas -> Preferencias -> Sonido y elegimos "Synth input port" como puerto MIDI.

Otra vez la flexibilidad


Como veis, el disgusto inicial de no escuchar sonido se debe a que estos programas siguen la filosofía Linux de "una tarea, una aplicación". Como tantas otras cosas en nuestro SO favorito y como las buenas amistades, se empiezan a disfrutar más a medida que se conocen mejor. Este enfoque modular nos ofrece una gran flexibilidad y podremos sacar cualquier sonido de estos programas, bien cambiando el archivo soundfont de qsynth o bien utilizando otro sintetizador completamente diferente que tenga entradas de alsa midi y salidas de jack audio. Esto nos permitirá grabar el audio directamente a cualquier grabador jackificado o hacer cualquier otra conexión que se nos ocurra a través de jack, incluyendo varios ordenadores en red como vimos en la entrada sobre netjack2.

Créditos

http://www.solfege.org/
http://www.solfege.org/Solfege/SoundSetup
http://tuxguitar.herac.com.ar/
http://www.hammersound.net/
http://www.melodymachine.com
http://www.hispasonic.com/comunidad/soundfonts-formatos-sfark-sfpack-t301964.html#p2362239

sábado, 20 de marzo de 2010

Presentación de netjack2

###################################
Notas de revisiones:
Revisión 0: 21 marzo 2010. Publicado.
###################################

Experimentos con netjack2

El otro día hicimos un intento de compartir audio y MIDI en tiempo real a través de una red local cableada, con un ordenador maestro (con su tarjeta de audio conectada a los altavoces) y varios esclavos. Las pruebas iban a ser:

1. En cada ordenador esclavo se reproduce una canción. Estas no suenan en el esclavo; se envían al maestro que decide cuál poner o las mezcla a su antojo.

2. En cada ordenador esclavo hay un sintetizador software. El maestro reproduce una canción en un secuenciador MIDI, con varias pistas. Cada pista MIDI se se envía a un esclavo diferente, que "traduce" el MIDI a audio con su propio sinte y envía el audio de vuelta al maestro.

3. Los esclavos envían mensajes MIDI al maestro a traves del teclado. El maestro traduce el MIDI a Audio con un sampler o un sintetizador software.

Yo no esperaba más de tres ordenadores con el software necesario instalado pero al final fueron 6 en total... No hubo tiempo de montar y probar bien la red y ésta resultó poco robusta. El experimento 2 no dio resultado :(

Lo que sí conseguimos fue reproducir canciones desde dos ordenadores esclavos a través de la tarjeta de audio del ordenador maestro. El que maneja el mezclador del maestro decide qué canción suena. Debe ser muy fustrante poner una canción en un reproductor y que no suene... ¡Sólo si le gusta al otro!

También salió bien el experimento 3. Usamos vmpk para enviar notas MIDI desde los teclados hasta hydrogen, que hacía de sampler, con un drumkit hecho a medida para la ocasión (un kit al que añadí un silbato y otros ruidos raros). Vamos, una batukada digital con tres "músicos" aporreando los teclados del ordenador. Para pasar el rato.

Las CCCP (Charlas con Café, Copa y Puro) son reuniones de sobremesa donde intentamos arreglar el mundo gracias al software libre y al hardware barato. En serio, hacemos charlas y presentaciones. Era mi primera presentación. A ver qué os parece.

Cómo instalar software (programas) en (ubuntu) GNU/Linux. I. Introducción

###################################
Notas de revisiones:
Revisión 0: 20 marzo 2010. Publicado.
###################################

Comienzo una serie de tres partes en la que explico cómo se instala software en Linux, dirigido sobretodo a recién llegados desde Windows. Está orientado a ubuntu, pero los fundamentos son los mismos para cualquier otra distribución moderna de "Escritorio". Este es un tema muy documentado pero me apetecía explicar algunas cosas que he ido aprendiendo y desaprendiendo con el tiempo.

Normalmente, la documentación oficial de las distribuciones se dirige a los nuevos usuarios como si fueran completamente nuevos a la informática. No tiene en cuenta que la mayoría llevan años usando Windows y tienen algunas ideas preconcebidas que en GNU/Linux no son válidas. La documentación se esfuerza sobretodo en enseñar, no tanto en desenseñar.

Preguntas frecuentes:

¿Es instalar software en Linux (="una distribución de GNU/Linux") más fácil o más difícil que en Windows?

Depende. Al fin y al cabo, en Windows también se puede compilar, no? :P

Si tomamos como referencia el conocido: "bajar-un-programa-desde-una-página-de-confianza-doble-click-setup.exe-aceptar-licencia-next-next-next" o, el un poquito más complicado y triste pero cierto: "bajarlo-desde-cualquier-lugar-incluido-crack-pasar-antivirus-etc"... se puede decir que instalar software en Linux puede ser desde mucho más fácil hasta mucho más difícil que esto.

Básicamente, existen dos formas de instalar un programa:

1. Por medio de un instalador ejecutable

2. Compilando el código fuente antes de instalar

La primera forma es como el clásico "setup.exe" de Windows: Un instalador binario. Sin embargo, una distribución moderna lo pone mucho más fácil que Windows, como veremos en el siguiente capítulo.

La segunda es un poco más complicada. Lo veremos en el tercer capítulo. Normalmente no es difícil pero suele llevar un rato. Es cuestión de cogerle el truco. Pero no os asustéis, cada vez es menos necesario y/o más fácil, pues al aumentar el número de usuarios aumenta el número de empaquetadores-distribuidores, informadores de fallos, "pedigüeños" (quiero este programa en ubuntu por favor!!!), profesores y ayudantes, traductores, incluso programadores aficionados (este programa está bien pero hay que mejorarlo, me apunto, toma parche!)... En general, esto redunda en beneficio del usuario final que cada vez está más cerca de las versiones "recién horneadas", al tiempo que éstas son cada vez mejores.

¿Entonces, cuál es la mejor forma de instalar?

Depende...Aquí debemos mantener un equilibrio y pensar un poco antes de actuar sobre qué es lo mejor en cada caso. Yo diría que hay 4 factores, la seguridad de que el programa será estable en nuestro sistema [1], la facilidad de instalación, la funcionalidad que esperamos y la paciencia que tengamos. Resumiendo y en primera aproximación:

- Lo más seguro y muy fácil, perdiendo quizás alguna funcionalidad de un programa concreto, pero esperando que mejorará con el tiempo --> Repos oficiales.

- Menos seguro y bastante fácil, en busca de versiones más recientes o de un programa que no está en los repos oficiales--> Repos no oficiales o paquetes sueltos desde internet (a ser posible desde la página oficial de los proyectos, si se facilitan).

- Muy seguro y no fácil, cuando queremos estar a la última con un programa concreto que nos interesa especialmente --> Compilar la última versión estable de un programa, después de descargar el código fuente desde su sitio oficial.

- Menos seguro y no fácil, cuando queremos tener la versión de desarrollo, para evaluarla y/o colaborar con el proyecto --> Compilar las versiones diarias cuyo código fuente bajamos desde el sistema de control de versiones que utilice el proyecto.

Los dos primeros métodos los vemos en la segunda parte.

¿Dónde se instalan los programas?. Pues no existe un directorio llamado "Archivos de programa" ni nada que se le parezca.

Los programas se instalan... cada archivo en su lugar. El ejecutable en el directorio de ejecutables, las bibliotecas en el directorio de las bibliotecas, las configuraciones generales en su directorio, las configuraciones de usuario, en su sitio, los iconos en su sitio, la documentación en su lugar, etc. Pues sí, un programa bien diseñado repartirá archivos por todo el sistema.

¿Por qué no tengo permisos para hacer lo que yo quiera en mi propio ordenador?

Los sistemas derivados de UNIX, como GNU/Linux, están diseñados desde su base para ser multiusuario. Hay un administrador y tantos usuarios como éste determine. En un ordenador personal, de usuario único, hay un administrador y un usuario. Los programas los debemos lanzar "como usuario". La gestión de nuestros archivos la debemos hacer también como usuario. Lo que no podemos hacer como usuario es, por ejemplo, instalar un archivo ejecutable en el sistema operativo. Eso sólo lo puede hacer el administrador. Si el ordenador es tuyo, el administrador eres tú, pero no "tú usuario", sino "tú administrador". Algunos nuevos usuarios piensan que esto es un engorro porque implica introducir una contraseña cada vez que queremos instalar algo. A mí me parece mucho más engorroso formatear, eliminar virus con sospechosos antivirus de código cerrado, etc, sólo porque a un "sistema operativo" le da por ejecutar un programa que hace cosas malas sin que el dueño del ordenador lo haya instalado intencionadamente.

¿A quién me puedo quejar si instalo un programa que no funciona?

Si es software bajo la GPL, no hay garantía. El software se ofrece tal y como es. Tienes derecho a estudiar su código, a modificarlo, a redistribuirlo, a usarlo en tantos ordenadores como quieras... pero no hay garantía. No puedes denunciar a nadie porque no funcione. El software libre está basado en la confianza de que las cosas se han hecho lo mejor posible, y todo el mundo está invitado a participar en su mejora y su desarrollo.

Y ahora, al grano


[1] Descarto el malware. Cuando hablo de seguridad, me refiero a fallos no intencionados, sean del programador, del empaquetador-distribuidor, o del propio usuario que ha tomado decisiones sin saber bien lo que hacía.