Après sept mois de développement, une nouvelle branche stable du serveur multimédia PipeWire 1.2.0 a été formée, remplaçant le serveur sonore PulseAudio et se distinguant par l'ajout de moyens pour gérer les flux vidéo, la possibilité de traiter le son avec des latences minimales et un nouveau modèle de sécurité pour gérer l'accès au niveau de dispositifs et de flux individuels. Le projet est soutenu dans GNOME et est utilisé par défaut dans Fedora Linux, RHEL, Ubuntu, Debian, SUSE/openSUSE et de nombreuses autres distributions Linux. Le code du projet est écrit en C et est distribué sous la licence LGPLv2.1.
PipeWire est basé sur une architecture multiprocessus, permettant un accès collaboratif au contenu de plusieurs applications.
Il offre des fonctionnalités pour le traitement de tout type de flux multimédia, le mélange et le redirectionnement de flux vidéo, ainsi que la gestion des sources vidéo, telles que les dispositifs de capture vidéo, les webcams ou le contenu de l'écran généré par des applications. Par exemple, PipeWire permet la collaboration de plusieurs applications avec une webcam et résout les problèmes de capture sécurisée du contenu de l'écran et d'accès à distance à l'écran dans un environnement Wayland.
Lorsqu'il est utilisé comme serveur sonore, PipeWire peut offrir des latences minimales et fournir des fonctionnalités combinant les capacités de PulseAudio et de JACK, prenant en compte les besoins des systèmes de traitement audio professionnel, ce à quoi PulseAudio ne pouvait prétendre. De plus, PipeWire propose un modèle de sécurité avancé, permettant de gérer l'accès au niveau de dispositifs individuels et de flux spécifiques, facilitant ainsi la gestion du passage du son et de la vidéo depuis et vers des conteneurs isolés. L'un des principaux objectifs est de soutenir des applications autonomes au format Flatpak et de fonctionner dans une pile graphique basée sur Wayland.
Dans la nouvelle version :
- Le modèle de traitement des flux de données basé sur un graphe de nœuds a ajouté le support du traitement asynchrone, où le graphe de nœuds n'est pas bloqué en l'absence de sortie d'un nœud spécifique, mais continue de fonctionner en utilisant les données obtenues du nœud au cycle précédent. Ainsi, au prix d'une latence d'un cycle, il est possible d'éviter une situation où un nœud bloque le fonctionnement des autres nœuds dans le graphe.
- La conception de groupes de nœuds synchronisés (node.sync-group) a été mise en œuvre, permettant de créer des groupes de nœuds activés simultanément par le planificateur. Cette fonction peut être utilisée pour planifier l'activation simultanée des nœuds lors du démarrage du transport JACK.
- Amélioration de la sortie des informations d'erreur dans le fichier de configuration, ajout de la mention de l'endroit où l'erreur s'est produite dans les paramètres (numéro de ligne et position dans la ligne).
- Ajout du support de la technologie Explicit Sync, permettant aux applications d'informer le gestionnaire de composition basé sur le protocole Wayland que l'affichage d'une image est prêt à être affiché à l'écran, ce qui permet de réduire les latences et d'éliminer l'apparition d'artefacts lors de l'affichage graphique. En particulier, Explicit Sync résout les problèmes de décalage d'affichage et de gel sur les systèmes avec GPU NVIDIA et le support Wayland activé.
- Mise en œuvre de la possibilité de déterminer des métadonnées obligatoires lors de la négociation des paramètres de tampon, utilisées pour assurer la prise en charge d' "Explicit Sync".
- Ajout du support pour la création et l'utilisation de plusieurs boucles de traitement de données (data-loop) dans le client et le serveur. Les boucles de traitement de données incluent des fonctionnalités pour se lier à des cœurs CPU spécifiques et définir des priorités.
- Possibilité de modifier les niveaux de débogage contrôlant la sortie des informations dans le journal sans redémarrage, en utilisant des métadonnées.
- Logique de liaison des pairs (nœuds dans le graphique des flux de données, définissant des sources externes ou des récepteurs de données) repensée.
- Patches acceptés pour le traitement des appareils marqués comme conflictuels via ALSA UCM (Use Case Manager).
- Ajout du module snapcast-discover pour le streaming de contenu dans serveurs SnapCast.
Source : opennet.ru
