Journal PulseAudio

Posté par  .
Étiquettes :
0
1
nov.
2007
Moment pub.

PulseAudio (anciennement PolypAudio) devrait passer sous le feux des projecteurs dans quelques jours avec la sortie de F8 qui l'intègre et l'active par défaut.

Certains pensent que PulseAudio est un serveur de son comme un autre et ne vaut pas dmix d'alsa :-)

Une démo (sans son :-( mais l'intérêt de PulseAudio saute au yeux :-)):
http://dev.gentooexperimental.org/~flameeyes/mezcalero-pulse(...)

Une interview du principal développeur (Lennart Poettering, un européen :-)) :
http://fedoraproject.org/wiki/Interviews/LennartPoettering

Le site PulseAudio :
http://pulseaudio.org/

On a enfin un truc qui roxe...

NB :
- C'est cross-plateforme (marche aussi sous Windows)
- N'est pas encore à la version 1.0.

  • # OGM

    Posté par  . Évalué à 3.

    Lé vidéo est illisible sur mon VLC, tout est décalée, et en travers.
    Encore un coup des ogms…

    Envoyé depuis mon lapin.

    • [^] # Re: OGM

      Posté par  . Évalué à 1.

      Ça marche chez moi avec mplayer et totem (version 2.16).

    • [^] # Re: OGM

      Posté par  . Évalué à 2.

      Chez moi la vidéo se lit très bien, mais j'ai quand même l'impression qu'il tape vachement moins vite que je lis ...

      Qui a dit que la technique faisait gagner du temps ?

      • [^] # Re: OGM

        Posté par  . Évalué à 4.

        Moi, je l'ai lu dans MPlayer en vitesse ×2, pour que ce soit supportable. Où comment résoudre les problèmes de la technique par la technique.

  • # On est presque vendredi

    Posté par  . Évalué à 1.

    Les diapos d'une présentation de pulseaudio :
    http://0pointer.de/public/pulseaudio-presentation-lca2007.pd(...)
    What can we do?
    [...]
    - We should stop abstracting abstracted abstraction layers

    Tout allusion à un "truc" ne serait pas un hazard.

    C'est le diaporama de cette présentation (voir les deux (vidéo et diaporama) en même temps est cool) :
    http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talk(...)

    • [^] # Re: On est presque vendredi

      Posté par  . Évalué à 7.

      Tout allusion à un "truc" ne serait pas un hazard.
      Tu ciblerais pas phonon par hasard ?
      Je vois nulle part sur pulseaudio de garantie d'API et d'ABI stable pour au moins 4 ans, voire plus. Donc phonon reste justifié.

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à -4.

        > Tu ciblerais pas phonon par hasard ?

        Tu m'as mal lu, ce n'est pas par hasard.

        > Je vois nulle part sur pulseaudio de garantie d'API et d'ABI stable pour au moins 4 ans, voire plus.

        Car KDE a la garantie pour tout ce qu'utilise KDE ?
        Qt4 (la plus grosse brique), tu as une garantie ?
        OK, on vient d'apprendre que KDE n'utilisera pas PulseAudio avant 4 ou 5 ans...
        PulseAudio va être intégré à Gnome dans les mois (voire semaines) à venir.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 10.

          Car KDE a la garantie pour tout ce qu'utilise KDE ?
          C'est pas le même problème. Une appli KDE n'appelle pas directement libpng par exemple. Ça n'aurait aucun sens. Par contre pour une plateforme multimedia...

          Qt4 (la plus grosse brique), tu as une garantie ?
          Oui. Pas de changement qui casse la compatibilité source ou binaire avant Qt5. Et donc avant KDE5.

          OK, on vient d'apprendre que KDE n'utilisera pas PulseAudio avant 4 ou 5 ans...
          Ben ça l'utilisera via un plugin phonon si ça en vaut la peine (sinon on passe par libxine pour pas se faire chier)


          Au passage, phonon ça gère aussi la vidéo...

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à -5.

            > Ben ça l'utilisera via un plugin phonon si ça en vaut la peine (sinon on passe par libxine pour pas se faire chier)

            Ça a l'air cool.

            > Au passage, phonon ça gère aussi la vidéo...

            Super.


            Inutile de discuter. On verra dans quelques mois/années. Il y aura peu d'applis KDE qui utiliseront Phonon. Mais bon, c'est super Phonon.

            • [^] # Re: On est presque vendredi

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

              > Il y aura peu d'applis KDE qui utiliseront Phonon.

              Soit sympa, la prochaine fois attends au moins encore quelques heures avant d'écrire des choses pareilles.

            • [^] # Re: On est presque vendredi

              Posté par  . Évalué à 10.

              Encore ce troll sur Phonon? C'est lourd.

              Pour ceux qui n'auraient pas encore compris (et apparemment tu en fais partie), Phonon n'est pas un concurrent à Gstreamer, PulseAudio ou je ne sais quoi.

              C'est juste une interface d'abstraction. Et je ne vois vraiment pas en quoi ça te dérange.

              Quelques rappels:
              - Les gars de KDE ont pour commencer eu une expérience malheureuse avec Artsd, qui à l'époque où ils l'ont retenu semblait techniquement une très bonne solution... Comme on dit, chat échaudé craint l'eau froide. Par exemple actuellement Gstreamer semble une bonne solution mais n'est pas la seule.

              - Ensuite la plupart des besoins des applis question audio ou vidéo sont le plus souvent basiques. Donc il faut une API simple. Si une appli a des besoins plus poussés rien ne l'empêche de taper directement Gstreamer ou autre. Mais au moins le programmeur qui veut juste jouer un son et n'en a rien à foutre que ce soit Gstreamer, libXine, ... qui soit derrière, il a pas à se casser la tête.

              - KDE4 a pour objectif d'être portable, notamment sous Windows. La solution logique est d'utiliser le système sonore en place (directsound?). Une lib d'abstraction simplifie énormément le travail.

              - Rien ne garantie que l'API de GStreamer sera stable sur toute la vie de KDE4. (Déjà que les dev d'Amarok avaient parfois du mal à suivre pour le backend Gstreamer). En cas de changement, la seule adaptation à faire sera au niveau de Phonon et pas au niveau de chaque appli.

              - Phonon pourra être configuré pour utiliser Gstreamer qui lui même pourra utiliser PulseAudio.

              Franchement le choix de faire une couche d'abstraction me semble le choix le plus judicieux. En plus ça laisse plus de liberté à l'utilisateur final.

              • [^] # Re: On est presque vendredi

                Posté par  . Évalué à 9.

                Ca ne sert à rien de lui expliquer : ça a déjà été fait 100 fois. Il ne veut pas écouter, reste campé sur sa position, son combat contre toutes technologies de KDE et surtout celle-là. Enfin bon, merci pour le rappel.

        • [^] # Re: On est presque vendredi

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

          PulseAudio va être intégré à Gnome dans les mois (voire semaines) à venir.
          C'est pas fait...
          Il y a eu une discussion animée il y a quelques semaines sur l'intérêt d'utiliser pulseaudio et les problèmes que ca poserait, mais je n'ai pas vu passer de décision de le supporter dans GNOME pour le moment.

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 0.

            > Il y a eu une discussion animée il y a quelques semaines sur l'intérêt d'utiliser pulseaudio et les problèmes que ca poserait

            C'est ici :
            http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

            Une réponse de Lennart Poettering sur les incompréhensions et FUD divers (ce qui est bien normal puisque peu connaissent PulseAudio). Très intéressant :
            http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

            Sinon, c'est comme d'hab, il y a les "emmerdeurs". Ceux qui ne veulent pas d'un daemon et ne veulent que dmix mais oublient que dmix est un daemon, ceux qui ne veulent pas que PulseAudio utilise plus de 0,000001 % de leur cpu ni plus de 1 Ko, ceux qui seraient prêt à tuer père et mère pour que les facilités mixer de leur carte son soient utiliséee, etc....
            Du très classique. Mais qui a fini par énerver Lennart Poettering :
            http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)
            Dude, what's wrong with you?


            Réponse de Jeff Waugh :
            http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)
            At this point Lennart, I think there's a pretty clear consensus emerging, and you have the option to ignore the statistical (and emotional) outliers. :-)


            Bref, PulseAudio est globalement accèpté et j'aurais beaucoup de mal à croire que PulseAudio ne soit pas dans Gnome 2.22 (voire 2.24 au pire).
            Fedora est passé à PulseAudio. SuSE passe actuellement à PulseAudio. Mandriva semble faire de même.

    • [^] # Re: On est presque vendredi

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

      Question bête: Ca apporte quoi à l'utilisateur lambda?

      Perso je vois pas :(

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à 1.

        À l'utilisateur vraiment lambda, rien du tout.
        À l'utilisateur qui joue à brancher des cartes sons USB, à faire de la VoIP tout en écoutant de la musique... ça peut servir (mais j'en connais aucun)

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à 4.

        Comme le téléphone portable à ses débuts...
        M'enfin, tu peux resté accroché à ce que tu utilises.

        C'est "marrant" de voir tout le buzz que fait Compiz alors que ça n'apporte rien. C'est joli, c'est tout (et c'est déjà très bien).

        PulseAudio, ce n'est pas joli, ça apporte des solutions.

        Par exemple on me contacte sur ekiga. Je branche à chaud mon casque audio usb et j'envois le son sur le casque (et que pour ekiga). Puis un pote arrive et je veux qu'il profite de la discussion en cours. J'envoie le son sur les haut-parleur (ou je débranche mon casque usb).

        C'est une vraie solution à un vrai problème. Problème que peut avoir l'utilisateur lambda. Ou alors l'utilisateur lambda n'utilise pas ekiga, n'a pas de casque audio, etc...

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 8.

          Ah non ! Compiz apporte beaucoup. Et le principal apport, c'est des arguments marketings, ensuite plus de fluidité, des métaphores visuelles plus compréhensibles (les bureaux virtuels), et des gadgets. Après, faut aussi aimer le beau.

          Envoyé depuis mon lapin.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 10.

          Ici en Chine, il est vendredi, alors je peux répondre:
          L'utilisateur lambda n'utilise pas ekiga, il utilise msn live!

          Quand il veut faire de la voip il passe par msn live, il branche son casque usb, redémarre (2 fois, la première fois le pilote s'est installé en double et ça a tout fait foirer).

          La deuxième fois son correspondant a trouvé le temps long et s'est déconnecté, alors il laisse son casque branché, mais la musique refuse de sortir par les hauts-parleurs.

          Ensuite quand son correspondant revient, il met le casque sur sa tête et son correspondant reçoit la musique qu'il écoute en même temps que ses propres paroles.

          Quand un tierce pote arrive dans la salle, il tente de rebasculer le son de la conversation sur les HP ce qui fait planter la machine. Il redémarre en débranchant son casque. Le son de la voip ne sort plus de nulle part, mais son correspondant reçoit bien la musique.

          Ensuite ils prennent tous les deux un vrai téléphone en se disant que l'informatique c'est vraiment trop compliqué.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 3.

          Par exemple on me contacte sur ekiga. Je branche à chaud mon casque audio usb et j'envois le son sur le casque (et que pour ekiga). Puis un pote arrive et je veux qu'il profite de la discussion en cours. J'envoie le son sur les haut-parleur (ou je débranche mon casque usb).
          Jack fait déja tout ça.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 2.

          Toi tu dois avoir de bon yeux! Le plugin que je prefere c'est le plugin zoom. Cela me permet d'avoir mes softs affichant mes images de facon confortable c'est a dire sans que l'image s'affiche integralement en 1:1 et pouvoir lire mes articles, mes pages web etc sans me casser les yeux et sans rechanger la resolution de l'ecran et/ou de chaque soft que j'utilise. Un must.

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 3.

            pouvoir lire mes articles, mes pages web etc sans me casser les yeux et sans rechanger la resolution de l'ecran et/ou de chaque soft que j'utilise. Un must.

            Le must, c'est d'acheter un bon écran plutôt que ce genre de rustine logicielle. Vu la durée de vie d'un écran et l'importance de la chose l'investissement va de soi.
            Je suis toujours stupéfait que des gens qui passent leurs journées sur un ordi (pour raisons professionnelles ou autre) acceptent de s'exploser les yeux sur un écran bas de gamme.

            • [^] # Re: On est presque vendredi

              Posté par  . Évalué à 4.

              le probleme c'est pas mon ecran il est tres bien mais j'ai tout de meme des yeux qui fatigue en fin de journee et je trouve tres agreable de pouvoir zoomer pour lire peinard un article. Certes les logiciels le font souvent mais cela demande des manips et c'est tellement plus rapide. Enfin moi je trouve ca pratique et c'est mon opinion :)

          • [^] # Re: On est presque vendredi

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

            Heuu scale ça sert juste de selecteur d'application quand on a 20 trucs ouverts :)
            Sinon, un bon écran c'est bien certes, mais je vois pas pourquoi ça empècherais d'utiliser une astuce logicielle qui augmente la lisibilité. Bon écran ou pas, lire un long texte en 12px, ça fatigue.

            • [^] # Re: On est presque vendredi

              Posté par  . Évalué à 4.

              Bon écran ou pas, lire un long texte en 12px, ça fatigue.

              Tu peux augmenter la taille de la police dans le logiciel de lecture, ou imprimer le texte. Les deux offrent probablement un rendu largement meilleur qu'un bête zoom bitmap.

              • [^] # Re: On est presque vendredi

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

                Perso c'est ce que je fait, FIrefox n'a pas le droit d'afficher une police sous 13.
                Mais le plugin zoom c'est aussi pratique pour mettre rapidement en plein écran une video youtube et compagnie.

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à 5.

        Moi, je vois déjà une application intéressante (du moins pour ceux qui vivent dans une maison/grand appart avec une grande famille) : brancher une set-top box sur la HiFi de la maison, qui partagerait sa sortie son avec PulseAudio, et permettre à n'importe qui de se pointer au salon avec son laptop posé à côté du canapé tout en profitant de l'installation HiFi.
        En plus c'est multiplateforme, donc tout le monde en profite vraiment.

        Bon évidemment, pour ceux qui vivent seuls, la partie réseau à moins d'intérêt.

        Mais il reste tout le hotplug, tout de même super pratique quand on fait de la VoIP. Pas besoin de relancer/reconfigurer Ekiga à chaque fois qu'on décide d'utiliser une oreillette bluetooth au lieu du casque micro branché sur la carte son, ou bien le micro intégré à la webcam USB.

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à 10.

        Il y a quelques fonctionnalités intéressantes (présentées par d'autres ici), de mémoire:

        - Pouvoir enfin exploiter le surround, et les divers systèmes audio multicanaux (5.1, 7.1 etc.) correctement (éventuellement en multiplexant plusieurs cartes son)
        - Hotplug de cartes audio (penser aux "skype phones usb" par ex, ou aux oreillettes bluetooth).
        - Possibilité d'intervenir sur les divers flux envoyés au daemon (pour régler les volumes différemment selon l'appli source, migrer un flux sur un autre périphérique, etc.)
        - La portabilité (support natif de Windows, *BSD, Linux, Solaris) (nb: sachez bien que Alsa ne supporte que Linux : même pas les BSDs, ce qui explique que les développeurs d'applis ont dans l'ensemble conservé la compat OSS sur le long terme).
        - Projet de gérer le son différemment selon les "états graphiques" (?), par ex. augmenter le volume de l'appli en avant plan, et baisser le volume de l'appli dans la barre des taches (pratique, lorsqu'on switche souvent entre firefox+vidéos flash, un lecteur de musique, un client irc qui blingue, etc.)
        - Le point le plus important pour moi : la possibilité d'avoir une *très faible* latence sans jitters. En effet PA tourne avec une priorité Real Time (possible parce que c'est un daemon: on ne peut pas donner une telle priorité à tout les logiciels susceptibles d'envoyer directement du son à alsa).

        Ce qui, en revanche, me semble très dommageable pour la réussite de ce remarquable projet, c'est l'attitude, le style, de son leader, Lennart Poettering. Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées (« stubborn », disait un gnomiste). Il est régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, insultant à l'égard des contributeurs potentiels peu dégourdis, des décisions à la « je force rigidement et artificiellement un choix en vérouillant le périphérique », mépris total des outils aimés par les utilisateurs (« amarock -- or whatever that awful media player everyone but me loves so much is called »), etc... Bref, c'est une grande gueule aux opinions très tranchées, et pas très intéressés par la collaboration avec les outils et technos non-gnome.

        C'est dommageable, parce qu'on attends vraiment d'un projet comme PA qu'il fédère, enfin, les divers projets libres autour d'une très bonne API son, à la façon d'un projet freedesktop ; qu'on se défasse enfin de la concurrence entre tout ces vieux logiciels presque non maintenus (esd, arts, lecteurs audios divers, ...) qui cherchent chacun à vérouiller la carte son en entrée, et même parfois en sortie (souvent en schuintant dmix au vol). Or s'il s'alienne déjà l'ensemble de l'environnement KDE (« I don't care about KDE »), l'objectif est déjà loupé ; nous garderons nos petits problèmes de conflits d'accès concurrent pour un bon moment encore ... :(

        Bon, mais rappelons-le, l'outil est excellent (et les projets de développements annoncés sont alléchants).

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 4.

          au fait,

          > Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées [...] régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, [...]

          Toute ressemblance avec un personnage existant dans le coin serait le fruit du hasard :P

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 1.

            voyons voir, serait-ce Theo de Raadt ? Linus Thorvald ? Richard Stallman ? ou encore Eric Raymond ? ;)

            Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

            • [^] # Re: On est presque vendredi

              Posté par  . Évalué à 5.

              Je pense qu'il parlait d'un gars un peu moins connu mais beaucoup plus présent sur les forums Linuxfr...

        • [^] # Re: On est presque vendredi

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

          En meme temps, pour Kde, y'a déjà Phonon qui en principe devrait apporter les même fonctionnalité que pulseaudio si j'ai bien suivi mais je m'avance ptet un peu trop vite...

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 4.

            Non, Phonon, c'est juste une couche d'abstraction au dessus des framework multimedia, eux-mêmes utilisant alsa/oss ou un serveur de son comme esd/jack/PulseAudio/... .

            Dans la pratique, vu que Phonon utilisera Xine, et que Xine a déjà une sortie PulseAudio, oui, Phonon proposera les fonctionnalités de PulseAudio (reste à voir s'ils auront prévu toute la GUI nécessaire pour que ce soit vraiment utilisable).

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 1.

          - Pouvoir enfin exploiter le surround, et les divers systèmes audio multicanaux (5.1, 7.1 etc.) correctement (éventuellement en multiplexant plusieurs cartes son)

          Ca c'est super fort de pouvoir utiliser 2 cartes stereo pour obtenir un son surround... Je connais pas de systeme de son capable de faire ca actuellement...

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 7.

            Ben ALSA le peut, avec les mains dans le cambouis.

            ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 2.

          Vu la derniere partie de ton message cela ne m'etonne pas trop que KDE n'ait pas saute sur ce projet...

    • [^] # Re: On est presque vendredi

      Posté par  . Évalué à 8.

      Il lit des mp3/ogg/flac/wav sur le dd/http/ftp directement pulseaudio ? J'ai cru comprendre que c'était uniquement un serveur de son, mais j'ai peut-etre mal compris.

      PulseAudio a une interface de programmation simple bien intégrée à KDE ? D'après ce que j'ai vu non.

      Donc aucun rapport entre Phonon et PulseAudio. (A part qu'on pourrait utiliser PulseAudio en backend de Phonon pour la sortie des sons)

      Sinon c'est vrai que ça a l'air cool PulseAudio

      • [^] # Re: On est presque vendredi

        Posté par  . Évalué à -1.

        > Il lit des mp3/ogg/flac/wav sur le dd/http/ftp directement pulseaudio ?

        Non, ce n'est pas son boulot. C'est "seulement" un serveur de son. Donc ce n'est pas un remplaçant à Gstreamer par exemple.

        > PulseAudio a une interface de programmation simple bien intégrée à KDE ? D'après ce que j'ai vu non.

        Et alors ?
        KDE peut bien se sortir les doigts du cul ou ils ne font qu'attendre que tout le boulot soit mâché ?

        > Donc aucun rapport entre Phonon et PulseAudio. (A part qu'on pourrait utiliser PulseAudio en backend de Phonon pour la sortie des sons)

        Aucun. PulseAudio fait des trucs que ne permet pas Phonon. A moins que Phonon ait déjà prévu toutes les fonctionnalités de PulseAudio dans son API, mais je n'y crois pas deux secondes.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 2.

          Aucun. PulseAudio fait des trucs que ne permet pas Phonon. A moins que Phonon ait déjà prévu toutes les fonctionnalités de PulseAudio dans son API, mais je n'y crois pas deux secondes.

          Et à part ce que tu crois, tu as des faits à proposer? Parce que ça commence à devenir lassant...

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 4.

          Aucun. PulseAudio fait des trucs que ne permet pas Phonon. A moins que Phonon ait déjà prévu toutes les fonctionnalités de PulseAudio dans son API, mais je n'y crois pas deux secondes.
          Ben les trucs prévus à la base c'était le branchement à chaud de périphériques audio avec la promenades d'applis entre les sorties, le changement automatique de volume, le volume indépendant par appli... Mais bon, je suppose que faire un minimum de recherches n'est pas à ta portée...

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 6.

            Nan, c'est pas ça. C'est juste que Phonon est tellement une merde que ça vaut pas le coup qu'on regarde ce que ça fait. En plus, ça vient de KDE, donc bon.

          • [^] # Re: On est presque vendredi

            Posté par  . Évalué à 0.

            "Tant mieux" si je me suis trompé. On a maintenant un doublon. Phonon est aussi un serveur de son (ou un serveur de serveur de son). Dérive "naturelle".

            • [^] # Re: On est presque vendredi

              Posté par  . Évalué à 9.

              Phonon n'est pas un serveur (et donc pas un serveur de son).
              C'est une bibliothèque qui fait office de couche d'abstraction entre les applications KDE et les serveurs de son.

        • [^] # Re: On est presque vendredi

          Posté par  . Évalué à 5.

          Non, ce n'est pas son boulot. C'est "seulement" un serveur de son. Donc ce n'est pas un remplaçant à Gstreamer par exemple.


          C'est bien ça que je voulais dire. Dans l'API de Phonon, tu peux faire un truc du genre Lire("http://monfichieraudio"), pas avec PulseAudio (dont ce n'est pas but). KDE a besoin de pouvoir faire ça, d'où Phonon (après tu peux encore troller et dire que ils auraient du utiliser gstreamer directement, mais pas PulseAudio).

  • # C'est bien joli tout ça...

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

    Le gros problème avec ce genre de "deamon son", c'est qu'il y'a toujours une latence plus ou moins importante.

    Y'a quelques années, je m'étais pris une soundblaster, car elle gérait plusieurs sorties simultanées sous GNU/Linux. Parce que ESD, c'est rigolo, mais avoir 1/2 seconde de décalage quand on lit une vidéo, c'est à chier.

    Et il existe un serveur de son sans latence, Jackd. Il permet déjà tout ce que présente la vidéo, et encore plus (prendre la sortie de xmms, la faire rentrer dans un compresseur de dynamique, prendre la sortie du compresseur et la faire sortir à la fois sur la sortie HP de ma carte 1, alors que la carte 2 reçois le flux direct de xmms, mais je fais également passer la sortie compressé dans un client icecast pour faire du streaming).

    Bref, pourquoi refaire un truc qui existe déjà, jackd est très puissant, dmix est très simple, la on à un truc le cul entre deux chaises. Peux être aurait-il suffit de faire une interface un peu plus simple que qjackctl (interface en QT pour brancher tous les fils virtuels) pour jackd.

    Jackd, c'est bon mangézan. ESD et ses bébés, noyez les.

    Ps : avec le pont, vendredi est arrivé trèèèès vite.

    • [^] # Re: C'est bien joli tout ça...

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

      >>> Le gros problème avec ce genre de "deamon son", c'est qu'il y'a toujours une latence plus ou moins importante.

      Tu a pris la peine de lire les liens postés par IsNotGood ?
      Le long post de Lennart explique bien toutes les qualités de PulseAudio et il répond aux divers FUD : http://mail.gnome.org/archives/desktop-devel-list/2007-Octob(...)

      Au sujet de la latence je vais te coller sa (longue) réponse mais en résumé : oui cela augmente un peu la latence mais pas plus que les autres solutions comme dmix. A long terme, et avec l'aide du kernel, une solution du type PulseAudio sera obligatoire pour obtenir des faibles latences.

      Son post sur ce sujet :
      yes, PA increases the latency
      over direct hw access. But so does dmix, because it enforces fixed
      fragment settings for all apps. What you really want to do (which
      however right now is only partially implemented in PA) is allowing
      per-stream fragment settings, by scheduling audio based on timer
      interrupts instead of sound io interrupts (based on fixed fragment
      settings). Those timer interrupts can be dynamically changed so we can
      change the wakeup points dynamically during playback without too much
      effort. However this needs some kind of kernel support (hrtimers,
      HPET), which only has become available very recently and on x86 only
      (not even amd64 yet), so until we get this fully implemented a few
      months will pass. If we have that however, we basically get the same
      PCM pipeline that Vista and MacOS have: a huge mixing buffer managed
      by a real-time userspace sound server which allows rewriting at any
      time and notifying clients dynamically, scheduled via timer
      interrupts. In essence, in the long run we really *need* something
      like PA, if we want to provide low latencies (i.e. short fragments ==
      frequent interrupts) and low power consumption (i.e. few interrupts ==
      huge fragments) at the same time and switch between them
      dynamically. Yes, right now, PA increases your achievable latencies a
      bit (but just a bit), but in the end we *need* a process that does the
      audio scheduling based on timers -- something that PA will then do. Of
      course, PA doesn't fully implement yet, which is partially PA's fault
      and partially the kernel's fault that sucks when it comes to timers,
      right now. We're getting there.

      • [^] # Re: C'est bien joli tout ça...

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

        Je veux bien le croire, à ce moment c'est donc réinventer la roue, puisque jackd existe et fonctionne très bien depuis des années. Il y'a des plugins pour beaucoup de logiciels, ce que pulse n'a pas encore. Et surtout jackd va beaucoup plus loin, en permettant de connecter des applications entre elles.

        Mais pourquoi pas, hein, je ne suis pas opposé catégoriquement à ce truc, j'ai juste quelques doutes. Si ils arrivent à faire un serveur léger, avec très peu de latence, adopté par tout le monde, très bien. Si c'est pour remplacer le killall esd par killall pulseaudio, ben...

        Tout cela montre bien que le son sous GNU/Linux, ça fonctionne, mais c'est pas prêt pour madame Mich (quoi que dmix a bien débroussaillé le terrain).

        • [^] # Re: C'est bien joli tout ça...

          Posté par  . Évalué à 3.

          Tout cela montre bien que le son sous GNU/Linux, ça fonctionne, mais c'est pas prêt pour madame Mich (quoi que dmix a bien débroussaillé le terrain).

          Je viens de tester la futur fc8 avec pa intégré et je peux te dire que cela fonctionne assez bien pour madame.

          Je ne pense pas que dmix aie apporté quelque chose (en tout cas à mme Mich) si ce n'est l'espérance d'avoir un mixage fonctionnel (malheureuse promesse qui ne sera pas tenue; certaines configurations ne sont pas supportées: frequences d'échantillonages, pb matériels. incompabitilités avec l'émulation oss).

          Donc il a été dit que le mixage ne devait pas se faire en kernel space. Soit, on a donc eu esd & arts qui sont vites relègués au rang de curiosités archéologiques lorsque jack peut synchroniser, « en temps réel » s'il vous plait, multitudes d'E/S.

          Ce qui rend PA innovant, c'est son attention portée sur l'utilisateur. C'est lorsqu'il parvient enfin à effectuer cette tâche basique sans se mettre dans le chemin de l'utilisateur; avec la touche d'automatisation nécessaire à rendre le tout très utilisable. Je ne pense pas que le démond jack se preoccupe de faire de la détection hotplug ou du reroutage automatique de flux...
          Maintenant si la question est de savoir s'il aurait été possible de faire cela au dessus de jack la réponse serrait sûrement oui.

        • [^] # Re: C'est bien joli tout ça...

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

          Jack peut fonctionner au dessus d'un serveur de son de ce type à terme.
          Le problème, c'est que (du moins pour l'instant) :
          - jack n'est pas capable de découvrir les cartes sons tout seul.
          - il marche mal avec deux cartes son
          - il peut bouffer pas mal de CPU (afin d'obtenir une latence 0)

          De fait, j'utilise jack et c'est très bien, mais ce n'est pas la panacée pour une utilisation bureau.

          Je pense qu'un système comme pulseaudio a sa place à ce niveau, quitte à l'interfacer bien avec jack de manière à obtenir le meilleur des deux mondes.

    • [^] # Re: C'est bien joli tout ça...

      Posté par  . Évalué à 3.

      > Le gros problème avec ce genre de "deamon son", c'est qu'il y'a toujours une latence plus ou moins importante.

      Pour compléter la remarque de patrick_g, et comme je l'ai indiqué plus haut, les parties critiques (en termes de latence) de pulse audio tournent avec une priorité RT (temps réel)... exactement comme jackd ;) (jackd est bien la preuve qu'un daemon n'ajoute pas forcément de la latence !).

      Mais à la différence de jackd, la latence n'est pas la priorité absolue de PA, il propose donc certaines facilités qui rendent son utilisation plus simple pour les applications qui veulent seulement jouer des sons (comme le support, et la conversion à la volée de diverses fréquence d'échantillonnage envoyées par les applications : ce qui peut rajouter un tout petit poil de latence, mais est tellement pratique...). Bref, PA fait un petit compromis sur la latence (mais rien à voir avec l'énorme latence de dmix, ou pire, l'intolérable décalage d'esd) pour être plus pratique à utiliser.

      • [^] # Re: C'est bien joli tout ça...

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

        Bon bon bon, y a des solutions à tout

        $ apt-cache search pulseaudio jack
        (...)
        pulseaudio-module-jack - jackd modules for PulseAudio sound server
        (...)

      • [^] # Re: C'est bien joli tout ça...

        Posté par  . Évalué à 6.

        Jack est quasiment devenu un standard pour les outils de MAO libre, même s'il n'y a que les musiciens qui sont au courant. Et il suffit d'écouter les devs des différentes applis pour comprendre que maintenant qu'ils ont gouté à la "latence-zéro" et autres friandises offertes par Jack, ils ne feront pas machine arrière. On aura donc deux APIs pour le son, et du coup il va falloir gérer la cohabitation:

        - une façon simple de lancer des applis audio "pro" sur un système utilisant pulseaudio. La commande "pasuspend" dont parle Lennart Poettering (dans le lien posté plus haut) semble être une bonne solution;

        - une façon simple d'échanger des flux entre applis "pros" et "non pros": le module pulseaudio pour jack est une partie de la solution, et je crois que pulseaudio offre une couche de compatibilité avec jack, donc tout va bien;

        - une cohabitation pacifique et respectueuse entre les deux projets. Là, j'ai l'impression que c'est pas gagné! ^_^

        • [^] # Re: C'est bien joli tout ça...

          Posté par  . Évalué à 3.

          Tout comme il y a ASIO sous windows en parallèle aux API standard de windows. Je ne connais pas bien l'API mac, mais d'un point de vue utilisateur j'ai pas l'impression qu'elle soit tip top question latence, sauf a mettre les mains de le cambouis, ce qui revient a peut prêt au même que d'avoir 2 apis avec chacune leur point fort (latence/simplicité).

          Moi j'aime bien l'approche "a besoin différents, outils différents" qui évitent a coup sûr les mauvais compromis pouvant au final casser les pieds a tout le monde. Et si au final une solution unique peut être trouvée, c'est du tout bon, mais ne nous pressons pas.

          • [^] # Re: C'est bien joli tout ça...

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

            C'est quand même plus simple et unifié sous mac que sous les autres OS. Il suffit de regarder le nombre de backends dans portaudio pour chaque os:

            - Mac:
            Coreaudio

            - Linux:
            OSS, alsa, jack

            - Windows:
            MME, Directsound, ASIO, WDM, WASAPI

            • [^] # Re: C'est bien joli tout ça...

              Posté par  . Évalué à 5.

              C'est normal, mac est, pour caricaturer une distribution que fait tout les choix pour l'utilisateur et limite au maximum la possibilité de changé quoi que ce soit. Le résultat :

              Pouvoir avoir une très bonne finition, c'est plus moins on a de logiciels et matériels à entretenir et plus on peut y passer de temps.

              L'inconvéntient est que sur mac, faut vouloir ce qu'on a parce que c'est pas vraiment évident de changer quoi que ce soit.

              Je n'ai que très peu utilisé mac, il est peut-être possible d'effectuer des trucs que j'ignore, mais par exemple j'ai voulu mettre vlc comme lecteur de dvd par défaut. C'est possible, mais quand on met le dvd, ça lance juste vlc (et pas la lecture du dvd). Le problème est qu'il m'a semblé impossible de paramétrer la commande à lancer (alors que ça marche très bien de la console).

              Donc pour moi mac est un système qui a une très bonne finition, très stable, mais où l'enfermement de l'utilisateur est encore pire que sous Windows.

              Chaque médaille à son revers

        • [^] # Re: C'est bien joli tout ça...

          Posté par  . Évalué à 4.

          Concernant PulseAudio et Jack: les 2 projets n'ont pas la même vocation et on peut raisonnablement espérer qu'il sera possible de les faire cohabiter harmonieusement. Le serveur jack est en période de restructuration, une nouvelle version jackdmp (http://www.grame.fr/~letz/jackdmp.html) existe depuis 2 ans et deviendra probablement à terme la version de référence.
          Par ailleurs les developeurs de jack (dont je fait partie) ont discuté dernièrement avec Lennart et évoqué les solutions techniques pour faire fonctionner les 2 systèmes ensemble et ça doit être possible, même si tout reste à tester.

  • # J'en profite

    Posté par  . Évalué à 2.

    J'en profite pour poser une question.

    En effet, ça fait quelques jours que je me bas avec pulseaudio, ce journal aparait donc au bon moment.
    En effet n'étant pas encore démocratisé (et j'espère qu'il va le devenir, pulseaudio est vraiment fabuleux) il manque un peu de documentation.

    J'étais justement en train de préparé un wiki sur son installation, mais j'ai un problème
    Les cartes sont sont détectées sans problème. Lorsque j'ai plusieurs carte son (testé avec usb) ça apparait directement et il est possible de passer de l'un à l'autre en direct.

    Mon problème viens du réseau. J'arrive sans problème à envoyer le son sur un autre ordi, mais en jouant sur « Defauls Sink ».
    Je n'arrive pas à faire apparaitre les « sink » du réseau comme si c'était en local.

    Je fais toute la config dans /etc/pulse/defaut.pa.

    Il semble dans la vidéo avoir une option que je ne trouve pas :
    « Make discoverable network sound card devices available locally »
    Ça semble correspondre à ce que je cherche, mais je ne vois pas comment l'activer (j'aimerai le mettre dans defaut.pa)

    Je n'ai pas encore réussi à trouver dans la doc.

    Si quelqu'un à la réponse, je suis preneur.


    En tout cas, c'est une bonne idée de Fedora de l'intégré, car même si il ne sert pas à tout le monde, il est super pratique et apporte énormément à ceux qui en ont usage.

    Personnellement, je l'en sert pour faire sortir le son de mon portable sur les enceintes de mon pc quand je suis dans une pièce avec un pc qui à des enceintes.

    Coté latance critiqué plus haut, j'ai été étonné de sa casi-absence (je ne vois pas de décalage sur les vidéos)
    Je n'ai pas encore fait sortir simultanément sur plusieurs sorties en même temps mais ça devrait venir et permettrai de mieux m'en rendre compte.

    Voilà, très bonne nouvelle pour le son sous Linux, qui je l'espère mettra un terme aux problèmes du types : « j'arrive pas à jouer deux sont en même temps », c'est de toutes les solutions que j'ai testé la plus efficace sur du matériel très mal reconnu.

    • [^] # Re: J'en profite

      Posté par  . Évalué à 2.

      La fonctionnalité que tu cherches n'est disponible qu'avec la toute dernière version (0.9.7), sortie il y a deux jours seulement.

      Je n'ai pas encore pu tester, mais apparemment le nouveau module qui permet de faire ça s'appelle module-zeroconf-discover. Et y'a pas encore de doc, sauf si tu considères http://pulseaudio.org/changeset/1983 comme de la doc ;-)

      Sinon je plussoie totalement : PulseAudio c'est génial, ce que j'adore c'est la possibilité d'avoir le son quand on fait de l'export display en ssh... On peut avoir le son avec l'image ! :-)

      Sinon je confirme la quasi-absence de latence : j'ai jamais eu de problème avec...

      Et pour le wiki sur l'installation, je trouve que c'est une très bonne idée. Indique moi l'adresse quand ce sera prêt, j'avais eu quelques problèmes pour le faire marcher correctement et ça m'intéresserait assez de publier ça quelque part...

      • [^] # Re: J'en profite

        Posté par  . Évalué à 2.

        Grand merci, j'ai mis à jour le paquet et réinstallé, mais bon ça ne marche pas directement (j'ai bien le module zeroconf activé et il fonctionne). Et comme pour l'instant pas de documentation, je vais attendre et voir si la doc du site se met à jour
        J'espère pouvoir faire le wiki ce week-end si j'ai le temps, je posterai le lien

Suivre le flux des commentaires

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