En un artículo anterior, describí como la configuración de bajo nivel de ALSA nos permitía encaminar todas las aplicaciones usando el API ALSA via PulseAudio. En este artículo echaremos una mirada a los distintos archivos de configuracion y a las variables que controlan este lado del camino de audio. Recorreremos por lo que pasa cuando una aplicación intenta reproducir sonido.

Aplicación ALSA

En primer lugar, una aplicación usando el API ALSA intenta abrir el dispositivo “predeterminado”. Asumiendo que hemos configurado el dispositivo predeterminado para que sea el plugin de PulseAudio para ALSA, básicamente actuará como cada aplicación PulseAudio cliente. Ahora estamos dentro de la tierra de la configuración de PulseAudio.

Cliente PulseAudio

PulseAudio adopta un modelo cliente/servidor que es muy similar en principio al del sistema X11. Es el servidor que realmente hace salir el audio y la aplicación cliente que le dice al servidor que reproducir. Si bien este enfoque puede ser ineficiente, resultando en la copia de datos por todos lados, PulseAudio hace lo más que puede para asegurar que los datos que se copian y otras operaciones sujetos a latencia se mantengan a un mínimo. En el uso comón tanto de cliente y servidor corriendo en la misma máquina, PulseAudio usa SHM (Shared Memory) para asegurar que los datos enviados desde el cliente al servidor no se copian a través del cable. El núcleo del servidor PulseAudio mismo es “copia cero” que quiere decir que las referencias a los datos se difundan sin copiar los datos mismos realmente.

Lo primero que un cliente PulseAudio tiene que hacer es conectarse  a un servidor. Para hacer esto, verifica que distintas variables y archivos de configuración para determinar precisamente a cual servidor se conectará!

Inicialmente, la librería del cliente PulseAudio busca una variable de entorno PULSE_SERVER. Si la encuentra, esta variable puede definir una lista de servidores a los que el cliente debería conectarse. Estos servidores se pueden especificar como sockets UNIX locales o direcciones de nombres/IP para una conexión TCP.

Si esta variable no existe o está vacía, PulseAudio entonces verifica las propiedades X11 en la ventana raíz. Estas propiedades son bastante parecidas a variables de entorno, pero estarán disponibles remotamente si hacés SSH a otra máquina sin redireccionamiento de X11. Hablaré de esto más tarde. Podés ver una lista de PulseAudio relacionada haciendo:

xprop -root | grep PULSE

Los nombres de las variables usadas son las mismas que aquellas usadas en el entorno, de manera que PulseAudio buscará una propiedad llamada PULSE_SERVER.

Asumiendo que aun no tiene un servidor al cual conectarse todavía, PulseAudio comprobará la configuración de un servidor predeterminado en el archivo client.conf. Este archivo está ubicado en /etc/pulse/ o ~/.pulse/. Solamente se procesa un archivo client.conf. De manera que si el usuario tiene el suyo, no se procesará el del sistema en absoluto (esta es un cuestión que traté de hacer vano en PulseAudio bug #606 – llevó un tiempo para que esto se entienda como podés ver!).

Entonces hemos tratado tres maneras de encontrar un servidor. Si todavía no hemos encontrado uno, recurrimos simplemente al predeterminado – i.e. conectándose a un daemon personal y a un daemon del sistema (un daemon del sistema generalmente no se recomienda, pero está soportado para diferentes circunstancias – comúnmente sistemas embebidos). Si todavía no podemos conectarnos, el archivo client.conf puede especificar si intentaremos o no iniciar automáticamente un daemon personal. Desde PulseAudio 0.9.11, este es el comportamiento predeterminado y permite a las aplicaciones de consola funcionar directamente sin iniciar un daemon PulseAudio de antemano.

Entonces, en el improbable caso que todo falle, finalmente no seremos capaces de reproducir sonido, pero hemos hecho casi todo lo que podemos hacer para hacerlo funcionar! Para visualizar mejor esto, miremos algunos de los escenarios comunes y reveamos el proceso de arriba.

Aplicación de consola

Entonces, en una instalación predeterminada, hemos arrancado en nivel de ejecución 3 y logueado en la terminal. No definimos ninguna variable especial e iniciamos una aplicación que reproduce sonido via ALSA. Aquí está lo que pasa.

1. La aplicación abre un dispositivo predeterminado.
2. El plugin de PulseAudio para ALSA (como cualquier cliente PulseAudio) comprueba que hay una configuración para un servidor y no encuentra uno.
3. Intenta conectarse a un servidor local pero falla por que no se está ejecutando.
4. Entonces arranca un servidor PulseAudio automáticamente y entonces se conecta a él.
5. La aplicación luego reproduce audio via las funcionaes del API de ALSA y este es finalmente reproducido por el daemon PulseAudio.
6. La aplicación cliente termina haciendo lo suyo, y luego sale.
7. El daemon PulseAudio permanece por ahí por un rato en caso de que otra aplicación quiera reproducir sonido en el futuro cercano.
8. Después de un rato, el daemon PulseAudio se enoja porque nadie lo quiere y se suicida :p

Así que es eso. Es bastante simple. Tomemos otro ejemplo.

Aplicación X11

Bajo X11 las cosas son un poquito diferente, pero se siguen los mismos principios básicos.

1. Durante la inicialización de X11, los escritorios modernos que soportan Autoinicio XDG finalmente ejecutan el script start-pulseaudio-x11. Este script asegura que el daemon PulseAudio sea reiniciado y que se carguen algunos módulos extra relacionados con X11 se carguen en él. Estos módulos aseguran que, a diferencia de una aplicación de consola, el damon PulseAudio de X11 no salga luego de un tiempo de espera inactivo – en cambio estará dando vueltas por ahí mientras la sesión X11 exista. Esto asegura que las propiedades X11 mencionadas antes se definan – las razones para eso se verán claramente en el próximo ejemplo.
2. Cuando cualquier cliente PulseAudio (sea una aplicación ALSA via el plugin PulseAudio vía ALSA, o PulseAudio nativo) se inicia pasa por su “rutina de buscar un servidor”. Ahora detendrá este proceso cuando alcanza las propiedades de X11 y usa la información de ella y se conecta al servidor.
3. La aplicación cliente luego reproduce sonido como antes y finalmente termina y sale.
4. El daemon PulseAudio no sale/se mata a sí mismo mientras la sesión de X11 está todavía andando.

Entonces de nuevo, las cosas son realmente simples.

La aplicación X11 remota

Una de las cosas más prácticas de X11 es la capacidad de conectarse a otra máquina en tu red y ejecutar aplicaciones con interfaz gráfica y mostrarlas en tu pantalla local. Con PulseAudio, el sonido también se oye en la máquina local. Las conexiones remotas (por razones de seguridad) no se habilitan de manera predeterminada. Para habilitarlas, ejecutá paprefs y habilitá la opción Habilitar el acceso desde la red  a dispositivos de sonido locales. Esta es la única opción que se necesita para este ejemplo. Carga un módulo adicional en el servidor que escucha en el puerto TCP 4713 para conexiones entrantes. Obviamente, no hace falta decir que cualquier firewall en la máquina debe habilitar conexiones a este puerto!

1. El usuario inicia una sesión X11 normal y el script start-pulseaudio-x11 asegura que las propiedades X11 sean definidas como en el ejemplo anterior.
2. El usuario entonces se conecta a otra máquina de su red vía ssh e inicia un reproductor de audio (e.g. Rythmbox, Amarok, etc.)
3. Aun cuando la aplicación se está ejecutando remotamente se mostrará localmente.
4. Cuando la aplicación comience a reproducir audio, la porción cliente buscará las propiedades X11 que han sido redireccionadas a través de la conexión SSH.
5. El cliente PulseAudio entonces se conectará por TCP al servidor PulseAudio ejecutándose en la máquina local del usuario.
6. El usuario disfruta la imagen y el audio local que la aplicación proporciona.

Entonces, como podés ver, el uso de las propiedades nos ha permitido subirnos a caballito del redireccionamiento X11. No es una conexión totalmente limpia ya que bajo SSH los datos de X11 realmente irán por un túnel por un enlace seguro manejado por SSH mismo, en cambio todo lo que estamos haciendo es decirle al cliente PulseAudio donde conectarse directamente, por fuera de cualquier túnel SSH. Esto significa que si bien la visualización puede funcionar sobre un systema NATeado, el sonido no lo hará. Esto es claramente tratado, pero tendríamos que enseñarle a SSH acerca de PulseAudio para que esto funcione. La razón por la que funciona para X11 es porque sabe de aquél, y tiene soporte específico para X11. Simplemente estamos subiéndonos a caballito de SSH. Dicho esto, la configuración actual es “suficientemente buena” para la mayoría de los casos.

Así que espero que este artículo haya desmitificado como interactuán el cliente y el servidor PulseAudio y las distintos archivos/variables de configuración que entran en juego. Si tenés cualquier pregunta, por favor preguntá en los comentarios y me esforzaré en actualizar el artículo.

Es decir, en Debian, Ubuntu, etc. podemos hacer:

• apt-cache search compiz

o bien

• aptitude search compiz

En Fedora, Red Hat, CentOS, etc, tenemos una opción similar:

• yum search compiz

¿Y en Mandriva?

Hay una manera de hacer algo parecido, aunque está un poco escondida:

• urpmf -i –description compiz

El wallpaper se puede bajar de GNOME-LOOK.ORG, los íconos son los black-white 2 Gloss, la decoración de ventanas y los controles es del tema Glossy.

El otro día encontré algo interesante. Como usuario de Linux, el desktop no es un terreno demasiado propicio para virus, por lo tanto los antivirus quedan relegados a un segundo o tercer plano. Sin embargo, husmeando un poco en la configuración de klamav, hallé una opción para bajar una versión actualizada de clamav. Lo más interesante es que baja el código fuente y hace la compilación en modo GUI con asistente. Como ocurre en la mayoría de las compilaciones dejo los archivos por debajo de /usr/local. Que interesante sería encontrar proyectos ofreciendo algo similar.

Los wireless routers Linksys WRT54G desde la versión 1.0 hasta la 4.0 podían ser flasheados con OpenWRT, lamentablemente a partir de la versión 5.0 en adelante, la empresa decidió reducir la cantidad de memoria disponible, y además cambiar a un sistema privativo (VxWorks).

Para compensar esto, en algún momento lanzó a la calle el modelo WRT54GL, recuperando la compatibilidad con OpenWRT.

1. Ahora bien, ¿qué pasa si ya tenemos un WRT54G 8.0? la respuesta es definitiva: No se puede instalar OpenWRT. Así de sencillo, la razón es que los desarrolladores de dicho sistema operativo no están dispuestos a trabajar para un espacio de memoria tan reducido.

No obstante, dentro de la variedad que tenemos en el mundo del software libre, se puede optar por dd-wrt. Las últimas versiones vienen con una herramienta que permite sacar al VxWorks, instalar dd-wrt y recuperar el firmware original en el caso de que algo salga mal o que el sistema open source no haya convencido las expectivas.

He probado dd-wrt sobre un WRT54G 8.0 y me ha funcionado. Es asombroso como el software libre consigue adaptarse a un espacio tan pequeño. El sistema permite, entre otras cosas:

• Usar un servicio de DDNS
• Configurar routing avanzado
• Trabajar con RADIUS
• Definir una serie de configuraciones avanzadas de wireless tales como soporte multimedia y restricciones de acceso por bandas horarias.
• Soporte para WDS
• Tareas programas

Sin embargo, no todas son buenas. Dos carencias notables con respecto a OpenWRT es la carencia de ssl y de ssh. El tráfico web va en texto plano, el acceso de consola es mediante el infame telnet.

Como todo Linux y al igual que en OpenWRT se pueden crear reglas con iptables. Pero tampoco se pueden esperar lujos, como tener un editor de textos o una partición al estilo jffs2. Muchas cosas se configuran con el comando nvram.

Con todo, la experiencia de instalar un Linux en un dispositivo para que parece haberse concebido para que dicha alternativa sea posible, es digna de realizar.

En los últimos años se ha producido un importante deterioro no solo
del servicio, sino tambien de la atención al cliente.

Fibertel impone al usuario (no lo hace explicito) un proxy
transparente, esto significa que hay un límite al tamaño de los
archivos que se pueden descargar.

Esto no es lo peor. Recientemente me mudé. Entonces solicité la
transferencia del servicio al nuevo domicilio (apenas unas diez
cuadras de diferencia). Intentar comunicarse llevó todo el día. Una
vez que alguien nos contestó, y luego de varios minutos, se acordó una
fecha para que pasaran por la nueva dirección para realizar la nueva
conexión. Todo parecía ir medianamente bien dentro la mediocre atencion acostumbrada.

Resulta que la persona que vive en mi domiicilio anterior, ahora dice
que no puede solicitar el cable porque le dijeron en Cablevision que
tenemos una deuda. Esto es inexacto. La unica que no teníamos paga era la
de marzo (ni siquiera estaba vencida) y de hecho ya la abonamos.
Llamamos el ultimo viernes 7/3/08 y nos confirmaron (tal como
habiamos quedado la semana anterior) que pasarian el sabado 8, de 8 a
14 hs.
Bien, estuve toda la mañana esperando (en mi casa) inultimente para nada. A eso de
las 13:15 llamo para ver que estaba ocurriendo para ver si iban a
venir o no. La persona que me atendió me dijo que sí, que iban a pasar
en una media hora.

Pasó la media hora y nada. Entonces llamé alrededor de las 14:30, me
contestaron ahora que iban a pasar de 14 a 20Hs!. Muy molesto, les
dije que deberían haber avisado, pero el empleado de la empresa me
decía que ése era el horario asignado!!! OK, esperé y esperé hasta las
18 hs. llamé de vuelta, qué me dijeron? Que NO iban a pasar.
Resultados objetivos:

• Mintieron respecto de la hora y el día.
• Perdí todo medio fin de semana en mi casa.
• Estoy todavía sin TV con cable y sin internet, y encima pagando, una
  cifra NADA despreciable.

¿Qué puede hacer el consumidor frente a estos atropellos? ¿No es hoy en
la práctica un monopolio lo que ejerce esta empresa, y por eso
descuida a los clientes históricos?

¿De todas maneras, a a quien cara** le importa?