Sortie de PulseAudio 4.0

Posté par . Édité par antistress, Jarvis, Davy Defaud, ariasuni, Xavier Claude, Nÿco, jcr83 et Maxime. Modéré par Christophe Guilloux. Licence CC by-sa
40
18
juin
2013
Son

PulseAudio est un serveur de son multi‐plate‐forme développé en C et publié sous licence LGPL 2.1. Son rôle au sein d’un système d’exploitation est d’effectuer le mixage des canaux audio en provenance des diverses applications et entrées sonores externes, puis leur lecture sur des périphériques audio tels que des cartes sons locales ou distantes (voir les schémas ici et ).

La version 4.0 est sortie le 3 juin (et est déjà disponible dans Debian Sid, par exemple).

Logo PulseAudio

Rappelons que PulseAudio, devenu le serveur de son de référence pour les systèmes GNU/Linux, a été créé par le très talentueux Lennart Poettering :

De nos jours les vendeurs de matériel comprennent que quand PulseAudio ne marche pas correctement avec leurs produits c’est sans doute de leur faute, pas celle de PulseAudio. D’une certaine façon, PulseAudio est devenu un test standardisé que les vendeurs de matériel utilisent pour évaluer leurs pilotes. (source)

Lennart Poettering

Les principales nouveautés

  • Meilleure gestion des demandes pour les flux nécessitant une faible latence ;
  • Optimisations du mixage des flux audio (générique, ARM NEON) ;
  • Le rééchantillonnage utilise maintenant par défaut une qualité de 1/10 plutôt que 3/10, et permet ainsi d’alléger la charge processeur sans perte de qualité notable ;
  • Factorisation du code pour le Bluetooth permettant une meilleure fiabilité et une maintenance plus simple ;
  • Complétion Bash et zsh pour les outils en ligne de commande ;
  • Correction de bogues pour Solaris et Mac OS X ;
  • Ajout du MPEG-2 AAC pour le matériel le prenant en charge ;
  • Beaucoup d’autres améliorations, corrections de bogues, documentation et mises à jour d’internationalisation.

Les nouveaux modules

module-role-ducking

Ce module permet d’adapter les niveaux sonores des différents flux en fonction de leur importance (ducking). Par exemple, par défaut, les flux audio et vidéo sont relégués au second plan lorsque un flux téléphone est présent. Ce comportement utilise les propriétés media.role des flux. Ce module n’est pas activé par défaut.

module-remap-source

module-remap-source permet d’encapsuler une source pour réassigner ses ports. Par exemple, il est possible de permuter les canaux droit et gauche.

  • # Pulse audio siffle dans mes oreilles...

    Posté par . Évalué à -10.

    Le fameux pulseaudio de Lennart, l'homme qui suscite tant de controverse…
    En plus je l'utilise je crois bien dans mon ordinateur…
    A moins, que, non finalement il n'est pas présent, pourtant j'ai du son quand même…

    Je me pose quand même une question philosophique:
    Et, XMMS il est définitivement mort ?
    Je m'en servais beaucoup avec Mandrake 8. Ah nostalgie quand tu nous tiens.

    --- " quand PulseAudio ne marche pas correctement avec leurs produits c'est sans doute de leur faute, pas celle de PulseAudio " (…)

    Si ça c'est une bonne chose je veux bien qu'on me pende…

    • [^] # Re: Pulse audio siffle dans mes oreilles...

      Posté par . Évalué à 5.

      Si tu cherches un remplaçant à XMMS, je ne peux que te conseiller Audacious.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Re: Pulse audio siffle dans mes oreilles...

        Posté par . Évalué à -10.

        --- " Si tu cherches un remplaçant à XMMS, je ne peux que te conseiller Audacious. " (…)

        Je parlais du serveur de son. Je connais audacious, il est présent dans cet ordinateur.

        XMMS 2 est un serveur de son du genre VLC (je crois) :
        selon wikipedia : " un lecteur basé sur un modèle client serveur, et une gestion des bibliothèques multimédia " (…)

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par . Évalué à 3.

          XMMS 2 est un serveur de son

          XMMS 2 c'est comme MPD, en plus… xmms ?

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par . Évalué à 10. Dernière modification le 18/06/13 à 13:07.

          Sous mandrake 8 via le dépôt urpmi ? pas les premières release alors.

          Parce que xmms2 d’après mes souvenirs était plutôt disponible sur la 9.0 voire .1

          xmms2 est autant un serveur de son que vlc, totem, xine, bmpx, audacious, mplayer, rhythmbox, …
          C'est autant un serveur de son que (choix multiples)
          - Firefox un serveur Web
          - les shells scripts permettent de faire du langage objet
          - GNU/Hurd est une grappe de calculs (pas les rénaux)

          Ce serait peut-être plus judicieux de sortir de wikipedia pour persister dans la non connaissance/maitrise/savoir-faire sur ce sujet… et plutôt d'aller voir du cote d'ubuntustudio par exemple qui te permettrait de mieux comprendre/maitriser ces concepts sur le son.

          Tu pourrais ainsi parler de jack D (pas daniels), oss (pas 117), alsa (pas pour la cuisine), mpd (rien a voir avec le mariage pour tous), et éventuellement ICECAST qui t’intéresserait !?

          Si je me suis emporte pour rien ou fourvoyé : mes excuses.

          • [^] # Re: Pulse audio siffle dans mes oreilles...

            Posté par . Évalué à -10. Dernière modification le 18/06/13 à 13:24.

            --- " Parce que xmms2 d’après mes souvenirs était plutôt disponible sur la 9.0 " (…)

            J'utilisais Mandrake 8 avec XMMS 1. Dans le texte c'est écrit XMMS [sans chiffre]
            Je cherche l'équivalent de la XMMS2 dès fois qu'il y en aurait …

            --- " xmms2 est autant un serveur de son que vlc, totem, xine, bmpx, audacious, mplayer, rhythmbox " (…)

            Je ne savais pas qu'audacious (ou totem) était un serveur de son.
            Le serveur de son qui m'intéresse c'est celui qui pourrait faire transiter par le réseau le son.
            VLC peut fonctionner en streaming via http par exemple.
            Merci pour la vanne; elle n'est pas drôle.

            En théorie, on peut transformer en serveur de son XMMS2, non seulement c'est écrit mais en faisant un xmms2 --help on a les commandes qui conviennent.
            " Network transparency means you can run and control XMMS2 remotely " (…)
            source XMMS2 official home page

            --- " Tu pourrais ainsi parler de jack D (pas daniels), oss (pas 117), alsa (pas pour la cuisine), mpd (rien a voir avec le mariage pour tous), et éventuellement ICECAST qui t’intéresserait " (…)

            Pas intéressé.

            --- " Si je me suis emporte pour rien ou fourvoyé : mes excuses. " (…)

            Je crois que ce sont les enfants qui se fâchent pour des prunes… T'es pas fâché au moins ?

            PS: Wikipedia est une bonne source d'information à qui sait s'en servir…

            • [^] # Re: Pulse audio siffle dans mes oreilles...

              Posté par (page perso) . Évalué à 2.

              Le serveur de son qui m'intéresse c'est celui qui pourrait faire transiter par le réseau le son.

              PulseAudio sait faire (c'est un des buts de sa conception d'ailleurs). Dans la dépêche on parle de Bluetooth d'ailleurs…

              Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Pulse audio siffle dans mes oreilles...

              Posté par . Évalué à 10.

              Quand on dit que Pulse Audio est un serveur de son, ce qu'on entend c'est qu'il va présenter (servir) les flux audio qui lui son soumis par les applications (lecteur vidéo, audio, jeu, etc) a la carte son pour qu'elle fasse vibrer les membranes de tes enceintes/écouteurs et produise ainsi du son.
              Quand on dit que XMMS2 est serveur c'est parce que la partie qui joue la musique peut tourner en arrière plan, sans interface graphique et être contrôlée soit en ligne de commande, soit par un client sur une autre machine Network transparency means you can run and control XMMS2 remotely, mais ça ne concerne pas le transit du son, qui lui va passer par pulse audio.

              Et puisque tu mentionnes Wikipedia: http://commons.wikimedia.org/wiki/File:Pulseaudio-diagram-fr.svg

              Depending on the time of day, the French go either way.

              • [^] # Re: Pulse audio siffle dans mes oreilles...

                Posté par . Évalué à -10.

                Pour moi un serveur de son (donner du son musical, etc.) c'est le logiciel qui lui lit les fichiers son (ogg) qu'on lui soumet, il les dispatche (http, alsa, oss, etc.), ou il attend (genre daemon qui attend ).
                ALSA, OSS, PulseAudio sont pour moi des serveurs audio: il autorise ou pas l'usage de la carte son locale.

                Maintenant si ce n'est pas ça, expliquez moi alors.

                • [^] # Re: Pulse audio siffle dans mes oreilles...

                  Posté par . Évalué à 3.

                  C'est ce que le monsieur vient de faire. Ce que tout le monde (sauf toi) nomme "Serveur de son" (ou "Sound server", "sound daemon", etc.), c'est un logiciel comme PA, ESD, ArTS (pas certain de la casse…), etc. Un logiciel qui permet (entre autres) la transparence réseau pour la diffusion du son.

                  • [^] # Re: Pulse audio siffle dans mes oreilles...

                    Posté par . Évalué à -10.

                    Ah ? Donc pour vous XMMS2 est un serveur de son ?
                    Parce que XMMS2 attend (daemon), dispatche (http, alsa, PA), lit les fichiers audio (ogg, mp3)…
                    Pulse lui il attend qu'on lui livre ce que XMMS veut bien lui passer…
                    Pulse EST le deamon entre la carte audio physique et le /dev/dsp par exemple
                    (Pulse est un serveur audio mais pas un serveur de son.)
                    Selon votre exemple, Pulse s'occupe du réseau aussi ?

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 3.

          XMMS 2 est un serveur de son du genre VLC (je crois) :

          VLC n'est pas un serveur de son, ne l'a jamais été et n'a jamais eu vocation à l'être.

          selon wikipedia : " un lecteur basé sur un modèle client serveur, et une gestion des bibliothèques multimédia " (…)

          Donc c'est un lecteur.

          Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 10.

          XMMS2 sous Mandrake 8.0, arrête la drogue, vite!

    • [^] # Re: Pulse audio siffle dans mes oreilles...

      Posté par . Évalué à 0.

      @kadalka : Tu m'as trop fait penser à ce gars en la ramenant de la sorte:
      https://www.youtube.com/watch?feature=player_embedded&v=SggWtYEirKE

      :)

    • [^] # Re: Pulse audio siffle dans mes oreilles...

      Posté par . Évalué à 10.

      Le fameux pulseaudio de Lennart, l'homme qui suscite tant de controverse…

      Sais-tu pourquoi il suscite des "controverses" ? Lesquelles ? Chez qui y a-t-il controverse ? La première fois que j'ai été confronté à PulseAudio, c'était sur une Ubuntu 8.04, et la version utilisée était encore bien loin d'être finalisée, du moins pas encore assez pour une distribution grand public. C'est le choix de la distribution qui est à remettre en cause ici. Quand j'ai essayé de le désinstaller, apt m'a gentiment notifié que c'était une dépendance et qu'il allait virer tout le desktop Ubuntu avec, alors du coup j'ai bricolé des après-midis durant pour obtenir quelque chose d'utilisable. Très user-friendly, n'est-ce pas ? Mais est-ce là la faute de Poettering ?

      Il faut bien que le développement suive son cours, et pour ce faire, que les versions pré-1.0 sortent et soient testées par les utilisateurs. Si les distributions décident de s'en servir, et de contraindre l'utilisateur dans ce choix (voir le wiki Ubuntu, sous "PulseAudio Removal", "This is generally a bad idea, for reasons outlined in this Article"), c'est leur entière responsabilité. D'ailleurs Poettering s'est prononcé contre la façon dont PulseAudio avait été adopté par Ubuntu 8.04 : "To my surprise when Ubuntu adopted PulseAudio they moved into one of their 'LTS' releases rightaway"

      Quand je suis passé à Fedora, j'avais encore des problèmes avec PulseAudio, installé par défaut. Cependant, d'une part le public visé par la distribution n'est pas le même, d'autre part quand j'ai voulu le désinstaller, Yum a désinstallé PulseAudio tout seul comme un grand et le problème était réglé. Depuis quand la désinstallation d'une composante logicielle est-elle "déconseillée" ?

      J'ai fui pendant des années PulseAudio pour des problèmes techniques, mais est-ce une raison pour en rajouter encore une couche au sujet de Lennart Poettering, qui fait son travail, et qui le fait bien, il me semble. En effet, la version 1.0 de PulseAudio était stable sur tous mes systèmes, ce qui est, je pense, le but d'une version 1.0, et systemd qui en prend pour son grade depuis un bon moment, se révèle être très efficace sur mon système, de sorte que j'ai bien l'impression que tout ce battage tient plus du troll frénétique que des problèmes techniques.

      Ah et en plus de revoir ta définition d'un serveur son, intéresse-toi un peu à celle de la philosophie qui aurait besoin d'un peu plus d'attention.

      • [^] # Re: Pulse audio siffle dans mes oreilles...

        Posté par . Évalué à 3.

        j'ai bien l'impression que tout ce battage tient plus du troll frénétique que des problèmes techniques.

        Je pense que c'est le fait que systemd éloigne Linux de la grande famille des UNIX, en particulier des BSD. Lennart dit qu'il a rien contre un port de systemd sur BSD mais il me semble que techniquement ça obligerait à modifier en profondeur le noyau des OS BSD, ce qui paraît à la fois coûteux et potentiellement dangereux, donc non souhaitable.

        Après, est-ce que c'est mal de se reposer sur des spécificités du noyau Linux bien que ça nuise à la portabilité du bousin ? Ça je suis bien incapable de le dire.

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 7.

          Le gros problème du portage vers BSD, ce sont les cgroups. Alors, soit les BSD ont un équivalent et systemd se porte assez bien, soit tu retire les cgroups de systemd et tu perds une grosse partie de sont intérêt (et donc, peut-être que ça ne vaut pas la peine de le porter).

          « 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: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 4.

          Après, est-ce que c'est mal de se reposer sur des spécificités du noyau Linux bien que ça nuise à la portabilité du bousin ? Ça je suis bien incapable de le dire.

          De toute façon systemd est sous LGPL, quelque soit les choix technologiques systemd ne sera pas installé par défaut sur les systèmes BSD.

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 10.

          Je pense que c'est le fait que systemd éloigne Linux de la grande famille des UNIX, en particulier des BSD.

          Mais ça on s’en fout un peu non?

          Lennart dit qu'il a rien contre un port de systemd sur BSD mais il me semble que techniquement ça obligerait à modifier en profondeur le noyau des OS BSD, ce qui paraît à la fois coûteux et potentiellement dangereux, donc non souhaitable.

          En fait c’est plutôt le contraire que j’avais compris, que c’était possible de faire tourner systemd sans certaines fonctionnalités sous BSD mais personne n’a envie de faire ce travail…

          Après, est-ce que c'est mal de se reposer sur des spécificités du noyau Linux bien que ça nuise à la portabilité du bousin ? Ça je suis bien incapable de le dire.

          Non, Linux a des fonctionnalités en plus de BSD mais faut pas s’en servir c’est mâââl.

          Pour conclure: on va pas râler parce qu’on a un logiciel performant, souple et puissant qui exploite un maximum de fonctionnalités de Linux quand même? on est pas une population de vieux con à ce point, si?

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Pulse audio siffle dans mes oreilles...

            Posté par . Évalué à 3.

            possible de faire tourner systemd sans certaines fonctionnalités sous BSD mais personne n’a envie de faire ce travail…

            Si, comme dit Xavier Claude, sans les cgroups systemd perd une grande partie de son intérêt, pourquoi dépenser de l'énergie dans un portage sous BSD ?

            on va pas râler parce qu’on a un logiciel performant, souple et puissant qui exploite un maximum de fonctionnalités de Linux quand même?

            Non pas du tout. Je n'utilise pas car je suis sous Debian et je préfère garder l'init par défaut mais j'imagine que si j'utilisais une distribution avec systemd par défaut je l'utiliserais. Ça ne me ferait pas changer de distribution ou bien me lancer dans du bricolage pour virer systemd et utiliser l'init « traditionnelle ». Enfin j'imagine.

            • [^] # Re: Pulse audio siffle dans mes oreilles...

              Posté par (page perso) . Évalué à 4.

              Si, comme dit Xavier Claude, sans les cgroups systemd perd une grande partie de son intérêt, pourquoi dépenser de l'énergie dans un portage sous BSD ?

              Faut arrêter, c’est quand même pas le seul avantage de systemd d’utiliser les cgroups… Bon si les performances ça intéresse personne il y a aussi les unités systemd qui sont faciles à écrire, un même code pour toutes les distributions (l’ayant adopté s’entend), des services qui se lancent à la demande, une administration simplifiées parce que systemctl saytropratik™, etc.

              on va pas râler parce qu’on a un logiciel performant, souple et puissant qui exploite un maximum de fonctionnalités de Linux quand même?

              Non pas du tout. Je n'utilise pas car je suis sous Debian et je préfère garder l'init par défaut mais j'imagine que si j'utilisais une distribution avec systemd par défaut je l'utiliserais. Ça ne me ferait pas changer de distribution ou bien me lancer dans du bricolage pour virer systemd et utiliser l'init « traditionnelle ». Enfin j'imagine.

              J’ai déjà bricolé l’init pour avoir systemd quand c’était pas encore celui par défaut et je n’ai pas eu de problèmes (en suivant les instructions du wiki ça passe tout seul). D’ailleurs systemd pourrait passer à systemd, mais Debian/kFreeBSD pose un problème…

              Pour en revenir au sujet: si c’est pas ton système d’initialisation, de quoi peux-tu te plaindre? :p

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Pulse audio siffle dans mes oreilles...

                Posté par . Évalué à 3. Dernière modification le 20/06/13 à 00:45.

                D’ailleurs systemd pourrait passer à systemd

                C’est pas un compilateur, il n’a pas besoin de se compiler lui-même pour prouver sa maturité ( ¬‿¬). D’ailleurs j’ai du mal à saisir ta phrase, j’aurai pu penser que tu parlais des BSD*, mais la mention de Debian juste après contredis cette hypothèse.
                Et pour rester sur les anecdotes, je viens de m’apercevoir que tu as posté le 20 juin, hors le 20 c’est encore demain pour moi ! Décalage horaire toussa-toussa.

                bépo powered

              • [^] # Re: Pulse audio siffle dans mes oreilles...

                Posté par (page perso) . Évalué à 5.

                il y a aussi les unités systemd qui sont faciles à écrire

                Autant écrire un traducteur unité systemdscript init, c'est plus simple et ça a le même avantage. Ça couvre beaucoup de cas, et pour les autres, on écrit le script init à la main.

                un même code pour toutes les distributions (l’ayant adopté s’entend)

                Là, on parle d'adapter le code pour les BSD, ce ne sera justement plus le même code.

                ne administration simplifiées parce que systemctl saytropratik™

                Il faudrait voir ce qui reste de systemctl une fois qu'on n'a plus les cgroups.

                des services qui se lancent à la demande

                Pas besoin de systemd pour ça.

                « 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: Pulse audio siffle dans mes oreilles...

                  Posté par . Évalué à 2.

                  Autant écrire un traducteur unité systemd → script init, c'est plus simple et ça a le même avantage. Ça couvre beaucoup de cas, et pour les autres, on écrit le script init à la main.

                  Et on se foire dans le script, et on revient à une unité systemd bien plus simple et sécurisée.

                  Been there, done that !

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Pulse audio siffle dans mes oreilles...

                  Posté par (page perso) . Évalué à 3.

                  Autant écrire un traducteur unité systemd → script init, c'est plus simple et ça a le même avantage. Ça couvre beaucoup de cas, et pour les autres, on écrit le script init à la main.

                  Ça m’étonnerait que ça soit possible, puisque les sripts et le système d’init ont toujours été très différents donc à moins qu’ils passent tous à OpenRC ou à un système d’init à la BSD…

                  un même code pour toutes les distributions (l’ayant adopté s’entend)

                  Là, on parle d'adapter le code pour les BSD, ce ne sera justement plus le même code.

                  J’espère quand même qui s’ils adaptent systemd ça changera pas les 3/4 du code parce que sinon ça sert à rien effectivement. OpenSSH sous GNU/Linux c’est pas la version «officielle», c’est un portage et pourtant c’est quand même relativement proche de l’upstream non?

                  ne administration simplifiées parce que systemctl saytropratik™

                  Il faudrait voir ce qui reste de systemctl une fois qu'on n'a plus les cgroups.

                  Bah systemctl enable/disable/start/stop/restart/reload/status/list-units/etc ça va quand même pas disparaitre si? Bon c’est sûr ça demandera du travail de changer toutes les parties qui dépendent des fonctionnalités de Linux, mais je pense que c’est possible (en virant les parties de code qui dépendent de Linux et en remplaçant quand c’est nécessaire par la version kifonktione™ sous BSD).

                  des services qui se lancent à la demande

                  Pas besoin de systemd pour ça.

                  C’est plus facile avec systemd quand même… (ex: systemctl enable cups.socket)

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Pulse audio siffle dans mes oreilles...

                    Posté par (page perso) . Évalué à 3.

                    Ça m’étonnerait que ça soit possible, puisque les sripts et le système d’init ont toujours été très différents donc à moins qu’ils passent tous à OpenRC ou à un système d’init à la BSD…

                    Tu veux dire que les BSD devraient passer à un système d'init à la BSD ?

                    Bah systemctl enable/disable/start/stop/restart/reload/status/list-units/etc ça va quand même pas disparaitre si?

                    Il y a déjà un service start/stop/reload/status, autant l'étendre que de tirer systemd si c'est juste pour avoir ça en plus.

                    (en virant les parties de code qui dépendent de Linux et en remplaçant quand c’est nécessaire par la version kifonktione™ sous BSD).

                    Et quand il n'y a pas d'équivalent comme les cgroups ? (parce que ça joue quand même dans tout systemd, y compris dans systemctl status ou systemctl restart.

                    C’est plus facile avec systemd quand même… (ex: systemctl enable cups.socket)

                    Ce n'est pas vraiment plus compliqué autrement.

                    « 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: Pulse audio siffle dans mes oreilles...

                      Posté par (page perso) . Évalué à 3.

                      Tu veux dire que les BSD devraient passer à un système d'init à la BSD ?

                      Je pensais aux distros GNU/Linux qui ne sont pas passées à systemd (oui j'ai bugué).

                      Mais je crois que tous les BSD n'ont pas le même système d'init. À vérifier.

                      Et quand il n'y a pas d'équivalent comme les cgroups ? (parce que ça joue quand même dans tout systemd, y compris dans systemctl status ou systemctl restart.

                      On fait comme avant avec les scripts shell, en mode bourrin? Après je sais pas jusqu'où va l'utilisation des cgroups…

                      Enfin bref, même si c'est pas systemd, les BSD gagneraient à avoir un système d'initialisation bien foutu, parce que même si les scripts shell ça marche, niveau maintenance c'est un cauchemar.

                      Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Pulse audio siffle dans mes oreilles...

          Posté par (page perso) . Évalué à 10. Dernière modification le 20/06/13 à 09:59.

          Je pense que c'est le fait que systemd éloigne Linux de la grande famille des UNIX, en particulier des BSD.

          Pendant que les uns se battent pour rester dans un vieux monde qui n'existe plus, d'autres avancent pour proposer des outils utiles dans le monde d'aujourd'hui (bien différent d'hier, en public visé et machines disponibles), et si ça nécessite de casser, on casse.

          C'est quoi le problème? Faut rester avec des contraintes datant du moyen-age juste pour le principe?
          systemd a l'air de répondre à pas mal de besoins…

          faut un autre argument que celui-ci pour ne pas bouger.

  • # PulseAudio, un test standardisé ?

    Posté par (page perso) . Évalué à 10.

    Je ne sais pas dans quel monde vit Lennart Poettering, mais moi j’ai plutôt l’impression que les vendeurs de matériel s’en contrefichent royalement que PulseAudio ne fonctionne pas bien avec leurs produits (ou que leurs produits ne fonctionnent pas bien avec PulseAudio).

    Sérieusement, on a des exemples documentés de vendeurs de matériel audio prenant la peine de tester la compatibilité de leur matériel avec GNU/Linux ? Moi je ne connais que des initiatives émanant de la communauté, mais rien qui témoigne d’une implication directe des constructeurs…

    • [^] # Re: PulseAudio, un test standardisé ?

      Posté par . Évalué à -5.

      --- " Je ne sais pas dans quel monde vit Lennart Poettering, mais moi j’ai plutôt l’impression que les vendeurs de matériel s’en contrefichent royalement que PulseAudio ne fonctionne pas bien avec leurs produits " (…)

      C'est une question que j'ai fini par me poser au final…

      --- " Moi je ne connais que des initiatives émanant de la communauté, mais rien qui témoigne d’une implication directe des constructeurs " (…)

      Avec le marché restreint de linux, je doute qu'ils vont mettre des billes dedans, mais bon si intel va vers le kernel, peut-être qu'un constructeur daigne bien donner sa chance à l'audio de linux ?

      • [^] # Re: PulseAudio, un test standardisé ?

        Posté par (page perso) . Évalué à 0.

        Avec le marché restreint de linux

        Majoritaire sur les ordiphones il me semble… Alors s'ils s'en moquent, ils sont bons pour mourir sans être regrettés.

        • [^] # Re: PulseAudio, un test standardisé ?

          Posté par (page perso) . Évalué à 10.

          Android n'utilise pas Pulseaudio, WebOS n'existe plus, SailfishOS n'existe pas encore, et pour FirefoxOS je ne sais pas s'il utilise Pulseaudio.

          « 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: PulseAudio, un test standardisé ?

          Posté par . Évalué à -9.

          --- " Majoritaire sur les ordiphones il me semble… Alors s'ils s'en moquent, ils sont bons pour mourir sans être regrettés. " (…)

          Tiens ce que vous dites là, qui est pertinent de mon point de vue personnel, me rappelle la phrase de misc:
          Qt/Gtk n'est pas adapté à l'ordiphone selon un dev qu'il connaît…
          Je n'en suis pas convaincu mais bon, je prends bonne note de ce qu'à dit misc.

          Du coup, j'ai envie de me poser la question: et pulseaudio, il est adapté pour les ordiphones ?
          Parce que sur ce marché, il vaut mieux être à la hauteur côté son… et c'est un euphémisme.

          • [^] # Re: PulseAudio, un test standardisé ?

            Posté par . Évalué à 3.

            En tout cas, ils semble que les dev font en sorte que PulseAudio soit adapté aux téléphones.

            C'est pourquoi il y a cette URL dans la dépêche. Mais c'est un peu vieux.

          • [^] # Re: PulseAudio, un test standardisé ?

            Posté par (page perso) . Évalué à 4.

            Je n'ai pas suivi dans les détails le dev de QtMoko pour le GTA04, mais cet OS avait des problèmes de mise en veille de la carte son (si j'avais bien compris) avec ALSA et est donc passé à pulseaudio pour ce matériel afin d'avoir une veille du téléphone correcte (ensuite ils ont tenté de l'utiliser également pour les OpenMoko, mais ces périphériques n'étaient pas assez puissant et le gain n'était pas suffisamment intéressant).

            Donc oui ça s'utilise sur des ordiphones et ça marche (en tout cas pour les appels/alarmes/videos youtube/…).

          • [^] # Re: PulseAudio, un test standardisé ?

            Posté par (page perso) . Évalué à 8.

            Si tu me permets ( c'est une formule de politesse, en fait, je vais prendre la permission avec ou sans ton consentement ), je vais me citer moi même pour qu'on puisse bien voir comment tu pars de ce qu'on dit vers ce que tu dis :

            Sur https://linuxfr.org/nodes/98638/comments/1461011 j'ai dit :

            "En fait, non, j'ai encore parlé à midi avec un développeur que je connais ( qui au passage bosse chez RH, mais qui parle en son nom, je précise même si c'est l'évidence vu que tu as du mal à faire la séparation ), et lui pense que GTK et Qt, c'est mort, et qu'il faut partir sur des technologies comme Cordova/phonegap. Car dans tout les cas, si tu vises du multiplateforme, ça inclue les téléphones et c'est le moyen le plus simple. Perso, je continue de penser que les widgets natifs permettent des choses que les UI en html5 ne font pas, et que la fragmentation webkit/blink/firefox/ie/etc est aussi chiante ( ça et les versions ). Et que c'est bien plus lourd qu'une appli local."

            De la, tu traduit en "Qt/Gtk n'est pas adapté aux smartphones", ce qui est un raccourci totalement foireux. J'ai bien préciser que pour lui, c'était Qt/Gtk qui sont largué pour faire du multiplateforme ( ie, dans la discussion, c'était du windows/linux/osx au début, puis vers les tablettes, et donc android/ios ). Il a pas dit que c'est inadapté dans tout les cas, ni inadapté sur les portables. Par exemple, pour cibler la plateforme Ubuntu Phone, qui n'a pas pour vocation d'être en multiplateforme, ça semble être plus que correct.

            Donc voila, forcément, si tu piges pas plus ce que les gens te disent en dehors de Linuxfr que sur Linuxfr, faut pas étonner que les gens soient pas d'accord avec toi et le fasse comprendre.

        • [^] # Re: PulseAudio, un test standardisé ?

          Posté par . Évalué à 4.

          D'un autre cote, vu l'etat pitoyable des API sons sous autre chose qu'iOS, on est en droit de se dire que tant que le chipset fait a peu pres pouic pouic a +/- 50ms, le constructeur/vendor est content (le vendeur, lui, s'en fout comme de sa premiere chemise, il travaille pour att, et c'est a peine s'il sait ce qu'est android)..

          Vous vous etes jamais demande pourquoi le marche des appli de creation musicales fleurit sous iOS alors que c'est le grand vide sous android?

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: PulseAudio, un test standardisé ?

            Posté par (page perso) . Évalué à 1.

            le constructeur/vendor est content (le vendeur, lui, s'en fout comme de sa premiere chemise, il travaille pour att, et c'est a peine s'il sait ce qu'est android).

            Keuwa?

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: PulseAudio, un test standardisé ?

              Posté par . Évalué à 2.

              Vendor est tres mal traduit dans la citation par vendeur, alors qu'il veut dire fournisseur/prestataire.
              Le vendeur en francais, c'est le gars avec un cravate chez darty.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

    • [^] # Re: PulseAudio, un test standardisé ?

      Posté par . Évalué à 8.

      Dans la version original, il dit:

      and to some extent PulseAudio has advanced to become a standardized test hardware vendors check their drivers against.

      Ce que je traduirais par

      D'une certaine manière PulseAudio a progressé pour devenir un test standard

      Ce que ce comprends comme une tentative de prophétie auto-realisatrice (ratée) plutôt qu'un constat.

  • # Ducking

    Posté par (page perso) . Évalué à 10.

    module-role-ducking permet d'adapter les niveaux sonores des différents flux en fonction de leur importance (ducking). Par exemple, par défaut les flux « audio » et « vidéo » sont relégués au second plan lorsque un flux « téléphone » est présent. Ce comportement utilise les propriétés media.role des flux. Ce module n'est pas activé par défaut.

    Ce module a l'air intéressant sur papier, mais en réalité il ne sert à rien (et bonne chance pour configurer les applications qui n'envoient pas leur rôle correctement à Pulseaudio…): j'ai essayé de l'utiliser avec Teamspeak et Mumble, et j'ai rencontré le même problème: les autres applications ont leur volume réduit même lorsque personne ne parle.

    Si vous voulez vraiment essayer le « ducking », la vraie façon de faire est d'utiliser jack, avec un side-chain compressor (par exemple le module LADSPA SC3). Avec un peu de bidouillage, on y arrive, on peut même garder Pulseaudio (qui enverra le son vers jack au lieu d'ALSA/OSS) pour pouvoir garder le contrôle du volume par application. Voici un exemple de ma config, attention c'est pas joli! http://i.imgur.com/KeOgnkm.jpg

    • [^] # Re: Ducking

      Posté par . Évalué à 2.

      M'enfin bon, s'il faut se transformer en sonorisateur pour pouvoir avoir un ducking décent de certains flux par d'autres…
      Hypothèse à la con : le mauvais comportement du ducking que tu remarques est peut-être dû au fait que les basses fréquences ne sont pas filtrées dans la sidechain : du coup, le moindre coup sur la table ou sur l'ordi lui-même déclenche le ducking ?

      • [^] # Re: Ducking

        Posté par (page perso) . Évalué à 7. Dernière modification le 18/06/13 à 13:15.

        Aucun rapport, si tu jettes un coup d'œil à la source, tu verras que le module n'analyse pas le flux censé être "prioritaire" par rapport aux autres, et baisse bêtement le volume des autres flux dès qu'un flux prioritaire est crée (même si c'est pour du silence). Le comportement attendu est de baisser le volume par rapport au volume du flux prioritaire (bref, un vrai side-chain compressor).

        Et même si jack est plutôt orienté vers un usage professionnel, je ne vois pas pourquoi s'en priver pour avoir quelque chose de correct :) Il suffit de lire les manuels et d'appliquer du bon sens…

        • [^] # Re: Ducking

          Posté par . Évalué à 2.

          En passant, ils indiquaient dans les notes de version qu'ils avaient corrigé un bug dans PulseAudio lorsque on veut lancer JACK sur la carte déjà utilisée par PA via ALSA.

          J'ai pas testé mais, en croisant les doigts, il sera plus simple de lancer JACK, et PA devrait lui laisser sa place comme un grand et se placer comme client de JACK.

        • [^] # Re: Ducking

          Posté par . Évalué à 4.

          […] je ne vois pas pourquoi s'en priver pour avoir quelque chose de correct […]

          Parce que la pile audio de linux est déjà suffisamment imbitable comme ça ?

          Que la première version d'une fonctionnalité pas activé par défaut soit un peu pourri ne me surprend pas tellement ça s'améliorera dans l'avenir :)

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

  • # Liens matériel-ALSA-PulseAudio

    Posté par . Évalué à 7.

    Je croyais naïvement que PulseAudio n'était qu'une couche au-dessus d'Alsa (parfois OSS). Avec cette idée, la citation de 2011 sur les vendeurs de matériel me semblait maladroite, puisqu'elle oublie les problèmes de pilotes ALSA. J'ai souvent eu des bugs lors de l'hibernation, avec divers PC, surtout lorsque l'audio était actif (lecteur en pause, etc). En général, il faut alors recharger les pilotes avec sudo alsa force-reload.

    Dans les nouveautés, j'ai vu le décodage AAC matériel. Si je comprends bien, PulseAudio dialogue donc généralement avec l'API ALSA, mais il peut de temps en temps la court-circuiter pour s'adresser directement au matériel. Je me plante peut-être, mais ça ne me semble pas très robuste : on peut avoir 3 applications qui accèdent simultanément à la même carte son par 3 voies distinctes. L'une par ALSA+matériel, l'autre par PulseAudio+matériel, la dernière par PulseAudio+ALSA+matériel. Il me semble miraculeux que ce scénario fonctionne !

    • [^] # Re: Liens matériel-ALSA-PulseAudio

      Posté par . Évalué à 8.

      PulseAudio utilise bien ALSA/OSS/… comme interface avec le matériel. Mais, pour ALSA par exemple, il remonte certaines "méta-données" depuis le matériel pour déterminer la corrélation entre le niveau réel (en dB) de la sortie analogique et le paramètre de volume logiciel. Sauf que pour certains matériels ces données sont complètement fausse; d'où la citation de Lennart à ce sujet.

      Pour ce qui est de l'AAC, il s'agit de "passthrough" et pas de décodage : PulseAudio est capable de passer directement du son encodé aux sorties numériques d'une carte son (S/PDIF) ou d'un appareil Bluetooth. Il ne s'agit pas d'un accès direct à la mémoire tampon du matos.

    • [^] # Re: Liens matériel-ALSA-PulseAudio

      Posté par . Évalué à 9. Dernière modification le 19/06/13 à 20:48.

      Certains utilisateurs (plein de pincettes tu vois) on justement reprochés cela initialement à PulseAudio, en résumé :
      « pourquoi refaire une mauvaise couche de trop ? »
      Et j'ajouterai « pourquoi prendre un nouveau dev plutôt que d'améliorer l'existant ? »

      Factuellement, ce qui était reproché initialement à PA c'était cela et rien d'autre : ne pas être capable de remplacer jack, et ne pas être capable de remplacer dmix. Bref, une couche de plus :-( Tout ça pour quels bénéfices initiaux ? Clairement : uniquement le blutooth et Adobe Flash. super :-/

      Aujourd'hui les choses changent, visiblement. PA n'est toujours pas capable de réaliser tout ce que fait Jack, mais il s'en approche. PA ou Jack, "on" s'en fiche, c'est simplement dommage qu'une solution de grande qualité n'ai pas bénéficiée des mêmes efforts qu'une solution initialement de bien piètre qualité.

      Quant aux autres devs de Mr Pottering, on ne peux que constater qu'il a complètement changé son fusil d'épaule, en cherchant justement à changer en profondeur certaines abbérations (de certains points de vue, quelque soit le jugement que l'on porte sur ces changements, il faut constater que nous ne sommes plus du tout sur un ajout mais sur de réels changements. Et en tant qu'admin comme en tant que user, systemD c'est juste génial). Ce qui a nourri d'autres types de trolls. Finalement Lennart s'en prends plein la tronche par certains pour des raisons très différentes.

      Quant à PA, je continue de le virer illico, mais je ne désépère pas d'avoir une solution pouvant prendre en compte gloablement les différents besoins, et cerise sur le gateau, tirer tout le monde vers le haut (ne pas grêver les usages lourds pour les gadgets)

      hop, moinssez moi.
      un systemd user ravi. et bientôt un wayland user ravi ;)

      • [^] # Re: Liens matériel-ALSA-PulseAudio

        Posté par . Évalué à 2.

        Le but de jack et de PA sont très différents.

        Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
        Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.

        C'est un peu la différence en linux et linuxRT.

        • [^] # Re: Liens matériel-ALSA-PulseAudio

          Posté par . Évalué à 0.

          charge machine faible ?
          On a pas dut avoir le même PA (en tout cas au début de sa vie)

          • [^] # Re: Liens matériel-ALSA-PulseAudio

            Posté par (page perso) . Évalué à 7.

            Bah regarde ce que ça donne à l’heure actuelle, au lieu de parler au passé.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Liens matériel-ALSA-PulseAudio

              Posté par . Évalué à 1.

              J'ai regarde et vu comment mon systeme est plus reactif depuis que j'ai vire ce truc, je dirai que PA est toujours un bouffeur de ressource.

              • [^] # Re: Liens matériel-ALSA-PulseAudio

                Posté par (page perso) . Évalué à 3.

                J'ai regarde et vu comment mon systeme est plus reactif depuis que j'ai vire ce truc, je dirai que PA est toujours un bouffeur de ressource.

                J'aurais bien aimé plus d'informations: config matérielle et logicielle, occupation processeur et mémoire prise par PulseAudio lorsqu'1/2/3/4 applications utilisent le son, effets sur les autres applications.

                Si on a aucune information, on peut pas vraiment résoudre le problème/bug.

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Liens matériel-ALSA-PulseAudio

                  Posté par . Évalué à 1.

                  Je n'ai plus envie (c'est curieux apres des annees d'emmerde) de remettre PA. J'aiu deja rempli des tonnes de bug report sur le sujet et j'en ai marre. J'ai trouve une solution qui FONCTIONNE et en plus me sort une couche de logiciel et utilise donc forcement moins de ressource… Parceque au final je dois etre dur de la comprehension mais je vois pas comment rajouter une couche peut diminuer les ressources utilise vu que de tout de facon tu n'as pas le choix Alsa sera utilise!

                  • [^] # Re: Liens matériel-ALSA-PulseAudio

                    Posté par (page perso) . Évalué à 2.

                    Je n'ai plus envie (c'est curieux apres des annees d'emmerde) de remettre PA. J'aiu deja rempli des tonnes de bug report sur le sujet et j'en ai marre.

                    Ok très bien.

                    J'ai trouve une solution qui FONCTIONNE et en plus me sort une couche de logiciel et utilise donc forcement moins de ressource…

                    Si ça te convient, tu fais ce que tu veux!

                    Parceque au final je dois etre dur de la comprehension mais je vois pas comment rajouter une couche peut diminuer les ressources utilise vu que de tout de facon tu n'as pas le choix Alsa sera utilise!

                    On a jamais dit que PuseAudio serait plus léger que ALSA seul (et heureusement d'ailleurs).

                    Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Liens matériel-ALSA-PulseAudio

                    Posté par (page perso) . Évalué à 2.

                    Maintenant que j’y pense, c’est PulseAudio qui mixe donc ça veut dire qu’on ne passe pas par le mixer d’ALSA donc la différence est peut-être négligeable (sauf dans ton cas visiblement)… Faudrait voir à benchmarker tout ça.

                    Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Liens matériel-ALSA-PulseAudio

              Posté par . Évalué à 7.

              Bah regarde ce que ça donne à l’heure actuelle, au lieu de parler au passé.

              Bah il a le droit d'être sous Debian, aussi.

        • [^] # Re: Liens matériel-ALSA-PulseAudio

          Posté par (page perso) . Évalué à 4.

          Le but de jack et de PA sont très différents.

          Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
          Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus > souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.

          Ben ouais mais regarde macos (ou ios). Une seule API, coreaudio, qui permet de tout faire, faible latence ou gros buffers, zéro prise de tête et tout le monde est content. Ca aurait surement été possible sous linux si poettering s'était interessé aux problématiques de temps réel pour l'audio dès le départ, et si les gens qui gravitent autour de jack avaient été un peu moins violents dans leurs réactions.

      • [^] # Re: Liens matériel-ALSA-PulseAudio

        Posté par . Évalué à 10.

        Hummm, ton avis est intéressant parce que plutôt subjectif pour quelqu'un qui n'utilise pas PulseAudio. Voici le mien :

        Avant PA il y'avait clairement un manque côté pile audio sous linux. Dire que dmix (le mixage logiciel pour ALSA) était/est une solution n'est valable que pour le mec qui utilise encore un PC type bureau en ne branchant jamais rien dessus. Rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau. Ne parlons même pas de fonctionnalitées avancées (suppression de l'echo, ducking, …)

        Jack a, lui, clairement une vocation professionnelle : réduire la latence au maximum pour permettre à des applications PRO de faire du monitoring/overdub/multi-pistes/synth… en temps réel. Est il le fait très bien.

        PA s'est toujours voulu orienté "consumer audio" pas "pro audio". Il a donc des fonctions avancées (y'a un gouffre avec dmix) pour l'utilisateur classique qui branche son oreillette et utilise skype (arf… le pauvre).

        Ce qu'on lui reproche c'est de ne pas être au niveau de CoreAudio (la pile audio OSX) qui, elle, arrive a concilier les deux. Mais là encore il y a des raisons. En faite une, principalement : ALSA n'est pas souple au niveau de sa gestion des tampons mémoires : explications [english]. CoreAudio sait le faire. Comment fait Jack ?? Il utilise un tampon de taille très petite, ce qui garanti une lantence très faible. Le problème c'est que seul les cartes avec une électronique pro et un processeur musclé arrivent a tenir la charge… (+ un kernel aux oignons + rtlimits + …)

        "Ouai, enfin, mon PulseAudio bouffe 151% de mon CPU !". Là aussi il y'a une raison. Ce qui coûte cher en audio c'est les IRQs et le rééchantillonnage. Les IRQs c'est vu plus haut. Le rééchantillonnage : Jack ou dmix imposent le taux d'échantillonnage, et c'est a l'application de faire avec, la charge CPU va donc au client. PulseAudio essaye de trouver le bon compromis et rééchantillone lui même, c'est lui qui prend la charge. Ce qui ne veux pas dire que PA est exempt de bugs !

        "Mais on peux très bien utiliser Jack sans RT ou faible latence". Certe. M'enfin niveau fonctionnalitées avancés on reppasera : un client veux jouer un son stéréo sur une carte 5.1 > il se connecte aux deux premier ports de la carte son > si c'est pas les deux L/R ben… il faut redistribuer à la main…

        De par son architecture "lock-free" et "zero-copy" (en faite, comme celle de Jack) PulseAudio est à priori capable de faire du temps réel comme Jack. Mais l'orientation et clairement à la légèreté et la faible consomation d'énergie, les dévellopements ne vont pas dans ce sens.
        On peux par contre regréter la mauvaise intégration avec Jack (PA deviens un simple client Jack quand celui ci se lance) : on notera un manque de volonté côté Jack qui ne veux pas entendre parlé de DBus (pour négocier la main sur ALSA, m'enfin ça va mieux depuis qu'il existe 36 version de Jack) et un retard côté PA dont le pilote Jack est plutôt (très) naze.

        Notons quand même que seul Jack est capable de faire cracher les watts à une carte firewire (via libffado,). Mais (toutes ??) les cartes firewire sont des cartes pro…

        Après si pour prouver ses dires il faut donner un exemple de quand ça marche pas, je vous laisse fouiner dans les buzilla respectifs de chaque projet à la recherche d'une pépité confirmant votre thèse. Je m'épargne cette peine.

        • [^] # Re: Liens matériel-ALSA-PulseAudio

          Posté par (page perso) . Évalué à 2.

          Ce qu'on lui reproche c'est de ne pas être au niveau de CoreAudio (la pile audio OSX) qui, elle, arrive a concilier les deux. Mais là encore il y a des raisons. En faite une, principalement : ALSA n'est pas souple au niveau de sa gestion des tampons mémoires : explications [english]. CoreAudio sait le faire.

          Et donc faut un remplaçant à ALSA pour avoir une meilleure pile audio? Parce que bon le seul espoir qu’on ai eu récemment c’est KLANG (et j’ai eu beaucoup d’espoir que ça règle tous les problèmes). Et vu l’état de la page d’accueil du projet (avant il avait beaucoup de textes et deux-trois liens) ainsi que le fait que l’auteur initial c’est fait sévèrement démonté par des professionnels de l’audio sous GNU/Linux…

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Liens matériel-ALSA-PulseAudio

            Posté par . Évalué à 3.

            Remplacer je ne sais pas, mais plusieurs développeurs (Lennart Poettering/Pulseaudio & Paul Davis/Jack) s'accordent pour dire que ALSA devrait arrêter de maintenir sont API en espace utilisateur et revoir l'architecture de ses pilotes internes. Mais le travail est énorme pour une main d'oeuvre très faible.
            Pour KLANG, l'objectif est similaire voir plus ambitieux mais la charge de travail est encore plus importante, il semble impossible que ca aboutisse un jour…

        • [^] # Re: Liens matériel-ALSA-PulseAudio

          Posté par . Évalué à 4.

          rappelons que ALSA ne gére QUE les cartes son internes et usb. Donc rien pour le firewire, le bluetooth ou le réseau.

          Euh j'ai vire PA et j'arrive a me connecter au systeme son par bluetooth. Est ce de la magie?

          • [^] # Re: Liens matériel-ALSA-PulseAudio

            Posté par . Évalué à 3.

            Oui, et le magicien s'appelle bluez-alsa probablement.

            • [^] # Re: Liens matériel-ALSA-PulseAudio

              Posté par . Évalué à 1. Dernière modification le 20/06/13 à 13:13.

              Je savais mais c'etais juste pour pointer du doigt que c'etait faisable sans PA. Donc dire que ALSA ne gere pas le bluetooth c'est un peu normal c'est pas fait pour et c'est laisse au … programme qui gere le bluetooth, comme il se doit je rajouterait, et oh miracle ca fonctionne!

              • [^] # Re: Liens matériel-ALSA-PulseAudio

                Posté par . Évalué à 5.

                Exactement, ALSA n'est pas fait pour. ALSA c'est des pilotes noyaux pour les cartes PCI/ISA/… & USB + une librairie en espace utilisateur pour son interface client. Au début tout le monde avais UNE carte son INTERNE, alors les clients utilisaient directement l'API ALSA, c'était simple.
                Le problème c'est que le matos a évolué et les pilotes ce sont retrouvés en dehors l'ALSA et là c'est devenu compliqué. Simuler une interface ALSA virtuel pour causé à un autre pilote qui peux lui même être en espace utilisateur (bluez-alsa) n'est pas, à mon sens, une bonne solution.
                La solution (PA ou Jack) c'est d'avoir une vrais API audio qui ne soit pas dépendante du pilote/matos. Utiliser l'API ALSA pour jouer du son dans son client haut niveau c'est stupide, a moins qu'ALSA centralise tout les pilotes pour le matos audio.
                ALSA n'est PAS une API audio haut niveau, même s'il est vrai que libasound a toujours eu un statut ambigu.

                • [^] # Re: Liens matériel-ALSA-PulseAudio

                  Posté par . Évalué à 2.

                  c'est peut etre pas LA bonne solution mais ca fonctionne alors que la soit disant bonne solution ne fonctionne pas. J'ai un peu l'impression que c'est tres similaire au micro-kernel comme HURD c'est soit disant la bonne solution mais ca fonctionne pas alors que le monolithique Linux a "quelques" succes…

                  • [^] # Re: Liens matériel-ALSA-PulseAudio

                    Posté par . Évalué à 9.

                    La comparaison ne me semble pas très adaptée mais en gros c'est un peu : "coder des plugins pour ALSA et assurer une rétro-compatibilité pour une API veille de + 15 ans" contre "corriger les imperfections d'intégration du tout (plus si) jeune PulseAudio".

                    PulseAudio a viandé dans ton cas, fonctionne dans le miens. J'ai autant de mal avec l'argument du "chez moi sa marche" qu'avec celui du "chez moi sa marche pas". Si on ne vois pas les avantages de PulseAudio (quand il marche), effectivement, ça vaut pas trop le coup de passer du temps a essayer de le faire marché.

                    • [^] # Re: Liens matériel-ALSA-PulseAudio

                      Posté par (page perso) . Évalué à 0.

                      PulseAudio a viandé dans ton cas, fonctionne dans le miens. J'ai autant de mal avec l'argument du "chez moi sa marche" qu'avec celui du "chez moi sa marche pas". Si on ne vois pas les avantages de PulseAudio (quand il marche), effectivement, ça vaut pas trop le coup de passer du temps a essayer de le faire marché.

                      +1

                      <grammar_nazi>
                      «fonctionne dans le mien»
                      «si on ne voit pas»
                      «chez moi ça marche».
                      «ça vaut pas trop le coup de passer du temps à essayer de le faire marcher»
                      </grammar_nazi>

                      Moinsez-moi moinsez-moi moinsez-moi…

                      Écrit en Bépo selon l’orthographe de 1990

                    • [^] # Re: Liens matériel-ALSA-PulseAudio

                      Posté par . Évalué à 3.

                      Sauf que Alsa est inclus au kernel et que PA n'est qu'une n'ieme surcouche au dessus de Alsa. Donc ok Alsa c'est pourrit mais bon c'est toujours la et a la fin c'est ca qui fonctionne (avec ou sans PA).

                      • [^] # Re: Liens matériel-ALSA-PulseAudio

                        Posté par . Évalué à 5.

                        Toi t'as toujours pas compris que Alsa c'est pas UN gros truc, c'est plusieurs morceaux. La partie de Alsa contenue dans le kernel, oui, on veut la garder, ça s'appelle "des pilotes de carte son" et on s'appuiera toujours dessus. La lib Alsa en userspace on veut la virer et la remplacer par PA pour le consumer et Jack pour le pro.

                        • [^] # Re: Liens matériel-ALSA-PulseAudio

                          Posté par (page perso) . Évalué à 2.

                          La lib Alsa en userspace on veut la virer et la remplacer par PA pour le consumer

                          Comme les bougies?

                          Plus sérieusement, est-ce que le mixage effectué par PA est vraiment plus lent/consommateur de ressources que celui fait par ALSA en espace utilisateur?

                          Écrit en Bépo selon l’orthographe de 1990

  • # PulseAudio / ALSA

    Posté par . Évalué à 8.

    C'est quoi l'intérêt d'utiliser PulseAudio, aujourd'hui, alors qu'ALSA fait aussi du mixage logiciel ?

    • [^] # Re: PulseAudio / ALSA

      Posté par . Évalué à 4.

      C'est quoi l'intérêt d'utiliser dmix, aujourd'hui, alors que PulseAudio s'occupe du mixage logiciel ?

    • [^] # Re: PulseAudio / ALSA

      Posté par (page perso) . Évalué à 8.

      Si pour toi, Pulseaudio, c'est juste du mixage logiciel, c'est que tu n'as rien compris au principe.

      « 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: PulseAudio / ALSA

      Posté par (page perso) . Évalué à 2.

      Je ne crois pas que tous les drivers ALSA et/ou hardware supportent le mixing. Le cas échéant, on utilise le contournement DMIX, et on se cogne la tête.

      • [^] # Re: PulseAudio / ALSA

        Posté par . Évalué à 4.

        En effet, pour avoir du mixage "dans l'pilote" il faut 1] que la carte supporte le mixage matériel (quasiment aucune depuis 2000, hors matos pro), 2] que le pilote prenne en charge cette fonctionnalitée. Le mixage logiciel avec ALSA c'est dmix ou rien : ALSA ne sait pas mixe mais peux éventuellement passer le boulot à la carte si elle sait faire.

  • # Merci pulseaudio

    Posté par (page perso) . Évalué à 10. Dernière modification le 18/06/13 à 13:45.

    Ce week-end, je viens de brancher une platine vinyle sur le pc, j'ai pu configurer tout ça très facilement avec pulseaudio :

    • redirection de l'entrée line-in vers la sortie de la carte son
    • application d'un filtre d'égalisation RIAA pour obtenir le son comme il faut.

    Tout ça en logiciel : c'est à dire juste deux lignes à rajouter dans le fichier de configuration. Alors oui il faut mettre les mains dans le cambouis, oui ça se fait sans interface graphique, mais sans PA, je ne crois pas que j'aurais pu mettre ça en place si rapidement.

    Pour moi, PA fait partie des logiciels qui occupent une place essentielle sur mon pc !

    • [^] # Re: Merci pulseaudio

      Posté par . Évalué à 3.

      Alors essaie jack… tu dois mettre les mains dans le cambouis aussi mais c'est plus puissant, plus léger. Tu pourras renvoyer tout ce que tu veux dans les filtres que tu veux.

      • [^] # Re: Merci pulseaudio

        Posté par (page perso) . Évalué à 8.

        En fait j'utilisais déjà pulseaudio pour centraliser tous les sons des PCs vers un serveur unique. Ça se fait par le réseau, et ça permet de n'avoir qu'une seule sortie son (et de brancher les bonnes enceintes sur cette machine).

        Je crois que ça s'appelait encore polypaudio quand j'avais mis ça en place…

    • [^] # Re: Merci pulseaudio

      Posté par . Évalué à 7.

      Idem ici, je voulais rediriger le son d'un PC vers les enceintes d'un autre, de meilleure qualité. Ça se fait super bien avec pulseaudio.

    • [^] # Commentaire supprimé

      Posté par . Évalué à 1.

      Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Merci pulseaudio

        Posté par (page perso) . Évalué à 4.

        Donc, tout le monde doit avoir ta config pour avoir le droit d'utiliser son PC ?

        « 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: Merci pulseaudio

      Posté par . Évalué à 5. Dernière modification le 19/06/13 à 14:19.

      mais sans PA, je ne crois pas que j'aurais pu mettre ça en place si rapidement.

      Ça se fait en un pipeline simple sous gstreamer. Je crois pas que ça prenne des années non plus. Point bonus tu peux même réencoder ça en vorbis et le stocker.

      • [^] # Re: Merci pulseaudio

        Posté par (page perso) . Évalué à 2.

        C'est vrai que je ne me suis jamais penché sur gstreamer, pour ma part je le vois comme une couche d'abstraction pour faire le lien entre les applications et les librairies, mais je suis peut être dans l'erreur…

        Tu aurais une doc sur la mise en place d'un pipeline sur un pc ne disposant pas de serveur X (ce que j'ai trouvé passe obligatoirement par une interface graphique…) ?

        • [^] # Re: Merci pulseaudio

          Posté par . Évalué à 3.

          man gst-launch est un très bon début, surtout sa section Pipeline Examples.

        • [^] # Re: Merci pulseaudio

          Posté par (page perso) . Évalué à 1.

          C'est vrai que je ne me suis jamais penché sur gstreamer, pour ma part je le vois comme une couche d'abstraction pour faire le lien entre les applications et les librairies, mais je suis peut être dans l'erreur…

          Bah Gstreamer c’est une bibliothèque qui va communiquer avec soit ALSA, soit OSS soit PulseAudio.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Merci pulseaudio

            Posté par (page perso) . Évalué à 6.

            Bah Gstreamer c’est une bibliothèque qui va communiquer avec soit ALSA, soit OSS soit PulseAudio.

            Ah c'est comme pulseaudio alors :)

            ----> []

  • # Sans pulseaudio

    Posté par . Évalué à 10.

    Sous arch, j'avais plein de problèmes avec pulseaudio :

    • Le son qui ce mute à chaque redémarrage : les volumes sont remis à zéro (impossible de trouver un moyen propre de restaurer la config, au final j'ai mis quelques lignes dans le .xinitrc pour mettre un volume par défaut…)
    • Le son qui s’arrête ou qui grésille quand les CPU sont à 100% : le 1080p ? C'est du passé.
    • MPD et pulseaudio, c'est vraiment pas ça
    • Je ne sais pas pourquoi, mais quand je joue à Teeworlds je n'ai plus le son des vidéos Flash, et parfois c'est l'inverse et le plus souvent, le son s'arrête et le seul moyen que j'ai trouvé pour le remettre c'est de redémarrer l'ordi ! Windows style !
    • Quand tout vas bien, c'est qui est rarement le cas, et bien juste en écoutant de la musique avec MPD, pulseaudio prend 10% d'un de mes deux CPU

    Et pourtant, j'ai passé des heures à essayer de comprendre d’où venait les problèmes, j'ai lu énormément de doc, j'ai tenté énormément de choses.

    Bon puis au final, juste après une mise à jour, je n'avais plus du tout de son et pourtant les volumes étaient bon et pulseaudio était lancé.. pacman -R pulseaudio pulseaudio-alsa pavucontrol on réinstalle quelques outils pour manipuler alsa. On configure vite fait MPD, on redémarre l'ordi (c'est devenu une habitude..) et on commence une nouvelle vie.

    • [^] # Re: Sans pulseaudio

      Posté par (page perso) . Évalué à 10.

      Comme quoi, Arch, ce n'est pas que des bonnes expériences.

      « 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: Sans pulseaudio

        Posté par . Évalué à 3.

        Arch ou Pulseaudio ?

        • [^] # Re: Sans pulseaudio

          Posté par (page perso) . Évalué à 10.

          Ça a quand même tendance à marcher depuis quelques années sur les distribs qui font l'effort de l'intégrer.

          « 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: Sans pulseaudio

            Posté par . Évalué à 4.

            bah ça a marché chez moi (même si je ne l'ai pas gardé).
            et surtout, ArchLinux n'intègre pas (ou très peu) les applis, du coup on peut dire que "rien n'est intégré sur Arch" :)
            elle n'est pas faite pour ça, et donc pas faite pour toi, si ce qui te plait est d'avoir un système prêt, intégré et configuré.
            les mauvaises expériences avec cette distribution proviennent surtout d'une incompréhension de sa philosophie.
            reprocher à Arch de ne rien avoir d'intégré, c'est comme reprocher à Debian de n'avoir que des vieilles version des logiciels, ou a LFS d'être trop compliquée.

            bref pour le coup rien à reprocher à Arch, juste PulseAudio qui est assez difficile à intégrer (et, avis personnel, pas super simple et stable, suivant l'utilisation qu'on en a).

          • [^] # Re: Sans pulseaudio

            Posté par . Évalué à 3.

            Ça a quand même tendance à marcher depuis quelques années sur les distribs qui font l'effort de l'intégrer.

            Avec des logiciels et patchs qui restent downstream (Xubuntu : xfce4-volumed-pulse, fork de xfce4-volumed, indicator-sound-gtk2, *buntu : support de Timidity++ avec PulseAudio quel que soit la manière dont on l'a lancé alors que j'ai dû trouver LA commande qui le fait fonctionner avec PA sous Arch, etc…), malheureusement.

            Reprocher à Arch de ne pas intégrer le logiciel X, c'est un peu ne pas comprendre Arch.

            Et sinon, chez moi PulseAudio ça fonctionne très bien. Mais pour ça, j'ai dû :
            - bien comprendre l'article sur PulseAudio sur le wiki Arch. Car comme d'habitude, l'intégration, c'est du DIY, c'est le revers de la médaille de sa philosophie KISS. Si t'en veux pas, tu prends une autre distrib' (je te conseillerais Xubuntu d'ailleurs : ça juste marche. Mais y'a pas pacman. :/ )
            - compiler xfce4-volumed-pulse (je l'ai mis sur l'AUR depuis), plutôt que d'utiliser xfce4-volumed
            - compiler psmixer-xfce4 depuis l'AUR pour avoir un vrai support de PulseAudio dans le tableau de bord Xfce (à la place de xfce4-mixer qui utilise le mixer de gstreamer0.10, tout comme xfce4-volumed, qui est abandonné)
            - ne pas lancer pulseaudio ni xfce4-volumed-pulse grâce à leurs fichier .desktop dans /etc/xdg/autostart ! Il faut que PA soit lancé en premier pour avoir du son. Du coup je lance dans l'ordre PA, xfce4-volumed-pulse, et timidity++ dans un script situé dans ~/bin, lancé depuis un fichier .desktop présent dans ~/.config/autostart
            - dire aux quelques logiciels (Audacious, SMPlayer, …) que j'utilise PA. Rien de compliqué.

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Sans pulseaudio

              Posté par (page perso) . Évalué à 2.

              • bien comprendre l'article sur PulseAudio sur le wiki Arch. Car comme d'habitude, l'intégration, c'est du DIY, c'est le revers de la médaille de sa philosophie KISS.

              Ouais mais bon il n’y a pas beaucoup d’étapes et ça se fait tout seul en suivant le wiki (j’apprécie beaucoup Arch Linux justement pour son wiki). On ne change pas de système audio tous les deux jours et le seul truc un peu crade c’est pour faire passer les applications Java par PulseAudio.

              En tout cas pour moi, ça c’est résumé à installer les paquets suivants: pulseaudio pulseaudio-alsa lib32-libpulse lib32-alsa-plugins, et c’est tout (gstreamer faisant déjà le boulot pour nous en gros et VLC ne demandant pas de conf supplémentaire).

              Faut que je vérifie cependant s’il y a toujours le bug que j’ai mentionné plus haut.

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Sans pulseaudio

                Posté par (page perso) . Évalué à 3. Dernière modification le 18/06/13 à 22:31.

                Ok, donc avec trois applications en même temps ça roule et PulseAudio détecte VLC à 100% de volume quand il est à 100% ou plus mais ça me dérègle complètement le son (après le son est à 100% mais le son du plugin alsa est à 30%, du coup quand je lance une autre application ça gueule mais j’entends rien avec le lecteur Flash sur Youtube). «Fonctionnalité» réglée en 10 secondes grâce au wiki d’Arch Linux.

                On peut régler le son par application dans le mixeur ce qui est pas mal même si je n’avais aucun problème avec ALSA — mais on perd le réglage quand on arrête l’application on dirait (au moins pour Flash).

                Je n’ai plus le bug des périphériques, mais le test de l’utilitaire de configuration dans KDE ne fonctionne pas (il n’apparait même pas dans les flux audio traitées par PulseAudio). C’est le truc le plus simple qui ne fonctionne pas (c’est peut-être dû à KDE par contre, mais avant ça marchait c’est bizarre… Si quelqu’un peut confirmer le bug).

                Enfin, 6-7% d’utilisation du processeur (AMD Athlon 64 x2) avec trois applications qui utilisent le son en même temps, 3% avec une seule application et rien si aucune application n’utilise le son ça me parait raisonnable (j’ai la dernière version, Arch Linux oblige).

                Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Sans pulseaudio

            Posté par . Évalué à 2.

            T'as réveillé la meute !

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

          • [^] # Re: Sans pulseaudio

            Posté par . Évalué à -2.

            Oui enfin les distribs qui sont passés courageusement après que les utilisateurs de Arch se soient cassés les dents quoi.

            • [^] # Re: Sans pulseaudio

              Posté par (page perso) . Évalué à 7.

              C'est Fedora qui a été la distribution qui a débuté l'intégration de PulseAudio et qui l'a poussé à atteindre un très bon niveau.
              Normal, c'est le but de la distribution que d'intégrer ce type d'utilitaire et déboguer les gros problèmes rencontrés à cette étape pour que les autres le fassent plus facilement si elles le souhaitent.

              Les utilisateurs de ArchLinux ne sont pas des victimes hein. ;)

      • [^] # Re: Sans pulseaudio

        Posté par (page perso) . Évalué à 3.

        Chezmoiçamarche™ aussi bien qu'ALSA à part un léger bug mineur qui n'arrive qu'avec KDE (il me dit que des périphériques audio ne sont plus là ou je sais pas quoi mais en fait ça fonctionne très bien), mais pas réessayé depuis un moment (je sais ce que je vais faire ce sois… :p).

        Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Sans pulseaudio

      Posté par . Évalué à 3.

      Merci 1000 fois, apres ton poste j'ai revire pulseaudio et bien c'est impressionant. TOUT fonctionne et bien mieux en particulier le bluetooth. Certes il a fallu que je mette un peu les mains dans le cambouis mais quel plaisir de pouvoir enfin me servir du bluetooth sans que les films saccadent et donc que ce soit inutilisable.

      C'est trop cool. Je croyais que c'etais mon ordi qui faisait sentir son age mais non c'est pas c'est juste … pulseaudio.

  • # bogue ou bogues ?

    Posté par . Évalué à 2. Dernière modification le 18/06/13 à 15:17.

    Pourquoi "bogue" reste-t-il au singulier ? Un bogue est dénombrable il me semble.
    "Correction de bogue" -> "Correction de bogues", Nan ?
    De même, "corrections de bogue" -> "corrections de bogues"

    • [^] # Re: bogue ou bogues ?

      Posté par (page perso) . Évalué à 3.

      Corrigé, merci.

      « 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

  • # Ouais, ben…

    Posté par . Évalué à 10. Dernière modification le 19/06/13 à 09:59.

    De nos jours les vendeurs de matériel comprennent que quand PulseAudio ne marche pas correctement avec leurs produits c'est sans doute de leur faute, pas celle de PulseAudio.

    Ou pas…

    J'ai été forcé de basculer sur PulseAudio il y a quelques mois de cela, pour pouvoir faire fonctionner la dernière mouture de Skype qui sinon plantait (freeze en allant dans les options audio ou au moindre appel).

    Le bilan de ces quelques mois est que :

    • Pulseaudio m'a viré toutes les jauges de réglage dans Kmix, remplacé par une unique jauge, à laquelle vient s'ajouter une jauge par application lancé qui sort du son, c'est super con quand l'application qu'on utilise arrête de faire du son/se met en pause lorsqu'elle perd le focus, du coup sa jauge disparaît lorsqu'on switch sur le mixeur de Kmix. En plus, ça ne me permet plus de régler la hauteur des différents canaux genre Surround, Center, Side, Front, Bass, Trebble, etc. ;
    • Pulseaudio me sort un son vachement atténué en comparaison de celui que j'avais avant, et même à fond, le volume n'équivaut pas à ce que j'avais à 50% auparavant, et la bidouille consistant à passer la puissance de pulseaudio à plus de 100% ne fait que produire un son dégueulasse qui crache ;
    • Quand je modifie la hauteur du volume avec Pulseaudio, il fait en fait une tambouille personnelle entre les canaux Master, PCM, etc. qu'il monte ou baisse tous à la fois dans des proportions aléatoires (manips visibles dans alsamixer) ;
    • Pulseaudio m'a foutu le canal PCM à 100%, du coup j'entends un souffle, alors qu'avant, je l'avais fixé à 80% (fixé, donc il n'en bougeait plus) et même en poussant le volume à fond, je n'avais aucun souffle ;
    • Régulièrement, au lancement de vidéos, Pulseaudio me fait planter les lecteurs (qu'il s'agisse de Kaffeine qui crashe sur un changement de vidéo, ou de Gnome-mplayer qui ne s'affiche pas et a son processus planté en fond) ;
    • Pulseaudio me bouffe souvent du CPU, et parfois même de manière inconsidérée (quand ça grimpe à plus de 10% malgré mon Core2Quad, juste pour lire une vidéo, faut pas déconner) ;
    • Il arrive fréquemment que le son avec Pulseaudio saute ou crachote, notamment en utilisant plusieurs applications activement ;
    • Il arrive fréquemment avec Pulseaudio qu'il y ait du lag dans le son ;
    • Pulseaudio m'a flingué le son dans Enemy-Territory, j'ai du passer par la bidouille du patch exploitant la couche sonore SDL ;
    • Dernièrement j'ai voulu réinstaller World of Warcraft, Pulseaudio n'est pas foutu de jouer du son dans une autre application lorsque WoW est lancé, tenter de lire un film avec Kaffeine à côté faisait que Kaffeine peinait à m'afficher 1/60 i/s – sans aucun son – avec un processus Pulseaudio qui crevait le plafond. J'ai tenté la bidouille consistant à utiliser OSS via Pulseaudio avec pads, rien à faire (système 64 bits, wine 64 bits, jeu 32 bits, etc.) ;
    • J'ai vécu un enfer.

    J'ai même tenté une réinstallation toute propre, en me disant que – peut-être – j'avais mal fait les choses, et que Pulseaudio installé par défaut fonctionnerait certainement mieux. Que nenni !

    Finalement, j'en ai eu marre. Il y a une semaine, j'ai purgé ma machine de toute trace de Pulseaudio. Depuis, je revis, c'est le rêve, un paradis ! Tout fonctionne de nouveau normalement ! Plus de souffle, plus de crachotements, plus de lag, un volume qui déchire les tympans des voisins si j'ai envie, plus de processus son qui me bouffe le CPU pour rien, j'ai retrouvé mes réglages de volume parfaits, j'ai du son dans toutes mes applications à la fois, plus aucun problème à lire mes vidéos, même quand je joue à WoW.

    Reste plus que Skype, l'application de la joint-venture Microsoft/NSA, qui ne me servait de toute façon plus qu'à faire de la messagerie instantanée (avantageusement remplacée par les SMS, via AirDroid si nécessaire), et que je vais prochainement virer.

    • [^] # Re: Ouais, ben…

      Posté par (page perso) . Évalué à 3.

      Tu utilises quelle distribution ?
      Car le but d'une distribution est de réaliser l'intégration propre des logiciels qu'elle maintient et si PulseAudio est proposé, elle doit faire en sorte que les applications qui l'utilisent fonctionnent bien avec.

      Fedora typiquement n'a plus de problèmes conséquents avec PA depuis un bon moment (après des débuts très délicats), et les autres ont pour la plupart suivis le pas.

      PulseAudio est un composant bas niveau qui a des impacts sur de nombreux logiciels et couches du système, si son intégration se fait à l'arrache c'est normal que tout plante et ce n'est pas forcément de la faute du dit programme… Le fait que certains distributions ont réussi à corriger la plupart des problèmes qui tu mentionnes tend à faire croire que le problème est plutôt dans la distribution en elle même.

      • [^] # Re: Ouais, ben…

        Posté par . Évalué à 7. Dernière modification le 19/06/13 à 10:20.

        Tu utilises quelle distribution ?

        Debian Testing.

        Car le but d'une distribution est de réaliser l'intégration propre des logiciels qu'elle maintient

        Je n'ai strictement rien à reprocher à l'intégration des logiciels par Debian, avant Pulseaudio, tout allait bien, après Pulseaudio, tout allait bien. Et depuis des années que je suis dessus, jamais un véritable problème.

        Fedora typiquement n'a plus de problèmes conséquents avec PA

        Ouais, mais Fedora non merci. Si c'est pour que Pulseaudio fonctionne mais que tout le reste ait des problèmes d'intégration… Fedora est bien trop instable à mon goût.

        Le fait que certains distributions ont réussi à corriger la plupart des problèmes qui tu mentionnes tend à faire croire que le problème est plutôt dans la distribution en elle même

        Quand un programme comme Pulseaudio entend révolutionner le son sous Linux et devenir LA référence, la moindre des choses, c'est qu'il arrive à faire mieux que la concurrence plus facilement.

        Et là, c'est l'échec complet. J'ai beau avoir une certain bagage dans l'informatique, je ne me considère plus que comme un simple utilisateur avancé, je ne veux plus m'emmerder pour avoir un système qui fonctionne et que je puisse utiliser simplement pour faire les tâches les plus basiques qui soient.

        Et de ce point de vue, Pulseaudio est une grosse merde ! Alsa ne m'a demandé strictement aucune configuration pour parfaitement fonctionner (allez, j'ai du fixer le canal PCM à 80% dans alsamixer parce que sinon le son à fond j'avais un léger souffle, trop de la bidouille c'est vrai…).

        • [^] # Re: Ouais, ben…

          Posté par (page perso) . Évalué à 2.

          Je n'ai strictement rien à reprocher à l'intégration des logiciels par Debian, avant Pulseaudio, tout allait bien, après Pulseaudio, tout allait bien.

          Je ne dis pas que Debian fait de la merde, amis elle peut sur un logiciel rater l'intégration, ce n'est pas exclu. Tu as regardé les rapports de bogues sur ta distribution pour voir si le problème était courant là bas ? Car cela serait triste que ton expérience sur le sujet n'aide pas à améliorer la situation.

          Quand un programme comme Pulseaudio entend révolutionner le son sous Linux et devenir LA référence, la moindre des choses, c'est qu'il arrive à faire mieux que la concurrence plus facilement. Là, c'est l'échec complet. J'ai beau avoir une certain bagage dans l'informatique, je ne me considère plus que comme un simple utilisateur avancé, je ne veux plus m'emmerder pour avoir un système qui fonctionne et que je puisse utiliser pour faire les tâches les plus basiques qui soient.

          T'inquiète pas, quand PulseAudio fonctionne directement (et c'est un cas assez courant maintenant), cela fonctionne très bien et c'est très puissant pour nombre de situations un peu plus complexe que d'avoir une seule paire d'enceinte. T'en fais pas qu'à l'usage il est bien intéressant et est facile. Seulement par essence le logiciel est plus complexe que Alsa et nécessite plus d'efforts d'intégration que Alsa pour que cela aboutisse proprement (et je signalerai qu'à la transition OSS-> ALSA il y a un paquet d'années, les problèmes de compatibilités ont été légions sans que ALSA soit réellement dénoncé comme le responsable).

          Et de ce point de vue, Pulseaudio est une grosse merde ! Alsa ne m'a demandé strictement aucune configuration pour parfaitement fonctionner (allez, j'ai du fixer la canal PCM à 80% dans alsamixer, trop de la bidouille c'est vrai…).

          Je n'ai pas touché à la configuration de PA depuis au moins 2 ans et cela fonctionne réellement sans problèmes. Il y a des problèmes c'est vrai mais ils sont de moins en moins rares et je t'invite à rapporter les bogues le cas échéant pour que cela ne se reproduise plus. ;)

          • [^] # Re: Ouais, ben…

            Posté par . Évalué à 3. Dernière modification le 19/06/13 à 10:43.

            Je ne dis pas que Debian fait de la merde, amis elle peut sur un logiciel rater l'intégration, ce n'est pas exclu.

            J'ai bien compris, et je ne l'exclu pas non plus, je ne tourne même pas en stable.

            Tu as regardé les rapports de bogues sur ta distribution pour voir si le problème était courant là bas ? Car cela serait triste que ton expérience sur le sujet n'aide pas à améliorer la situation.

            J'ai fouillé le net avec Google, j'ai testé diverses manips qui tenaient de la bidouille à l'aveugle, rien à faire ou situation pire (genre pousser l'amplification pulseaudio à plus de 100%).

            Honnêtement, je n'ai plus la patience ni la passion pour m'investir à ce point dans le fonctionnement de ma machine. Je veux quelque chose qui simplement fonctionne au quotidien, sans avoir à me prendre la tête régulièrement. Éditer du fichier de config à tour de bras pour avoir un semblant de son, c'est un coup à me faire manger une pomme.

            Les problèmes que m'a posé Pulseaudio sont d'autant plus rédhibitoires que sans lui tout fonctionne à merveille (et que dire de Pulseaudio qui désactive les haut-parleurs lorsqu'un casque est branché, tout ça sans offrir la possibilité de choisir simplement la sortie ?).

            cela fonctionne très bien et c'est très puissant pour nombre de situations un peu plus complexe que d'avoir une seule paire d'enceinte

            Si j'avais besoin d'un usage complexe du son, je pense que je me pencherais sur jackd. J'ai besoin d'un usage élémentaire du son, que le son fonctionne, qu'il exploite correctement mon matériel et me donne accès aux réglages matériels de ma carte son, qu'il mixe correctement le son de différentes applications simultanément, tout ça sans que je n'ai rien besoin de faire autre que bouger quelques jauges initialement, et celle du volume (Master) ensuite.

            Je n'en ai rien à cirer de pouvoir gérer le son de chaque application indépendamment via pulseaudio, chaque application qui produit du son intègre déjà une propre jauge du volume si j'ai besoin de la gérer individuellement. Et en fait, toutes sont à 100%, et je ne joue que sur le volume général. Je n'en ai rien à cirer de pouvoir envoyer du son par le réseau, sur mes hypothétiques haut-parleurs bluetooth ou sur la lune, ça ne m'intéresse pas.

            Seulement par essence le logiciel est plus complexe que Alsa

            Complexe, le mot est faible. Pulseaudio est une usine à gaz de mon point de vue, et pas une qui sent bon.

            Il y a des problèmes c'est vrai mais ils sont de moins en moins rares

            Soit ta fangue à lourché, soit ton inconscient t'a trahi. :)

            • [^] # Re: Ouais, ben…

              Posté par (page perso) . Évalué à 3.

              Honnêtement, je n'ai plus la patience ni la passion pour m'investir à ce point dans le fonctionnement de ma machine. Je veux quelque chose qui simplement fonctionne au quotidien, sans avoir à me prendre la tête régulièrement. Éditer du fichier de config à tour de bras pour avoir un semblant de son, c'est un coup à me faire manger une pomme.

              C'est bizarre, tu dis toi même que tu utilises une version non stable et tu te plains de ce genre de problèmes qui peuvent avoir pour origine ton choix de la version de la distribution. Quelqu'un qui utilise sciemment Debian-testing ne devrait pas au minima s'attendre à bidouiller à l'occasion et rapporter des bogues éventuels ?

              Les problèmes que m'a posé Pulseaudio sont d'autant plus rédhibitoires que sans lui tout fonctionne à merveille (et que dire de Pulseaudio qui désactive les haut-parleurs lorsqu'un casque est branché, tout ça sans offrir la possibilité de choisir simplement la sortie ?).

              Ses utilitaires permettent d'avoir le comportement que tu veux, je le sais car je le fais.
              Son comportement par défaut reste logique (c'est rare de brancher un casque pour écouter ses hauts parleurs).

              Si j'avais besoin d'un usage complexe du son, je pense que je me pencherais sur jackd. J'ai besoin d'un usage élémentaire du son, que le son fonctionne, qu'il exploite correctement mon matériel et me donne accès aux réglages matériels de ma carte son, qu'il mixe correctement le son de différentes applications simultanément, tout ça sans que je n'ai rien besoin de faire autre que bouger quelques jauges initialement, et celle du volume (Master) ensuite.

              Il le fait très bien chez de nombreuses personnes.
              Mine de rien, pourquoi ne pas en discuter sur le système de rapport de bogues de Debian ? Soit la distribution est fautive et dans ce cas ils vont bosser pour mieux l'intégrer, soit c'est un bogue de PulseAudio et ils le corrigeront. Dans les deux cas la communauté s'en sortirait avec un meilleur confort d'utilisation…

              Je n'en ai rien à cirer de pouvoir gérer le son de chaque application indépendamment via pulseaudio, chaque application qui produit du son intègre déjà une propre jauge du volume si j'ai besoin de la gérer individuellement. Et en fait, toutes sont à 100%, et je ne joue que sur le volume général. Je n'en ai rien à cirer de pouvoir envoyer du son par le réseau, sur mes hypothétiques haut-parleurs bluetooth ou sur la lune, ça ne m'intéresse pas.

              Je vais faire une critique qui n'est pas personnellement contre toi mais que je retrouve régulièrement. Ce n'est pas parce que tout le monde n'a pas besoin de toutes les options du logiciel qu'il faut virer ces dites fonctions. PA a de nombreuses options et possibilités qui sont très appréciées par ceux qui en ont besoin ou l'usage. Personnellement j'ai le même usage que toi mais je pense important que les autres aient la solution générique à leur besoin qui est une surcouche du notre.
              Donc non, tu n'as pas besoin de PA pour ton cas, cela ne remet pas en cause son utilité en général seulement il faut travailler pour qu'il s'adapte à chaque situation.

              Complexe, le mot est faible. Pulseaudio est une usine à gaz de mon point de vue, et pas une qui sent bon.

              Complexe ne signifie pas usine à gaz, ses fonctionnalités se limite au cas d'usage pour lequel il a été conçu et ne va pas au delà (ce n'est pas comme X11). Seulement PA est au centre de multiples interactions entre de nombreux composants logiciels ce qui implique forcément une intégration délicate et une certaine complexité du système.

              Soit ta fangue à lourché, soit ton inconscient t'a trahi. :)

              Tu sais très bien que j'ai voulu dire que les problèmes sont de plus en plus rares, je me base non seulement sur mon expérience et celle de mon entourage mais aussi des endroits que je fréquente (le bugzilla de Fedora et les forums de la distribution posent de moins en moins de requêtes au sujet de PA ce qui est un bon indicateur de transparence et de bon fonctionnement).

              • [^] # Re: Ouais, ben…

                Posté par . Évalué à 2. Dernière modification le 19/06/13 à 11:18.

                C'est bizarre, tu dis toi même que tu utilises une version non stable et tu te plains de ce genre de problèmes qui peuvent avoir pour origine ton choix de la version de la distribution. Quelqu'un qui utilise sciemment Debian-testing ne devrait pas au minima s'attendre à bidouiller à l'occasion et rapporter des bogues éventuels ?

                Avant d'être en testing, je suis longtemps resté en stable, et j'y avais déjà essayé Pulseaudio avant de le virer. Ce n'est que Skype 4.x qui m'a forcé à passer de nouveau à Pulseaudio il y a quelques mois.

                Testing est parfaitement adaptée à ce que j'attends d'une distribution : un système qui se met à jour tout seul et avance lentement mais sûrement, avec des logiciels décemment à jour sans avoir à m'investir dans le déboguage, et qui très occasionnellement va peut-être m'occasionner un problème mineur qui sera très rapidement corrigé.

                Son comportement par défaut reste logique (c'est rare de brancher un casque pour écouter ses hauts parleurs).

                Ce n'est pas rare d'avoir une tour sous le bureau, et même s'il y a une prise casque en façade, c'est chiant d'avoir à se pencher pour débrancher le casque afin d'avoir du son sur les haut-parleurs. Avec Alsa, j'ai les deux branchés, quand je veux écouter avec mon casque je coupe les haut-parleurs, sinon je pose le casque sur le bureau et j'allume les haut-parleurs.

                C'est donc une attente illogique que dans le cas d'un logiciel « complexe » comme Pulseaudio avoir la possibilité de choisir simplement la sortie son souhaitée (hp/casque/tout/etc.) en fonction du besoin ? Une simple liste déroulante dans les options c'est trop compliqué pour le complexe Pulseaudio ?

                C'est une attente illogique qu'avant de vouloir balancer le son sur ses haut-parleurs bluetooth, on veuille avant tout pouvoir régler les volumes de son système surround et de son caisson de basses ?

                Mine de rien, pourquoi ne pas en discuter sur le système de rapport de bogues de Debian ?

                Parce que je n'ai ni la patience, ni la passion. C'est comme pour tout, ce genre de choses s'érodent. Peut-être l'âge et les changements de priorité qui veulent ça.

                Ce n'est pas parce que tout le monde n'a pas besoin de toutes les options du logiciel qu'il faut virer ces dites fonctions.

                Ce n'est pas parce que un pouillardième des utilisateurs se branle la nouille en écoutant sa musique qui crachote et lag sur ses haut-parleurs bluetooth qu'il faut pour autant imposer un fonctionnement de base dégradé à l'immense majorité des autres. La solution précédente fonctionnait bien mieux. C'est tout ce que je constate et qui m'importe en tant que simple utilisateur final.

                le bugzilla de Fedora et les forums de la distribution posent de moins en moins de requêtes au sujet de PA ce qui est un bon indicateur de transparence et de bon fonctionnement

                Ou peut-être est-ce que de guerre lasse, la majorité a fini par faire comme moi, et a viré Pulseaudio ? :p

                • [^] # Re: Ouais, ben…

                  Posté par (page perso) . Évalué à 4.

                  C'est donc une attente illogique que dans le cas d'un logiciel « complexe » comme Pulseaudio avoir la possibilité de choisir simplement la sortie son souhaitée (hp/casque/tout/etc.) en fonction du besoin ? Une simple liste déroulante dans les options c'est trop compliqué pour le complexe Pulseaudio ?

                  C'est une attente illogique qu'avant de vouloir balancer le son sur ses haut-parleurs bluetooth, on veuille avant tout pouvoir régler les volumes de son système surround et de son caisson de basses ?

                  Mais l'utilitaire de PA permet de faire ça justement, je ne te parlais que du comportement par défaut…

                  • [^] # Re: Ouais, ben…

                    Posté par . Évalué à 5.

                    Tu parles de pavucontrol ?

                    Si c'est le cas, alors non. Il m'affiche bien quelques infos (genre je ne peux régler que les canaux droit et gauche, adieu le surround et les basses, je n'ai droit qu'à du audio interne stéréo analogique (et ce même sans le casque) et pour choix de sortie même s'il me liste bien « Sortie analogique » et « Casques analogiques », quand le casque est branché, rien ne sort sur les haut-parleurs, quelle que soit ma sélection.

                    Capture de l'horreur visuelle pavucontrol

          • [^] # Re: Ouais, ben…

            Posté par . Évalué à 3. Dernière modification le 19/06/13 à 14:02.

            T'inquiète pas, quand PulseAudio fonctionne directement (et c'est un cas assez courant maintenant), cela fonctionne très bien et c'est très puissant pour nombre de situations un peu plus complexe que d'avoir une seule paire d'enceinte. T'en fais pas qu'à l'usage il est bien intéressant et est facile. Seulement par essence le logiciel est plus complexe que Alsa et nécessite plus d'efforts d'intégration que Alsa pour que cela aboutisse proprement (et je signalerai qu'à la transition OSS-> ALSA il y a un paquet d'années, les problèmes de compatibilités ont été légions sans que ALSA soit réellement dénoncé comme le responsable).

            PA se place entre ALSA et les applications. Et dans la majorité des cas, aujourd'hui, cela ne sert à rien puisqu'ALSA fait du mixage logciel. Donc sauf cas exotique, PA est totalement dispensable alors vouloir en faire le serveur de son de référence sous Linux…

            • [^] # Re: Ouais, ben…

              Posté par . Évalué à 3.

              Et dans la majorité des cas, aujourd'hui, cela ne sert à rien puisqu'ALSA fait du mixage logciel

              Effectivement, en général, ce n'est pas pour ça qu'on utilise PulseAudio. Sans aller jusqu'aux cas d'utilisation impliquant la diffusion du son par le réseau, voici quelques intérêts sur une utilisation de type desktop "grand public" :
              - Éviter d'avoir le volume sonore globale qui change constamment. Je tiens à mes tympans, surtout quand j'ai des écouteurs dans les oreilles. Alors quand j'ai de la musique qui tourne avec le volume sonore à 35%, et que l'application X s'initialise et en profite pour mettre le volume à 100% et me péter les tympans, ça fait toujours plaisir (ou pas).

              Et dans l'interface graphique pavucontrol plus spécifiquement :
              - Pouvoir mettre une application en particulier à 100% (voire jusqu'à 150 % quand la piste sonore est basse) sans que tout le monde se retrouve à ce même niveau.
              - Que ces états/niveaux sonores soient sauvegardés et restaurés automatiquement pour chaque application.
              - Avoir un volume sonore différent pour les haut-parleurs, les écouteurs, le micro, …
              - Configurer le volume en entrée pour les applications enregistrant du son (et là aussi c'est sauvegardé automatiquement).

              Bref, tout ce que permet le mixer logiciel de Windows depuis Windows Vista (il y a pas que des mauvaises idées chez la concurrence).

              "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: Ouais, ben…

                Posté par . Évalué à 1. Dernière modification le 19/06/13 à 16:25.

                Je ne comprends pas trop, tu as une telle différence de niveau sonore entre tes applications, et ce de manière aussi aléatoire, que tu as davantage besoin de pulseaudio que des jauge de volume de chacune des applications en question ?

                Personnellement, si j'avais besoin de retoucher les volumes, je le ferais dans kmix pour le micro ou le casque (qui ont des canaux spécifiques), et dans chacune des applications que j'utilise si besoin était, genre kaffeine, vlc, youtube, amarok, etc. qui conserve leur réglage entre chaque démarrage. Qu'apporte Pulseaudio qui n'existe pas déjà à ce niveau ?

                Maintenant, pour être honnête, j'avoue que j'ai rarement besoin de retoucher le volume, j'ai l'impression que toutes mes applications sont grosso-modo au même niveau sonore. À moins que ce ne soit ma distribution qui intègre un système de normalisation audio ?

                Toujours est-il que toutes mes applis ont le volume calé à 100%, j'ai réglé le micro pile poil pour que mon correspondant ait un son parfait, mon casque pour ne pas qu'il me pète les oreilles, et le reste, ben j'ai le master à 75%, et le bouton du volume de mes haut-parleurs à portée de main, ou mieux, les 3 touches de réglage (volume down, volume up, mute) sur mon clavier. Les rares fois où cela est nécessaire, en moins de deux le son est au niveau qui me convient.

                Bref, à part une surcouche inutile et coûteuse en ressources, en plus d'être particulièrement inefficace, je ne vois pas ce qu'apporte Pulseaudio, clairement.

                • [^] # Re: Ouais, ben…

                  Posté par . Évalué à 4. Dernière modification le 19/06/13 à 16:42.

                  Je ne comprends pas trop, tu as une telle différence de niveau sonore entre tes applications, et ce de manière aussi aléatoire, que tu as davantage besoin de pulseaudio que des jauge de volume de chacune des applications en question ?

                  PulseAudio m'évite d'avoir cet aspect aléatoire, justement.
                  Avec ALSA seul, tout le monde modifie constamment le volume globale, et tout le monde se réfère au volume globale.
                  A moins de bloquer le volume globale (ça semble possible avec alsamixer - ce qui n'est pas une solution très pratique non plus), je me fais régulièrement zigouiller les esgourdes.

                  Avec PA, c'est l'utilisateur qui maitrise le volume globale, et au besoin celui de chaque application, constamment et automatiquement.

                  Toujours est-il que toutes mes applis ont le volume calé à 100%, j'ai réglé le micro pile poil pour que mon correspondant ait un son parfait, mon casque pour ne pas qu'il me pète les oreilles, et le reste, ben j'ai le master à 75%, et le bouton du volume (physique) à portée de main, et 3 touches de réglage (volume down, volume up, mute) sur mon clavier. Les rares fois où cela est nécessaire, en moins de deux le son est au niveau qui me convient.

                  Je n'ai pas de bidule pour gérer le volume sur mes écouteurs, ni sur mes hauts-parleurs. Et avoir le volume calé à 100% n'est pas une solution, du coup (comme par exemple certains musiques dans Audacious qui ont un volume plus fort que d'autres)

                  Bref, à part une surcouche inutile et coûteuse en ressources, en plus d'être particulièrement inefficace, je ne vois pas ce qu'apporte Pulseaudio, clairement.

                  Pour moi c'est une surcouche légère, très pratique. Je maîtrise enfin le volume sonore globalement, et par applications, sans y revenir toutes les 5 minutes. Et j'ai enfin fini d'avoir un mixing audio des années 1990, cassé par dessus le marché.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Ouais, ben…

                    Posté par . Évalué à 1. Dernière modification le 19/06/13 à 17:09.

                    Avec ALSA seul, tout le monde modifie constamment le volume globale, et tout le monde se réfère au volume globale.

                    Je crois comprendre le problème que tu décris, et je ne le rencontre pas.

                    Par exemple, je viens de vérifier, si je touche à la jauge de volume de Kaffeine, aucune des jauges de kmix et encore moins celle du volume global (Master dans mon cas) n'est affectée. C'est uniquement le volume sonore de Kaffeine qui est changé. De même pour Clémentine, que je viens de vérifier, ainsi que Youtube (là rien d'étonnant). Pareil pour Amarok. Idem pour VLC.

                    Ton problème ne serait-il pas lié à une histoire d'option de mixer matériel/mixer logiciel que certaines applications proposent dans leurs préférences ? (genre surtout les applications Gnome, tel Gnome-Mplayer par exemple) L'un des choix reposant – je pense – sur le volume global, et l'autre gérant le volume de manière interne à l'application (pure hypothèse de ma part).

                    Avec PA, c'est l'utilisateur qui maitrise le volume globale, et au besoin celui de chaque application, constamment et automatiquement.

                    Justement non, je n'ai pas envie de réinstaller PA pour le confirmer, mais je crois bien me souvenir avoir été emmerdé, lorsque Pulseaudio était installé, par le fait que modifier le son dans Amarok/Kaffeine/etc. affectait directement mon canal Master. Mais bon, mes bidouillages avec Pulseaudio remontent à il y a quelques mois, et je ne me rappelle plus exactement des conditions dans lesquelles j'ai fait ces observations (et comme je disais, la flemme de réinstaller pour vérifier).

                    Je n'ai pas de bidule pour gérer le volume sur mes écouteurs, ni sur mes hauts-parleurs. Et avoir le volume calé à 100% n'est pas une solution, du coup

                    Je ne sais pas quel environnement de bureau tu utilises, mais si tu étais sous KDE, je te proposerais de faire un tour dans Configuration système -> Raccourcis et gestes -> Raccourcis globaux de clavier -> Kmix et là tu affectes une combinaison de touches pour Augmenter le volume (genre Méta + +), Diminuer le volume (genre Méta + -) et Muet (genre Méta + /), et à toi les fonctionnalités qui te manquent d'un clavier multimédia ou d'un potentiomètre ! :)

                    Pour moi c'est une surcouche légère, très pratique. Je maîtrise enfin le volume sonore globalement, et par applications, sans y revenir toutes les 5 minutes.

                    De même sans la surcouche PA. :)

                    • [^] # Re: Ouais, ben…

                      Posté par . Évalué à 1. Dernière modification le 19/06/13 à 17:34.

                      Je ne sais pas quel environnement de bureau tu utilises, mais si tu étais sous KDE, je te proposerais de faire un tour dans Configuration système -> Raccourcis et gestes -> Raccourcis globaux de clavier -> Kmix et là tu affectes une combinaison de touches pour Augmenter le volume (genre Méta + +), Diminuer le volume (genre Méta + -) et Muet (genre Méta + /), et à toi les fonctionnalités qui te manquent d'un clavier multimédia ou d'un potentiomètre ! :)

                      J'ai déjà xfce4-volumed (mixer gstreamer, qui appelle celui de ALSA), remplacé par xfce4-volumed-pulse (qui provient de Xubuntu) pour gérer le mute/unmute globale et le volume globale vite fait avec les touches [Fn]-[F10]/[F11]/F[12]. ;-)
                      Mais ça ne fait que utiliser ALSA ou PA, et non pas rajouter un contrôle de volume "analogique" (dans le même genre je n'ai pas de quoi éteindre mes hauts parleurs, c'est un ordi portable : donc pas de mute à moins de passer par un mixer logiciel ou d'éteindre l'ordi, ou de blacklister le module snd_hda_intel. C'est un peu trop permanent, tout ça…)

                      Par exemple, je viens de vérifier, si je touche à la jauge de volume de Kaffeine, aucune des jauges de kmix et encore moins celle du volume global (Master dans mon cas) n'est affectée. C'est uniquement le volume sonore de Kaffeine qui est changé. De même pour Clémentine, que je viens de vérifier, ainsi que Youtube (là rien d'étonnant). Pareil pour Amarok. Idem pour VLC.

                      Intéressant. Quelle est ta distribution ?
                      Arch est connue pour être proche de l'upstream (on évite au maximum les patchs maison).

                      Ton problème ne serait-il pas lié à une histoire d'option de mixer matériel/mixer logiciel que certaines applications proposent dans leurs préférences ? (genre surtout les applications Gnome, tel Gnome-Mplayer par exemple) L'un des choix reposant – je pense – sur le volume global, et l'autre gérant le volume de manière interne à l'application (pure hypothèse de ma part).

                      J'en sais rien. J'ai bien pourtant un mixing logiciel ou matériel quelque part, vu que sans rien faire, et avec ALSA seul, j'ai le son de plusieurs applications en même temps sans problème.

                      En tout cas c'était bel et bien toutes les applications : SMPlayer, Audacious, Flash, Parole, DOSBox, …

                      Seul Audacious (un clone de XMMS) me permet d'utiliser un mixing logciel propre à Audacious. Cette option est déconseillée (et je crois comprendre pourquoi, vu qu'elle introduit de la latence : le nouveau volume met quelque temps à être effectif, et le contrôle du volume d'Audacious répond moins vite).
                      Avec ALSA seul, ça évite de modifier le volume globale quand je modifie le volume d'Audacious. C'est cool, mais c'est pour une seule application.
                      Avec PA, ça sert juste à ce que la modification du volume d'Audacious ne modifie pas le volume de l'application dans PA (le volume d'Audacious est bien modifié, c'est juste qu'Audacious n"utilise plus PA pour son volume sonore).

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Ouais, ben…

                      Posté par (page perso) . Évalué à 1.

                      Justement non, je n'ai pas envie de réinstaller PA pour le confirmer, mais je crois bien me souvenir avoir été emmerdé, lorsque Pulseaudio était installé, par le fait que modifier le son dans Amarok/Kaffeine/etc. affectait directement mon canal Master.

                      https://wiki.archlinux.org/index.php/Pulseaudio#Clients_alter_master_output_volume_.28aka_volume_jumps_to_100.25_after_running_appliaction.29

                      Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Ouais, ben…

                Posté par . Évalué à 5.

                J'ajouterais trois autres avantages pour Pulseaudio :
                – pouvoir gérer le volume de toutes les applications en un seul endroit, dans kmix par ex.
                – la suppression de l'echo, indispensable pour les applications de VoIP
                – l'aspect réseau, pour envoyer le son sur une autre machine. Ça nécessite un peu de manip, mais c'est quand même vachement pratique quand tu as plusieurs ordinateurs dans une maison.

                Sur le papier, le module-role-ducking à l'air très intéressant. On est effectivement à des années lumières de la gestion du son par ALSA.

                • [^] # Re: Ouais, ben…

                  Posté par . Évalué à 1.

                  – pouvoir gérer le volume de toutes les applications en un seul endroit, dans kmix par ex.

                  Ca marche aussi dans kmix avec Alsa seul.

                  Sur le papier, le module-role-ducking à l'air très intéressant. On est effectivement à des années lumières de la gestion du son par ALSA.

                  Ben disons que en dehors de prendre du CPU et de faire saccader la lecture video quand je le connecte au bluetooth (alors que avec Alsa seul il n'y a pas de probleme) c'est genial comme truc mais pas pour MON utilisation basic…

          • [^] # Re: Ouais, ben…

            Posté par . Évalué à 2.

            Je ne dis pas que Debian fait de la merde, amis elle peut sur un logiciel rater l'intégration, ce n'est pas exclu.

            Je n'ai jamais compris cette aspect "d'intégration" d'un serveur.

            L'intégration d'une gui pour qu'elle offre un look& feel et une ergonomie identique au reste du système je comprend.

            L'intégration d'un soft dans une infrastrucure (réseau, autres logiciels, …) aussi je comprends

            Mais là on parle d'un soft qui
            -> en entrée a son propre connecteur et protocoel
            -> en sortie utilise le noyau linux et plus précisément la couche alsa, qui est standard

            Il peut y avoir quelle intégration avec ça ?

            • [^] # Re: Ouais, ben…

              Posté par (page perso) . Évalué à 3.

              Il faut s'assurer que tous les composants qui sont liés à PulseAudio de près et de loin ne sont pas impactés par sa présence. Mais aussi il faut que toutes ces applications exploitent les possibilités de PA au mieux.

              Tu n'es pas naïf au point de croire que parce qu'il y a des I/O standards pour les dialogues entre certains composants du système qu'aucun effet de bords est possible ? Un logiciel tel que PA demande beaucoup d'effort d'intégration car de nombreuses applications y sont touchées (celles susceptibles de fournir du son), dans une couche intermédiaire et qui doit dialoguer avec de nombreux composants distincts pour réaliser sa tâche.

              Ce n'est vraiment pas si simple et une distribution doit gérer cet aspect.

              • [^] # Re: Ouais, ben…

                Posté par . Évalué à 4.

                Tu n'es pas naïf au point de croire que parce qu'il y a des I/O standards pour les dialogues entre certains composants du système qu'aucun effet de bords est possible ?

                Le respect des standard et des protocoles sert à ça.

                Je suis "naif" car quand un soft est bien codé, il n'y a presque pas d'effet de bord.

                Je n'ai encore jamais eu à "intégrer" un apache avec un firefox.
                Et si j'ai un quelconque problème, je regarde qui ne respecte pas le standard ietf.

                C'est quand même marrant où 99% des softs "daemon" fonctionnent sans avoir besoin d'intégration poussé (le chemin des fichiers de conf, et les scripts d'init et c'est à peu près tout), mais que pour 1%, sans raison, l'intégration ressemble à du voudou (le soft fonctionne mais prend bizarrement 15% du cpu sans raison à un moment X, …)

                Pour prendre une comparaison automobile : quand je met un sac dans mon coffre, je ne m'attend pas à devoir changer de bouchon de radiateur.

                Un logiciel tel que PA demande beaucoup d'effort d'intégration car de nombreuses applications y sont touchées (celles susceptibles de fournir du son

                euh faut pas déconner, elles communiquent avec PA avec le "langage" propre à PA (ie son api)
                Si il n'est pas capable de comprendre son propre "langage" sans avoir besoin qu'on le bichonne, c'est qu'elle est mal codé, point.

    • [^] # Re: Ouais, ben…

      Posté par . Évalué à 2.

      c'est super con quand l'application qu'on utilise arrête de faire du son/se met en pause lorsqu'elle perd le focus, du coup sa jauge disparaît lorsqu'on switch sur le mixeur de Kmix

      Ahahah énorme ! C'est ptêtre bien un problème d'intégration. Cela dit c'est curieux qu'ils ne proposent pas d'autres connecteurs que PA.

      Je suis tombé sur ce bout de FAQ qui indique comment utiliser ALSA si ça peut aider.

    • [^] # Re: Ouais, ben…

      Posté par . Évalué à 2.

      Bonjour,
      si audio intel, alors
      SND_HDA_PREALLOC
      de rien.

  • # c>n|k

    Posté par (page perso) . Évalué à 3.

    Rappelons que PulseAudio, devenu le serveur de son de référence
    pour les systèmes GNU/Linux

    C'est malin, tu me dois un clavier !

    • [^] # Re: c>n|k

      Posté par . Évalué à 1.

      Ce n'est pas bayo qui a écrit ce passage à troll. Je connais le coupable mais je ne dénonce jamais.

      • [^] # Re: c>n|k

        Posté par (page perso) . Évalué à 2.

        Et tu fais bien, l'auteur pourrait en dénoncer d'autres à son tour ;)

        • [^] # Re: c>n|k

          Posté par . Évalué à 1.

          J'avais bien compris ma condition de fusible… il est de combien le turnover de pseudo chez linuxfr ?

          • [^] # Re: c>n|k

            Posté par (page perso) . Évalué à 2.

            La prochaine fois on signera "Lennart" ces dépêches sur PulseAudio et Systemd

  • # Pour y voir plus clair

    Posté par (page perso) . Évalué à 2.

    J'ai trouvé cet article avec cette illustration :

    Pile son Linux

    En fait faudrait lancer sur Wikipédia une page Pile son Linux comme celle de la Pile graphique Linux

  • # JACK

    Posté par . Évalué à 2.

    Pourquoi ne pas utiliser JACK (avec ALSA comme backend) par défaut sous GNU/Linux. La plupart des utilisateurs n'ont pas besoin des fonctionnalités de routage entre applications que propose JACK mais partant du principe que « qui peut le plus peut le moins » pourquoi pas ?

    Est-ce que c'est parce que trop peu d'applications supportent JACK ? Est-ce parce qu'il « bouge » encore trop ?

    • [^] # Re: JACK

      Posté par (page perso) . Évalué à 2.

      Parce qu'il pompe toute les ressources pour faire du temps réel. Et depuis le temps que Jack existe on a eu le temps de réfléchir à la mise en place de Jack par défaut.

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: JACK

        Posté par . Évalué à 2.

        JACK peut fonctionner en temps réel mais ce n'est pas obligatoire.

        Et depuis le temps que Jack existe on a eu le temps de réfléchir à la mise en place de Jack par défaut.

        Bah oui, d'où ma question : Pourquoi ? Comme je dis, le coup du temps réel ce n'est pas une raison.

    • [^] # Re: JACK

      Posté par . Évalué à 4.

      De ce que j'ai lu, je n'ai jamais bidouillé à aussi bas niveau.

      JACK est fait pour de la faible latence ce qui est plus gourmand en CPU. Paradoxalement l'API est bien plus simple que PulseAudio.

      Normalement PulseAudio a été architecturé pour réduire son emprunte sur le CPU, c'est ce qu'on attend d'une utilisation grand public : il va adapter les latences à juste ce qu'il faut ; il ne va se réveiller que lorsque c'est nécessaire ; il peut utiliser des algo mois coûteux.

      Pour les API, je pense qu'elles sont toutes deux extrêmement stable. Il y a tellement de trucs qui reposent sur les deux que j'espère pour eux…

  • # Page "Pile audio Linux" sur Wikipédia

    Posté par (page perso) . Évalué à 3.

    Allez, ne soyez pas timides, il serait dommage de laisser tout ce savoir inexploité, aidez à compléter la page Pile audio Linux de Wikipédia !

  • # ca pulse in the place ?

    Posté par . Évalué à 3.

    hello :)
    du coup je me demandai :
    quelles sont les distros qui n'utilisent pas encore pulse audio ?
    les polémiques sur Pottering c'est fini ? C'était de la résistance au changement ?

  • # Finalement, tout baigne avec la pile audio de Linux ?

    Posté par (page perso) . Évalué à 3.

    Je vois PulseAudio évoluer, certains composants devenir obsolètes sous Linux (ESD, OSS, Xine, aRts, Phonon).

    Au final la pile audio n'est plus si compliquée si je comprends bien, avec essentiellement :

    • Logiciel applicatif (lecteur audio ou vidéo, etc.)
    • Bibliothèque logicielle : GStreamer ; SDL
    • Optionnel : Serveur de sons : PulseAudio ; JACK
    • Sous-système son (modules ou pilotes du noyau Linux) : ALSA ; FFADO

    En plus je comprends que PulseAudio est assez polyvalent (notamment sur les latences)

    Du coup, on est plus à la ramasse par rapport à Windows/MacOS ?

  • # comparaison à sndio (OpenBSD)

    Posté par (page perso) . Évalué à 1.

    Est-ce que quelqu'un est capable de comparer jack et pulseaudio au système de son d'OpenBSD (sndio) ? Par curiosité, car sndio a l'air pas mal dans le genre, sûrement beaucoup plus simple, possiblement plus gourmand en ressources.

    http://www.sndio.org/

    • [^] # Re: comparaison à sndio (OpenBSD)

      Posté par (page perso) . Évalué à 1.

      Ah ouais, ça peut être intéressant… Mais bon le premier lien pointe vers http://www.opebsd.org/. Ça la fout mal quand même. (j’ai envoyé un courriel à l’auteur)

      Mais pourquoi faire un nouveau système de son? Sans doute parce que malgré ses qualités OSS est trop limité au niveau des fonctionnalités (ce pourquoi on pousse ALSA et PulseAudio sous GNU/Linux).

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: comparaison à sndio (OpenBSD)

        Posté par . Évalué à 2.

        Mais pourquoi faire un nouveau système de son? Sans doute parce que malgré ses qualités OSS est trop limité au niveau des fonctionnalités (ce pourquoi on pousse ALSA et PulseAudio sous GNU/Linux).

        Euh… Alsa a remplace OSS dans le kernel a cause d'une histoire de licence.

        • [^] # Re: comparaison à sndio (OpenBSD)

          Posté par (page perso) . Évalué à 1.

          J’ai pas dit le contraire, mais actuellement pourquoi on n’a pas OSS dans le noyau Linux vu que la version 4 est libre?

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: comparaison à sndio (OpenBSD)

            Posté par . Évalué à 2.

            Ben, est-ce que les développeurs d'OSS4 veulent qu'il soit intégré au noyau?

            • [^] # Re: comparaison à sndio (OpenBSD)

              Posté par (page perso) . Évalué à 0.

              Est-ce que les utilisateurs de Linux veulent que ça soit intégré à Linux?

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: comparaison à sndio (OpenBSD)

                Posté par . Évalué à 2.

                On s'en fout, si les développeurs ne veulent pas, ça ne se fera pas.

                • [^] # Re: comparaison à sndio (OpenBSD)

                  Posté par (page perso) . Évalué à 1.

                  Ce que je veux c’est que si OSSv4 était si génial que ça il serait déjà par défaut dans Linux nan? Je dis pas que c’est naze, mais comme PulseAudio ça correspond à des usages plus modernes de l’audio, même si ça s’accompagne d’une plus forte latence et de pile audio plus lourde.

                  Écrit en Bépo selon l’orthographe de 1990

Suivre le flux des commentaires

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