En Ubuntu 22.10 se usará PipeWire en lugar de PulseAudio

Hace ya algunos días se dio a conocer la noticia que el repositorio de desarrollo de la versión Ubuntu 22.10 se movió para usar el servidor de medios PipeWire predeterminado para el procesamiento de audio.

Con este cambio, los paquetes relacionados con PulseAudio se han eliminado de los paquetes desktop y desktop-minimal, y por compatibilidad, en lugar de bibliotecas para interactuar con PulseAudio, se ha agregado una capa pipewire-pulse que se ejecuta sobre PipeWire, lo que le permite mantener todos los existentes clientes de PulseAudio funcionando.

La persona quien confirmo el cambio fue Heather Ellsworth de Canonical, quien mediante una publicación comento sobre la decisión de migrar completamente a PipeWire en Ubuntu 22.10.

Se observa que en Ubuntu 22.04 se usaron ambos servidores en la distribución: PipeWire se usó para procesar video al grabar screencasts y proporcionar acceso a la pantalla, pero el audio continuó procesándose usando PulseAudio. En Ubuntu 22.10, solo permanecerá PipeWire.

Así es, a partir de hoy, Kinetic iso (pendiente, aún no actual ya que se acaban de realizar los cambios) se ha actualizado para ejecutar solo pipewire y no pulseaudio. Asi que@copong, puede esperar esto para kinetic.

Para Jammy, puede notar que tiene tanto pipewire como pulseaudio ejecutándose. Esto se debe a que aún se usa pulseaudio para el audio, pero se usa pipewire para el video. (Se necesita Pipewire para transmitir y compartir pantallas en Wayland).

Espero que esto aclare nuestros planes con respecto a pipewire/pulseaudio, pero avísenos si tiene más preguntas.

Hace dos años, ya se implementó un cambio similar en la distribución de Fedora 34, que permitió brindar capacidades profesionales de procesamiento de audio, eliminar la fragmentación y unificar la infraestructura de audio para diferentes aplicaciones.

Para quienes desconocen de PipeWire, deben saber que este ofrece un modelo de seguridad avanzado que le permite administrar el acceso por dispositivo y por transmisión, lo que facilita la transmisión de audio y video desde y hacia contenedores aislados.

PipeWire puede procesar cualquier flujo de medios y puede mezclar y redirigir no solo flujos de audio, sino también flujos de video, así como administrar fuentes de video (dispositivos de captura de video, cámaras web o contenido de pantalla que muestran las aplicaciones). PipeWire también puede actuar como un servidor de audio de baja latencia y brindar una funcionalidad que combina las capacidades de PulseAudio y JACK , lo que incluye tener en cuenta las necesidades de los sistemas de procesamiento de audio profesionales que PulseAudio no podría reclamar.

De las características clave que se pueden destacar:

• Capacidad de capturar y reproducir audio y video con demoras mínimas
• Herramientas para el procesamiento de video y sonido en tiempo real
• Arquitectura multiproceso que permite organizar el acceso compartido al contenido de varias aplicaciones
• Modelo de procesamiento basado en gráficos de nodos multimedia con soporte para bucles de retroalimentación y actualizaciones de gráficos atómicos. Está permitido conectar controladores tanto dentro del servidor como en complementos externos
• Interfaz eficiente para acceder a secuencias de video a través de descriptores de archivos y acceso de audio a través de un búfer de anillo compartido
• Capacidad para procesar datos multimedia de cualquier proceso
• La presencia de un complemento para GStreamer para simplificar la integración con las aplicaciones existentes
• El soporte para entornos aislados y sistema de paquetes Flatpak
• El soporte para complementos en formato SPA (Simple Plugin API) y la capacidad de crear complementos que funcionan en tiempo real duro
• Sistema flexible para negociar formatos multimedia usados ​​y asignación de búfer
• Capacidad de poder usar un solo proceso en segundo plano para enrutar audio y video.
• La capacidad de actuar como un servidor de sonido, un centro para proporcionar video a las aplicaciones (por ejemplo, para la API de screencast de gnome-shell) y un servidor para controlar el acceso a los dispositivos de hardware de captura de video.

Finalmente para quienes estén interesados en poder conocer más al respecto sobre la nota, pueden consultar el hilo de la discusión en el siguiente enlace.