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-(...)
Journal Qt/Phonon bientôt mort et remplacé
9
sept.
2009
# bof
Posté par fearan . Évalué à 10.
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 Jean Roc Morreale . Évalué à 2.
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 Pinaraf . Évalué à 0.
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 Troy McClure (site web personnel) . Évalué à 9.
Je trouve quand même que ça sent le sapin
[^] # Re: Connerie...
Posté par Nicolas . Évalué à 4.
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 Axel . Évalué à 2.
"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 Sylvain Colinet (site web personnel) . Évalué à 3.
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 Victor STINNER (site web personnel) . Évalué à -3.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
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 zebra3 . Évalué à 3.
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 Bapt (site web personnel) . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 2.
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 Sylvain Colinet (site web personnel) . Évalué à 3.
[^] # Re: Phonon était pas prêt
Posté par Moonz . Évalué à 2.
Si tu parles de mplayer, oui, et ce depuis un bon moment
[^] # Re: Phonon était pas prêt
Posté par jiyuu . Évalué à 2.
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 allcolor (site web personnel) . Évalué à 2.
Mencoder reste quand même le meilleur couteau suisse de l'encodage ;)
[^] # Re: Phonon était pas prêt
Posté par Sylvain Sauvage . Évalué à 1.
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 ʭ ☯ . Évalué à 1.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Phonon était pas prêt
Posté par Sylvain Sauvage . Évalué à 1.
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 tanguy_k (site web personnel) . Évalué à 10.
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 Sylvain Colinet (site web personnel) . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par Jean Roc Morreale . Évalué à 3.
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 Troy McClure (site web personnel) . Évalué à 1.
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 Axel . Évalué à 10.
[^] # Re: Phonon était pas prêt
Posté par mscestdelamerde . Évalué à -2.
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 bubar🦥 (Mastodon) . Évalué à 5.
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 Laurent A. . Évalué à 5.
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 gnumdk (site web personnel) . Évalué à 3.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
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 gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Phonon était pas prêt
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 4.
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 Prosper . É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 zebra3 . Évalué à 4.
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 gnumdk (site web personnel) . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 3.
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 gnumdk (site web personnel) . Évalué à 2.
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 mscestdelamerde . Évalué à 1.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
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 mscestdelamerde . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par benoar . Évalué à 2.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
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 benoar . Évalué à 2.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 5.
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 benoar . Évalué à 2.
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 gnumdk (site web personnel) . Évalué à 2.
> 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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par lezardbreton . Évalué à 2.
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 fearan . Évalué à 4.
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 mscestdelamerde . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 3.
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 mscestdelamerde . Évalué à -1.
[^] # Re: Phonon était pas prêt
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
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 Spyhawk . Évalué à 3.
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 lezardbreton . Évalué à 1.
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 mscestdelamerde . Évalué à 1.
[^] # Re: Phonon était pas prêt
Posté par lezardbreton . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par mscestdelamerde . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
Dis-moi donc quel logiciel à part PA permet de switcher une appli de carte son à la volée ? De faire du contrôle de volume par application centralisé ? De balancer le son d'une appli sur le réseau ? D'avoir le son sur un terminal léger sans configuration ?
[^] # Re: Phonon était pas prêt
Posté par Jean Roc Morreale . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
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 Larry Cow . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par dinomasque . Évalué à 2.
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 20 ans !
[^] # Re: Phonon était pas prêt
Posté par mscestdelamerde . Évalué à -1.
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 5.
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 mscestdelamerde . Évalué à -1.
ps: l'agressivite ne mene a rien.
[^] # Re: Phonon était pas prêt
Posté par mscestdelamerde . Évalué à -2.
[^] # Re: Phonon était pas prêt
Posté par Smarter . Évalué à 1.
[^] # Re: Phonon était pas prêt
Posté par bubar🦥 (Mastodon) . Évalué à 3.
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 Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 4.
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 gnumdk (site web personnel) . Évalué à 2.
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 zebra3 . Évalué à -2.
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 gnumdk (site web personnel) . Évalué à 3.
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 zebra3 . Évalué à 2.
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 mscestdelamerde . Évalué à 0.
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 zebra3 . Évalué à 2.
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 mscestdelamerde . Évalué à 1.
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 mscestdelamerde . Évalué à 1.
parceque Gnome a decide que le control de volume utiliserait PA et plus alsa....
[^] # Re: Phonon était pas prêt
Posté par Maclag . Évalué à 4.
---------> [ ]
[^] # Re: Phonon était pas prêt
Posté par YLD . Évalué à 3.
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 vrm (site web personnel) . Évalué à 0.
[^] # Re: Phonon était pas prêt
Posté par benoar . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par vrm (site web personnel) . Évalué à 2.
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 benoar . Évalué à 3.
[^] # Re: Phonon était pas prêt
Posté par benoar . Évalué à 1.
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 bubar🦥 (Mastodon) . Évalué à 3.
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 benoar . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 benoar . Évalué à 2.
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 Pygeon Paul . Évalué à 2.
[^] # Re: Phonon était pas prêt
Posté par tanguy_k (site web personnel) . Évalué à 1.
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 GeneralZod . Évalué à 3.
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 tanguy_k (site web personnel) . Évalué à 3.
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 GeneralZod . Évalué à 3.
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 tanguy_k (site web personnel) . Évalué à 2.
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 GeneralZod . Évalué à 2.
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 wismerhill . Évalué à 5.
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 GeneralZod . Évalué à 6.
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 wismerhill . Évalué à 3.
[^] # Re: Phonon était pas prêt
Posté par thedude . Évalué à -1.
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 tanguy_k (site web personnel) . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 4.
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 Maclag . Évalué à 4.
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 GeneralZod . Évalué à 3.
ç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 gnumdk (site web personnel) . Évalué à 3.
http://blog.mrtomlinux.org/index.php?post/Le-cauchemare-Puls(...)
http://aseigo.blogspot.com/2009/01/i-will-not-drink-koolaide(...)
http://artipc10.vub.ac.be/wordpress/mandriva/bye-bye-pulseau(...)
[^] # Re: Phonon était pas prêt
Posté par zebra3 . Évalué à 5.
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 GeneralZod . Évalué à 2.
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 Spyhawk . Évalué à 3.
[^] # Re: Phonon était pas prêt
Posté par herodiade . Évalué à 10.
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 bubar🦥 (Mastodon) . Évalué à 3.
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 Gof (site web personnel) . Évalué à 6.
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 Christophe Meessen . Évalué à 2.
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.
[^] # Re: Pas de webcam avec Phonon...
Posté par mscestdelamerde . Évalué à 3.
http://kamoso.wordpress.com/2009/09/09/kamoso-project-presen(...)
En gros ils sont passe a VLC pout faire quelque chose qui ressemble a tes besoins.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.