PipeWire es una de las tecnologías llamadas a jugar un papel muy importante en el futuro del escritorio Linux, no solo porque ha sido postulada como la sustituta de PulseAudio y JACK, sino porque en realidad es un servidor de transmisión de multimedia que va más allá de la etiqueta de “servidor de sonido” que muchos le han puesto.

Los retos a los que se enfrenta PipeWire han quedado plasmados en una entrevista publicada en Fedora Magazne que Christian Schaller, director senior del equipo de escritorio de Red Hat y uno de los pesos pesados de GNOME y Fedora, ha realizado a Wim Taymans, uno de los fundadores de GStreamer, creador de PipeWire y también empleado de Red Hat.

La ambición mostrada en el desarrollo de PipeWire queda plasmada en los diversos desafíos que tiene por delante, de entre los que se puede destacar el dotar a GNU/Linux de un servidor de sonido de categoría profesional y el ofrecer un marco que facilite la captura y la compartición de la pantalla en sesiones de Wayland. En lo que respecta al último apartado se han dado muchos pasos hacia adelante en los últimos meses, sobre todo gracias al futuro OBS Studio 27 y a pequeños proyectos como Kooha.

Wim Taymans explica en la entrevista que PipeWire ha terminado siendo el resultado de dos ideas anteriores: “La primera fue PulseVideo, que fue escrito por William Manley en 2015. Era un pequeño servidor que enviaba el video desde una cámara V4L2 a uno o más procesos. Usó GStreamer, DBus y el pase de descriptor de archivo (fd) para realizar el proceso de manera eficiente.”

“Por aquella época empezamos a pensar en la captura de la pantalla desde Wayland y me pidieron que investigara las opciones. La idea fue entonces tomar el concepto de PulseVideo e implementar la posibilidad de que los clientes también proporcionen transmisiones (no solo dispositivos V4L2). Otro requisito era hacer esto de forma segura y lidiar correctamente con Flatpak y su concepto de portales para manejar cosas con posibles problemas de seguridad”.

Llegados a este punto, podría ser de valor recordar que el desarrollo de PipeWire está bastante vinculado al de Flatpak, algo que no tendría que sorprender si tenemos en cuenta que esas dos tecnologías, además de GNOME, systemd y PulseAudio, están todas impulsadas principalmente por Red Hat, lo que explica el hecho de que Fedora sea la distribución que marque la evolución tecnológica de GNU/Linux.

Como vemos, la función de PipeWire como servidor de sonido es algo que no estaba al principio, ya que en Fedora 27, primera versión de la distribución que lo suministró, solo era capaz de lidiar con la captura de vídeo. El propio Wim Taymans dice que PipeWire necesitó de “otra reescritura” para poder manejar sonido, cosa que refuerza su condición de servidor de transmisión de multimedia. Sin embargo, desde MuyLinux no vamos a rebatir a quien lo defina como un servidor de sonido, porque así será visto y percibido por parte de los usuarios de perfil más bajo que se limitan a usar su ordenador solo para Internet, oficina y jugar a videojuegos.

En lo que respecta a la relación de PipeWire con GNOME, Taymans ha explicado que “GNOME Shell enviará una transmisión a PipeWire cuando se active el uso compartido de la pantalla. PipeWire enrutará este flujo a aplicaciones como Firefox o la grabadora de pantalla. Tenemos algunas características más avanzadas implementadas, como el paso de DMA-BUF y los metadatos para el cursor y las regiones de recorte cuando se comparte una sola ventana. También existe el control de volumen que interactúa a través de la API de PulseAudio con PipeWire para administrar los volúmenes”.

PipeWire en alsamixer

El nuevo marco para realizar screencasting y screensharing desde una sesión de Wayland, que es uno de los principales frentes que se pretenden cubrir con PipeWire, está suponiendo todo un reto, más si tenemos en cuenta que las gráficas de Intel son las únicas que cuentan con una implementación madura de DMA-BUF. En AMD Radeon por ahora está presentando bastantes problemas y NVIDIA está empezando a recorrer el camino por su terquedad.

Continuando con la relación de PipeWire con GNOME, Taymans expone que en realidad antes “no había nada para compartir la pantalla”, sino solo llamadas de X11 para capturar el contenido de la pantalla. “Jan Grulich trabajó con el proyecto WebRTC para agregar código que interaccionara con las nuevas API de portales definidas para Wayland y luego negociara las opciones de uso compartido de la pantalla y el soporte nativo de PipeWire para obtener el contenido de la pantalla. Luego, Martin Stransky portó hacia atrás ese trabajo en la copia de Firefox de WebRTC y Jan Grulich y Tomas Popela se aseguraron de que los cambios se fusionaran en Chromium/Chrome”.

A estas alturas no hace falta explicar que PipeWire es compatible con ALSA, PulseAudio y JACK, pero solo puede sustituir a los dos últimos porque el primero, al ser parte del kernel Linux, se encarga de suministrar el firmware necesario para hacer funcionar los chips de sonido. La transición de PulseAudio y JACK a PipeWire ha sido muy bien estudiada, hasta el extremo de que el tercero ofrece una alta compatibilidad con las herramientas hechas para funcionar con los dos primeros.

Quienes siguen de cerca este portal saben que soy usuario de Fedora y que ahora tengo una configuración pura de PipeWire con la versión 34 de la distribución (Ubuntu 21.04 sigue usando PulseAudio por defecto). Tengo que reconocer que PipeWire me tenía atemorizado porque en mi equipo de sobremesa no uso un chip de sonido Realtek, sino una tarjeta de sonido dedicada Xonar DSX debido a que el ALC1220 de la placa base que uso me ha salido rana. La razón de mi temor no venía de la detección de la tarjeta, porque de eso se encarga ALSA, sino del hecho de que la integración de la Xonar DSX con PulseAudio lleva rota muchos años.

Por suerte, PipeWire trabaja muy bien con la Xonar DSX, detectando correctamente los conectores Jack y no solo eso, sino que he recuperado la gestión centralizada del volumen de salida a través de la interfaz de GNOME, permitiéndome de esta manera prescindir de QasMixer, una interfaz gráfica para alsamixer que he usado durante un tiempo debido a los mencionados problemas con PulseAudio (sin embargo, desde la versión 0.36 de PipeWire me he encontrado con un bug que se reproduce cuando se cierra y abre la sesión a gran velocidad).

Como vemos, PipeWire tiene muchos retos por delante y es ahora cuando empezará a tener que lidiar con entornos reales en los que hay configuraciones de hardware y software de lo más variopinto. Si queréis conocer más detalles y curiosidades de PipeWire, cuyo desarrollo se inició en Andalucía (si bien Taymans es belga), os invitamos a ver la entrevista publicada en Fedora Magazine.