Un par de ejemplos visibles de estos cambios son:

• Kernel Mode Setting: En donde parte de la funcionalidad del sistema gráfico se sacó de X.org y se integró en el kernel.  Específicamente se trata de la configuración del modo de video, lo que permite reutilizar un modo gráfico ya configurado para no tener que reinicializar el video al cambiar de sistema de despliegue gráfico, evitando los molestos pestañeos.  También permite que otros sistemas gráficos como Wayland sean más simples de programar.
• FUSE: Se trata de sistemas de archivos que se pueden implementar fuera del kernel, lo que se conoce como User Space (en vez de Kernel Space).   Con FUSE se pueden agregar nuevos sistemas de archivo a Linux sin tener que integrarlos en el kernel, esto permitió implementar tranquilamente el soporte para sistemas de archivo NTFS.

En la próxima versión del kernel se incluirá una nueva extensión llamada CUSE o Character Devices in User Space.  La idea es similar a FUSE, pero en vez de que sean sistemas de archivos externos al kernel, ahora se trata de drivers o controladores de dispositivos externos al kernel.

En Linux y Unix en general se utilizan algunos archivos especiales para comunicar a las aplicaciones con los drivers, se trata de esos archivos que se encuentran en el directorio /dev.  Un problema que surge, especialmente con aplicaciones antiguas, es que las aplicaciones al usar directamente los archivos que están ahí, necesitan que exista el driver relacionado con cada archivo.  Un ejemplo clásico son los archivos /dev/dsp y /dev/mixer que se usaban en el antiguo sistema de sonido Open Sound System.

Con CUSE ahora son aplicaciones las que podrán tomar el control de esos dispositivos especiales y como es de esperar, la primera aplicación práctica es un proxy de OSS que permitirá que las aplicaciones crean que están usando OSS, pero serán direccionadas a PulseAudio/ALSA para aprovechar toda la potencialidad de estos sistemas de audio.

Otro uso propuesto es atender las solicitudes a /dev/pilot que realizan aplicaciones antiguas que se conectan a Palm Pilot.  Con CUSE no será necesario tener un driver especial, sino que se podrá escribir un proxy que tome las solicitudes a /dev/pilot y las convierta en lo necesario para comunicarse con el dispositivo bajo estándares actuales.

Con CUSE, nuevos desarrolladores podrán dar soporte a sus dispositivos de una forma sencilla, y aplicaciones antiguas podrán seguir funcionando, adaptándose automáticamente a las nuevas funcionalidades que se vayan incorporando al sistema.

Links:
- Kernel Log – Coming in 2.6.31: CUSE… (The H Open)
- Character devices in user space (LWN.net)

Esto quiere decir que de aquí en adelante, estos usuarios contarán con soporte de su hardware out of the box, sin tener que instalar nada adicional, como sucede para la gran mayoría del hardware de audio soportado.

En forma similar a lo sucedido con ATI/AMD, inicialmente Creative no se había mostrado muy cooperativa ya sea desarrollando un driver o entregando la documentación necesaria para desarrollarlo, pero luego dieron todo el apoyo necesario para que desarrolladores de código abierto pudieran construir el driver e integrarlo en forma adecuada al resto del sistema.

ALSA 1.0.21 además contiene una impresionante cantidad de mejoras y correcciones, en donde se ve un fuerte trabajo en los drivers de audio que cumplen con Intel HDA.

Links:
- ALSA 1.0.21 released with many driver updates (Phoronix)
- Creative se reconcilia con Linux y su driver X-Fi (Fayerwayer)

Las distribuciones de Linux más populares se están estandarizando respecto al manejo de audio a través de un componente llamado PulseAudio.  Se trata de la última encarnación de una funcionalidad muy antigua para soportar que múltiples aplicaciones compartieran un único dispositivo de audio, los famosos servidores de audio.

Si bien estos servidores antes se centraban sólo en compartir el dispositivo de audio entre varias aplicaciones, hoy en día existen muchas formas de usar el audio y con la avalancha de dispositivos enchufables como parlantes USB o audífonos bluetooth, estas soluciones se quedaban cortas.

Con Ear Candy se comienzan a ver los primeros frutos de usar como base un servidor de audio moderno como PulseAudio. Su principal característica es manejar en forma inteligente lo que el usuario está escuchando.  Por ejemplo si estás viendo un video y recibes una llamada por Skype, el audio del video se reducirá para que pongas atención en la llamada.  O bien si estás escuchando música y abres un video en Youtube, la música se detendrá automáticamente para darle prioridad al video que quieres ver.

Favoreciendo la usabilidad, Ear Candy no es un programa con millones de opciones para modificar, sino que simplemente lo ejecutas y te olvidas de él.  Sólamente lo recordarás cuando automáticamente aparezca para hacer su trabajo, antes de que por hábito muevas el mouse para detener esa canción de fondo.

En su última versión incluso no es necesario indicarle cómo debe manejar las aplicaciones, gracias a la estandarización que existe en Linux para entregar información acerca de las aplicaciones al entorno de escritorio – qué es la misma que se usa para construir el menú organizado por categorías – EarCandy es capaz de analizar la descripción de cada aplicación para detectar qué hace y actuar en consecuencia.

Si bien ya es usable y estable, EarCandy aún se considera en estado Alpha y no hay paquetes para usuarios finales.  Aquellos con alma de pionero pueden descargarlo directamente desde el repositorio bzr de EarCandy.

Bonus track : Audio en Linux, dejando atrás el caos

El manejo de audio en Linux siempre ha sido un tema bastante conflctivo, el estado actual es notablemente superior a lo que existía hace un par de años atrás, pero aún a veces aparecen pesadillas del pasado.

Existen al menos dos capas de abstracción para exponer el audio a las aplicaciones.  La primera capa corresponde a los drivers, y la segunda es el servidor de audio, un proceso que ayuda a eliminar las restricciones de los dispositivos de audio tradicionales en sistemas operativos multitarea.

Los drivers de audio en Linux se manejan como un componente especial del kernel, con su propio set de drivers y aplicaciones para administrar los dispositivos.  Originalmente se usaba Open Sound System (OSS) y más tarde fue reemplazado por ALSA que era capaz de manejar hardware con nuevas capacidades.

En la década de los noventa, en los tiempos de OSS, los dispositivos de audio eran muy sencillos y salvo destacadas excepciones, todos usaban una arquitectura basada en SoundBlaster.  Básicamente se trataba de un dispositivo con varias entradas, un mezclador, un canal de audio en estéreo y un sintetizador, ya sea un clásico FM (Yamaha OPL3) o en sus versiones más modernas, uno basado en wavetables.

Con esta arquitectura, y considerando que en esos años los sistemas eran monotarea, con un canal de audio era suficiente.  En paralelo aparecían dispositivos como Gravis Ultrasound que permitían hasta 32 canales de audio independiente, pero eran orientados a música, no a compartir canales entre aplicaciones.

La solución que adoptó Linux para poder usar un sólo canal para múltiples aplicaciones en forma simultánea fue agregar un componente central que tenía control sobre ese canal y las aplicaciones le enviaban el sonido a ese componente, se conoció como sound server o servidor de sonido.  No se realizó un esfuerzo de estandarización y aparecieron dos implementaciones, una asociada al gestor de ventanas Enlightenment llamada Enlightenment Sound Daemon o ESD, y otra de KDE llamada Analog Realtime Synthesizer o aRts.

Dadas estas condiciones, las aplicaciones tenían que decidir entre usar el dispositivo en forma directa via OSS (o ALSA), mediante ESD o mediante aRts.  Y para ello comenzaban a depender de bibliotecas específicas de ESD o aRts.

Si eso parece un problema, donde las cosas se ponían complicadas era cuando una aplicación sólo implementaba acceso directo a OSS y se apropiaba del dispositivo de audio, dejando sin audio a todas las aplicaciones que lo quisieran utilizar, incluyendo a los servidores de sonido.   Otro escenario posible era tener una aplicacion que gentilmente compartía el sonido por ESD, pero este dejaría fuera las aplicaciones con aRts.

Estos servidores comenzaron a perder relevancia cuando apareció ALSA, ya que en caso de disponer de hardware con más de un canal de audio se puede entregar a cada aplicación su propio canal, o bien emular esta capacidad por software de una forma transparente a la aplicación, aunque obviamente consumiendo más recursos del procesador.

Las cosas se pusieron más entretenidas aún con la aparición de dispositivos de audio enchufables, desde tarjetas de audio profesionales (Digidesign, M-Audio, etc) a unos simples audífonos bluetooth.  Esto cambia totalmente el modelo que antes se tenía de dispositivos fijos, que siempre estaban disponibles.

PulseAudio surge como una solución diseñada bajo criterios acorde a los requerimientos actuales de audio, es una capa de abstracción que reemplaza a los servidores de audio tradicionales, pero que evita los errores cometidos en el pasado, como es la dependencia de un entorno de escritorio o el deficiente manejo de la latencia que tenían los servidores tradicionales.

PulseAudio es una abstracción completa del sistema de audio subyacente, puede combinar múltiples dispositivos de audio como uno solo, manejar niveles de volumen por aplicación, sincronizar múltiples flujos de audio, etc.

Si bien algunos usuarios aun experimentan problemas con PulseAudio, se trata de una solución que vino para quedarse y sentar las bases de una nueva era del manejo de audio en Linux.

Link : EarCandy is a smart PulseAudio Volume Manager (Web Upd8)

Via Phoronix nos enteramos de que esta historia parece tener un final feliz, ya que se ha logrado integrar por primera vez el driver de Creative X-Fi al sistema de audio ALSA en Linux, en otras palabras, las tarjetas X-Fi de Creative tendrán soporte oficial de audio en las distribuciones de Linux más populares.

Originalmente Takashi Iwai de Novell había intentado contactar a Creative para trabajar en este tema, pero no había suficiente interés por parte de la compañía y como solución de parche se había modificado otro driver para intentar integrarlo en ALSA, pero era lejos una solución aceptable.

Takashi finalmente logró obtener cooperación de Creative Labs para crear este driver oficial de X-Fi para ALSA.  Este nuevo driver se llama snd-ctxfi y estará disponible en la próxima versión del kernel de Linux 2.6.31, por lo que seguramente lo veremos en las distribuciones que serán liberadas a fines de este año.

Links:
- Finally, a Creative X-Fi driver going into ALSA (Phoronix)
- Testers wanted : A new SB X-Fi driver (alsa-devel mailing list)
- Alsa 1.0.20 trae múltiples mejoras para audio en Linux (FayerWayer)

(cc) José Serralde

ALSA es el componente que se encarga del sonido en Linux.  Consiste básicamente en un conjunto de drivers y utilidades para dar soporte a los dispositivos relacionados con el audio : chips de sonido, tarjetas externas via USB/Firewire, manejo de conectores de audífonos, parlantes. etc.

Esta entrega de ALSA 1.0.20 tiene muchos cambios, pero algunos destacables son los que afectan al driver C-Media Oxygen, HDA Codec y HDA Intel.  Sin embargo, los usuarios de Creative X-Fi tendrán que seguir esperando.

El driver de Oxygen es el que soporta tarjetas de la gama alta del segmento “gaming/consumer” como son la Razer Barracuda AC-1 y la Asus Xonar.  Hace un par de años este driver fue reescrito debido a que no había tenido una buena fundación.  En ALSA 1.0.20 ahora el driver Oxygen tiene soporte para la tarjeta de sonido Xonar Essence STX, soporte para salida de audífonos en las tarjetas Claro entre otras mejoras.

HDA  es una especificación de Intel para audio de alta definición (High Definition Audio), se trata de una mejora sobre la ya obsoleta especificación AC97, dando soporte a más canales y mayor calidad.  Con esta especificación, distintos fabricantes pueden construir hardware que soporte 2 canales hasta 192Khz con 32 bits por sample o hasta 8 canales con 96Khz y 32 bits por sample.   Como referencia, el CD Audio es de 44.1Khz a 16 bits por sample.

El HDA Codec se encarga de mover el audio desde o hacia los distintos conectores del sistema, en esta versión de ALSA hay soporte para varios laptops nuevos e implementaciones de HDA que incluyen algunas de Apple.  En el driver genérico de HDA Intel se incluyen correcciones para audio por HDMI.

Mega Bonus Track : La historia de amor y odio con Creative X-Fi.

Lo que aun sige pendiente es el soporte de las tarjetas Creative X-Fi.  En esta versión de ALSA aún no hay soporte pese a que la tarjeta lleva sus años y Creative Labs liberó un driver de código abierto hace poco.

Phoronix nos cuenta la historia de Creative X-Fi y Linux.

En Junio del 2006 Creative anunció que estaba trabajando en un driver para X-Fi, y esperaban tenerlo listo para el segundo trimestre del 2007.  El driver prometido ofrecería soporte para ALSA, OpenAL e incluso EAX.

Cuando el plazo se cumplió, Creative Labs admitió que tuvieron que bajar la prioridad del soporte a Linux en favor de Windows Vista.  Crear el soporte para la serie Sound Blaster en Windows Vista requirió más recursos de lo esperado, y tuvieron que reducir la asignación al soporte de Linux. Cambiaron la fecha para el driver de X-Fi en Linux a finales del 2007, pero sólo sería una versión beta.

En Septiembre de 2007 finalmente apareció el driver en su versión beta, pero era sólo un binario lleno de bugs que mas bien parecía en estado alfa.  De hecho el poco código fuente que podía ser compilado no era compatible con las versiones modernas de GCC y sólo soportaba la arquitectura Linux x86_64.

En Febrero del 2008, apareció el soporte para Creative X-Fi en el Open Sound System (OSS) de 4Front, que es sistema de audio que se usaba en Linux antes de la inclusión de ALSA.  A pesar de que este esfuerzo, para las distribuciones más usadas no cambiaba la situación ya que desde años se basan en ALSA.

En abril del 2008, Creative nuevamente trató de crear un driver para Linux, pero nuevamente estaba lleno de bugs.  Al menos tenía soporte para la arquitectura Linux x86 que aún es la más común, y era compatible con la serie 4.x del compilador GCC.  Aun asi, un año después del lanzamiento del beta, el driver se mantenía en malísimo estado.

A principios de Noviembre, la comunidad Linux quedó impactada porque Creative abría el código de su driver para X-Fi  bajo GPL.  El código era funcional, a pesar de que faltaba soporte para algunas características como S/PDIF pass-through.  A partir de ese momento, nunca más se publicaron actualizaciones de este driver.

Aun no hay soporte de X-Fi en ALSA.  Hay un driver a medio camino que fue derivado del trabajo en OSS, pero no tiene relación con el driver de código abierto de Creative, y nadie se encuentra trabajando en él.

Takashi Iwai, el desarrolladore de SuSE que originalmente portó el driver de OSS a ALSA, hace poco habló sobre Creative Labs en la lista de correo de ALSA y dijo que la compañia no estaba interesada en trabajar con los desarrolladores de código abierto y que no tenían interés de que su driver fuera incluido en ALSA.

Usuarios de Linux, ya saben qué hardware no conviene comprar.

Links:
- ALSA 1.0.20 released, many fixes & improvements (Phoronix)
- Creative Labs continues to shaft Linux (Phoronix)