Journal PipeWire veut unifier la gestion des flux audio et video

Posté par  . Licence CC By‑SA.
Étiquettes :
38
22
juin
2017

TLDR; c'est résumé sur le site web de Pipewire

Qui parmi les lecteurs réguliers de LinuxFr.org n'a jamais entendu parler de PulseAudio ? Pour les profanes, rappelons que PulseAudio(1) est une brique logicielle que l'on retrouve au sein de nombreuses distributions GNU/Linux. Son rôle est de recevoir l'ensemble des flux audio issus des différents logiciels, et de les transmettre ensuite à une carte son ou bien un autre équipement à travers le réseau - par exemple un PC dédié au Home Cinema (HTPC). Il s'agit d'une alternative à un autre serveur de son plus ancien nommé Jack, que PulseAudio visait à remplacer, sujet hautement polémique s'il en est.

Hé bien Wim Taymans, connu pour son travail sur Gstreamer (voir la page Wikipedia anglosaxone le concernant), travaille pour le compte de RedHat sur un logiciel du nom de Pipewire (anciennement Pinos). Ce logiciel dont le nom de code était PulseVideo est inspiré de vous aurez deviné quoi. Pulsevideo visait à permettre à plusieurs applications d'accéder simultanément à un même flux vidéo, tel que celui d'une webcam, comme l'indique la maquette de WimManley sur Github

L'intérêt ? Christian Schaller (salarié RedHat) nous le présentait il y a 2 ans sur son blog, du moins pour ce qui concerne Fedora. Il peut s'agir par exemple de faire des démos logicielles en combinant l'enregistrement d'écran avec la webcam. Les applications isolées dans un bac à sable devraient également en bénéficier pour exposer leurs flux vidéo et audio. Mais à l'époque, non non, il n'était pas question de remplacer PulseAudio nous assurait-on.

Depuis, de l'eau a coulé sous les ponts et Schaller évoque Pipewire parmis les perspectives de Fedora Workstation 26 et au-delà. Les ambitions sont autrement plus grandes que celles affichées autrefois car il est désormais question d'« unifier l'audio et la vidéo sur Linux ». Et ça veut dire unifier l'audio, donc « gérer l'audio d'une manière qui non seulement couvre les cas d'utilisation de PulseAudio, mais aussi ceux gérés par Jack aujourd'hui »…

PipeWire fera-t-il disparaître PulseAudio, et aura-t-il la peau des trolls qui depuis 12 ans se repaissaient de cet inépuisable sujet de conversation ?


  1. PulseAudio est aujourd'hui maintenu par Arun Raghavan et Tanu Kaskinen. Ce dernier a récemment lancé une campagne de financement parce qu'après tout, c'est pas parce qu'on aime ce qu'on fait qu'on doit pas être payé.
  • # Le troll ne partira pas avec un PulseAudio 2

    Posté par  . Évalué à 1.

    J'ai un peu l'impression (d'après ton résumé) que l'on va se retrouver avec un PulseAudio 2, toujours plus de fonctionnalités au sein d'un même logiciel. N'était-ce pas justement le "trop de fonctionnalités" qui était critiqué (en partie) pour PulseAudio ?

    (en tout cas c'est bien sur ça que je vais le troller à l'avenir, bisous)

    • [^] # Re: Le troll ne partira pas avec un PulseAudio 2

      Posté par  (site web personnel) . Évalué à -3.

      On se marre bien avec le libre n'empêche.

      À coup sûr ça va alimenter les trolls jusqu'en 2020 au moins ! Chouette chouette chouette !

      • [^] # Re: Le troll ne partira pas avec un PulseAudio 2

        Posté par  . Évalué à -2.

        Ce qui est magnifique avec l'informatique, ce sont les abstractions que l'on arrive à faire pour simplifier l'usage de quelque-chose. Avec l'audio nous n'avons que des mécanismes complexes, spécifiques. PulseAudio, tout comme Jack, n'ont clairement pas la simplicité d'usage d'un pipe ou d'un fichier. J'aime donc ni l'un ni l'autre.

        Donc ouais, les trolls seront encore là pendant longtemps.

        • [^] # Re: Le troll ne partira pas avec un PulseAudio 2

          Posté par  . Évalué à 7. Dernière modification le 29 juin 2017 à 00:32.

          Contrairement à ce qui est dit dans le journal Jack et Pulseaudio n'ont jamais été des alternatives, donc normalement à part si tu recherches un serveur basse latence pour faire de l'enregistrement audio professionnel sous Linux on ne te demande pas d'aimer Jack :) !

          A part ça Pulseaudio est un excellent exemple d'abstraction moderne mais pour des besoins plus évolués. Diriger plusieurs sources simultanées sur plusieurs sorties simultanées avec priorisation des associations et mémoire des volumes, sans la moindre configuration et à la volée depuis un petit applet présent par défaut dans tous les DE ou presque, c'est quand même une belle victoire pour le desktop Linux. Et pour les cas très simples, ceux ou effectivement Pulseaudio n'apporte pas grand chose voire rien, ça fait plusieurs années qu'il sait se rendre fiable et transparent. Une vraie abstraction quoi.

          • [^] # Re: Le troll ne partira pas avec un PulseAudio 2

            Posté par  . Évalué à 1.

            Alors nous n’avons simplement pas la même définition "d'abstraction". En aucun cas cela désigne un programme "simple" ou "qu'on a pas à utiliser". Le fonctionnement de l'audio est spécifique, on est très loin de l'abstraction que nous faisons pour lire et écrire sur un SSD/HDD/DVD. On a inventé les fichiers, les arborescences, et nous réutilisons ces concepts pour un grand nombre d'applications qui n'ont pourtant aucun rapport avec l'écriture sur un matériel de stockage de données, c'est ça une abstraction.

            Je n'ai rien contre pulseaudio ou jack, je pense que tu te méprends sur ce point. Je comprends parfaitement l'usage de ces deux, et je les utilise tous les deux (je fais aussi de la MAO…). Je trouve que ce ne sont pas de bonnes abstractions malgré tout : tant que nous n'aurons pas un environnement où l'audio se traitera comme un fichier, nous aurons un fonctionnement spécifique pour cet usage.

            Après, peut-être que l'audio ne peut se traiter de cette manière, auquel cas nous devrions créer un autre type d'abstraction… une autre notion que celles de fichiers et d'arborescences.

  • # Leave Jack alone!

    Posté par  (site web personnel) . Évalué à 10.

    Il s'agit d'une alternative à un autre serveur de son plus ancien nommé Jack, que PulseAudio visait à remplacer, sujet hautement polémique s'il en est.

    Bah c’est sûr qu’en présentant les choses de façon erronée, on va susciter des polémiques…

    PulseAudio n’a jamais visé à remplacer Jack. PulseAudio visait à remplacer (et a effectivement remplacé) les serveurs de sons de la génération de aRtsd ou EsounD. PulseAudio n’a jamais ne serait-ce que tenté de faire le travail de Jack, de même que Jack n’a jamais tenté de faire le travail de PulseAudio (ce qui n’empêche pas certains utilisateurs de Jack de s’en servir comme d’un serveur de sons généraliste, mais ça n’a jamais été le but).

    gérer l'audio d'une manière qui non seulement couvre les cas d'utilisation de PulseAudio, mais aussi ceux gérés par Jack aujourd'hui

    Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?

    • [^] # Re: Leave Jack alone!

      Posté par  (site web personnel) . Évalué à -1.

      C’est quoi le problème avec ces outils qui font très bien leur boulot ?

      hum… on n'est que jeudi donc on va prendre des pincettes

      Tout d'abord je dois dire que mes dernières expériences avec l'un comme avec l'autre remontent à un temps quasi pré-historique. 5 ans au moins. Peut-être que ça a changé… Mais comme on dit : "Vous n'aurez jamais une deuxième chance de faire une bonne première impression".

      Avec Jack ce serait le coté, comment dire… usine à gaz ? Ça ressemble en vrai à un cabinet de brassage, alors je comprends que les sysadmins se sentent à l'aise mais pour ma part quand je dois passer plus de 5 minutes à lire une doc pour régler un problème qui n'est pas (à mes yeux) essentiel, j'ai tendance à passer à autre chose.

      Avec Pulse Audio j'ai eu tellement de problème avec le midi (Musical Instrument Digital Interface, pas la Provence) que j'ai abandonné tout aussi rapidement.

      Bref je n'ai ni l'un ni l'autre et tout fonctionne bien. Je conçois que certains puissent avoir des besoins que je n'ai pas mais j'ai du mal à comprendre que tant d'applications en dépendent alors qu'elles fonctionnent tout aussi bien avec un pulseaudio-fake.

      Pensée unique ?

      • [^] # Re: Leave Jack alone!

        Posté par  . Évalué à 9.

        Allez, je saute dedans.

        Avec Jack ce serait le coté, comment dire… usine à gaz ? Ça ressemble en vrai à un cabinet de brassage,

        C'est son but, permettre d'organiser les flux entre applications pour permettre un maximum de flexibilité comme tu pourrais le faire avec des instruments

        alors je comprends que les sysadmins se sentent à l'aise mais pour ma part quand je dois passer plus de 5 minutes à lire une doc pour régler un problème qui n'est pas (à mes yeux) essentiel, j'ai tendance à passer à autre chose.

        Je pense que la plupart des utilisateurs de Jack n'ont pas un sysadmin pour configurer jack. Ceci dit, la partie qui devrait être gérée par un sysadmin devrait se limiter à la configuration de jack au chargement d'une session utilisateur, ou encore de rediriger pulse vers jack. Et c'est assez simple à faire, pour ne pas dire trivial.

        Avec Pulse Audio j'ai eu tellement de problème avec le midi (Musical Instrument Digital Interface, pas la Provence) que j'ai abandonné tout aussi rapidement.

        Normal, PulseAudio ne gère pas le midi. Et ce n'est pas son but. Tu dois confondre avec alsa..

    • [^] # Re: Leave Jack alone!

      Posté par  . Évalué à 2.

      Bah c’est sûr qu’en présentant les choses de façon erronée, on va susciter des polémiques…

      Très juste. Erreur fortuite, j'aurais dû écrire ESD si je ne m'étais pas mélangé les pinceaux. Merci pour la correction (que j'aurais volontiers intégré à l'article original si je l'avais pu) et mes excuses au lecteur.

      Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?

      Ben ça c'est une vraiment bonne question. Peut-être qu'une partie de l'explication est similaire à ce qu'on peut trouver pour la bataille snap/flatpak ou Mir/Wayland : celui qui réinvente la roue qui sera utilisée par les autres élève sa position sur la concurrence et l'ensemble des contributeurs ?

      • [^] # Re: Leave Jack alone!

        Posté par  (site web personnel) . Évalué à 10.

        Alors, d’après le billet de blog indiqué dans le journal :

        A big part of the motivation for this is that we want to make Fedora Workstation the best place to create content and we want the pro-audio crowd to be first class citizens of our desktop.

        Alors, d’une, je ne sais pas pour les utilisateurs de Fedora Workstation mais mour ma part en tant que MAOïste amateur je ne me suis jamais senti « citoyen de seconde classe » sur mon GNU/Linux.

        Et de deux, pour être « la meilleure place pour créer du contenu », ce dont on a besoin n’est pas un n-ième framework mais des applications.

        Il se trouve que GNU/Linux n’est pas dépourvu d’applications dédiées à la création audio-numérique. Ardour, Rosegarden, Qtractor, Bristol, NON, LMMS… pour ne citer que celles que j’utilise ou ai utilisées (il y en une tripotée d’autres). Leur point commun ? Elles utilisent toutes Jack (en tout cas pour leur version GNU/Linux, dans le cas des applications multi-plateformes).

        Vouloir remplacer, sans aucune bonne raison (autre que « on peut le faire »), un composant qui s’est imposé de lui-même comme la pièce maîtresse de l’audio dite « pro » sous GNU/Linux ne va sûrement pas donner aux développeurs desdites applications qu’ils sont des « citoyens de première classe »…

        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 — mais on compte sur vous pour que les créateurs se sentent « citoyens de première classe » sur notre système, hein, ne nous lâchez pas.

        We expect to start shipping PipeWire with Fedora Workstation 27, but at that point only have it handle video […] We will the bring the audio features onboard in subsequent releases as we also try to work with the Jack and PulseAudio communities to make this a joint effort.

        « Allô, la communauté Jack ? Votre machin, là, que vous avez conçu sur mesure pour répondre pile poil aux besoins de l’audio numérique, et qui semble pas trop mal d’après ce qu’on m’a dit… on vient vous proposer de le remplacer par un truc qu’on a d’abord conçu pour faire complètement autre chose, mais auquel on aimerait bien rajouter après coup des fonctionnalités pour l’audio pro, comme ça en passant. C’est génial comme idée, non ? »

        Cette proposition, c’est comme celle de KLANG il y a quelques années, c’est un gros doigt d’honneur à tous ceux qui veulent réellement faire de GNU/Linux une plate-forme sérieuse de création audio-numérique.

        Sérieusement : Leave Jack alone! Si ça amuse quelqu’un de vouloir à nouveau « casser l’audio sous GNU/Linux », Poettering-style, grand’bien vous fasse, proposez un remplaçant à PulseAudio, introduisez une nouvelle période de confusion ou personne ne saura quelle est la bonne voie à suivre ou le bon outil à utiliser, donnez du blé à moudre à tous ceux qui se plaignent que la pile audio sous GNU/Linux est un bordel sans nom… mais pitié, laissez les développeurs et utilisateurs de Jack et des outils d’audio-numérique « pro » en dehors de tout ça.

        • [^] # Re: Leave Jack alone!

          Posté par  (site web personnel) . Évalué à 5.

          En même temps, je vois pas trop pourquoi tu t'emballes, jack continuera à fonctionner, ils vont pas virer ALSA.

          Ce qui te fait peur, c'est que si leur projet fonctionne, les devs d'applications vont abandonner JACK, en encore, rien ne les empêchera de supporter les deux. Par contre, sur le long terme, les nouveaux projet risque de se concentrer sur l'interface par défaut.

          • [^] # Re: Leave Jack alone!

            Posté par  (site web personnel) . Évalué à 7.

            Par contre, sur le long terme, les nouveaux projet risque de se concentrer sur l'interface par défaut.

            Et donc on se retrouvera avec non pas une mais deux piles audio pouvant être utilisées pour l’audio-numérique « pro ». Avec des applications qui supporteront l’une, des applications qui supporteront l’autre, des systèmes où l’une sera installée par défaut mais pas l’autre, des utilisateurs qui n’y comprendront rien et qui viendront demander sur les forums « pourquoi c’est si compliqué l’audio sous GNU/Linux, je vais retourner sur MacOS X »…

            Y’a pas à dire, les « créateurs de contenus » vont vraiment se sentir des « citoyens de première classe » avec une idée pareille.

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à 2.

              Et donc on se retrouvera avec non pas une mais deux piles audio pouvant être utilisées pour l’audio-numérique « pro ». Avec des applications qui supporteront l’une, des applications qui supporteront l’autre, des systèmes où l’une sera installée par défaut mais pas l’autre, des utilisateurs qui n’y comprendront rien et qui viendront demander sur les forums « pourquoi c’est si compliqué l’audio sous GNU/Linux, je vais retourner sur MacOS X »…

              Pourtant il suffit que l'application lance JACK ou PipeWire via D-Bus à son lancement et tout marche bien, non ? ^_^

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: Leave Jack alone!

                Posté par  (site web personnel) . Évalué à 4.

                Ouais, il « suffit » que les développeurs d’applications (qui n’ont que ça à foutre) implémentent le support de Jack ET de PipeWire. Une broutille, quoi.

                • [^] # Re: Leave Jack alone!

                  Posté par  . Évalué à 3.

                  Ou qu'il existe une bonne lib d'abstraction pour les deux et le problème est réglé.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Leave Jack alone!

                    Posté par  . Évalué à 7.

                    Un truc comme phonon quoi?

                    J'ai l'impression de me revoir 15 ans en arriere…

                • [^] # Re: Leave Jack alone!

                  Posté par  . Évalué à 3.

                  Non, ils lancent le serveur qui leur convient, de la même manière que tu l'explique dans ton autre commentaire. S'ils savent faire ça pour gérer la dualité PA/JACK, ça marche aussi si tu as plus de serveur.

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Leave Jack alone!

            Posté par  . Évalué à 3.

            rien ne les empêchera de supporter les deux.

            Même pas le temps et l’argent ?

        • [^] # Re: Leave Jack alone!

          Posté par  . Évalué à 4.

          Je ne comprends pas trop ton problème:
          Si jackd satisfait les dévs et les utilisateurs et ses mainteneurs, rien ne pourra l'arrêter.

          Si PipeWire s'avère être "meilleur" et que des dévs le préfèrent, c'est qu'il y a une bonne raison aussi.

          Conclusion: laisse couler, personne ne va venir l'enlever de ton ordinateur, personne ne va mettre un flingue sur la tempe des dévs pour qu'ils migrent leurs applis.

          Linux, c'est le choix, y compris celui de ne pas changer.

          • [^] # Re: Leave Jack alone!

            Posté par  (site web personnel) . Évalué à 6.

            Je ne comprends pas trop ton problème:

            Une question : pourquoi ?

            Pourquoi vouloir remplacer un composant qui ne pose aucun problèmes à ses utilisateurs par un truc encore en conception et même pas conçu pour faire la même chose ?

            Autant je peux comprendre qu’on ait voulu remplacer aRtsd ou EsounD par PulseAudio (unification de couches concurrentes), autant je peux comprendre qu’on ait voulu remplacer SysVinit par Systemd (remplacement d’un outil devenu trop limité parce que trop vieux), autant je ne comprends pas l’intérêt de remplacer Jack par PipeWire. Et le post de blog mentionné ne donne aucune raison, autre que « donner aux créateurs l’impression d’être des citoyens de première classe » — alors que cette proposition, au mieux ne changera rien, au pire créera de la confusion (et renforcera encore un peu plus l’idée que décidément GNU/Linux n’est pas prêt pour le desktop, ils en sont encore à chercheur leurs briques de base au lieu de se concentrer sur les applications attendus par les utilisateurs).

            (Ah, et comme je la vois venir : non, PipeWire qui remplacerait à la fois Jack et PulseAudio n’est pas comparable à PulseAudio qui a remplacé aRtsd et EsounD — comme déjà expliqué, PulseAudio et Jack n’ont pas le même rôle, ce que leurs développeurs respectifs reconnaissent très bien.)

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à 4.

              Pourquoi y'a-t-il encore Gnome et KDE et pleins d'autres environnements de bureau?
              Pourquoi a-t-on vu plusieurs schedulers dans le noyau?
              Pourquoi certains projets démarrent alors que d'autres sur le même créneau existaient déjà?

              Parce que le dév avait envie, ou qu'il avait une vision différente à proposer, ou parce qu'il veut coder en Go et pas en Java, qu'importe!

              Et puis la confusion? La bonne blague, les utilisateurs lambda ne savent sans doute pas qu'ils utilisent PulseAudio. Ça va tout changer tu crois?

              • [^] # Re: Leave Jack alone!

                Posté par  (site web personnel) . Évalué à 8.

                Et puis la confusion? La bonne blague, les utilisateurs lambda ne savent sans doute pas qu'ils utilisent PulseAudio.

                Les utilisateurs lambda, sans doute pas, mais les fameux « créateurs de contenu » (ceux dont le but du projet est de faire des « citoyens de première classe », et c’est la seule putain de raison avancée), eux, savent qu’ils utilisent Jack (tout comme les mêmes « créateurs » sous Windows savent qu’ils utilisent ASIO.

                Parce que le dév avait envie, ou qu'il avait une vision différente à proposer, ou parce qu'il veut coder en Go et pas en Java, qu'importe!

                Peu importe la raison, OK, c’est le droit le plus strict du développeur.

                Mais lorsque la raison, c’est grosso modo « on veut que les créateurs de contenu soient des citoyens de première classe, sous-entendu je méprise tout le travail abattu par tous les développeurs de logiciels d’audio-numérique depuis vingt ans sous GNU/Linux — grâce à qui les “créateurs” sont des citoyens de première classe sous GNU/Linux aujourd’hui — et je propose donc une nouvelle fois de tout recommencer à zéro » … mon droit le plus strict est de dire que c’est une raison à la con, qui va directement à l’encontre de l’objectif affiché — tellement à l’encontre d’ailleurs que je ne peux pas croire que ce soit la véritable raison, à mon avis c’est surtout un cas supplémentaire de NIH.

                Je le redis : ce dont ont besoin les « créateurs », ce sont des applications. Changer une brique de base utilisée par tout le monde (enfin, le petit monde des utilisateurs audio « pro ») et dont personne ne se plaint, ça ne va aider personne. Ça n’aidera sûrement pas à donner l’impression qu’on est à l’écoute des attentes des utilisateurs.

                Merde, GNU/Linux sur le desktop, c’est une maison dont on veut en permanence recouler les fondations alors que les occupants n’attendent plus que le carrelage dans la salle de bains et la peinture sur les murs…

                (Pour info, depuis au moins vingt ans que Steinberg a inventé ASIO, personne n’a songé à le remplacer juste pour satisfaire un syndrome NIH, pas même les concurrents de Steinberg.)

                • [^] # Re: Leave Jack alone!

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  J'ai surtout l'impression que tu t'excite un peu pour pas grand chose. Ou du moins, que tu le fais prématurément. Pour le moment, il n'y a encore aucun site officiel, le développeur ne s'est pas exprimé sur le sujet, je n'ai pas vu passer d'article explicatif complet…

                  En gros, pour le moment, nous n'avons droit qu'à quelques lignes d'un développeur externe au projet, qui semble juste parler de son existence, sans rentrer dans les détails. À aucun moment il ne parle de remplacer Jack. Ni même PulseAudio, d'ailleurs. Au contraire, il indique que les utilisateurs ne voudraient pas subir à nouveau tous les problèmes qu'ils avaient rencontrés à l'époque de la migration vers PulseAudio. Les applications devront donc être compatibles sans la moindre modification.

                  Ensuite, de ce que je comprends de la référence à JACK, ça semble juste vouloir dire que ça devra répondre correctement aux problématiques auxquelles répondent JACK et PulseAudio. J'extrapole, mais j'imagine que les applications JACK resteront des applications JACK et que PipeWire fera en sorte d'être complètement transparent, sans rajouter de la latence, par exemple.

                  Et pour finir sur l'histoire du citoyen de première classe, connaissant Christian Schaller et Fedora, à mon avis, ça veut juste dire que les créatifs qui opteront pour Fedora (ne pas oublier que tout le monde n'est pas ingé son) auront droit à un système le plus simple possible, où les différents projets s'emboîteront parfaitement et où tout fonctionnera out of the box.

                  Je ne fais pas de MAO, mais quand je jette un oeil à la page décrivant GNU/Linux sur le site de Linux MAO et que je lis dans les inconvénients la « Difficulté de configuration de certaines distributions et obligation de parfois mettre "les mains dans le cambouis" », ça donne vachement envie. J'imagine que c'est cette image qu'ils souhaitent changer.

                  • [^] # Re: Leave Jack alone!

                    Posté par  (site web personnel, Mastodon) . Évalué à 4.

                    Ah oui, puis un autre point qui n'a pas été abordé, ce sont les créatifs. De nos jours, ça peut tout aussi bien être des professionnels particulièrement compétents qui maîtrisent leur sujet, comme ça peut être de simples YouTubeurs passionnés. Avec un Mac et quelques logiciels grand public, ils peuvent créer des vidéos, faire du montage, ajouter quelques effets spéciaux… puis publier leur création sur YouTube.

                    Au niveau de l'audio, on retrouve d'ailleurs pas mal de YouTubeurs qui se sont fait connaître par leurs reprises de titres à succès.

                    Ça n'a pas été abordé dans ces 3-4 lignes de blog, mais ça se trouve, personne n'a jamais eu l'intention de remettre en cause JACK, qui restera la solution privilégiée par les pros, et que PipeWire tentera juste de répondre aux mêmes problématiques, tout en étant orienté grand public.

                    Ce ne sont que des théories, mais encore une fois, sans site et sans articles complets sur le sujet, on ne peut que supputer :p

                    Par contre, je te rejoins complètement sur les applications. Ce qui fera le succès d'une plateforme, quelle quelle soit, ça sera toujours ses applications. Maintenant, pour concevoir de bonnes applications, il faut également pouvoir proposer de bonnes bases et de bonnes technologies.

        • [^] # Re: Leave Jack alone!

          Posté par  . Évalué à 4.

          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  (site web personnel, Mastodon) . Évalué à 8.

            Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ?

            Mon utilisation la plus courante de jack consiste à synchroniser Blender et Ardour.
            Pour des cas plus simples, Ardour permet aussi du monitoring video, la vidéo étant donc visible avec xjadeo et synchronisé avec l'audio par jack. Donc oui ça existe et est même une utilisation importante de jack.

            Pour le reste, je n'ai pas trop d'avis. Ce nouveau projet est-il une bonne ou mauvaise chose? L'avenir le dira. Je dois dire que GNU/Linux est effectivement déjà une très bonne plateforme pour le traitement audio, bien meilleure que Windows même d'après beaucoup.
            Mais ça ne veut pas dire pour autant que c'est parfait. Cette dualité PA/Jack est en effet très énervante quand on souhaite un ordinateur "desktop" qui puisse aussi se transformer en station de travail audio, sans avoir à installer une distrib dédiée en dual-boot ou sans impacter sur la partie desktop. Quand on voit que beaucoup se retrouvent souvent à dédier une machine juste pour l'audio, c'est un peu triste.
            Et même si on utilise sa machine un peu "simplement" avec jack, sans se prendre la tête et en se disant "bon je m'en fous du temps réel pour ce que je fais", ben on rencontre pas mal de problème. Du genre, lorsqu'on lance jack, le son ne marche plus pour les applications non-jack. C'est vraiment embêtant lorsque par exemple on cherche des sons pour les intégrer dans un travail en cours. Bon en fait y a un module PulseAudio pour l'intégrer à jack, mais faut le savoir! C'est clairement pas plug'n play.
            Sans compter les fois où le serveur jack veut pas démarrer, et on sait pas pourquoi, etc.

            Au final, y a vraiment des choses améliorables. Est-ce du travail à faire dans jack même? Ce serait bien. Un nouveau projet fusionnel peut-il être la réponse? Je n'en sais rien.
            En tous cas, j'espère que la personne qui développe ce nouveau système connaît quand même bien jack et l'utilise. Parce que si par exemple la synchro audio-vidéo est citée comme un plus alors que c'est une fonctionnalité assez basique de jack (même moi, c'est ce que j'utilise le plus; je suis un très faible utilisateur audio avec jack)… Ou alors cette comparaison vient de toi, et pas de ce développeur? :-)

            Enfin bon… le mieux est d'attendre et de voir…

            Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

            • [^] # Re: Leave Jack alone!

              Posté par  (site web personnel) . Évalué à 2.

              Cette dualité PA/Jack est en effet très énervante quand on souhaite un ordinateur "desktop" qui puisse aussi se transformer en station de travail audio, sans avoir à installer une distrib dédiée en dual-boot ou sans impacter sur la partie desktop.

              J’ai un ordinateur « desktop » (bon, « laptop » en réalité) que j’utilise pour tout et qui « se transforme aussi en station de travail audio ». Je n’ai jamais installé de distribution dédiée à l’audio-numérique : je n’ai qu’un seul système sur cette machine, pour l’usage « desktop » et pour l’usage « audio ». Et mon utilisation « audio » n’a jamais impacté l’utilisation « desktop ».

              C'est clairement pas plug'n play.

              Ça pourrait l’être. Ça ne l’a pas été chez moi parce que j’utilise Slackware, donc bon je l’ai un peu cherché, mais rien de ce que j’ai eu à faire pour avoir un système « dual-use » desktop/audio-pro (installer Jack, créer un cgroup dédié aux applications audio avec les privilèges temps-réel, faire cohabiter Jack et PulseAudio) ne pourrait pas être fait automatiquement par les distributions (et pas seulement les distributions dédiées à l’audio pro). Peut-être pas par défaut, mais par exemple dès que l’utilisateur demande l’installation d’Ardour, Rosegarden, ou toute autre application marquée « audio pro », boum : on installe automatiquement Jack et on configure tout pour que ça marche tout seul. Qu’on ne me dise pas que ce n’est pas possible.

              Mais peaufiner ce genre de détails d’intégration est moins excitant que d’annoncer yet-another-framework-de-base qui va tout révolutionner, c’est vrai…

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à 2.

              Par exemple avec Jack est-il possible de synchroniser des flux vidéos en plus de l'audio ?

              Parce que si par exemple la synchro audio-vidéo est citée comme un plus alors que c'est une fonctionnalité assez basique de jack (même moi, c'est ce que j'utilise le plus; je suis un très faible utilisateur audio avec jack)… Ou alors cette comparaison vient de toi, et pas de ce développeur? :-)

              Oui cette comparaison vient de moi, c'était une vraie question. Je ne connais vraiment pas bien Jack.

              Le développeur de PipeWire je pense qu'il s'y connait vraiment bien, c'est Wim Taymans, le co-créateur de GStreamer. C'est lui qui a le plus de commits dans GStreamer (en tout cas dans le repo git principal).

    • [^] # Re: Leave Jack alone!

      Posté par  (site web personnel) . Évalué à 10.

      C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?

      Ils n'ont pas été écrits par RedHat c'est tout :-D

      kentoc'h mervel eget bezan saotred

    • [^] # Re: Leave Jack alone!

      Posté par  . Évalué à 4.

      Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?

      Je présume qu'il n'est pas très pratique d'avoir à changer de serveur de son pour passer de la MOA à de la simple écoute en bluetooth (ou je ne sais quelle fonctionnalité pas supportée par jack).

      Pour les développeurs devoir choisir entre être utilisé dans un contexte MOA ou pour des usages plus classiques n'est pas forcément plus agréable.

      Je dis ça je ne sais pas je ne connais pas jack, c'est juste pour donner des pistes et oui une autre solution pourrait être d'améliorer jack.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Leave Jack alone!

        Posté par  (site web personnel) . Évalué à 5.

        Je présume qu'il n'est pas très pratique d'avoir à changer de serveur de son pour passer de la MOA à de la simple écoute en bluetooth

        Étant donné que ça peut se faire complètement tout seul¹, je ne vois pas en quoi « ce n’est pas pratique ».

        Ça n’a jamais dérangé les MAOïstes sous Windows d’avoir leurs diverses applications audio fonctionnant avec ASIO (en gros une pile audio spécifique à l’audio pro, inventé par Steinberg parce que la pile audio de base de Windows n’était pas satisfaisante — un peu comme Jack, quoi) pendant que le reste de leurs applications de bureau utilisaient DirectSound.

        une autre solution pourrait être d'améliorer jack.

        Encore une fois : c’est quoi le problème avec Jack, à part qu’il fait bien son boulot ?


        ¹ Exemple : Je ne fais pas de MAO, PulseAudio tourne et gère le sons de mes applications. Tiens, je décide de faire un peu de musique. Je lance Rosegarden, qui lance automatiquement Jackd (via D-Bus), PulseAudio cède automatiquement la main tant que Jackd est en service. Bon finalement je ne suis pas inspiré, je fere Rosegarden, Jackd se termine, PulseAudio reprend la main. Je n’ai rien eu à faire, où est la pénibilité ?

        Autre exemple (plus réaliste à mon avis, parce qu’un MAOïste même amateur a plus de chance d’avoir une carte son dédiée en plus du chipset son intégré aux carte-mère) : PulseAudio fonctionne et gère le chipset son de la carte-mère pour toutes les applications desktop ; Jackd fonctionne et gère la carte son dédiée pour toutes les applications audio « pro ». En quoi est-ce « pénible » ?

        • [^] # Re: Leave Jack alone!

          Posté par  . Évalué à 2.

          ¹ Exemple : Je ne fais pas de MAO, PulseAudio tourne et gère le sons de mes applications. Tiens, je décide de faire un peu de musique. Je lance Rosegarden, qui lance automatiquement Jackd (via D-Bus), PulseAudio cède automatiquement la main tant que Jackd est en service. Bon finalement je ne suis pas inspiré, je fere Rosegarden, Jackd se termine, PulseAudio reprend la main. Je n’ai rien eu à faire, où est la pénibilité ?

          Autre exemple (plus réaliste à mon avis, parce qu’un MAOïste même amateur a plus de chance d’avoir une carte son dédiée en plus du chipset son intégré aux carte-mère) : PulseAudio fonctionne et gère le chipset son de la carte-mère pour toutes les applications desktop ; Jackd fonctionne et gère la carte son dédiée pour toutes les applications audio « pro ». En quoi est-ce « pénible » ?

          Tu explique comment gérer les contraintes que ça impose, pas qu'il n'y en a pas. C'est différent ;)

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Leave Jack alone!

            Posté par  (site web personnel) . Évalué à 5.

            Ben non, j’explique que je n’ai rien à gérer, ça marche tout seul. C’est si difficile à croire que des choses peuvent fonctionner out-of-the-box sous GNU/Linux ?

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à 2.

              Il sait comme ça quelle carte utiliser pourquoi ? Tu ne peux pas vouloir tout faire avec une même carte ? Tu ne veux pas avoir des usages parallèles avec une seule carte ? Des contraintes il y en a. Tu as l'impression que c'est hors de ton horizon, mais repousser ces contraintes ça laisse toujours la possibilité à plus de flexibilité et à de nouveaux usages.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à 1.

              Justement, la cohabitation Jack/pulseaudio ne marche pas tout seul… et même pas bien du tout de mon expérience.

              Au final, pour avoir une latence faible (2.5ms) et sans problème, dans mon cas cela a consisté en :
              - un noyau RT ;
              - pas jack2/jack-dbus, mais uniquement jack1 ;
              - un utilisateur à part de mon compte habituel, dédié à la MAO ;
              - à chaque connexion à ce compte, tuer le processus pulseaudio utilisateur (systemctl --user …). Va savoir, pourquoi un disable ne règle pas définitivement la question.

              Ouf… c'est pas vraiment out-of-the-box

              • [^] # Re: Leave Jack alone!

                Posté par  (site web personnel) . Évalué à 3.

                • à chaque connexion à ce compte, tuer le processus pulseaudio utilisateur (systemctl --user …). Va savoir, pourquoi un disable ne règle pas définitivement la question.

                disable le service ça doit éviter le lancement auto mais pas le lancement en dépendance d'autre chose.

                • [^] # Re: Leave Jack alone!

                  Posté par  . Évalué à 4.

                  Pour être sûr qu'un service ne soit pas lancé (même à la main), il faut utilisé mask.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

              • [^] # Re: Leave Jack alone!

                Posté par  . Évalué à 1.

                http://fedoraproject.org/wiki/JACK_Audio_Connection_Kit
                et ca ca marche pas ?
                j'y connais rien

    • [^] # Re: Leave Jack alone!

      Posté par  . Évalué à 10.

      Mais pourquoi ? C’est quoi le problème avec Jack ? C’est quoi le problème avec ces outils qui font très bien leur boulot ?

      Le problème est peut-être que ceux qui parlent de Jack ne savent pas ce qu'il fait et à quoi il sert ? Je dirais que si une personne prend peur devant un tel objet physique :

      table de mixage

      alors Jack n'est pas fait pour elle et elle peut passer son chemin.

      Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

    • [^] # Re: Leave Jack alone!

      Posté par  . Évalué à 6.

      Je lis souvent sur ce site que Jack c'est trop de la balle et que PA devrait reposer six pieds sous terre depuis longtemps.

      En essayant de rester objectif et en s'adressant à un néophyte, pouvez-vous expliquer ce que fait l'un et ce que fait l'autre ?

      En vous remerciant.

      • [^] # Re: Leave Jack alone!

        Posté par  (site web personnel) . Évalué à 10.

        Pour faire simple :

        ça c'est pulse audio :
        Caricature pulse audio

        Et ça c'est jack :
        Caricature Jack

        C'est 2 logiciels ne s'adressent pas tout à fait au même public, ils sont plus complémentaires que concurents ;-)

        kentoc'h mervel eget bezan saotred

      • [^] # Re: Leave Jack alone!

        Posté par  . Évalué à 6.

        Une grande différence est le public visé, ce qui influence énormément les compromis faits en terme d'architecture:

        • Jack vise l'audio pro, avec un accent très net sur la minimisation de la latence: un décalage de 20 ms en jouant 20 piste simultanément avec une flopée d'effets par piste dans un contexte de studio cela peut être déjà beaucoup trop. Par conséquent, Jack est désigné pour faire le moins de compromis possible en terme de latence. Si cela demande de réquisitionner 90% de la puissance de calcul disponible (ou de la mémoire), ainsi soit-il.

        • Pulseaudio vise le grand public, il a donc des contraintes de facilité d'utilisation et de consommation d'énergie: En gros, si la bande sonore d'un film est décalé de 50 ms à cause de la latence, mais qu'il faudrait faire sortir le processeur du mode d'économie d'énergie pour régler le problème, autant attendre.

        • [^] # Re: Leave Jack alone!

          Posté par  . Évalué à 0.

          Donc pulse-audio consomme moins alors ? ;)

          Sinon, Windows n'est pas RT et pourtant c'est une plateforme de choix pour l'audio.

          • [^] # Re: Leave Jack alone!

            Posté par  . Évalué à 6.

            Sur windows il y a ASIO justement, ça permet d'avoir une faible latence.

            Mais en plus de ça, Jack permet facilement de connecter n'importe quel canal audio/midi de sortie à un autre canal d'entrée (indépendamment du logiciel, il faut juste qu'il soit compatible Jack). Ça gère aussi de pouvoir contrôler la lecture/pause etc… d'un logiciel à un autre. L'idée est que ça permet de constituer un studio complet avec des dizaines de logiciels tournant en même temps.
            Ce qui est génial c'est la modularité que ça offre. Par exemple si dans Ardour (logiciel important de MAO libre) il me manque un effet sur une piste, je peux la connecter à un autre logiciel puis rediriger le son dans Ardour.

            Ceci étant dit dès je trouve que cet aspect modularité amène aussi une grande complexité à la mise en place de l'environnement de travail. Il manque à mon goût un bon logiciel tout-en-un (un peu ce que Blender est pour la 3D, mais pour la MAO), que l'on pourrait étendre grâce à Jack justement (et surtout les plugin LV2 bien entendu).

            • [^] # Re: Leave Jack alone!

              Posté par  . Évalué à -1.

              Sur windows il y a ASIO justement, ça permet d'avoir une faible latence.

              Je connais ASIO mais du coup je suis allé voir en détail sur en.wikipedia.org (sic!). Ça n'a rien à voir avec le temps réel.
              Encore un mythe de libriste qui s'effondre.

              • [^] # Re: Leave Jack alone!

                Posté par  (site web personnel) . Évalué à 3.

                Je ne sais pas de quel mythe tu parles, mais je ne crois pas que quiconque ait prétendu que ASIO avait quelque chose à voir avec le temps réel…

                Au passage, attention à ne pas confondre « faible latence » et « ordonnancement en temps réel ». En gros, la latence, c’est le temps de traitement, le délai entre l’entrée et la sortie. L’ordonnancement en temps réel, c’est le fait de garantir un délai de traitement le plus constant possible, qu’il soit court ou long.

                L’ordonnancement en temps réel est strictement du ressort du noyau¹, un démon en espace utilisateur comme Jack n’a pas d’impact là-dessus. Au maximum, on peut augmenter la latence au profit du temps réel : en gros, si le système n’arrive pas à garantir qu’il peut traiter les données en 8 ms, on va lui demander de le faire en 16 ms, parce qu’une latence plus élevée mais régulière est généralement préférable, en audio, à une latence plus faible mais erratique.

                Ah, et concernant Windows qui ne serait « pas RT » : Windows est tout-à-fait capable de faire du « temps réel mou » (= le système fait son maximum pour respecter les délais, mais hé ho hein bon, parfois il peut être à la bourre, ça arrive aux meilleurs), tout comme Linux. Il ne peut pas faire du temps réel « dur » (= strictement aucun retard permis, c’est peut-être une question de vie ou de mort), mais de toute façon aucun système d’exploitation généraliste ne le peut (même Linux avec le patch -rt) — le temps réel dur nécessite un OS expressément et entièrement conçu dans ce but.


                ¹ Ce qui, aujourd’hui, ne nécessite plus forcément le patch -rt. Plusieurs des fonctionnalités de ce patch ont été progressivement intégré au noyau mainline, dans bien des cas c’est suffisant. Je recommande systématiquement au MAOïste amateur de faire ses premiers essais avec un noyau standard, et seulement si nécessaire de passer à un noyau -rt.

                • [^] # Re: Leave Jack alone!

                  Posté par  . Évalué à 2.

                  Je ne sais pas de quel mythe tu parles, mais je ne crois pas que quiconque ait prétendu que ASIO avait quelque chose à voir avec le temps réel…

                  le mythe qu'il faille un noyau RT pour faire de la MAO sous linux.

  • # :(

    Posté par  . Évalué à 8.

    TLDR; c'est résumé sur le site web de Pipewire

    Ah oui donc le résumé consiste simplement en "Pipewire is coming!", super, j’ai loupé quoi là ?

    Il s'agit d'une alternative à un autre serveur de son plus ancien nommé Jack, que PulseAudio visait à remplacer

    Comme déjà signalé par goutted, PulseAudio n’a jamais été une alternative à Jack. Il n’a jamais rempli un critère primordiale pour la MAO : une latence faible. Il ne me semble pas avoir entendu les auteurs ou les promoteurs de PulseAudio avoir jamais prétendu offrir une alternative crédible à Jack, au début ils étaient même plutôt occupé à essuyer les critiques dues au fait que c’était sacrément buggé comme produit.

    • [^] # Re: :(

      Posté par  . Évalué à 6.

      Ah oui donc le résumé consiste simplement en "Pipewire is coming!", super, j’ai loupé quoi là ?

      Ben rien, avec le titre tu sais qu'un logiciel libre étroitement lié à Linux (et à ma connaissance unique en son genre) est en cours de développement, avec le résumé t'as l'explication de pourquoi c'est un journal plutôt qu'une dépêche. Autrement dit t'as les infos pour décider de lire le billet ou non.

      Comme déjà signalé par goutted, PulseAudio n’a jamais été une alternative à Jack. […] Il ne me semble pas avoir entendu les auteurs ou les promoteurs de PulseAudio avoir jamais prétendu offrir une alternative crédible à Jack

      Moi non plus, cf ma réponse à gouttegd. Merci d'en avoir remis une couche !

  • # AirPlay / Chromecast

    Posté par  . Évalué à 4.

    Est-ce que ça veut dire qu’on va pouvoir avoir un AirPlay-like ou Chromecast-like sur Linux (et qui fonctionne) ?

  • # L'intérêt principal est peut être ailleurs...

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    Je reprends le paragraphe évoquant PipeWire de l'article annonçant les développements futurs pour Fedora 26 / 27.

    PipeWire

    I talked about PipeWire before, when it was still called Pinos, but the scope and ambition for the project has significantly changed since then. Last time when I spoke about it the goal was just to create something that could be considered a video equivalent of pulseaudio. Wim Taymans, who you might know co-created GStreamer and who has been a major PulseAudio contributor, has since expanded the scope and PipeWire now aims at unifying linux Audio and Video. The long term the goal is for PipeWire to not only provide handling of video streams, but also handle all kinds of audio. Due to this Wim has been spending a lot of time making sure PipeWire can handle audio in a way that not only address the PulseAudio usecases, but also the ones handled by Jack today. A big part of the motivation for this is that we want to make Fedora Workstation the best place to create content and we want the pro-audio crowd to be first class citizens of our desktop.

    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.

    We expect to start shipping PipeWire with Fedora Workstation 27, but at that point only have it handle video as we need this to both enable good video handling for Flatpak applications through a video portal, but also to provide an API for applications that want to do screen capture under Wayland, like web browser applications offering screen sharing. We will the bring the audio features onboard in subsequent releases as we also try to work with the Jack and PulseAudio communities to make this a joint effort. We are also working now on a proper website for PipeWire.

    Pour moi, ce qui est le plus intéressant à court terme (sans le support de l'audio):

    • utiliser plusieurs applications nécessitant une capture vidéo d'un même périphérique en même temps au lieu d'utiliser un verrou exclusif par application
    • proposer pour les applications Flatpak un portail vers les périphériques de capture vidéo
    • proposer une solution pour le protocole Wayland pour permettre la capture et le partage d'écran de manière sécurisée

    A long terme, le projet PipeWire sera :

    • un projet supplémentaire qui gère l'audio Linux, mais dont la volonté est de créer une collaboration avec les communautés de PulseAudio (dont Wim Taymans est un contributeur important et fait partie des développeurs de PipeWire) et Jack
    • compatible avec les applications sachant utiliser PulseAudio quand l'audio sera supporté (et donc compatible avec les cas d'utilisation de PulseAudio)
    • compatible également avec les cas d'utilisations prévus par jack

    Si PipeWire n'arrive pas à amener une unifications de la vidéo et de l'audio sous Linux, je pense que les objectifs à court terme sont déjà une très grande amélioration de la situation de l'utilisation des périphériques vidéos.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.