At the same time we don’t want to make this another painful subsystem transition so PipeWire so we will need to ensure that PulseAudio applications can still be run without modification.
Merci. Je note quand même que ce souci d’éviter de trop grandes souffrances ne concerne que les développeurs d’applications utilisant PulseAudio. Développeurs d’applications Jack, vous allez en chier [...]
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier... Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.
[^] # Re: Leave Jack alone!
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal PipeWire veut unifier la gestion des flux audio et video. Évalué à 4.
Ce n'est pas pcq il n'est rien dit au sujet de Jack qu'il faut imaginer que les développeurs d'applications Jack vont en chier... Comme pour PulseAudio, il sera peut-être possible que Jack utilise en interne PipeWire.
PipeWire est un projet encore très jeune, en ce qui concerne les plans pour l'audio pro et Jack, les plans sont encore peut-être flous.
Aussi, Christian Schaller a l'air d'avoir écrit son blog post assez vite, en tout cas il ne s'est pas relu attentivement pcq il y a pas mal de phrases avec des petites erreurs (comme celle ci-dessus). Donc ça ne sert à rien d'essayer d'extrapoler sur des choses qui sont omises dans ce blog post.
Bref, je pense qu'on n'a pas assez d'informations sur PipeWire pour avoir un avis raisonné, en tout cas en ce qui concerne l'audio pro.
Pour ma part, après avoir lu les fichiers README et doc/design.txt (en plus des blog posts de Christian Schaller), PipeWire m'a l'air d'être un projet très prometteur.
Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ? Est-il possible de sandboxer des applications Jack et qu'elles puissent toujours communiquer entre-elles ? PipeWire règle en tout cas ces deux problèmes, avec une solution plus générale, c'est-à-dire qui convient pour n'importe quel flux multimédia (audio et/ou vidéo), pas seulement pour l'audio. Et puisque PipeWire se base en grosse partie sur GStreamer, il y a énormément de code existant qui peut être réutilisé. Je suis sûr que l'équivalent de PulseAudio réécrit dans PipeWire aura beaucoup moins de lignes de code. Réutiliser la même stack multimédia que fournit GStreamer, ça a tout à fait son sens, selon moi.