Thread by @devruso

¿Queríais rant sobre el lamentable estado del stack de audio de Linux (porque el rant sobre el lamentable estado del stack gráfico se os quedó corto)? ¡Pues allá vamos! ⬇

El "stack de audio" es esa parte del OS que te permite escuchar los diálogos ̶d̶e̶l̶ ̶p̶o̶r̶n̶o̶ de las películas, música, tener notificaciones con sonido, etc...

MacOS lo tiene. Windows lo tiene. Arrancas el ordenador, enchufas cualquier altavoz comprado en el todo-a-cien, abres una o varias aplicaciones a la vez y todo se escucha. Sin dramas, sin complicaciones. Es lo *único* que pide y se espera el 836% de los usuarios en desktop. Fin.

... y luego está Linux...

Todo empezó allá por el siglo XIV cuando los "PCs" podían reproducir sonido de 2 maneras: por los impactos de los golpes que se les daba o usando una tarjeta de sonido.

Y no una cualquiera, sino LA tarjeta de sonido. Estoy hablando de la Sound Blaster (SB en adelante). Absolutamente todo estaba hecho para *esa* tarjeta de sonido (sobretodo los juegos). Era tan popular que el resto de fabricantes hacían sus tarjetas compatibles con ella.

Y en Linux se implementó el soporte para SB bajo una API llamada (tirando de creatividad ilimitada) "Linux sound API". Los drivers del resto de tarjetas seguían el mismo diseño de dicha API; A mediados de los 90 su nombre cambió a OSS[0].

[0] - en.wikipedia.org/wiki/Open_Soun…

Cada driver de cada tarjeta de sonido implementaba la interfaz de OSS, así que las aplicaciones usaban OSS para no tener que implementar soporte para cada tarjeta de sonido.

Recapitulemos:

App -> OSS -> altavoces
App <- OSS <- micrófono

Facil facil 👍👌

Seguimos!

OSS estaba diseñado muy bien, con una interfaz muy simple, y una buena documentación. Era la pera limonera! Hasta tal punto que se portó a *BSD y Solaris. Y gracias a ello todas las apps que usaban OSS automáticamente pasaron a ser "multi-OS" (en lo que se refiere al tema sonido)

Las tarjetas de sonido molaban fuertemente porque hacían mixing por hardware. "Mixing" es cuando 2 fuentes de audio independientes, por ejemplo 2 apps, intentan usar el sistema de sonido y acabas oyendo ambas cosas a la vez porque la tarjeta de sonido "mezcla" ambas fuentes.

Ejemplo: jugar a un juego con los efectos de sonido activados y escuchar musica con un reproductor de musica.

Y OSS molaba fuertemente porque le dejaba a las tarjetas de sonido hacer el mixing.

Molaba hasta que un día los fabricantes decidieron abaratar costes y las tarjetas de sonido dejaron de hacer mixing por hardware. ¿Y qué pasó luego? Pues que cada driver detrás de OSS (y OSS en sí) tuvo que ser parcheado para hacer el mixing por softwAJAJHAHJAHJAHJAJHAJHAJHJAHjhA

Empezó el caos. Veréis... Ni OSS estaba diseñado para hacer mixing por software, ni nadie se iba a poner a reescribir todos los drivers para que hicieran el mixing por software. Al no poderse hacer mixing por software (por aquel entonces y en aquella versión de OSS), cuando una

aplicación reproducía sonido, ganaba acceso exclusivo al sistema de sonido y ninguna otra aplicación podía usar el sistema de sonido de ninguna manera.

Es decir, si tenías abierto el reproductor de música y alguien te enviaba un mensaje a tu cliente de mensajería instantánea, este se bloqueaba, puesto que no era capaz de acceder al sistema de sonido para reproducir el sonido de notificación.

Bienvenidos al "Can't open audio device /dev/dsp: Device or resource busy". Este mensaje definiría la siguiente década en el mundo del sonido en Linux.

Y la comunidad de Linux se puso manos a la obra para solucionar el problema de la mejor manera que saben: dando tumbos a diestro y siniestro, creando media docena de estándares para cubrir lo mismo, pero con distintos nombres <because choices>.

Y asi nacen aRts (artsd)[1] de KDE y ESD[2] de Enlightenment y Gnome. Son 2 servidores de sonido (principios de los 1999).

[1] - en.wikipedia.org/wiki/ARts
[2] - en.wikipedia.org/wiki/Enlighten…

"¿Y qué hace un servidor de sonido?" os preguntareis.

Muy simple. Se encarga de comunicar las aplicaciones (clientes) con OSS.

De esa manera, si 2 aplicaciones intentan usar el sistema de sonido a la vez, el servidor de sonido puede hacer el mixing (entre otras cosas; no voy a entrar en detalles sobre todo lo que hace un servidor de sonido) y darle al usuario el resultado que se espera.

Recapitulemos de nuevo:

App -> aRts / ESD -> OSS -> altavoces
App <- aRts / ESD <- OSS <- micrófono

Genial. Problema arreglado, no?

mmm... nope...

Resulta que la situación empeoró porque ahora había:

* apps que usaban directamente OSS (haciendo uso exclusivo del sistema de sonido y bloqueando artsd / ESD y cualquier app que los usara)

* apps que usaban artsd (que no funcionaban si tu distro / entorno usaba ESD)

* apps que usaban ESD (que no funcionaban si tu distro / entorno usaba artsd)

Tampoco podías instalarte artsd y ESD a la vez porque eran mutuamente excluyentes (al fin y al cabo cada uno de ellos usaba OSS por debajo, lo cual significaba que en cuanto uno de ellos empezaba a usar OSS, el otro se quedaba sin acceso)

Vamos, que si antes las probabilidades de que el sonido funcionase eran bajas, ahora eran nulas.

Los devs simplemente no podían implementar OSS + aRts + ESD en sus apps para que funcionasen en cualquier distro. Así que los creadores de aRts y ESD unificaron su trabajo en un único proyecto llamadJAHJHAHJAHJAJHAHJAJHAJHJAHJHAJHAJHAJHAJHAHJA

Nacieron libao, SDL, Allegro y GStreamer (entre otras librarías), que implementaron soporte para OSS + aRts + ESD, para que los devs usasen alguna de esas para comunicarse con el servidor de sonido.

Recapitulemos de nuevo, que esto empieza a ser lioso.

App -> [libao | SDL | Allegro | GStreamer ] -> [aRts | ESD] -> OSS -> altavoces
o
App -> [libao | SDL | Allegro | GStreamer ] -> OSS -> altavoces

(y para el micrófono lo mismo, pero recorriendo al revés)

Y ahí es cuando una empresa (4Front Technologies) decidió contratar al creador de OSS y hacer negocio. La idea era que OSS seguiría teniendo una parte libre y gratuita y otra parte de pago (con características avanzadas).

La comunidad entera se cogió un rebote increíble e hicieron, una vez mas, lo que mejor saben: unificar todo bajo un mismo proyecto, mejorando drásticamente la experiencia del usuarHJAHJAHJAHJAHJAHJAHJJHAJHAHJAJHAJH

Crearon ALSA, que ocuparía el lugar de OSS. Así que ahora las apps y los servidores de sonido tenían que soportar también eso.

Y los *BSD y Solaris hicieron un fork de OSS.

Supongo que hasta aquí llegó el tema de "muti-OS" en las apps que usaban OSS (en lo relativo al sonido).

ALSA (en esa primera versión) tenía algunas características más avanzadas que OSS, pero carecía de la única cosa que pedían los usuarios: mixing por software que funcionase...

Pero a lo hecho pecho. ALSA reemplazó a OSS dentro del Kernel (2002) e implementó una capa de compatibilidad con OSS para hacerse pasar por OSS y que así las apps que usaban OSS pudiesen usar ALSA sin enterarse.

Las apps / servidores de sonido podían elegir entre usar la API de ALSA (y esas funciones avanzadas, como el mixing por software que no terminaba de funcionar) o usar la capa de compatibilidad con OSS (que por alguna razón extremadamente oligofrenica no implementaba el mixing...

...por software; aunque daría igual, porque tampoco funcionaba) y seguir con las mismas limitaciones como hasta ahora.

Básicamente los devs tenían que elegir entre que sus apps siguiesen sin funcionar o portar (una vez mas) el sistema de sonido a otra API para que todo siguiese sin funcionar.

Difícil elección, ¿verdad?

Mientras tanto OSS empezó a implementar más cosas, entre las cuales estaba el mixing por software (este sí funcionaba), pero esa nueva versión no se iba a incluir en el kernel, así que la situación no mejoraba para

la mayoría de usuarios (mejoró solo para aquellos que sabían entender todo esto e instalarse OSS por su cuenta; ...recompilando el kernel...).

En un giro dramático de los acontecimientos OSS decidió implementar una capa de compatibilidad con ALSA, para que las apps que usaban la API de ALSA pudiesen funcionar con OSS.

Eran poco los servidores de sonido, así que entran en escena dos más: Jack[3] y sndio[4]

[3] - en.wikipedia.org/wiki/JACK_Audi…
[4] - en.wikipedia.org/wiki/Sndio

Jack brillaba por sus funcionalidades (orientadas a profesionales). Latencia baja, resampling, mixing... Podía tratar cada componente (app, servidor de sonido, driver) como una pieza de entrada o salida, lo cual permitía hacer autenticas locuras, como por ejemplo duplicar y

enrutar la salida de audio de un juego a la entrada de audio de una app de grabación y a la entrada de audio de un servidor de sonido remoto.

Pero su API era ridículamente compleja, lo cual dificultó su adopción.

Tampoco ayudaba el hecho de que muchas apps seguían usando directamente ALSA u OSS (lo cual bloqueaba el acceso al sistema de sonido al resto de cosas que había por encima)

Y luego estaba sndio, que era tan simplón que no tenía ni archivo de configuración. Todo funcionaba sin más. Obviamente su adopción fue nula porque nadie quería que el sonido le funcionase sin mas. Eso era de jipies!

Vamos con el resumen:

En este punto los devs que querían reproducir sonido en sus apps debían elegir entre:

* libesd-alsa
* libesd-oss
* alsa-oss
* alsaplayer-esd
* alsaplayer-jack
* alsaplayer-oss
* gstreamer-alsa
* gstreamer-esd
* gstreamer-jack
* lib-alsa-oss
* libao

por nombrar algunas.

Todo era una 💩. No funcionaba nada. Ni iba a funcionar, porque toda la comunidad estaba en un jaque-mate táctico. Nadie cedía, todo el mundo decía que su servidor de sonido era la mejor opción.

Nadie mejor que XKCD para resumir lo que pasó a continuación.

Sí, efectivamente... Nace otro servidor de sonido: PulseAudio[5] (2004) (PA de aquí en adelante)

[5] - en.wikipedia.org/wiki/PulseAudio

La idea es que, como hay tantos servidores de sonido y nadie cede, PA va a implementar una capa de compatibilidad con todo. Literalmente. *LITERALMENTE*. Así que PA hablaba la API de ESD, la API de artsd, la API de Jack y la API de sndio.

Lo que me sorprende es que siquiera fuera posible compilar eso.

Contra todo pronostico, Lennart (el creador de PA. Y de systemd... ya lo veremos en otro hilo) consigue convencer a las distros para meter por defecto PA como servidor de sonido.

Pero seguía estando el problema de las muchas apps que usaban ALSA u OSS directamente (en vez de usar cualquiera de los servidores de sonido), así que PA decide hacer otra capa de compatibilidad de ALSA y de OSS. Nacen pulseaudio-alsa y ossp / padsp.

Esto, en teoría, debería haber mejorado drásticamente el problema de las mil piezas que se conectaban.

Y digo "en teoría", porque la practica es que PA fue lanzado de manera muy prematura y no funcionaba absolutamente nada. Fue solo varios años mas tarde (circa 2010) cuando PA realmente empezó a solucionar los problemas para los que fue diseñado.

Ademas, hubo otro problema a mayores. El problema de "por mis huevos morenos que mi creación es mejor que la tuya, tonto🍆". ALSA saca una capa de emulación para hacerse pasar por PA: apulse[6] (2014)

[6] - github.com/i-rinat/apulse

Y el panorama del audio a estas alturas se podía resumir así:

¿Estamos bien? ¿Seguimos? Enga...

Empiezan a salir cascos bluetooth, teles y altavoces que soportan DLNA y Chromecast, sistemas de sonido de alta fidelidad con muchos canales y Dolby Surround Premium Platinum UltraPlus, etc...

Y PA saca modulos para todo. Nada mas y nada menos que la friolera de 70 modulos[7]. Ni voy a entrar a evaluar si todo eso funciona bien o mal, quien lo haya usado ya tendrá su opinion.

[7] - freedesktop.org/wiki/Software/…

El caso es que en el 2015 se empieza a trabajar en un complemento de PA: PipeWire[8] (PW de aquí en adelante)

[8] - en.wikipedia.org/wiki/PipeWire

Supuestamente PW estaba orientado al vídeo en Linux.

Por mencionar algún problema que aspira a solucionar: al igual que 2 aplicaciones de audio no podían reproducir audio sin algo que hiciera "mixing", 2 aplicaciones de vídeo no pueden acceder a la webcam sin algo que haga de "túnel".

¿Y por qué estoy metiendo PW en el hilo? Porque en el 2017 se decidió que...

...PW iba a...

...sustituir PA...

...actuando como un servidor de sonido...

...y haciéndose pasar (con una capa de emulación) por PA...

...y por ALSA...

...y por Jack...

...y por no-se-que-mas...

Y aquí estamos, en el 2022. Y PW no está operativo, ni cerca de estarlo (a juzgar por la wiki de Gentoo[9])

[9] - wiki.gentoo.org/wiki/PipeWire

Allá por el 2035, cuando hayan salido otros 6 o 7 servidores de sonido voy a continuar con el hilo. De momento, I'm out!

Notas del autor: he dejado fuera todo el tema de codecs, xine, phonon, jack2, ffado, portaudio, bluez, etc... porque el clusterfuck de decisiones tomadas con estos es del mismo estilo que el del hilo.