Lo que sigue es una traducción “quick and dirty” del primero de dos excelentes artículos escritos por Colin Guthrie. Todo comenzó por mi intento de desentrañar la manera en que Linux maneja el audio por estos días. Luego dí con Colin Guthrie el encargado de la parte de sonido en Mandriva, el cual tuvo la amabilidad de responder varias de mis preguntas, y al parecer todo esto fue un disparador para que él escribiera estos dos posts altamente recomendables, aquí va el primero (el original en inglés del primer artículo se puede leer haciendo clic aquí):
Ya que oigo la frase: “El sonido en Linux es confuso”. Si bien no discrepo totamente con ese comentario, como con todo en Linux el sistema de sonido es bastante lógico y si seguís bien los pasos podés desmitificar cosas bastante rápido. Así que este artículo explica como funcionan las cosas en Mandriva y debería asegurar a los usuarios para que estén más cómodos con “como funcionan las cosas”.
Primero de todo deberíamos probablemente explicar un poquito como funciona esto. ALSA es la Arquitectura Avanzada de Sonido de Linux. Es un reemplazo para OSS (Open Sound System) que tenía varios problemas en Linux y que últimamente ha sido suplantado por ALSA como el único sistema de sonido en el Kernel. A pesar de una distensión de los términos de la licencia y últimos desarrollos de OSSv4, es improbable que OSS reemplace a ALSA en la línea principal del kernel.
ALSA tiene un componente en espacio de usuario, libasound, que actúa como la primera interfaz para la capa en nivel driver. La mayoría de las quejas acerca de la complejidad del API ALSA se relacionan en realidad a este componente en espacio de usuario, no con la capa en el nivel del kernel, que como podrías esperar, está controlada mucho más rigurosamente. No sufre de la misma necesidad de permanecer retrocompatible con las distintas aplicaciones en espacio de usuario (los drivers del kernel de ALSA solamente necesitan funcionar on libasound que puede obviamente desarrollarse en paralelo) llevando así a un diseño más limpio que la capa de espacio de usuario mismo que tiene que permanecer retrocompatible.
Además de servir de interfaz con la capa en el nivel del kernel e interactuar con el hardware físicamente instalado, ALSA también tiene una arquitectura de plugins. Este sistema de plugins permite a los dispositivos ser simulados/emulados, de distintas interesantes maneras. Permite, por ejemplo crear un dispositivo nulo que envia todo el audio a /dev/null, permite a los auriculares bluetooth ser usados (notar que esto se considera una manera obsoleta en estos días), y permite que todo el audio sea encaminado a través de PulseAudio el cual discutiré más tarde en un subsiguiente artículo.
Así que, hablemos acerca de los archivos de configuración de ALSA. Ahora la mayoría de los archivos de configuración de ALSA viven en:
/usr/share/alsa/
Se puede afirmar que no son realmente archivos de “configuración” en el sentido clásico, i. e. no significa que tengas que cambiarlos como un usuario de acuerdo a tus propias preferencias y caprichos — son realmente más bien como archivos de código fuente y definen la estructura de los distintos plugins de ALSA y configuraciones multicanal. A menos que estés desarrollando/hackeando en ALSA, probablemente no deberías modificar la gran mayoría de los archivos en esta carpeta.
El principal archivo
/usr/share/alsa/alsa.conf
define una lista de archivos adicionales para procesar y el orden en el cual procesarlos. Para incorporar PulseAudio de una elegante y configurable manera, hacemos algunos cambios a la lista de archivos adicionales:
— alsa-lib-1.0.15rc3.lennart/src/conf/alsa.conf 2007-10-17 18:28:03.000000000 -0400
+++ alsa-lib-1.0.15rc3/src/conf/alsa.conf 2007-10-17 18:33:10.000000000 -0400
@@ -8,6 +8,8 @@
{
func load
files [
+ "/usr/share/alsa/pcm/pulseaudio.conf"
+ "/etc/alsa/pulse-default.conf"
"/etc/asound.conf"
"~/.asoundrc"
]
El primer archivo nos permite definir un “dispositivo” para ALSA llamado “pulse”. Esto está siempre presente aun si el usuario decide finalmente no usar PulseAudio de manera predeterminada en su máquina. Esto les permitiría e.g. definir un servidor PulseAudio remoto (vía variables de entorno o configuracion de client.conf – ver el próximo artículo en esta serie, enlazado debajo) y les dice a las aplicaciones de ALSA que usen este “dispositivo” específicamente. Se puede afirmar que este es un caso extremo, pero no hay razón para no sostener esto sin embargo :)
El segundo archivo nos permite activar PulseAudio de manera predeterminada. Esto es bastante importante ya que ofrece a los usuarios una manera sencilla de habilitar/deshabilitar PulseAudio es altamente deseable. La implementación de PulseAudio no está completamente libre de problemas y darles a los usuarios la capacidad de deshabilitar rápida y fácilmente es esencial. Firmemente creo que todos al final usarán PulseAudio, pero llevará tiempo para cada programa soportarlo completamente (quitando el uso de API ALSA “segura”) y para que los problemas de drivers sean resueltos apropiadamente.
En este segundo archivo, o bien comentamos el archivo completamente para deshabilitar PulseAudio de manera predeterminada, o lo dejamos decomentado para habilitar PulseAudio. Esto es manejado por draksound para que los usuarios solamente vean una interfaz gráfica sencilla que es una simple pero efectiva solución. Dicho esto, probablemente cambiaré este archivo para Mandriva 2010.0, cambiando a un sistema manejado por “Alternatives” ¡aunque esto realmente no importa en el esquema de cosas!
Entonces cuando la aplicación ALSA arranque, procesa todos estos archivos y finalmente resuelve como encaminar tu audio. 99% de las veces, el dispositivo “predeterminado” es usado (y uso “dispositivo” en el sentido menos estricto posible). Para una instalación de Mandriva estándar, el dispositivo de manera predeterminada es realmente PulseAudio (via el plugin PulseAudio para ALSA).
Entonces ¿qué pasa después? En el siguiente artículo, voy a hablar acerca de como una aplicación ALSA (o cualquier cliente PulseAudio) funciona cuando se conecta a PulseAudio.
