Journal Qt/Phonon bientôt mort et remplacé

Posté par (page perso) .
Tags : aucun
16
9
sept.
2009
Il y a quelques chamboulements dans le microcosme KDE et Qt.
Phonon [1] est une API multimédia crée par Matthias Kretz à l'époque pour le futur KDE 4.

Phonon utilise un système de backends qui permet d'utiliser au choix GSteamer, DirectX, QuickTime, Xine, VLC... sans que le développeur ne se soucis de tout cela et puisse jouer un son ou une vidéo en quelques lignes de code seulement. Phonon est une surcouche par dessus les systèmes audio existants.

L'équipe KDE après les déboires de aRts [2] a décidé qu'il fallait s'abstraire du système audio sous jacent. Ainsi si celui-ci devient obsolète ou si une meilleure alternative arrive sur le "marché" il suffit de réécrire un backend sans devoir réécrire toutes les applications.

A l'époque il y avait eu une polémique surtout en dehors de KDE pour dénoncer les surcouches de surcouches. La question qui revenait le plus était "pourquoi ne pas avoir utiliser GStreamer directement ?"

L'auteur de Phonon a travaillé avec Trolltech/Nokia pour l'intégrer dans Qt (Phonon est à l'origine un projet KDE), ce qui fut fait dans la version Qt 4.4 en mai 2008. Tout se passait bien, Trolltech/Nokia a notamment contribué des backends pour Phonon.

MAIS, coup de théâtre, il y a quelques jours Nokia a annoncé (façon cheveux sur la soupe et la bouche en coeur) le projet QtMobility Multimedia Framework [3]. QtMobility Multimedia a grosso modo les mêmes objectifs et fonctionnalités que Phonon (cf Brice de Nice : "moi c'est pareil que toi, mais... en mieux !").

Pourquoi ne pas avoir améliorer Phonon ? La clarification est arrivé quelques jours après [4]: Phonon n'est pas assez flexible pour ce que l'on veut faire, il faut réécrire.

Au final Phonon est supporté dans Qt 4.x mais les prochaines version de Qt devrait intégrer QtMobility Multimedia.
KDE va surement continuer d'utiliser Phonon et l'on va se retrouver avec 2 API concurrentes pendant longtemps :/
Le vainqueur est deja tout désigné vu les moyens de Nokia (Matthias Kretz a developpé Phonon sur son temps libre et n'a d'ailleurs plus le temps en ce moment)

[1] http://en.wikipedia.org/wiki/Phonon_%28KDE%29
[2] http://en.wikipedia.org/wiki/Artsd
[3] http://labs.trolltech.com/blogs/2009/09/03/multimedia/
[4] http://labs.trolltech.com/blogs/2009/09/09/multimedia-in-qt-(...)
  • # bof

    Posté par . Évalué à 10.

    suffit de créer un backend phonon pour s'appuyer sur QtMobility Multimedia...

    C'est pas le but non? pouvoir changer de backend comme de chemise :D
    Une couche de plus ou de moins qu'est ce que ça change ?

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: bof

      Posté par . Évalué à 2.

      Phonon dans Qt ne sera plus étendu (alors que son développement continu sous KDE via Martin T. Sandsmark) :

      The Qt 4.6 MultiMedia APIs are a continuance on the old familiar architecture offering media playback via Phonon. This solution/architecture will be supported and maintained for the entire Qt 4 series, but no substancial new features will be added
  • # Connerie...

    Posté par . Évalué à 0.

    Je vais me contenter de citer la documentation de Qt 4.6 (cf http://doc.trolltech.com/4.6-snapshot/qtmultimedia.html ) :
    The functionality provided by the Phonon Module is on a higher level and in many cases more suitable for application developers.

    Donc ton titre à scandale est tout simplement faux...
    • [^] # Re: Connerie...

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

      http://labs.trolltech.com/blogs/2009/09/09/multimedia-in-qt-(...) : We will continue to maintain Phonon for the duration of the 4.x series, but new functionality will be added in the new multimedia module.

      Je trouve quand même que ça sent le sapin
    • [^] # Re: Connerie...

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

      Tu confonds le Qt Multimedia qui est dans Qt 4.6, et ce nouveau framework, qui fait partit du projet Qt Mobility, et qui s'affiche comme un concurrent direct de Phonon (rien qu'en lisant les blogs, ça paraît évident).

      C'est expliqué dans un commentaire d'un blog:
      To try clear the confusion regarding the difference between the Qt 4.6 MultiMedia APIs and the new Qt APIs shared here:
      The Qt 4.6 MultiMedia APIs are a continuance on the old familiar architecture offering media
      playback via Phonon. This solution/architecture will be supported and maintained for the
      entire Qt 4 series, but no substancial new features will be added.
      The newly architected MultiMedia APIs, which this Labs entry is all about, target both desktop and mobile development needs, have an entirely new architecture and will ultimately offer
      developers support for Video/Audio capture, Camera APIs, Playlist Management, Playback, Radio and more.
      It is intended that they will become part of Qt at some future point once we have completed
      development, are happy that the APIs are considered stable/mature and most important that they meet our Qt standard.
    • [^] # Re: Connerie...

      Posté par . Évalué à 2.

      Hum, le titre extrapole un peu, mais vu le contenu du journal et des urls, on peut imaginer qu'il a des chances importantes de se réaliser.
      "Phonon est maintenu mais plus développé, et ce n'est plus l'avenir de l'audio Qt", c'est un peu ce qui est dit. Donc si, bye bye Phonon, hello QtMMF.
  • # Phonon était pas prêt

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

    Quand j'ai voulus bosser avec Phonon et faire des choses un peu avancé qui pour moi devrait être trivial actuellement, bah à part lire une vidéo ça vas pas très loin.
    La compatibilité binaire est pénible si on veut rajouter des machins à Phonon, Phonon est selon moi trop jeune pour que l'API/ABI soit déjà fixé.
    On est trop vite confronté au limite du backend et certaine feature dépende trop du backend (genre les sous titres), et on a pas la possibilité de manipuler le flux pour gérer tout ça soit même.
    De toute façon j'ai la sensation que toute l'énergie des déveleppeurs dans le domaine des framework multimédia libre est accaparé par le besoin de supporter le dernier codec top moumoute useless qui sort.
    Je suis bien content que Qt veulent tout repenser.
    • [^] # Re: Phonon était pas prêt

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

      La compatibilité binaire est pénible si on veut rajouter des machins à Phonon

      Tiens bizzare, j'avais entendu que la principale raison pour laquelle KDE a développé Phonon est qu'ils ne voulaient pas être dépendant du cycle de release Gstreamer. Autrement dit, Gstreamer était trop instable (niveau API) pour KDE.

      J'ai toujours trouvé cette excuse super pourrie, et maintenant je lis que Phonon a une API trop stable !?

      Phonon est selon moi trop jeune pour que l'API/ABI soit déjà fixé.

      Encore une fois, je ne comprend pas pourquoi Phonon a été écrit. Vu que Phonon a écrit après Gstreamer, il est forcément plus jeune, moins complet, etc. (dumoins au début)

      --

      À côté de ça, il y a pulseaudio. Autre surcouche super pourrie qui est bourré de bugs (les derniers exploits noyau utilisent une faille PulseAudio qui est en suid !?), plus limité que ses backends (pas d'accélération matérielle à ce que j'ai entendu), etc.

      Pourquoi ne pas utiliser Gstreamer partout ? Je crois que c'est le syndrôme NIH qui a encore fait des victimes.
      • [^] # Re: Phonon était pas prêt

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

        Pourquoi ne pas utiliser Gstreamer partout ?

        Parce que je veux utiliser Xine pour décoder mes vidéos ?

        Quand à remplacer pulseaudio par Gstreamer, ça n'a rien à voir, les deux softs font des choses très différentes. Certes, pulseaudio ne marche pas toujours très bien, mais quand ça marche c'est bien puissant.
        • [^] # Re: Phonon était pas prêt

          Posté par . Évalué à 3.

          Personnellement, j'utiliserai Xine quand il saura lire des vidéos Dirac, et pareil pour Mplayer. VLC de son côté sait le lire, mais pas l'encoder (ou alors j'ai pas trouvé comment).

          Pour ce coup-là, Gstreamer reste quand même le seul framework capable de traiter ce format, qui je pense pourrait relancer le libre dans le domaine du multimédia (il est en compétition pour remplacer WMV dans le futur VC-2).

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Phonon était pas prêt

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

            mplayer sait lire en encoder du dirac depuis longtemps.
            • [^] # Re: Phonon était pas prêt

              Posté par . Évalué à 2.

              C'est combien, « depuis longtemps » ?
              Parce que j'ai la version 1.0.rc2svn20090823 de debian-multimedia, et je ne peux pas lire de vidéos Dirac (j'ai au moins le son, donc les fichiers ne sont pas corrompus selon lui).

              Pourtant, il semble compilé avec le support du codec :
              $ mplayer -vc help | grep -E "dirac|schro"

              fflibschroedinger ffmpeg working Dirac (through FFmpeg libschroedinger) [libschroedinger]
              fflibdirac ffmpeg working Dirac (through FFmpeg libdirac) [libdirac]


              Je précise que je tente de lire des vidéos encodées avec la librairie Schröedinger (bien plus rapide que l'implémentation officielle).

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Phonon était pas prêt

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

              ouah trop fort et maintenant qu'on est fin 2009 il peut me lire mes sous-titre en couleur dans mon mkv (bah ouais blanc sur fond blanc ça rox) ? ah bah non toujours pas, c'est cool les nouveaux formats, mais niveau feature utile on est largement largué par les players windows.
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 2.

                > ouah trop fort et maintenant qu'on est fin 2009 il peut me lire mes sous-titre en couleur dans mon mkv
                Si tu parles de mplayer, oui, et ce depuis un bon moment
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 2.

                Tu veux parler de lire des sous-titres au format "ssa/ass" dans mplayer ?

                Si c'est le cas un petit tour dans la page de man et hop, la belle option '-ass' (pas évident à trouver, je l'avoue).
                • [^] # Re: Phonon était pas prêt

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

                  Ça marche bien avec mplayer... malheureusement pas avec mencoder. C'est quand même bizarre qu'une vidéo passant par mencoder passe pas par le même chemin qu'une vidéo lue par mplayer.

                  Mencoder reste quand même le meilleur couteau suisse de l'encodage ;)
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 1.

                    Au moins, ce sont deux programmes différents (nom, options).

                    Avec vlc, sur un flux rtsp : impossible de le voir en direct, en revanche, je peux le « dumper » (sans transformation) et lire le « dump » après. C’est le même programme. Ce sont les mêmes bouts de vidéo qui sont lus depuis un flux fichier ou un flux réseau ! Pourquoi ceux qui viennent d’un fichier sont affichables et les autres pas ?
                    • [^] # Re: Phonon était pas prêt

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

                      Parce qu'il peut lire le fichier dans le désordre, pas le flux réseau.

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

                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 1.

                        Et alors, à quoi ça sert un cache ? C’est de l’UDP en dessous, il est prévu que les paquets arrivent dans le désordre ou soient perdus. Quand les paquets arrivent dans le désordre, il suffit soit d’un cache pour les remettre dans l’ordre, soit de sauter ceux qui arrivent en retard. Les sauter rendra sûrement moins bien que de les remettre dans l’ordre mais ça n’empêche pas d’afficher quelque chose ! (Et puis, faut pas déconner, il n’y a pas tant de pertes ou de désordre que ça.)

                        Et puis, une version ça marche, celle d’après ça ne marche plus, puis ça remarche, puis ça remarche plus…
      • [^] # Re: Phonon était pas prêt

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

        > Pourquoi ne pas utiliser Gstreamer partout ?

        Vision tres Linux-centriste de la chose
        - Qt est un framework simple et complet qui se suffit à lui meme
        - Qt est multiplateforme et s'integre nativement a toutes les plateformes

        GStreamer sous Windows, Mac, les téléphones portables... ba c'est pas terrible.
        Sous Windows, on veut utiliser DirectShow, sous Mac, QuickTime ect...
        La gestion du natif est imperatif.

        De plus GStreamer n'a pas une API facon Qt avec les types Qt, les slots/signaux Qt ect...

        Faire une surcouche Qt est evident quand on utilise Qt.

        Et Phonon c'est une coquille quasi vide, ce n'est pas un nouveau framework multimedia comme GStreamer mais juste une API.

        La meme question pourrait etre posée pour tous les autres composants de Qt: regexp, xml, network ect...
      • [^] # Re: Phonon était pas prêt

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

        Non toute ces technologies en général ont des buts très différents, Phonon est "light" en code, le but est surtout de facilité l'écriture de tache basique (écrire un lecteur multimédia) en permettant a un développeur Qt/kde de ne pas à avoir a assimiler un nouveau concept de framework (gstreamer c'est assez bien foutut mais c'est pas "simple"). Pour moi c'est comparable au besoin que remplis DBUS, on peut utiliser par exemple Hal de manière simple avec des appel DBUS alors qu'on pourrait utiliser une libhal directement.
      • [^] # Re: Phonon était pas prêt

        Posté par . Évalué à 3.

        Parce que gstreamer = phonon ou pulseaudio ? C'est ridicule que ce soit par rapport à la taille du code ou au but recherché (c'est quand même marrant cette critique pour pulseaudio connaissant le discours de lehnnart sur gstreamer).

        Et quant à Pourquoi ne pas utiliser Gstreamer partout ?, c'est une rengaine que je lis depuis avant la 0.6, le résultat était que totem-xine pour lire des dvd c'était bien pendant le bordel de la 0.8, pareil pour phonon-xine et amarok aujourd'hui (dont les devs ont su laisser derrière eux le mantra gstreamer-is-the-only-true-one).
      • [^] # Re: Phonon était pas prêt

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

        > plus limité que ses backends (pas d'accélération matérielle à ce que j'ai entendu)

        qu'est ce que tu veux accelerer materiellement dans pulseaudio ? Si c'est juste le mixage ça n'a à mon avis strictement aucun interet


        Je crois que c'est le syndrôme NIH qui a encore fait des victimes.
        Ils ont l'air bien atteints chez Nokia, d'abord PyQt, maintenant Phonon, qui sera le prochain ?
        • [^] # Re: Phonon était pas prêt

          Posté par . Évalué à 10.

          Avec Pulseaudio tu peux accélerer les crashs et la vitesse de remplissage de son bugzilla !
      • [^] # Re: Phonon était pas prêt

        Posté par . Évalué à -2.

        ils ont pas tort personnellement je trouve que gstreamer marche moins bien que libxine meme si cela s'est ameliore.
        Pour pulseaudio par contre je ne peux que te rejoindre tout ses emmerdes pour pouvoir connecter un casque bluetooth (et ca fonctionne pas terrible en plus) je suis pas sur et certains que cela en valait le coup.

        En ce qui concerne cette annonce je commence a me poser des questions sur Nokia entre pyqt qu'ils ont joliment tue et ca ca commence a faire beaucoup de trucs bizarres. Ils voudraient que linux reparte quelques annees en arriere qu'ils ne pourraient pas s'y prendre autrement.
        • [^] # Re: Phonon était pas prêt

          Posté par . Évalué à 5.

          Peut être qu'au contraire ils vont chercher à faire mieux ? Je ne vois pas trop en quoi ça serait dans leur intérêt de dépenser à refaire lorsque cela n'est pas vraiment nécessaire.

          Cela me semble bien logique pour une vision "embarqué" ce type de couche, afin de faciliter le dev d'applications (et le poids final de chacune, certainement ?). Mais pour un bureau d'un PC, sincèrement je me pose toujours la question : pourquoi autant de couche alors que Alsa fonctionne au poil ?? Dmix mériterai des améliorations, héritées des possibilités de jack certainement, certes. Mais avec ça "on" a une couche basse, base et solide.

          Libre à chaque dev ensuite de passer par SDL / libxine / gstreamer / whatever, éventuellement. Avec ou sans, le tout fonctionnera en étant mixé par un dmix amélioré. Selon moi c'est bien cette couche qu'il faudrait amélioré. La couche primaire.

          Enfin bon, avec un tel bordel, c'est pas demain que des applications grand public seront portées car pas d'assurance de fonctionnement du son. Les applis proprio "pro-audio" (de type www.pianoteq.com !!!) ont choisies Jack de manière naturelle. Quant aux applis de types "dvd fluendo player" (fourni dans le powerpack mandriva) ont choisies Gstreamer. Tandisque Adobe s'est fait ch*** à porter son plugin Flash sur Alsa directement (et ça marche bien).

          Quant aux applis libres, ben c'est le foutoir aussi :( heureusement quasiment toutes supportent Jack. (merci à vous !)

          Pas simple, le son, toujours pas simple. Pourtant un élément crucial pour l'adoption de linux par le grand public.
          • [^] # Re: Phonon était pas prêt

            Posté par . Évalué à 5.

            Alsa est d'ailleurs tellement bas niveau que c'est un bordel à employer pour le commun des mortels. Je pense que beaucoup de gens n'ont pas envie de se palucher un fichier ~/.asound dès qu'il veulent rediriger le son vers le casque audio, bluetooth, enceintes stéréo, 5.1, etc.

            Personnellement, j'en ai assez de voir cette cabale envers Pulseaudio, surtout en avançant dmix comme remède miracle.
            • [^] # Re: Phonon était pas prêt

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

              C'est pas une cabale, pulseaudio fonctionne mal, point...

              Franchement, ca fait des années qu'on me dit que un jour gstreamer sera mature, j'attend toujours... Fait bouffer une collection musical de Windowsien à Rhythmbox, tu vas voir le carnage...

              Donc tant qu'on me prouvera pas le contraire, apt-get --purge remove pulseaudio
              • [^] # Re: Phonon était pas prêt

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

                Le rapport entre tes trois phrases me laisse un peu perplexe…
                C'est la faute de pulseaudio si gstreamer ne lit pas les formats proprio (j'imagine que c'est de ça qu'il s'agit quand tu dis windowsien) ?
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 4.

                C'est quoi une collection musicale de Windowsien ?

                Personnellement, j'ai une petite collection d'un peu plus de 1400 morceaux, le tout en Vorbis q9 et avec les métadonnées parfaitement remplies et agrémentés des pochettes (ce sont mes CD que j'ai encodés), et j'utilise tous les jours Rhythmbox avec Gstreamer pour l'écouter.

                Ce n'est certes pas une collection avec des dizaines de milliers de fichiers, mais je n'ai jamais aucun problème avec ça, ni bugs, ni lenteurs. Tu as essayé les dernières versions avant de critiquer ? Au moins depuis RB 0.10 ?

                Au passage, oui, Gstreamer est parfaitement mature. Et je ne dis pas seulement cela en tant qu'utilisateur, car je m'en sers pour du transcodage tant audio que vidéo.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 2.


                  Au passage, oui, Gstreamer est parfaitement mature. Et je ne dis pas seulement cela en tant qu'utilisateur, car je m'en sers pour du transcodage tant audio que vidéo.


                  Ca rentre dans quel cadre si ce n'est celui d'un utilisateur de faire du transcodage audio et vidéo avec gstreamer ?
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 4.

                    Dans ce cas précis, je me place à mi-chemin entre un utilisateur et un développeur, car j'utilise Gstreamer dans des scripts shells, et ce n'est pas toujours du simple transcodage (ajout de métadonnées, multiples pistes, découpage avec Gnonlin, etc).

                    Mais je ne suis pas non plus développeur, loin de là. Pourtant, il faudrait que m'intéresse à Pygst, car je suis parfois assez limité avec le shell...

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Phonon était pas prêt

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

                      Ben, je suis désolé, mais j'ai installer un Gnome dernièrement, et j'avais voulu laisser gstreamer, j'ai vite déchanté. On m'a vite recontacter pour me dire que y'avait des fichiers qui passaient pas... Depuis j'ai remis libxine et résultat, plus de nouvelles...
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 3.

                        Pas de bol.

                        Je n'ai personnellement jamais de soucis avec Gstreamer, sauf dans deux cas précis :
                        * le plugin MPEG était buggé pendant longtemps et empêchait de se déplacer dans la lecture, mais depuis quelque temps ça marche bien mieux,
                        * pas moyen de lire du Indeo ou d'autres codecs tout pourris disponibles uniquement en 32 bits car je suis en 64 bits; or Mplayer est bien capable de les lire.

                        Pour le reste, aucun problème, même les WMV ou les MOV.

                        C'était quoi comme fichiers ?

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: Phonon était pas prêt

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

                          Des films, j'ai pas regarder le format...

                          Enfin ca fonctionnait avec Xine...

                          Et pour Rhythmbox, des mp3 et des wmv où gstreamer faisait semblant de le lire... => La barre de progression avancé mais sans son.
            • [^] # Re: Phonon était pas prêt

              Posté par . Évalué à 1.

              C'est pas complique pulseaudio c'est 50% de personne qui l'adore 50% de personne qui le deteste. C'est peut etre chouette comme techno mais je dirais que cela ne fait pas l'unanimite loin de la.

              Je ne dis pas que le son n'est pas un bordel inommable sous linux mais depuis pulseaudio les problemes qui avaient disparu en 99 sont de retour et cela redevient la croix et la banniere pour faire marcher certaines applications avec. N'y avait il pas plus simple que rajouter une couche tres complexe tel que celle la?

              Decris moi donc les avantages uniques a PA (en dehors du casque bluetooth dont on nous serine depuis des mois alors que cela n'a commence a fonctionner qu'avec F11) de ce truc. Cela fais plus de 1 an que l'on casse les pieds a pas mal d'utilisateur pour un truc qui apporte une seule avancees? Ca fait long pour pas beaucoup d'avantage.
              • [^] # Re: Phonon était pas prêt

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

                Le son par le réseau ?
                Avoir deux cartes sons, une branchée à l'ampli Hi-Fi dans le salon, l'autre à des enceintes à 10€, et avoir les sons normaux sur les enceintes pourries, et la musique sur l'ampli sans avoir à coder spécifiquement une page de configuration pour choisir la carte son dans chaque appli ?
                Avoir un mixer par application sans le recoder dans chacune des applis, qui plus est centralisé ?
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 2.

                  Le son par le reseau cela se fait autrement j'ai bien dit une NOUVELLE fonctionnalite. Apres que cela soit un peu complexe c'est un autre probleme la caracteristique existe deja et pourrait tout a fait etre user-friendly. De plus allez que l'on rigole faisons un sondage de combien de personne ont besoin de ce genre de fonctionnalite et faisons un sondage de combien se font !@#!# par PA depuis son apparition. Les benefices me semblent toujours tres faible par rapport aux problemes introduit (sans compter les trous de securite que cela a introduit dernierement).
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 2.

                  Laisse moi rire : ces fonctionnalités fonctionnent-elles actuellement ?
                  Pour le son en réseau, j'ai déjà mpd qui marche, merci.
                  Pour l'autre (un mixer par application) je ne l'ai jamais vu marcher (debian sid).
                  Et "sans recoder", excuse moi mais il me semble qu'il faut justement utiliser l'API de PA pour en profiter ...
                  • [^] # Re: Phonon était pas prêt

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

                    Pour le son en réseau, j'ai déjà mpd qui marche, merci.

                    Merveilleux. Moi j'utilise amarok. J'utilise un terminal léger (XDMCP) mais je veux que le son revienne sur mon terminal (sauf amarok, justement). Je suis au bureau, j'écoute de la musique, et là, une intro d'un morceau qui déchire : je dis à mon collègue « écoute mon flux réseau », 3 clics, il entends ma musique. Tout ça, aujourd'hui, c'est implémenté. Alors oui, ça ne marche pas toujours, parfois ça plante, etc. Personne ne dit que PA est parfait. Mais PA permet des utilisations que rien d'autre ne permet.

                    Pour l'autre (un mixer par application) je ne l'ai jamais vu marcher (debian sid).

                    Chez moi ça marche. Malheureusement je t'accorde que ce n'est pas le cas partout. Je veux juste faire remarquer que pa a une utilité, même s'il ne marche pas parfaitement, et que l'abandonner complètement est une mauvaise idée.

                    Et "sans recoder", excuse moi mais il me semble qu'il faut justement utiliser l'API de PA pour en profiter ...

                    C'est là tout l'intérêt d'un framework comme Phonon, s'abstraire de la sortie audio utilisée (alsa, oss, pa). En tant qu'auteur d'application, tu lis un fichier avec une api simple et c'est tout. En tant qu'utilisateur, toutes tes applis qui utilisent Phonon peuvent en trois clics utiliser PA, ou alsa si PA ne marche pas.
                    • [^] # Re: Phonon était pas prêt

                      Posté par . Évalué à 2.

                      Pour les deux premiers points, ça ne marche pas chez moi en tous cas. Et je n'ai encore jamais vu quelqu'un en parler correctement, à part toi.
                      Alors, avoir un framework qui ne m'apporte rien et en plus fait déconner ce qui marchait bien avant, non merci (autant ceux qui apportent des trucs nouveaux en cassant un peu les anciens, pourquoi pas, mais là, non).

                      Sinon pour ta dernière remarque, on parlait de PA, pas Phonon, et tu disais :
                      Avoir un mixer par application sans le recoder dans chacune des applis, qui plus est centralisé ?
                      Ce qui est faux : il faut recoder les applications.
                      • [^] # Re: Phonon était pas prêt

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

                        Ça fait deux fois que tu dis que pulseaudio est un framework, alors que pulseaudio est un serveur de son. C'est une appli stand-alone.

                        Seconde chose, s'il ne t'apporte rien, configure tes applis pour ne pas l'utiliser (c'est là que phonon génial, quand PA plante et que ça me gonfle, trois clics et toutes les applis KDE utilisent alsa directement).

                        Sinon pour ta dernière remarque, on parlait de PA, pas Phonon, et tu disais :
                        Avoir un mixer par application sans le recoder dans chacune des applis, qui plus est centralisé ?
                        Ce qui est faux : il faut recoder les applications.


                        Non, ce que je dis c'est que les applis qui utilisent un framework de son (gstream, xine) ou une couche d'abstraction de ces framework de son (Phonon) n'ont pas besoin d'être recodées.

                        Ma remarque, c'était : tu codes une fois le backend pulseaudio dans ton framework favori, et toutes les applis disposent à présent d'un contrôle de volume indépendant. Pas besoin, dans chaque appli, de recoder un slider machin, qui appelle les fonctions du framework de son qui vont bien etc, sans compter qu'un tel contrôle n'est pas forcément intégrable, par exemple pour les notifications du bureau. Avec pulseaudio, j'ai mon appli dans la barre des taches, je cliquouille, je peux diminuer le son des notifs qui est trop fort par rapport à la musique. Pourtant, aucun code spécifique au contrôle du volume dans knotify.
                        • [^] # Re: Phonon était pas prêt

                          Posté par . Évalué à 2.

                          OK, c'est aussi un appli. Mais si des applis comme mplayer ont aussi une sortie son "pulseaudio", c'est que pour moi il y a une lib/framework derrière.

                          Ensuite, si je veux pas que mes applis l'utilisent, bah je ne peux pas puisqu'il bloque la sortie alsa. Ma solution : killall pulseaudio.

                          Non, ce que je dis c'est que les applis qui utilisent un framework de son (gstream, xine) ou une couche d'abstraction de ces framework de son (Phonon) n'ont pas besoin d'être recodées.

                          Ma remarque, c'était : tu codes une fois le backend pulseaudio dans ton framework favori, et toutes les applis disposent à présent d'un contrôle de volume indépendant. Pas besoin, dans chaque appli, de recoder un slider machin, qui appelle les fonctions du framework de son qui vont bien etc, sans compter qu'un tel contrôle n'est pas forcément intégrable, par exemple pour les notifications du bureau. Avec pulseaudio, j'ai mon appli dans la barre des taches, je cliquouille, je peux diminuer le son des notifs qui est trop fort par rapport à la musique. Pourtant, aucun code spécifique au contrôle du volume dans knotify.

                          Ha ok, merci de l'explication, je ne l'avais pas compris comme ça (je parlais d'applis "simples" qui utilisent alsa/oss). Effectivement, dans ce cas là, c'est en gros avantage (quand ça marche ...)
                • [^] # Re: Phonon était pas prêt

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

                  > sans avoir à coder spécifiquement une page de configuration pour choisir la
                  > carte son dans chaque appli

                  Ca s'appelle phonon ton truc... Et ca fonctionne avec Alsa...

                  Donc, pulseaudio ne résoud rien vu que Kde le propose sans ce dernier et sans couche lourde...
                  • [^] # Re: Phonon était pas prêt

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

                    On ne peut pas changer de carte son à la volée avec Phonon.
                    • [^] # Re: Phonon était pas prêt

                      Posté par . Évalué à 2.

                      Ce qui est bien évidemment une fonctionnalité très utilisée d'après toi ?
                      Je me demande combien de personnes ont deux cartes sons...

                      Je précise : le fait que tu aies ce besoin démontre qu'il faudrait s'y intéresser. Maintenant, je ne suis pas sûr que ça soit prioritaire.
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 4.

                        tout ceux qui ont des radeon HD et une carte mere avec controleur son intégré
                        tout ceux qui ont une vrai carte son et une carte mere avec controleur son intégré
                        Et je suppose que les nvidia font comme les ati.

                        Ça commence à en faire...

                        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                        • [^] # Re: Phonon était pas prêt

                          Posté par . Évalué à 2.

                          Oui et combien switch d'une carte son a l'autre tous les jours? Parceque avoir deux cartes sons j'ai connus mais je n'utilisais curieusement que la meilleur (c'est a dire pas celle sur la carte mere). C'etais il y a plus de 5 ans...
                          • [^] # Re: Phonon était pas prêt

                            Posté par . Évalué à 2.

                            combien switch d'une carte son a l'autre tous les jours?

                            Personne, puisque la possibilité n'était pas simple à mettre en place. S'il suffit d'une case à cocher pour le faire, qui te dit que maintenant de nombreuses personnes ne se disent pas « tiens, c'est intéressant comme feature ».

                            Après tout, puisque tu as deux cartes, tu as maintenant la possibilité d'utiliser les deux plutôt qu'une. Il est où le problème ?

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                            • [^] # Re: Phonon était pas prêt

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

                              je dirais que le problème n'est pas là.
                              C'est bien beau de permettre de switcher entre deux cartes son ... mais ça serait déjà vraiment bien si ça marchait avec une seule...

                              Je pense que c'est surtout ça qui est reproché, y'a plein de features top moumout mais le truc de base ... ben c'est pas glop du tout
                            • [^] # Re: Phonon était pas prêt

                              Posté par . Évalué à -1.

                              Bon ok tu as la possibilite de le faire (si ca marche car comme tous les trucs "sexy" de PA c'est pas certains) mais QUI va s'en servir et cela sert a quoi concretement? Tu as une carte super bien et une carte pouurri (celle sur la carte mere), qui va penser "Tiens aujourd'hui je m'ecoute la Traviata en mode pourri, c'est super cool PA me permet de le faire et hop je switch ca, je me penche derriere mon ordi et je rebranche tous mes cables comme il faut. Ah trop bon cette Traviata avec la moitie des sons deforme".
                              • [^] # Re: Phonon était pas prêt

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

                                cela sert a quoi concretement?

                                J'ai une carte son reliée à ampli et des enceintes.
                                Quand j'aurais un peu d'argent (d'ici là, peut-être que pulseaudio marchera correctement !), je m'offrirais un bon casque avec une bonne carte son/ampli externe (mon ampli ne rend pas bien avec le casque de mes rêves).
                                Le scénario est le suivant : j'écoute de la musique sur mes enceintes, le voisin tape au mur pour me faire comprendre qu'il est tard, pouf, trois clics, j'ai le son sur mon casque sans aller changer ni la conf ni redémarrer mon lecteur audio favori.
                                • [^] # Re: Phonon était pas prêt

                                  Posté par . Évalué à 3.

                                  Il a dit "concrètement".

                                  Parce que là, tu va switcher ta carte pour la soirée, et juste plugger le casque sur ta carte met 3 secondes...
                                  Concrètement, à quoi sert de switcher d'une carte son à une autre ?
                                  • [^] # Re: Phonon était pas prêt

                                    Posté par . Évalué à 1.

                                    Je peux comprendre le cas. Moi aussi, j'ai une radeon HD sur laquelle j'ai une sortie en HDMI. Je m'intéressais justement au fait de mettre un film directement sur ma télévision avec le son et laisser l'ordinateur tranquillement connecté sur ses amplis/carte son de la carte mère.

                                    Cependant, je suis bien conscient que régler les problèmes de base avec une carte son sont beaucoup plus important que gérer les multiples cartes son car je me considère comme ultra-minoritaire.
                                    • [^] # Re: Phonon était pas prêt

                                      Posté par . Évalué à 1.

                                      ca c'est peut etre la premiere reponse non theorique sur le sujet et ou je vois un interet mais bon cela ne change pas le fait que c'etait faisable avant PA (de facon complique mais est ce faire un GUI pour creer les fichiers de confs automatiquement n'aurait pas ete plus simple?)
                                      • [^] # Re: Phonon était pas prêt

                                        Posté par . Évalué à 2.

                                        Je suis d'accord avec toi : il existait surement des solutions plus simples à mettre en oeuvre que recoder un serveur de son.
                                        • [^] # Re: Phonon était pas prêt

                                          Posté par . Évalué à 2.

                                          Ben voila c'est ce que toutes les personnes ayant des ennuis avec PA s'obstine a dire. PA n'apporte rien qui n'aurait pu etre fait d'une facon differente et plus simplement. Donc de la part d'un utilisateur linux a 100% depuis plus de 10 ans, je trouve que PA apporte plus d'ennuis (je reste poli) que d'avantages. C'est, a mon avis, l'equivalent gnome de arts qui devait etre capable de faire tout cela mais qui etait tellement complexe qu'il en est mort, paix a son ame. (Tiens c'est rigolo je viens de m'apercevoir que a l'epoque une des premieres choses que je faisais sous kde c'etait de decocher l'utilisation de cela... comme quoi meme probleme meme attitude!).
                                  • [^] # Re: Phonon était pas prêt

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

                                    Concrètement, à quoi sert de switcher d'une carte son à une autre ?

                                    Le casque en question nécessite un ampli et n'a qu'une seule sortie analogique, donc plugger le casque sur la même carte son demande à aller trifouiller derrière le pc pour changer l'ampli branché sur la carte son.
                                • [^] # Re: Phonon était pas prêt

                                  Posté par . Évalué à 2.

                                  Perso j'ai deux sorties sur ma carte son (intégrée à ma CM). Mes enceintes sont sur la sortie arrière, mon casque sur la sortie avant. J'ai un script de deux lignes qui bascule entre les deux sorties (enfin qui mute l'une et un-mute l'autre, alternativement). Une fois attaché à un raccourci KDE (ou à une icône), je satisfait mon voisin encore plus rapidement que toi. Et sans rien d'autre qu'Alsa.
                          • [^] # Re: Phonon était pas prêt

                            Posté par . Évalué à 2.

                            C'est très facile : ceux qui utilisent un micro-casque USB pour faire du Skype.

                            Le micro-casque une fois branché est reconnu comme une carte son vers laquelle on veut que les sons aillent.

                            BeOS le faisait il y a 15 ans !

                            • [^] # Re: Phonon était pas prêt

                              Posté par . Évalué à -1.

                              sachant que le skype fonctionnant avec PA vient a peine de sortir en version beta, qu'ils fonctionnent pas chez tous le monde et que il est bien plantogene je ne pense pas que cette exemple soit le bon desole.
                              • [^] # Re: Phonon était pas prêt

                                Posté par . Évalué à 5.

                                On s'en fout que ça ne marche pas encore : tu as demandé un exemple d'utilisation qui rend légitime le développe de PulseAudio, on t'en donne un, point.

                                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                                • [^] # Re: Phonon était pas prêt

                                  Posté par . Évalué à -1.

                                  Tu veux vraiment que je ressorte les messages du devs de PA sur a propos de skype? Parceque tu as pas de chance il dit clairement que skype il en a rien a battre.

                                  ps: l'agressivite ne mene a rien.
                                • [^] # Re: Phonon était pas prêt

                                  Posté par . Évalué à -2.

                                  puis comme dit par d'autres que ce soit avec phonon ou avec alsa c'est faisable cet exemple donc il n'existe AUCUN exemple d'une specificite particuliere de PA qui ne soit pas deja realisable par un moyen ou un autre sans cette couche.
                    • [^] # Re: Phonon était pas prêt

                      Posté par . Évalué à 1.

                      Bah si, c'est même une des fonctionnalité première de Phonon: http://media.photobucket.com/image/kde%20systemsettings%20ph(...)
            • [^] # Re: Phonon était pas prêt

              Posté par . Évalué à 3.

              Pas de cabale ni de remêde miracle, malheureusement.

              un constat : pulseaudio ajoute une couche et ne résoud rien (en plus marchouille, mais ça c'est déjà un autre sujet, et plutôt polémique).

              une question aux experts : amélioré dmix n'est il pas une meilleure solution ?
              une question aux experts : ajouter une couche, la meilleure soit elle, par dessus un dmix par terrible, n'est pas ce pas demandé à un haut niveau de corriger les manquements du bas niveau ? si oui, est ce beau ? (vraie question et j'écoute les réponses)

              le constat qui me fait me poser ces questions :
              pulse n' a rien résolu.
              jack est meilleur (empreinte miniscule, encaisse les faibles latences) techniquement, mais sur le bureau on reste dans ce que tu décris aussi "je pense que beaucoup de gens n'ont pas envie de se palucher .jackrc et les sessions jack"
              Les deux pourraient être ensemble, mais ça fait deux couches.

              Il n'y a vraiment aucune cabale de ma part à l'égard de pulseaudio, faut pas sortir les grands mots permettant d'accuser les autres de mauvaise foi comme seul argument pour défendre un truc qui marche pas. moi aussi j'en ai marre.
              • [^] # Re: Phonon était pas prêt

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

                jack est meilleur

                C'est surtout que jack n'a rien à voir avec pulseaudio, jack c'est du routage (la sortie de l'appli A va dans la sortie de l'appli B), pulseaudio c'est un serveur de son (mixage, réseau, gestion fine des cartes son…). En combinant des modules de pa entre eux on arrive à des choses très sympa qui ne sont pas du tout possible avec jack (et c'est normal, jack n'a pas le même but).

                pulse n' a rien résolu

                Si, dans la mesure ou beaucoup de choses qui n'étaient pas possible avant sont maintenant possible (quand ça marche ;) ). Dans un environnement multi-machines, ou les setup sons deviennent complexes (PC dans le salon relié à une chaîne Hi-Fi, casque USB/bluetooth, terminaux légers), c'est quand même extrêmement pratique, et il n'y a pas d'équivalent à pulseaudio sous Linux.
                • [^] # Re: Phonon était pas prêt

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

                  >En combinant des modules de pa entre eux on arrive à des choses très sympa

                  Je ne dis pas le contraire...

                  Mais y'a combien de personne qui ont besoin des fonctions de pa et combien qui ont juste besoin que le son fonctionne ?

                  Parce que le problème, c'est bien qu'il n'est plus possible d'avoir du son correct si la machine est chargée.
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à -2.

                    Mais y'a combien de personne qui ont besoin des fonctions de pa et combien qui ont juste besoin que le son fonctionne ?

                    Combien ont besoin d'un navigateur avec des onglets, et combien ont juste besoin d'ouvrir une page à la fois ?

                    Combien ont besoin d'un navigateur de fichier qui puisse découper sa fenêtre en trente-six cadres sur autant de dossiers différents, et combien veulent juste voir leur fichiers ?

                    Combien ont besoin d'afficher les paroles de ce qu'ils écoutent, et combien ont juste envie d'écouter leur musique ?

                    Combien veulent un système entièrement libre, et combien ont juste besoin d'un ordinateur qui fonctionne à l'achat ?

                    Etc, etc.

                    Avec des raisonnements pareils, il n'y aurait plus d'innovation, plus de recherche, plus rien. Si on n'essaie pas d'innover, comment peut-on savoir si ça va plaire ou être utile à quelqu'un ?

                    Et surtout, surtout, comment se démarquer de la concurrence, qui elle continue d'évoluer ?

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Phonon était pas prêt

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

                      J'ai pas dit qu'il fallait abandonné pulseaudio...

                      Ce que je ne comprend pas, c'est pourquoi par exemple ubuntu veut l'imposer dans la prochaine version karmic.

                      Il fonctionnerait sans problèmes, je dis pas...
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 2.

                        D'ac, je n'avais pas compris comme ça.

                        Je n'utilise pas moi-même PulseAudio, car je pense qu'il n'est pas encore mûr, mais j'ai plutôt l'impression que c'est dû à un manque d'intégration dans l'environnement de bureau qu'à des problèmes au niveau de l'application.

                        Je pense que si Ubuntu tient absolument à l'intégrer, c'est parce que tout le monde le fait (au moins Mandriva, Fedora, Suse, etc), et qu'ils ne peuvent pas se permettre d'être à la traîne.

                        Après, si personne ne s'en sert, ça va être assez difficile de lui permettre de mûrir. Il faut passer par une phase debuggage, et donc par une phase d'intégration et de tests grandeur nature.

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                        • [^] # Re: Phonon était pas prêt

                          Posté par . Évalué à 0.

                          Cela fait plus de un an et demi que l'on nous serine cela. Cela commence a faire long pour integrer un serveur de son. Meme kde4 a mis moins de temps pour se stabiliser...

                          Actuellement le constat est simple depuis 1 an et demi Fedora et ubuntu ont mis PA par defaut et c'est la merdouille. Les inconvenients ont les a et a peu pres aucun des avantages clames ne fonctionnent ou fonctionnent quand ca veut. Franchement j'ai l'impression de me retrouver dix ans en arriere avec OSS/Alsa.
                          • [^] # Re: Phonon était pas prêt

                            Posté par . Évalué à 2.

                            Meme kde4 a mis moins de temps pour se stabiliser...

                            Et ça s'est fait tout seul, où a-t-il fallu que des distribs l'intègrent et que les utilisateurs l'essayent ?

                            Franchement j'ai l'impression de me retrouver dix ans en arriere avec OSS/Alsa.

                            Ben ne l'utilise pas. Après tout, tu as encore le choix entre Alsa et OSS, et laisse ceux qui veulent se servir de PA y trouver leur compte.

                            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                            • [^] # Re: Phonon était pas prêt

                              Posté par . Évalué à 1.

                              Et ça s'est fait tout seul, où a-t-il fallu que des distribs l'intègrent et que les utilisateurs l'essayent ?

                              La phase de test a ete moins longue et KDE4 c'est "legerement" plus que un serveur de son.

                              Ben ne l'utilise pas.

                              C'est ce qui passe chez moi. Je teste de temps en temps pour voir si cela marche mieux mais chaque fois cela se termine par enlever ce truc.

                              ps: je suis pas sur que remonte les bugs sur le sujet servent a quelque chose. Que ce soit sous Fedora ou Ubuntu c'est le silence plat sur le bugzilla et launchpad (ceci n'est pas specifique a PA, il y a juste trop de bug remonte)
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 1.

                        Ce que je ne comprend pas, c'est pourquoi par exemple ubuntu veut l'imposer dans la prochaine version karmic.

                        parceque Gnome a decide que le control de volume utiliserait PA et plus alsa....
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 3.

                ...beaucoup de gens n'ont pas envie de se palucher .jackrc et les sessions jack
                Uh, jamais vu.

                Le propre de Jack, c'est justement de posséder tout un tas d'interfaces graphiques bien foutues (qjackctl notamment) qui permettent de contrôler en deux ou trois clics le fonctionnement du serveur les patchs et le fichier .jacdrc.

                Jackd est plutôt un serveur-patcheur de son en temps réel qui répond à la norme MIDI. Il est plus utile à un studio de son qu'à un bureau.
                • [^] # Re: Phonon était pas prêt

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

                  Sauf que Jackd traite TOUT en virgule flotante donc totalement inutilisable sur machine sans FPU (ARM par exemple) donc exit jackd sur autre chose que i386/PCC (téléphone, MID, etc..).
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 2.

                    Doucement, les ARM modernes ont une FPU ... http://en.wikipedia.org/wiki/ARM_architecture#VFP
                    • [^] # Re: Phonon était pas prêt

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

                      Tu déconne ? C'est loin, très loin d'être la norme.
                      S3C24xx pas de FPU,
                      PXAxxx pas de FPU,
                      IMX27 pas de FPU,
                      AT91.. pas de FPU,
                      et encore je parle pas des ARM7, ou des blackfins..
                      Plein d'ARM11 n'ont pas de FPU.
                      De même que plein de CPU utilisés dans les lecteurs MP3, téléphones, PDA sous linux.

                      Sorti de l'IMX31 et des derniers OMAP il y a pas beaucoup de SOC/CPU a base de coeur ARM avec FPU.
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 3.

                        Bon, j'ai mal dit ce que je pensais : on trouve un certains nombre d'ARM avec FPU, et donc on ne peut pas dire que jack est importable sur ARM ... Après, faut voir sur quel genre d'embarqué on veut avoir jack : ça vise plutôt le "haut de gamme" selon moi, et il y a plus du chances qu'il y ait une FPU à ce moment là.
            • [^] # Re: Phonon était pas prêt

              Posté par . Évalué à 1.

              Moi ce qui me casse les burnes avec PA, c'est qu'il empêche tout autre système de fonctionner en parallèle.

              Quand tu as gstreamer, tu peux choisir de l'utiliser ou non pour lire une vidéo (genre utiliser directement mplayer).

              Quand j'ai pulseaudio de lancé, il me bloque complètement les sorties alsa à toutes les autres applis. Alors qu'avant, plusieurs applis pouvaient se partager le périph alsa sans problème. Pourquoi ne peut-il pas juste faire comme les autres, au lieu de vouloir passer au dessus des autres ?

              C'est le principe de base de tous les nouveaux frameworks : laisser la possibilité d'utiliser les anciens, ou cas où l'utilisateur en ait envie (ou que le nouveau framework en question lui casse les couilles : je suis d'habitude qqun qui accepte de tester quelques temps avant de jeter une appli (j'ai eu du mal avec gstreamer au début, mais aujourd'hui je trouve qu'il est vraiment très bien) mais la non, j'ai aptitude purge pulseaudio il y a deux jours parce que j'en avait marre d'avoir des merdes partout (genre mplayer qui n'arrive pas à utiliser PA, qui veut passer par alsa mais qui est bloqué par PA, et qui tombe sur OSS qui marchotte de temps en temps, je suppose à cause de PA : ça fait un peu trop pour un seul homme, donc bye bye PA)).
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 3.

                regarde ton ficheir .asoundrc ... je te parie qu'il ne connait plus qu'une fonction : pulseaudio.
                Modifie le, tout en conservant pulseaudio dedans, mais en remettant les éléments "en ordre", et il pourra y avoir un accès concurentiel sur alsa avec un pulseaudio qui tourne.

                pas besoin de commenter je crois ;)
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 2.

                  Je n'ai pas d'asoundrc. Tout est par défaut, et ça marchait très bien avant que PA arrive.
                  Si quelqu'un me dit que ça marche bien dans une autre distro que Debian, je veux bien accepter que c'est l'intégration dans Debian qui est pourrie. Mais je ne vois pas grand chose qui marche pour l'instant, nulle part.
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 4.

                    Je ne sais pas comme ça, mais franchement je ne pense pas que cela soit l'intégration dans Debian qui soit pourrie. Même si cette intégration n'est pas parfaite, PA doit en faire pas mal par lui même :(
                    Par exemple sur Mandriva, qui a dès le départ soutenu PA, dont l'intégration est sans reproche, en plus quelque soit le bureau, et qui dispose même d'un développeur consacré (Colin Guthrie), ben même dans cette situation idéale, PA consomme du cpu plus java et flash réuni (j'exagère mais c'est impressionnant de voir autant de conso cpu juste pour mixer deux sources). PA en est bien cause, en lui même.

                    Si tu n'a pas de .asoundrc dans le ~, peux tu regarder du côté de asound.state (ou équivalent) quelquepart dans /etc ? Par exemple, dans le mien, sur le netbook, j'ai un paragraphe simple pour state.TuxDroid et un très complet pour state.Intel (et rien à propos de PA :p )

                    Bon heu ça en vient presque à faire du ""support"" Pulse pour Debian sur une dépêche parlant de Phonon et de la politique de Nokia. heu, désolé... je sort :honte:
                    • [^] # Re: Phonon était pas prêt

                      Posté par . Évalué à 2.

                      OK, merci pour le support quand même, même si c'est HS ;-)
                      J'attend que PA revienne par une dépendance (parce qu'à mon avis ça va arriver un jour ...) avant de m'y relancer, quand même.
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 2.

                    Ben moi de mon côté, tout est parfait. Carte télé et carte son. Tous mes petits y trouvent leur compte sans problème. Pourtant sur ma Mandriva, je n'ai rien bricolé. Tout s'est mis en place lors de la mise à jour de la 2008.1 à la 2009.0 et ensuite à la 2009.1. Chanceux peut-être, je sais pas, mais PulseAudio, ça marche chez moi :)
        • [^] # Re: Phonon était pas prêt

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

          En meme temps PyQt c'est un probleme de license, pas de code comme avec Phonon. Ils ont discuté avec Riverbank mais si l'auteur original ne veut pas changer de license, il n'y a pas 36 milles solutions...

          Il faut bien dissocier probleme technique et probleme "politique".

          De toute facon on verra avec le temps si l'excuse des problemes techniques de Phonon est justifiée ou pas.

          En tout cas Matthias Kretz et les autres (dont moi) qui ont passe du temps sur Phonon doivent l'avoir un peu en travers.
          Nokia a vraiment tres tres mal communiqué sur ce coup la, ils sont en train de braquer les devs de Phonon contre eux :/
          • [^] # Re: Phonon était pas prêt

            Posté par . Évalué à 3.

            > Ils ont discuté avec Riverbank mais si l'auteur original ne veut pas changer de license, il n'y a pas 36 milles solutions...

            L'autre solution, c'était que Nokia arrête d'être pleure-pain et allonge un peu plus de monnaie.
            Phil Thompson était ouvert à un changement de licence tant que ça lui permettait de gagner sa vie. Qt n'est passé en LGPL qu'après le rachat par Nokia, parce que Qt n'est pas la principale source de revenu de Nokia, alors PyQt c'est la principale source de revenu de Riverbank.

            > Nokia a vraiment tres tres mal communiqué sur ce coup la, ils sont en train de braquer les devs de Phonon contre eux :/

            Nokia n'a rien communiqué, ce sont des développeurs sur leurs blogs.
            1. l'API multimédia est une API bas-niveau sur laquelle pourra s'appuyer Phonon. Les deux APIs ne sont pas en concurrence.
            2. l'API multimédia est encore en cours de gestation
            3. le concurrent de Phonon est l'API QtMobility Multimédia qui reposera sur l'API précédente.
            QtMobility est un projet R&D pour définir des APIs communes pour les applications mobiles (Windows CE, Symbian, Maemo). Et cette API ne fait pas partie de Qt 4.6
            L'embarqué est une cible majeure pour Nokia (c'est même la raison même de l'acquisition de Trolltech), or Phonon et ses backends ne sont pas adaptés aux mobiles. D'où l'arrivée d'une nouvelle API bas-niveau qui permettra d'accèder aux périphériques bas-niveau (chip audio, caméra etc ...), de développer des applications multimédias nécessitant plus de performances (ie: VoIP), et d'une API haut-niveau pour le playback.

            L'auteur du billet s'est "emballé":
            * rien ne garantit que QtMobility sera intégré à l'édition "Desktop" de Qt.
            * Phonon est maintenu pour toute la durée de vie de Qt4. Et M. Ettrich estimait dans une interview que la prochaine réécriture de Qt n'aurait pas lieu avant 2012.
            * Phonon est maintenu par KDE, Trolltech se synchronise régulièrement sur leur branche et maintient quelques backends. On peut envisager que Phonon ait une existence séparé de Qt, techniquement, ça se fait très bien.
            • [^] # Re: Phonon était pas prêt

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

              > L'auteur du billet s'est "emballé":

              C'est moi l'auteur du journal.

              > 1. l'API multimédia est une API bas-niveau sur laquelle pourra s'appuyer Phonon.
              > Les deux APIs ne sont pas en concurrence.

              Ce journal parle uniquement de QtMobility, je connais parfaitement QtMultimedia fournit avec Qt-4.6 http://doc.trolltech.com/4.6-snapshot/qtmultimedia.html
              A aucun moment je n'ai fait reference a QtMultimedia.

              > rien ne garantit que QtMobility sera intégré à l'édition "Desktop" de Qt.

              Ce n'est pas encore fait, mais l'objectif est plutot clair :

              Like all of the Mobility projects, the QtMobility Multimedia API is targeted to merge with Qt at some future date, which has not been decided yet.
              http://labs.trolltech.com/blogs/2009/09/09/multimedia-in-qt-(...)

              Et dans le premier blog (http://labs.trolltech.com/blogs/2009/09/03/multimedia/ )

              The new QtMultimedia APIs were designed after much consideration of developer needs for extensibility, much more functionality (not least Video/Audio Capture) and of course plaform flexibility. The decision to build something new rather than completely re-architect Phonon was something the Qt development team thought long and hard about. But a new architecture is seen as the best solution to meet developer need

              It is intended that they will become part of Qt at some future point once we have completed

              Je ne pense donc pas m'etre "emballé". Au contraire, si tout se passe comme prevu, un hypothetique Qt 5 ne contiendra plus Phonon mais QtMobility Multimedia a la place.

              Pour info je connais tres bien Phonon, je l'utilise et je contribue au code.
              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 3.

                > C'est moi l'auteur du journal.

                J'ai bien dit "billet", pas du journal. Si tu préfères, c'est l'employé de Nokia qui s'est emballé parce que rien n'est fait.
                Le journal en lui-même est conforme aux standards du site.


                > Ce n'est pas encore fait, mais l'objectif est plutot clair :

                Encore une fois, c'est une affirmation faite par un des développeurs et non pas par Nokia.
                QtMobility est un jeu d'API destinés aux appareils mobiles et plus particulièrement aux système WinCE, Symbian et Maemo.
                http://labs.trolltech.com/page/Projects/QtMobility
                Certes, il est probable que QtMobility soit intégré plus tard, mais sous quelle forme (dans une édition "tout-en-un", dans une édition " mobile") ? Est-ce que ça remplacera effectivement Phonon ? Pour le moment, le "Phonon-killer", il casse pas trois pattes à un canard, le temps qu'il soit utilisable, Phonon aura bien évolué mais ça tu le sais probablement mieux que moi.
                C'est un projet R&D et de l'aveu du mec, ils n'ont même pas de roadmap.
                "Un jour, on va l'inclure dans Qt comme c'est prévu pour les autres projets Mobility. Comme QtMobility Multimedia entre en concurrence avec Phonon, on en éliminera un".
                Le mec, il bosse sur QtMobility Multimedia, forcément, il espère que son bidule éliminera l'autre truc. Si tu demandes aux mecs qui bossent sur Phonon chez Nokia, ils te diront le contraire. Vu l'avancement du projet, rien n'est joué.

                > si tout se passe comme prevu, un hypothetique Qt 5 ne contiendra plus Phonon mais QtMobility Multimedia a la place.

                Faudra qu'il surpasse Phonon d'abord, mais d'ici là, on a le temps de voir venir.
                Et si c'est vraiment mieux, de quoi peut-on se plaindre après tout.

                > Pour info je connais tres bien Phonon, je l'utilise et je contribue au code.

                Raison de plus, pour ne pas faire paniquer les foules.
                • [^] # Re: Phonon était pas prêt

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

                  En general les developpeurs dans une entreprise ne codent pas ce qu'ils veulent. QtMobility Multimedia n'a pas ete voulu par un gus dans ce coin qui a ensuite posté une news tout seul sur un blog hyper-visité.

                  The decision to build something new rather than completely re-architect Phonon was something the Qt development team thought long and hard about.

                  > Si tu demandes aux mecs qui bossent sur Phonon chez Nokia

                  Nokia ne contribue pas.

                  > le temps qu'il soit utilisable, Phonon aura bien évolué

                  Phonon est au point mort en ce moment (nouveau mainteneur, Kretz n'a plus le temps)
                  Nokia a des developpeurs paye a plein temps pour bosser sur QtMobility.
                  • [^] # Re: Phonon était pas prêt

                    Posté par . Évalué à 2.

                    > En general les developpeurs dans une entreprise ne codent pas ce qu'ils veulent.

                    C'est un projet R&D destiné à écrire des APIs pour des appareils mobiles.

                    > Nokia ne contribue pas.

                    Les backends Gstreamer, Quicktime et DirectShow se sont écrits tout seuls ?

                    > Phonon est au point mort en ce moment (nouveau mainteneur, Kretz n'a plus le temps)

                    alors, si le mainteneur n'a plus le temps, il dégage et laisse sa place à un autre.
                    • [^] # Re: Phonon était pas prêt

                      Posté par . Évalué à 5.

                      alors, si le mainteneur n'a plus le temps, il dégage et laisse sa place à un autre.

                      Bonjour la reconnaissance!
                      Les développeurs ne sont pas des kleenex que l'on jette après usage.
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à 6.

                        C'est surtout de l'hypocrisie.
                        On peut être reconnaissant pour les efforts fournis, mais c'est du logiciel libre, baby !
                        Passer la main à d'autres, c'est le rôle d'un mainteneur de LL quand il abandonne un projet (désintérêt, manque de temps, décés, transformation en loup-garou, etc ...), ça fait partie du cycle de la vie.
                        Sinon, on n'avancerait jamais, c'est valable pour le logiciel libre comme dans First Life ...
                      • [^] # Re: Phonon était pas prêt

                        Posté par . Évalué à -1.

                        Qu'est ce que ca a voir avec la reconnaissance?
                        Si le mec n'a pas le temps d'assumer ses responsabilites, il les passe a quelqu'un d'autre.
                    • [^] # Re: Phonon était pas prêt

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

                      Nokia ne contribue plus si tu preferes.
                      Depuis l'integration de Phonon dans Qt (mai 2008), Phonon lui meme (pas les backends) n'a pas changé.
          • [^] # Re: Phonon était pas prêt

            Posté par . Évalué à 4.

            Moi j'ai beaucoup aimé (et continue) les petites notifications, les premières fois que j'ai vu ces notifications sur kde4 c'était pour dire un truc de genre : "le système a basculé sur Jack"
            Je clique sur plein de trucs : tout marche \o/ for-mi-da-ble pour l'utilisateur que je suis ! merci.
        • [^] # Re: Phonon était pas prêt

          Posté par . Évalué à 4.

          Pulseaudio c'est un peu comme KDE4.1:
          C'était absolument pas prêt à être utilisé, mais comme c'est hype et que tout le monde en parle, les distros se sont fait un devoir de l'intégrer le plus vite possible.

          Donc perso, ça va attendre un moment avant que je ne l'essaie (j'essaie assez de trucs tordus comme ça, peux pas tout faire, même sur une Sid!).
          • [^] # Re: Phonon était pas prêt

            Posté par . Évalué à 3.

            > C'était absolument pas prêt à être utilisé, mais comme c'est hype et que tout le monde en parle, les distros se sont fait un devoir de l'intégrer le plus vite possible.

            ça fait presque 2 ans que j'utilise Pulseaudio quotidiennement et ça marche très bien. Pulseaudio existe depuis près de 5ans (avant, ça s'appelait Polypaudio) et avait pour objectif de remplacer l'immonde esound que tout le monde semble avoir oublié.
            Au bout de 5 ans de développement, fallait bien se lancer. Là, où je suis d'accord c'est que beaucoup de distributions l'ont intégrés trop rapidement (notamment Ubuntu qui a fait n'importe quoi), pas étonnant que PA se traine une sale réputation souvent injustifié.

            Actuellement, PA est *fonctionnel*, il y a encore des détails à régler comme la conso CPU sur certaines machines mais globalement, c'est un pas en avant vers un meilleur desktop.
            • [^] # Re: Phonon était pas prêt

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

              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 5.

                Humf, « cauchemare », certains feraient mieux d'apprendre à écrire avant l'informatique.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Phonon était pas prêt

                Posté par . Évalué à 2.

                En règle général, quand un logiciel marche bien, on ne le crie pas sur tout les toits.
                Mais pour revenir sur le post de MrTom, il se plaint principalement de la consommation excessive de CPU, c'est un problème connu mais qui ne concerne pas tout le monde (ie: PA tourne comme un charme sur la plupart des netbooks du marché), quant à Aaron Seigo, il utilise une OpenSuSE mutante et se plaint principalement du non fonctionnement d'applications propriétaire à la con (Lennart Pottering s'est fait chier à corriger la plupart des applications libres pour garantir leur bon fonctionnement avec PA avant la sortie de Fedora 8, malheureusement, il ne peut pas faire des patchs binaires pour Skype), pour le billet sur Mandriva, il est bourré d'inexactitudes et date de janvier 2008, j'ose espérer que Mandriva n'est pas assez frappadingue pour utiliser 21 mois après PA si c'est aussi pourri que ça.

                Si les gens qui se plaignaient de PA faisaient un peu plus de rapports de bogues et moins de billets pour cracher sur PA ...
                La réalité, c'est que la pile audio de GNU/Linux est un tas de merde comparé à ce qui se fait sous OS X ou pire Microsoft. Beaucoup de problèmes attribués à PA sont souvent des bogues existants dans Alsa et les pilotes, des bogues souvent contournés par les applications mais jamais corrigés.
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 3.

                  C'est quoi une openSUSE mutante ? C'est pour les mainteneurs qui se sont transformés en loup-garou ?
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 10.

                  Poster des rapports de bugs sur PulseAudio ?

                  Voila ce qu'en disait Thomas Vander Stichele, un core dev de GStreamer / Fludo (et accessoirement sympathisant des ambitions de PA) pas plus tard que la semaine dernière :
                  http://thomas.apestaart.org/log/?p=1012

                  C'est aussi ce que je reproche le plus à PA. Il est affreusement buggué, certes.
                  Mais le problème n'est pas là ; comme tout logiciel très utilisés, il pourrait se bonifier rapidement et ne pas (trop) taper sur le système de ses utilisateurs s'il n'était pas si opaque, automagique et uber-complexe, tout ce qui fait que peu de gens rapportent les bugs qu'ils rencontrent, et peu de gens peuvent aussi les contourner ou trouver des workarounds. Aussi, la personnalité de Lennart Poettering n'aide pas forcément (à faire des rapports de bugs, à faire reconnaitre qu'un comportement donné est un bug, à faire admettre des workarounds pour avoir le son qui marche dans la vraie vie, celle des users de desktops)...

                  Un logiciel libre très utilisé qui donne à ses utilisateurs les moyens de faire des bons rapports de bugs, sinon de le fixer eux-même (doc interne, doc des interactions, messages d'erreurs clairs, aux bons endroits et bien formulés, modes verbose efficaces, etc) est promis à une stabilité irréprochable en un rien de temps. Après 5 ans d'existence PA ne devrait pas en être encore au stade du "je pers le controle de la carte son et je ne loggue rien".

                  Merde, même le noyau - et c'est pourtant pas facile à ce niveau du système - est incroyablement plus débugguable que PA (printk très pertinents, docs riches, myriades d'outils de traçage, profiling, débogguage des verroux, des problèmes mémoire, netconsole, autodocumentation des états internes via /proc et /sys ...) ! Résultat, les bugs sont corrigés. Et les développeurs kernel ne t'envoient pas chier parce que tu rencontre un bug en utilisant un logiciel proprio sur leur système, ou rejettent une solution réduisant drastiquement les problèmes parce qu'elle serait "moins pure" (voyez la récente aventure d'Alan Cox et des standards posix relatifs aux ttys).

                  Vous faites quoi, vous, quand PA décide, sur votre système, de ne plus sortir de son, ou crash silencieusement ? vous arrivez à trouver de quoi faire un rapport de bug ? perso je lance un strace en desespoir de cause (mais ça ne sert à rienà, puis le le "/etc/init.d/pulseaudio restart" (inutile aussi, visiblement PA ne doit pas être lancé ainsi), puis je reboot. Classe.
                • [^] # Re: Phonon était pas prêt

                  Posté par . Évalué à 3.

                  La réalité, c'est que la pile audio de GNU/Linux est un tas de merde comparé à ce qui se fait sous OS X ou pire Microsoft.
                  perso je ne permettrai pas dire cela, mais plus simplement que je me pose des questions sur Alsa lui même, oui. Et -surtout- Dmix : j'avoue ne pas comprendre pourquoi le routage et le mixage des flux ne se fait pas à ce niveau là...

                  Beaucoup de problèmes attribués à PA sont souvent des bogues existants dans Alsa Certainement. Beaucoup d'autres sont internes à P.A. certainement aussi... Et d'autres sound-server fonctionnent pas trop mal, hein :)

                  ailleurs : bluetooth, réseau, pa roxe ben c'est bien le problème il roxe sur plein de trucs (j'ai jamais vu ça, mais je vous crois sans pb) mais il s'est attaché sur des éléments secondaires alors que son core ne semble toujours pas opérationnel correctement. (je ne parle même pas d'une utilisation MAO, qui est spécifique, juste lui demander de ne pas bouffer 10% de 2 xeons 3ghz pour mixer 2 sources, c'est trop demandé, ça ?)



                  Tiens la fusion jackdmp et jack est en train de se fignoler :

                  nouveauté sur le réseau. pour bientôt.

                  Systèmes de notifications et informations détaché du flux audio lui même, qui est 'RT', et attaché sur un fil séparé. Conséquence : souplesse.

                  jack : http://jackaudio.org
                  jackdmp : http://www.grame.fr/~letz/jackdmp.html
                  NetJack2 : http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2
                  Jack2, le nouveau Jack : http://trac.jackaudio.org/wiki
  • # Info à prendre avec des pincettes.

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

    Les blogs sur labs.trolltech.com sont juste des blog et représente uniquement l'opinion de leurs auteurs.

    Le projet mobility n'est d'ailleurs pas développé par les développeurs de Qt d'avant l'aquisition, mais par les anciens développeurs de Qtopia
  • # Pas de webcam avec Phonon...

    Posté par . Évalué à 2.

    Je développe un programme qui doit piloter un appareil sur lequel on dispose d'une webcam. L'application est développée en Qt.
    J'aimerais beaucoup utiliser Phonon, mais je n'ai pas trouvé de solution pour récupérer les images de ma webcam. De même il n'y a apparemment pas moyen de sauvegarder le flux video ou des captures. Je travaille sous Gnome (Ubuntu) et donc avec GStreamer.

    Il est très surprenant que Qt ne puisse pas proposer de telle fonctionnalité. Faut-il utiliser xine ? Le développement de Phonon est apparemment très très lent.

    Le plus pénible est la difficulté de trouver de la documentation et une explication sur les options d'entrées et sortie et ce qu'il faut faire pour pouvoir en bénéficier.

    J'utilise pour le moment une moulinette qui attaque directement le V4L2 et fait la conversion de YUV en RGB. Cela me bouffe 10% du CPU alors que la version gstreamer ne consomme rien du tout (dim: 1600x1200).

    Le choix entre Phonon et Qt Multimedia sera déterminé pour moi par les critères suivants: documentation, intégration à Qt, entrées et sorties. De ce point de vue Phonon est décevant et m'a déjà fait perdre beaucoup de temps. J'attends donc avec impatience Qt Multimédia pour l'évaluer suivant ces critères.

Suivre le flux des commentaires

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