Encore une entrée de blog de Lennart Poettering, le dev de pulseaudio:
http://0pointer.de/blog/projects/when-pa-and-when-not.html
Il explique pourquoi, selon lui, vouloir fusionner pulseaudio et JACK n'est pas une bonne idée, car ils ont des objectifs differents et difficilement conciliables:
- pulseaudio: economie de resources (il tourne sur des telephones), souplesse, configuration dynamique (on branche/debranche des cartes sons, des casques bloutouf, la latence est ajustée en fonction des applications etc), transparent pour l'utilisateur.
- JACK: faible latence a tout prix (mais pour cela il faut souvent sacrifier les economies d'energies, par exemple le cpu throttling), utilisateur compétent (et admin), hardware performant. On pourrait aussi ajouter "simplicité de l'API".
Concernant JACK, il y a eu un long thread recemment sur la ml linux audio, en réponse à ce post annonçant un début de concertation entre les distributions linux pour remplacer JACK par JACK2 (réécriture en c++ de jack qui est portable (windows, macos) et multiprocesseur friendly):
http://thread.gmane.org/gmane.comp.audio.jackit/21576
S'en est suivi une réaction très mitigée des dev de jack. jack2 était jusqu'à présent plutot considéré comme le successeur de jack1. Mais les deux autres dev de jack (ils sont trois developpeurs actifs à l'heure actuelle) se disent mal à l'aise face à jack 2 ( http://article.gmane.org/gmane.comp.audio.jackit/21604 ). On se retrouve désormais face à trois implémentations differentes de jack (le jack 1 originel, le jack 2 en c++, et un fork de jack 1 (tschack) qui essaye de combler les differences avec jack 2). C'est censé etre transparent pour les utilisateurs celà dit.
Journal Pulseaudio vs JACK
5
mai
2010
# API ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
J'ai du mal à comprendre que l'on ne puisse pas, ensuite, rajouter des modes ultra basse latence (désactivation du cpu throttling, priorité temps réel, buffer court, etc...).
"La première sécurité est la liberté"
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
PA supporte donc le temps réel, mais c'est en théorie. Pour l'avoir trituré aussi pas mal (moins que jack mais quant même) c'est pas ça. Et là je ne jetterai pas la pierre à Pa, ne sachant pas si les pb ne viennent pas d'ailleurs ( de dbus par exemple ?). D'ailleurs Lennart lui même le dit : il déconseille d'utiliser PA en RT. C'est un "work in progress" (depuis plus de 2 ans...) Le support de Flash et du bluetooth ayant été des priorités plus importantes.
PA c'est juste le nouvel ESD, rien de plus, mais rien de moins. Un ESD en bien mieux, mais son auteur ne cesse de le répéter : PA n'est pas fait pour les fortes contraintes. Donc faudra pas attendre d'évolutions de ce côté là.
La seule voie actuellement possible c'est de faire comme sous Windows : un truc de base de merde mais qui marche bien pour les trucs de base, et des softs "Pro" qui implémentent en douce un jackd lorsqu'ils sont lancés. Bref, moi je comprends plus rien à la philosophie de gnu, en matière de son.
[^] # Re: API ?
Posté par Nicolas Boulay (site web personnel) . Évalué à -2.
Rien n'empêche de faire évoluer PA pour faire baisser sa latence a fonctionnalité égale.
"La première sécurité est la liberté"
[^] # Re: API ?
Posté par lolop (site web personnel) . Évalué à 9.
Ça c'est un truc que je n'oserais pas écrire sans être un développeur connaissant en détail la structure et l'implémentation de PA...
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: API ?
Posté par imr . Évalué à 5.
Ca n'a rien à voir avec le son c'est pareil ailleurs mais regarde l'exemple de jack donné au dessus, ils sont trois et se prennent le bec.
Le monde Linux a inventé un concept: "se diviser pour ne pas régner".
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 5.
Je ne parlais pas de cette philosophie là, mais plutôt d'intégration et de propreté du système. Là on va se retrouver à coup sûr avec du Windows-like :
pulseaudio pour les taches courantes.
jack qui sera lancé par les appli pros.
C'est complètement con, j'attendais un PulseAudio qui soit capable de remplacer Jack.
Bien maintenant j'attends un Jack qui soit capable de remplacer PulseAudio.
J'attends en continuant de me demander à quoi cela a servi que les gens du kernel se décarcassent. jack aujourdhui il se lance en rt sur un kernel vanille par défaut, c'est fantastique. Et moi j'ai PulseAudio qui bouffe 40% de mon cpu le temps de router un flux vers une nouvelle entrée, et pendant qu'il fait ça, j'ai le temps de préparer un maté.
Bref, je fais aujourdhui le même choix que celui qui m'a conduit à conserver linux à mes débuts : j'ai quelques restrictions certes, avec jack, mais je sais que là il y a qq chose de meilleur.
/mode/
[^] # Re: API ?
Posté par imr . Évalué à 10.
>Bien maintenant j'attends un Jack qui soit capable de remplacer PulseAudio.
Tu as 2 solutions qui ne sont pas satisfaisantes qui éparpillent les quelques devs qui savent faire du son au lieu d'une qui regrouperait devs et fonctions. Comme ça, on est certain d'avoir une solution qui jamais ne satistera personne par simple manque de développeurs.
C'est exactement ce que je disais dans ma boutade.
Donc:
-pleins de distros qui font et réinventent la même chose les unes après les autres avec une pléthore d'outils de gestion de paquets mais qui refusent de reprendre les outils originaux des autres.
-deux desktop qui font refont exactement la même chose à quelques nuances probablement importantes près (haha), mais si tu regardes bien leurs problèmes viennent du manque de dev et chaque desktop couvre les défaut de l'autre.
-des applis redondantes à tire larigo dont aucune n'est finie, et dans le meilleur des cas quand une commence à être finalisée et stable, on casse tout et on recommence en mieux un jour promis, et au pire ben elles sont jamais finie. Bref, elles sont jamais finies.
Et au final, on se contente d'un pis aller.
/mode MoiJE/ mon pis aller à moi, vu que je ne fais pas du son comme toi, c'est de ne pas essayer jack et d'utiliser une distro qui n'utilise pas PA. Et si un jour, une année, PA devient utile et utilisable, je l'utiliserai mais mes années béta testeur, c'est fini.
Et oui, quand je baisse le son d'une appli, ça baisse le son de toutes les applis, c'est mon désavantage à moi avec ma méthode.
Bizarrement, j'ai très rarement besoin d'écouter plus d'une chose à la fois.
J'imagine que les utilisateurs qui en ont besoin, ce qui a amené à casser les couilles de tous les utilisateurs de desktop linux pendant des années, doivent être vraiment nombreux.
Donc voila, moi aussi j'aime bien linux, j'ai pas peur de mettre les mains dans le cambouis, mais quand ça le justifie (par exemple jack si je faisais du son ), mais j'en ai marre d'être transformé en béta testeur perpétuel non volontaire pour des applis et des projets qui jamais ne se stabilisent, c'est pour Sisyphe, c'est pas pour moi.
Donc vive les distros conservatrices et stables, il y en a peu mais il y en a, et je laisse tomber le frisson des mises à jour sans regarder en arrière.
/mon mode MoiJe à Moi/
[^] # Re: API ?
Posté par grid . Évalué à 4.
C'est encore pire pour KDE et GNOME. Tiens, on me dit qu'ils n'ont pas le même objectif.
[^] # Re: API ?
Posté par imr . Évalué à 2.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par imr . Évalué à 5.
Mais au final, on obtient un desktop avec des icones, des applis qui inter agissent, du drag and drop, un menu contextuel, un file manager, une console, un ensemble d'applications similaires, etc etc. Rien de très différent, rien de très nouveau.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
Le résultat est semblable mais la technique derrière est fort différente, c'est pour ça que les développeur préfère l'un ou l'autre. Même s'il repique des idées d'un côté ou l'autre quand elle est bonne ou apprennent des erreurs des autres (on verra avec Gnome3.0).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par imr . Évalué à 5.
Le résultat est semblable mais la technique derrière est fort différente, c'est pour ça que les développeur préfère l'un ou l'autre. Même s'il repique des idées d'un côté ou l'autre quand elle est bonne ou apprennent des erreurs des autres (on verra avec Gnome3.0).
Je sais bien tout ça, et ce ne sont que des petites différences pour se distinguer, on se crée une identité par rapport à l'autre et à la fin l'identité devient plus importante que le but initial. Le but initial étant "faire un desktop libre efficace".
Je sais bien aussi que c'est tellement ancré dans les esprits des devs que ça ne changera pas, et je sais bien aussi que ça rebute pleins de devs qui voient ce genre de gachis et n'adhèrent pas au decorum obligé et du coup ne participent pas.
Quant à l'argument de la compétition qui permet l'émulation et que lui aussi j'entends depuis plus de 10 ans, le problème c'est que la vraie compétition ce sont les desktop proprio. Mais on n'est pas compétitif parce que chaque desktop a tellement de manques qu'il ne peut pas satisfaire un utilisateur qui vient de windows ou linux. Mais bien sur, dans ces cas là, on a le joker ultime, c'est parce qu'il ne comprend pas les enjeux philosophiques.
Au passage, les entités proprios sont capables de fusioner pour mieux résister à la compétition. Regarde macromédia et adobe. C'était deux entreprises en compétition féroce avec des projets qui se marchaient dessus mais fortement complémentaires. Quand elles ont vu la puissance de ceux qui allaient se tourner contre eux, microsoft parce que je ne pense pas qu'ils avaient prévu le retour d'apple alors, ils on su fusionner. Nous on sait pas faire, pire, on peut pas faire.
Autre chose, du point de vue des solutions techniques en compétition en interne, ça aussi les projets proprio savent faire. Tu pourrais avoir une équipe qui travaille sur une implémentation technique qui lui plait, une autre sur une autre et on voit ce qui marche le mieux. Tu peux faire ça quand tu as assez de dévs, nous, on a pas assez de dévs pour finir à temps aucun des deux desktop, et on les voit se trainer tous les 6 mois et se prendre des régressions et on perd des utilisateurs à chaque fois.
Donc KDE4 veut partir dans une direction innovante et originale avec les activités. Problèmes, ça me rappelle les services de konqueror dans KDE3 qui était innovants et originaux, mais dont on ne vit jamais venir de nouveaux au fil des années.
Donc on a l'activité bureau qui fonctionne et qui réimplémente un bureau traditionnel, et les autres sont des cagades jamais finies parce qu'il n'y a pas de devs pour travailler dessus.
Réaction de GNOME, ils vont faire pareil de leur coté.
Donc on va avoir 2 bureaux innovants buggués qui réimplémentent l'ancien concept, n'ont pas les moyens de faire le nouveau, le distribuent dans un état inachevé, transforment les utilisateurs en testeurs, ceux qui parmi ceux ci ne sont pas prévenus essaient de rapporter des bugs auprès de leurs distros, gros merdier et incompréhension s'ensuivent, fuite d'utilisateurs, burnt out de développeurs, joker ultime. Remettre 1 euro, recommencer la partie.
Bref, je comprends tout ça mais je reste sur mon analyse "Se diviser pour ne pas régner".
Sisyphes qui atteignent leur sommet tous les 6 mois, les développeurs, packageurs et utilisateurs de linux, quand ils ne veulent pas désespérer et retrouver le courage de remonter la pente, conspuent le sisyphe d'à coté sur sa propre montagne, détaillant les défauts de sa méthode. Puis repoussent d'éventuelles solutions originales et repoussent leur boule.
Il y a pourtant 2 solutions:
A deux, on pousse plus facilement et arrivé en haut, il y en a un qui peut aplanir le sol, et retenir la boule. Une fois la boule plantée au sommet, on va s'occuper de l'autre.
Et l'autre, on laisse la boule amasser la mousse.
Et bye bye tantale.
[^] # Re: API ?
Posté par Antoine . Évalué à 2.
Je crois que Freud a appelé ça le "narcissisme de la petite différence".
[^] # Re: API ?
Posté par imr . Évalué à 3.
Intéressant, je ne connaissais pas, mais j'ai pu observer souvent ce phénomène.
En anthropologie, il a été observé que les sociétés humaines se désignent toujours par des termes désignant les êtres humains, et leurs voisins par des noms d'animaux.
Je ne sais pas si le phénomène de l'exclusion pour se déterminer est commun à toutes les sociétés humaines ou si le recours à un groupe externe à montrer en différence suffit. Peut être que c'est un double mouvement, interne et externe. Eux, à l'extérieur, sont différents, lui, à l'intérieur, est différent.
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 3.
"C'est comme dans Lost,
Il y a les autres, et ils sont bizarres"
(...)
[^] # Re: API ?
Posté par patrick_g (site web personnel) . Évalué à 5.
Je crois que tu peins la situation un peu (beaucoup) trop en noir.
Je n'utilise pas KDE donc je n'en parlerai pas mais en ce qui concerne GNOME je peux l'évaluer par rapport au desktop XP que j'utilise au boulot et au desktop Win7 que mon cousin utilise chez lui.
Je ne constate aucun manque criant dans mon GNOME que j'ai chez moi. Il n'est pas buggé, il fait tout ce que je souhaite et il a des performances fort correctes.
Contrairement à ce que tu dis je trouve que le desktop sous Linux (au moins dans le cas de GNOME) est parfaitement compétitif avec les desktops proprio.
[^] # Re: API ?
Posté par Albert_ . Évalué à 4.
Tu en verrais si tu utilisais KDE4.4 :)
[^] # Re: API ?
Posté par imr . Évalué à 2.
[^] # Re: API ?
Posté par imr . Évalué à 4.
GNOME fait tout ce que tu souhaites et ça te suffit, parce que tu es totalement le genre de personne pour qui GNOME ou KDE sont fait et s'en suffit. Moi aussi, j'ai toujours un terminal lancé et je fais pleins de trucs avec, et samsuffy, et je contourne des problèmes mais aussi des usages dont je ne perçois pas les manques.
Par exemple, le file selector GNOME et ses manques et ses performances. Alors, moi je suis content, j'ai le file selector KDE ou qt.
Sauf que récemment, je tombe sur une comparaison entre le file selector qt et un file selector natif de l'appli et le type dit, le file selector qt pourra vous convenir si vous vous contentez d'un file selector des années 90.
Donc je mets de coté mon contentement, ma satisfaction qui représente 0.0001% des utilisateurs informatiques et je me dis, si ça se trouve, les file selector ont vachement évolué et moi je reste dans ma comparaison KDE vs GNOME et je ne vois pas qu'ils sont archaÏques tous les deux.
Quand tu regardes l'ensemble de l'appli sous ce jour, il s'agissait ici dans mon cas de photoshop vs gimp, c'est tout un ensemble de fonctionnalités et de possibilités qui n'existent pas et qui font que le workflow d'un graphiste va être 10 fois plus rapide sous photoshop. Et tu peux fermer les yeux là dessus, et te mettre les mains sur les oreilles en disant gimp me suffit pour les 3 png de mon site oueb.
Un autre exemple, les logiciels de comm. Il y a 6 mois j'ai lu que le support vidéo était arrivé dans pidgin et empathy. Cool!
J'ai essayé, marche pas. J'ai été voir sur les forums d'une autre distro (ubuntu), pareil. Pleins de fils qui disent ça marche pas.
Donc j'ai essayé ekiga, marche pas, message d'erreur cryptique. J'ai trifouillé (ce que ne ferait pas un utilisateur dont je parle) firewall et autre, marche pas. Retour sur les forums des autres distros, marche pas, aléatoirement.
J'imagine que tu vas me dire que ça marchait chez toi ou que tu n'utilises pas de webcam parce qu'irc ça suffit?
En tout cas, skype marche très bien, très vite, bien que je l'utilise pas de gaieté de coeur. Mais j'ai pas le choix.
Autre chose. Suite à la discussion sur resynthetizer et gimp et photoshop, j'ai installé photoshop pour tester les fonction de magic wand. J'ai donc du installer win7 dans VirtualBox. J'ai des meilleures performances avec photoshop dans win7 dans VirtualBox et 1o de ram que gimp en natif avec 2 go de ram.
J'ai aussi testé gimp dans ubuntu 10.04 dans virtualbox pour voir si le plantage de resynthesizer se reproduisait aussi dans ubuntu avec des grosses photos. Et bien ubuntu dans VB se traine comme une loutre asmathique et oui, resynth plante aussi.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
(et puis pour les versions buggué, il faut pas exagérer, j'ai aucun bug génant sous kde 4.4 au quotidien).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par imr . Évalué à 6.
aucun bug ou aucun bug génant que tu utilises ou aucun bug génant tout court?
Parce que des bugs génant j'en connais une tripotée.
Je peux même te pointer vers une série de bugs d'une application ou le developpeur s'est pris le bec avec les utilisateurs en refusant leurs remontees d'experiences et au final a quitté le projet (et même 2 devs sur 3 iirc).
Tu as un des utilisateurs qui a pris la peine de mesurer au pixel près toute l'UI, d'en faire les pourcentages par rapport à l'écran et qui s'est fait envoyé péter parce que c'était pas une étude d'UI.
25% de l'écran occupé par une fonction inutile dans ce cas d'usage (le premier eee) et juste quelques lignes de code à rajouter pour cacher le panneau, code qui était soumis en patch dans le premier commentaire.
Et je peux te pointer vers des bugs du même genre concernant GNOME.
Je crois tu ne te rend pas compte que ce sont des bénévole pour la plupart derrière ces projets
Si, à tel point que j'ai souvent pris la défense des dévs et que je ne les persécute pas avec mes vieux dossiers. Mais qu'on ne puisse pas parler des problèmes de l'existant tel qu'il est ni à un desktop, sans qu'il y ait une levée de bouclier, telle est notre petite communauté, et telle elle était il y a plus de 10 ans.
Si c'est libre, c'est bien, si c'est pas libre, c'est mal, et en ne regardant pas les problèmes suffisament longtemps ils finiront par disparaitre.
[^] # Re: API ?
Posté par claudex . Évalué à 0.
Aucun bug génaut que j'utlise (sinon je ne sais pas qu'ils sont là)
Et je peux te pointer vers des bugs du même genre concernant GNOME.
Ah, mais si utilise n'importe quoi comme DE aussi... :-)
Si c'est libre, c'est bien, si c'est pas libre, c'est mal, et en ne regardant pas les problèmes suffisament longtemps ils finiront par disparaitre.
Je pense que tu ne parle que d'une partie des développeurs. Il suffit de voir de port de KDE vers windows et mac os pour se rendre compte de tous ne pense pas comme ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par Maclag . Évalué à 5.
- Deux bureaux Linux:
En fait, plus que ça.
C'est seulement que les dévs ont des visions différentes des choses, mais c'est aussi que j'ai des attentes complètement différentes de mon voisin de bureau ou de Madame Michu.
Plus il y aura de bureaux mâtures, plus j'aurai de chance d'en trouver un "parfait", parce que la perfection d'un bureau, c'est complètement subjectif!!
- Des bureaux buggés sous Linux, pas comme sur les OS proprios:
On parle de Win95 ou du très apprécié Vista?
- On perd des utilisateurs à cause des bugs:
Non. S'ils sont déçus par une régression c'est soit qu'ils utilisent une version expérimentale, soit la distribution a mal fait son boulot! Le reste n'est pas différent du monde proprio:
Il n'y a jamais eu de régression dans les logiciels propriétaires??
- Compétition saine:
Ben oui, c'est ce qui fait que les deux bureaux ont finit par adopter D-Bus sur une base de DCOP, et d'une manière générale, on peut regarder comment Freedesktop avance: avec des idées de l'un, puis des idées que l'autre a eu pour faire la même chose mais qui marche mieux!
- Les boites qui font du proprio savent fusionner:
L'avantage du libre, c'est que ce n'est pas une compétition à mort:
Le compétiteur n'est pas ton ennemi! D'où l'adjectif "saine" compétition.
Les projets collaborent à travers Freedesktop.
De plus, on a déjà vu des projets libres fusionner (et beaucoup même!).
- Les Sisyphes:
S'il y avait eu deux Sisyphes, peut-être que le premier aurait commencé à aplanir sa montagne pendant que l'autre construit une poulie.
Ensuite, le premier aurait fait une grue après avoir vu l'efficacité de la poulie tandis que l'autre invente un bulldozer pour aplatir sa montagne.
Et on recommence: la poulie est une bonne idée, la grue est mieux, le bulldozer c'est sympa! Si on faisait une machine depuis 0 capable de tout faire en même temps et prendre en compte l'existence des différents outils?
Je continue?
[^] # Re: API ?
Posté par imr . Évalué à 3.
Plus que 2, tu comptes xfce?
Plus il y aura de bureaux mâtures, plus j'aurai de chance d'en trouver un "parfait", parce que la perfection d'un bureau, c'est complètement subjectif!!
Entièrement d'accord, et le premier point important, c'est "mature", pas "plus".
Quand KDE3 finit par être stable, on passe à KDE4 pour résoudre les derniers bugs liés à qt3, donc j'aurais jamais eu très longtemps un KDE stable.
Quand GNOME2 finit par être fonctionnel, on passe à GNOME3. Pareil.
Et dans les 2 cas, j'ai toujours pas un éditeur vidéo qui tient la route, un IM qui fasse la vidéo de façon stable et simple sans être du msn.
Puisque la plupart de ces problèmes viennent du manque de dev, et bien qu'étant conscient des mécanismes de préférences qui font qu'on a et aura deux desktop redondants, je ne peux pas m'empêcher de regretter cette état de fait inutile qui réduit encore plus nos forces.
Des bureaux buggés sous Linux, pas comme sur les OS proprios:
J'ai dit que c'était la concurrence, j'ai pas dit qu'ils étaient pas buggués. Mais si tu regardes l'attitude de microsoft dans les années 90, avec les "c'est pas un bug c'est un feature" ou bill gates interviewé qui refuse d'admettre qu'il y a des bugs dans son os, on retrouve souvent exactement la même dans le monde linux maintenant.
Sauf que c'est SA distro, SON desktop, SON logiciel fétiche qu'on défend.
Au passage, regarde le post au dessus ou je parle des perfs de win7 dans VirtualBox. J'utilise pas win7, c'est pas mon intention, mais je vais pas me leurrer ni aller perdre du temps à dire des conneries sur ses perfs à des gens qui l'utilisent tout en racontant des conneries sur les perfs de linux ou de ses desktop. Ils se trainent sur mon pc de 2004.
En tout cas, voila un logiciel libre excellent, virtual box.
on peut regarder comment Freedesktop avance
Mal ces dernieres années, voire pas du tout. C'est surtout que j'ai beaucoup espéré de freedesktop et que pas grand chose en est sorti.
Mais c'est clair que dans cette situation absurde de diviser ses forces en deux, créer une troisième entité pour avoir un lieu ou résoudre l'écart entre elles est la suite logique.
L'avantage du libre, c'est que ce n'est pas une compétition à mort:
Le compétiteur n'est pas ton ennemi! D'où l'adjectif "saine" compétition.
Les projets collaborent à travers Freedesktop.
Tout ça c'est de la théorie. En pratique, c'est beaucoup moins rose.
De plus, on a déjà vu des projets libres fusionner (et beaucoup même!).
Vas y, cites en pleins.
S'il y avait eu deux Sisyphes, peut-être que le premier aurait commencé à aplanir sa montagne pendant que l'autre construit une poulie.
Si je comprends bien ton évocation, on aurait du commencer par aplanir la difficulté principale à l'origine de GNOME à savoir résoudre le problème de license avec trolltech plutot que créer un desktop concurrent évidemment dilueur de forces par trop minces.
C'est gonflé, mais là dessus, je suis assez d'accord.
[^] # Re: API ?
Posté par Maclag . Évalué à 2.
Maemo & Moblin
LiPS & LiMo
Compiz & Beryl (ok, c'était un fork, n'empêche qu'à la fin ça fusionne!)
SpipBB & GaFoSpip
Comme ça y'en a à tous les niveaux!
[^] # Re: API ?
Posté par FreeB5D . Évalué à -2.
Il fait quoi de moins bien que GNOME, pour l'abruti de windowsien^W^W^Wle windowsien moyen que vise GNOME ?
Un navigateur -> Midori (de toute façon Epiphay/Midori les distributions s'en foutent et mettent Firefox à la place)
Et il y a aussi AbiWord, Pidgin, GQView, Claws-Mail, Xarchiver etc. qui sont des applications GTK2 indépendantes du bureau et qui s'intègrent aussi bien à Xfce qu'à GNOME . De toute façon, pour ceux qui veulent vraiment des applications bien intégrées qui font officiellement partie de l'environnement de bureau, c'est chez KDE qu'il faut voir .
[^] # Re: API ?
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par imr . Évalué à 3.
Mais on désigne par environnement de bureau un ensemble au delà d'une liste de soft et notamment qui contient des processus de communication inter applications.
Genre je drag and drop une image depuis l'appli graphique dans la suite bureautique pour qu'elle s'intègre dans le document que je suis en train de faire. Ceci dit, je viens d'essayer, ça marche pas entre krita et kword, ça marche même pas entre dolphin et gwenview, donc on pourrait dire que kde4 n'en est plus un non plus.
Tout fout le camp, c'était mieux à vent, mon bon monsieur.
[^] # Re: API ?
Posté par FreeB5D . Évalué à 10.
[^] # Re: API ?
Posté par Antoine . Évalué à 10.
Reprenons :
- à l'origine, GNOME choisit Gtk parce qu'il ne veut pas de C++ et que le C est suffisant pour faire de l'objet
- pendant 15 ans, les développeurs GNOME se font chier, je veux dire s'amusent comme des fous, à écrire du code objet convolué avec l'API C de gobject
- au final, tout le monde GNOME saute de joie avec l'arrivée de Vala parce qu'ils peuvent enfin écrire leurs applications dans un langage exprimant de l'objet plus ou moins naturellement
AMA, on a là une gabegie de dimensions plus que respectables.
[^] # Re: API ?
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: API ?
Posté par Albert_ . Évalué à 5.
[^] # Re: API ?
Posté par Antoine . Évalué à 4.
[^] # Re: API ?
Posté par auve . Évalué à 5.
[^] # Re: API ?
Posté par GeneralZod . Évalué à 10.
À l'origine, c'est surtout que Qt était pas libre d'où la recherche d'une alternative libre (Gtk+).
Quant au choix de C, c'est surtout dû à la facilité d'écrire des bindings et de permettre d'écrire des applications GNOME dans une variété de langages. Là où KDE estimait que C++ se suffit à lui-même, GNOME a préféré laisser le choix du langage.
GNOME n'est pas écrit entièrement en C, seul le coeur l'est, les applications GNOME sont écrites dans une variété de langage: C++, Python, Javascript, C# etc ...
Pour Vala, l'intérêt c'est d'avoir un langage de haut niveau simple (pas comme C++), performant (pas comme C#, Java) et qui soit 100% interopérable avec le C.
Avec l'arrivée de GI (GObject Introspection), l'écriture de bindings sera encore plus facile (voire s'en passer).
C/GObject était et reste encore un choix pertinent, si tu veux des plantages de GNOME, c'est du côté de Bonobo et des libgnome* qu'il faut voir.
De son côté, KDE pousse un peu plus les bindings (grâce à smoke entre autre), pour autant, je vais pas dire non plus que le choix de C++ est un échec de KDE. Faut replacer chaque chose dans son contexte.
[^] # Re: API ?
Posté par Albert_ . Évalué à 3.
Qui etait absolument pas prevu pour ce que cela a ete utilise au depart d'ou un joyeux merdier et des annees avant de voir sortir un truc du projet Gnome et en dehors de Gimp c'etait passablement minable...c'est rigolo car justement Gtk a l'epoque cela voulait dire Gimp Tool Kit... (je vous laisse juste verifier mes dires, installer une distrib a base de gnome1 et une avec KDE de la meme epoque vous allez pleurez).
Et par rapport a Qt pas libre c'etait juste un pretexte comme l'a prouve mono de plus a l'epoque le projet officiel etait GNUstep qui n'a jamais decolle par manque de developpeurs.
Cela me rappelle une expression d'ailleurs: "Diviser pour mieux regner"...
[^] # Re: API ?
Posté par GeneralZod . Évalué à 0.
prétexte à quoi ? Qt n'était pas libre point barre, à l'époque, les gens avaient tenté de convaincre Trolltech de modifier la licence et/ou convaincre KDE d'utiliser autre chose.
> comme l'a prouve mono de plus a l'epoque
Prouver quoi ? Mono est libre, et ses fesses sont assurés par OIN.
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
Tu as oublie la partie sur GNUstep. Si il y avait eu une veritable logique c'etait pousse GNUstep pas creer un nouveau projet sur des fondations totalement batarde (Gimp Tool Kit).
Mono est libre, et ses fesses sont assurés par OIN.
Et Qt est libre.
[^] # Re: API ?
Posté par GeneralZod . Évalué à 2.
Non, la première version publique de GNOME est sortie avant que la partie graphique de GNUStep soit utilisable. Certes OpenStep était probablement une meilleure base de travail, mais les gens voulaient quelque chose d'utilisable le plus rapidement possible. GNOME n'a pas été démarré par la FSF (ni GNUStep d'ailleurs) mais avec la bénédiction de la FSF.
Il est arrivé la même chose avec Linux et le Hurd, à l'origine Linux comme GNOME c'était un bricolage qui a finalement pris le dessus sur le projet plus "carré" Hurd ou GNUStep.
Au moins GNUStep n'a pas connu le destin du Hurd ou presque.
> Et Qt est libre.
Aujourd'hui oui, ça ne l'était pas à l'époque des débuts de GNOME. Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
Qt est libre maintenant, mono est "libre" des attaques de Microsoft depuis tres recemment (et encore cela ne concerne meme pas l'integralite de mono il me semble donc situation du meme tonneau).
Qt/X11 a été disponible sous une licence libre à la même période ou GNOME présentait une version fonctionnelle donc voilà.
Gnome est fonctionnel? Depuis quand, la derniere fois que j'ai essaye c'etait pas le cas et c'etait il a une semaine
Plus serieusement il a fallu combien de personnes, de temps et d'argent pour arriver a un truc un peu fonctionnel par rapport a KDE? Je trouve effrayant la difference de moyen des deux et le peu de resultat de Gnome par rapport a KDE. En dehors de Opensuse et Mandriva il n'y a aucune distribution majeur derriere le projet contrairement a Gnome et encore Mandriva je ne suis plus sur que l'on puisse appeler ca encore distribution majeurs... (non ne me parlais pas de Kubuntu ca c'est de la deconstruction qu'ils font).
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
[^] # Re: API ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
[^] # Re: API ?
Posté par FreeB5D . Évalué à 2.
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
Aller si tu preferes je citerais Moonlight initie et developpe par la meme personne qui a lance Gnome et la c'est amusant mais les problemes de liberte l'embettent beaucoup moins... Donc je persiste c'etait bien un pretexte la licence de Qt.
D'ailleurs Moonlight a ete mis a l'index par ta distribs prefere.
https://fedoraproject.org/wiki/ForbiddenItems#Moonlight
[^] # Re: API ?
Posté par FreeB5D . Évalué à 1.
[^] # Re: API ?
Posté par Antoine . Évalué à 2.
À ce que j'en sais, Qt fournit des bindings Python & co aussi bien que gtk. J'imagine que KDE pourrait faire de même, si ce n'est pas déjà le cas.
[^] # Re: API ?
Posté par GeneralZod . Évalué à 3.
KDE n'a jamais été réfractaire aux bindings, c'est juste que le dialecte C++ employé par Qt était suffisamment souple pour que la majorité des développeurs s'y retrouvent.
Sinon, à l'exception de PyQt (Riverbanks), QtJambi &PySide (Nokia), la plupart des bindings Qt sont maintenu par KDE à l'aide de l'outil smoke (.Net, Ruby notamment)
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
[^] # Re: API ?
Posté par claudex . Évalué à 6.
T'es tu posé la question du pourquoi chaque desktop recouvre les défauts des autres parce qu'il n'a pas fait les même choix technique que l'autre. S'il n'y avait qu'un desktop, il y aurait peut-être beaucoup plus de défaut et beaucoup de moins de développeurs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par imr . Évalué à 2.
oui
>parce qu'il n'a pas fait les même choix technique que l'autre.
non
>S'il n'y avait qu'un desktop, il y aurait peut-être beaucoup plus de défaut et beaucoup de moins de développeurs.
comment est ce possible?
[^] # Re: API ?
Posté par benoar . Évalué à 5.
Les devs ne sont pas des esclaves, ils bossent sur ce qu'ils aiment. Si un bureau unique fait des choix techniques de merde, il aura beaucoup moins de devs. CQFD.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: API ?
Posté par grid . Évalué à 2.
Je dis ça, je dis rien.
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: API ?
Posté par Laurent A. . Évalué à -2.
Au lieu de raconter n'importe quoi, tu ne pourrais pas aller lire le blog de Poettering ? Ce type passe des heures à communiquer -- au lieu de développer -- sur son blog pour essayer de faire disparaître toutes les bêtises qu'on peut voir à propos de PA. Le moins que l'on puisse faire, c'est au moins de lire ce qu'il raconte, non ? Notamment, le monsieur explique que PA et Jack ont des objectifs TRÈS différents. Alors maintenant, tu vas lire son blog et ensuite tu reviendras...
Merci.
PS : si PA consomme 40% de CPU, il faut faire un rapport de bug. Moi, j n'en ai rien à faire de lire tes problèmes, on n'est pas sur Clubic où chacun vient raconter n'importe quoi. Si tu espères une aide sur linuxfr, va sur le forum pour décrire précisément ta configuration matérielle, la version de PA que tu utilises, sous quelles conditions tu rencontres ton problème, etc. Si tu penses que c'est un problème fondamental de PA et qu'il faut que le monde entier soit au courant, il faudrait le prouver ^_^
[^] # Re: API ?
Posté par Cyberdivad . Évalué à 5.
Ben en même temps, j'ai l'impression que tout le monde subit ses petites contrariétés avec PA. En tout cas toutes les personnes qui utilisent PA et avec qui j'ai eu l'occasion de discuter. Chez moi aussi PA prend souvent plus de cpu que je ne voudrais. Etant joueur à mes heures je me rend vite compte de ce genre de phénomènes :) Sinon il y a aussi le fait qu'il claque souvent entre les doigts, une chance que cela arrive chaque fois que l'on lance ou quitter une application utilisant le son. Je n'ai pas déclaré mes soucis car je n'ai pas les compétences pour le faire mais après avoir fouillé google avec mes logs, j'ai découvert que des milliers de pages de forums/mailing lists/etc. traitaient des mêmes problèmes. Je n'ai pas la compétence pour désactiver PA (le guide que j'ai suivi n'a pas marché et je n'ai pas envie d'y passer des heures pour risque de casser tout mon système) alors je subis, comme les autres.
[^] # Re: API ?
Posté par claudex . Évalué à 5.
Utilise alors une distribution adaptée à tes compétences.
(sous mandriva: controle center -> son -> désactiver pulse audio -> appliquer)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par Cyberdivad . Évalué à 1.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par Cyberdivad . Évalué à 1.
[^] # Re: API ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: API ?
Posté par Cyberdivad . Évalué à 1.
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Autre chose, si tu dé-installes tout pa, le mplayer du paquet mdv va segfaulter à coup sûr. Il faut au minimum laisser la biblio principale, juste ce paquet suffit.
Néanmoins mdv propose draksound : un clique suffit pour ne pas utiliser pa et laisse l'utilisateur libre de ses choix : ceci suffit à utiliser facilement mandriva dans tout les cas. Le problème d'une casse si on touche au choix du système est alors secondaire car il n'est que dans un objectif de choix différent, voir de 'construction' d'une base différente. Et non de l'utilisation du système sans utilisation de pa.
[^] # Re: API ?
Posté par Albert_ . Évalué à 2.
sudo rm /usr/bin/pulseaudio
ou tu le bouges si tu as un peu peur. Ce qui est amusant en faisant cela, comme cela m'a ete confirme dans un forum ou j'avais donne cette solution, c'est que c'est la seul method pour que ce logiciel ne prenne pas la main pour le son (la method officielle avec padevsuspender je crois n'est pas fonctionnel).
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 3.
'est au moins de lire ce qu'il raconte,
Tu exagères : crois tu que je ne sois pas aller lire son blog ou/et les échanges sur les principales listes ?
PA et Jack ont des objectifs TRÈS différents
Cela n'a pas toujours été le cas : pa devait amener l'unification des fonctions de gestion du son et de plus être adoptés de manière uniforme.
Ensuite je ne reproche pas cela à pa, au contraire. Je pose des questions et rale un peu sur l'impression et ma constatation d'utilisateur que pa ne permet pas et ne permettra pas dans un futur proche de remplir cette fonction d'être là pour tous.
Enfin les objectifs différents je marre dessus, si tu permet ces expressions ...
Si tu espères une aide sur linuxfr, va sur le forum
Ai je demander un support ? Les commentaires des dépêches et journaux sont ils fait pour cela ?
[^] # Re: API ?
Posté par Laurent A. . Évalué à -1.
$ lash_control
lash_open_socket: could not connect to host 'localhost', service '14541'
lash_comm_connect_to_server: could not create server connection
jackd 0.118.0
C'est quoi cette histoire ??! Pourquoi il ne se connecte pas ? Et plus loin (dans le même message) :
JACK is running in realtime mode, but you are not allowed to use realtime scheduling.
Your system has an audio group, but you are not a member of it.
Please add yourself to the audio group by executing (as root):
usermod -a -G audio lolo
Donc pour permettre à quelques applications de faire pouet lorsque je clique sur un bouton il faudrait que tout un framework ait des permissions permettant de bloquer tout le système ? Déjà que Flash fait chier parce qu'il passe trop de temps CPU à faire des traitements graphiques, là j'aurais aussi la possibilité d'avoir des blocages grâce à l'audio. Chouette !
Par design, Jack semble être tourné vers les pros. C'est une supposition qui fait sens. Elle permet de considérer que si l'utilisateur est mauvais ou fait n'importe quoi, les choses ne fonctionneront pas et le programme pourra même planter. La taille du code est ainsi réduite. Pourquoi vouloir transformer cela en un machin à tout faire ?!
[^] # Re: API ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
Non, ça te dit qu'il faut que toi, lolo, tu sois membre du groupe audio pour avoir le droit d'écrire sur la carte son. Rien de plus normal.
[^] # Re: API ?
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: API ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: API ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Là tu ne va pas voir comment utiliser jack, tu vas déjà lancer tout un cadre de travail.
pour permettre à quelques applications de faire pouet lorsque je clique sur un bouton il faudrait que tout un framework ait des permissions permettant de bloquer tout le système ? (...) Par design, Jack semble être tourné vers les pros.
+ 1
On retombe sur ton exemple au dessus : pour une utilisation lambda, il n'est pas nécessaire de donner tant de droits. Jack le permet : il sait fonctionner comme un serveur de son basique permettant de faire pouet quant je clique sur un bouton. On abandonne là ses possibilités spéciales en terme de latence, de traitement, et on se concentre sur ses possibilités de 'routeur' et de liberté d'action pour faire pouet.
Mais si la personne le veux, il peut alors, avec la même solution, "que tout un framework ait des permissions (...)" et avoir ainsi, avec une seule solution, une réponse à ses besoins là également.
La taille du code est ainsi réduite. Pourquoi vouloir transformer cela en un machin à tout faire ?!
encore + 1
c'est un des mes reproches envers pa (mais qui, je le repête, ne sont que des reproches d'utilisateur) : un truc qui veux tout faire. Moi ça me semble bizarre que soit au "core" de la gestion du son et de ses "routages" de faire également de la gestion évènementielle externe au son lui même. Quant le téléphone sonne, pour moi, ce n'est pas au "core" de gérer une politique de coupure des autres volumes... Quant à la gestion multi-cartes, moi il me semble que là non plus c'est pas son taf, là c'est plutot alsa lui même.
[^] # Re: API ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 3.
Ce n'est rien d'autre que du routage évenementielle : « quand tel évènement arrive, change le routage ». Ce n'est pas non plus le rôle d'ekiga de décider quand couper le son des autres applis. Par contre c'est le rôle d'ekiga d'informer PA qu'un évènement vient d'arriver, pour que PA puisse router correctement.
Quant à la gestion multi-cartes, moi il me semble que là non plus c'est pas son taf, là c'est plutot alsa lui même.
Et c'est quoi d'autre que du routage, la gestion multi-cartes ?
[^] # Re: API ?
Posté par cosmocat . Évalué à 5.
Pour ceux qui n'y comprennent rien comme moi ou comme toi (bien que tu as l'air de tater...) :
http://www.tuxradar.com/content/how-it-works-linux-audio-exp(...)
# [:aloy]
Posté par sirrus . Évalué à 1.
Cette dimension fractale fait que par exemple, beaucoup de gens se plaignent aujourd'hui qu'il y ait 42 fois plus de distributions que dans les premières années de linux.
De même on se retrouve avec 42 logiciels pour un certain type d'utilisation (genre la lecture multimédia) au lieu d'un nombre plus restreint. L'argument étant que chaque logiciel a une spécificité en particulier.
Ce que les gens ignorent, c'est que ça va être pareil pour le son sous linux ! 42 serveurs ou composants faisant la même chose mais différemment et chacun avec une spécificité !
C'est ça aussi l'esprit gnu.
[^] # Re: [:aloy]
Posté par Gniarf . Évalué à 5.
..."remets Windows"
[^] # Re: [:aloy]
Posté par kursus_hc . Évalué à 4.
Ca marche parfaitement sous linux via wine, c'est simple, rapide, sans flash, il y a un énorme catalogue, la qualité est correcte (320 kbps), et c'est sûrement beaucoup plus légal qu'une collection de plusieurs milliers de mp3 rippés à partir d'on ne sait quoi. Ca coûte 10€ par mois, soit le prix de deux pintes.
[^] # Re: [:aloy]
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: [:aloy]
Posté par Gniarf . Évalué à 4.
peut mieux faire...
oui ça se contourne, ça se règle, mais je n'ai pas l'intention de faire du support à travers la ville pour quelque chose qui devrait marcher out of the box.
[^] # Re: [:aloy]
Posté par imr . Évalué à 7.
Il y a deux possibilités pour résoudre ce problème.
L'une est d'utiliser une distro avec pulse audio.
L'autre est d'utiliser une distro sans pulse audio.
[^] # Re: [:aloy]
Posté par Gniarf . Évalué à 4.
*avoir du son qui marche très très vite presque tout de suite et passe le cas utilisateur décrit précedemment, avec au plus une Bidouille Technique Magique (comme virer/remplacer PulseAudio ou déplonker le schgouna dans /proc/zlika) mais pas deux.
*ne pas utiliser Linux et retourner sous Windows
le reste, c'est être emmerdé, et j'ai pas que ça à foutre. enfin, si, moi à titre perso pour ma pomme ça irait, mais pour essaimer des Liniouks à gauche et à droite en chantant les louanges du Logiciel Libre c'est aller au casse-pipe.
[^] # Re: [:aloy]
Posté par Frédéric Perrin (site web personnel) . Évalué à 3.
C'est ça aussi l'esprit gnu.
L'esprit GNU ? Montre-moi plusieurs projets GNU qui font la même chose les uns que les autres (oui, bon, GNOME est un projet GNU, et il a sa part de duplication de code...)
Dans le système GNU, il y a un shell (bash), un éditeur de texte (emacs), un compilateur (gcc), un gestionnaire de version centralisé (CVS) et un décentralisé (bazaar), etc.
Après, si tu dis que c'est l'esprit Linuxien...
[^] # Re: [:aloy]
Posté par claudex . Évalué à 10.
Déjà Emacs fait doublon avec tout les autres.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: [:aloy]
Posté par Diagonale de Cantor (site web personnel) . Évalué à 10.
Ben y'a:
– GNU/Emacs shell vs bash ;
– GNU/Emacs (Info) vs man ;
– GNU/Emacs vs evince (et oui emacs lis les pdf) ;
– GNU/Emacs vs Gtwitter ;
– GNU/Emacs vs Evolution ;
– GNU/Emacs vs epiphany (navigateur)...
Par contre j'ai pas trouvé d'équivalent GNU/Emacs à Gimp.
[^] # Re: [:aloy]
Posté par dguihal . Évalué à 8.
Heuuuuh non rien faites pas attention j'ai rien dit ~~~>[]
[^] # Re: [:aloy]
Posté par Frédéric Perrin (site web personnel) . Évalué à 3.
Donc non, emacs et Hurd ne se font pas concurrence :)
Je n'aurais jamais dû mentionner emacs...
# non pas 3 jack, mais 4
Posté par bubar🦥 (site web personnel) . Évalué à 10.
Jack2 fourni jackd, tel que jack1 mais ré-écrit en c++ donc, avec support des multi-coeurs.
Jack2 fourni aussi jackdbus, qui lui est beaucoup plus soumis à controverse (attention : de manière réellement objective).
Jackd de jack2 :
Il est logique que les distributions tendent à remplacer jack1 par jack2, pour et uniquement pour son jackd. On y gagne en fiabilité et en stabilité. Objectivement. Jackd de jack2 n'est jamais emporté avec une application qui plante sévèrement, ce qui a tjs été un point noir de jack. [C'est certainement possible, néanmoins je ne l'ai jamais vu, et pourtant je le maltraite fort et le pousse à bout, le jackd). Il n'est pas seulement question donc de portabilité, ni même de choix de langage : il s'agit là de débat allant bien au delà. Plus basiquement il s'agit d'utilisation : jackd de jack2 est objectivement meilleur que jack1.
Bravo à grame.fr ...
Jackdbus de jack2 :
il y a là un côté enfermement qui fait bizarre, avec les outils ladish. On aime ou pas. En tout cas une large majorité de développeurs Linux Audio ne semblent pas vouloir l'adopté, et quasiment aucune application ne supporte actuellement et ne s'oriente vers le support de jackdbus. On revient donc sur Ladish, qui apporte des éléments assez essentiels de manière facile : les enregistrements des studios [ie : on retrouve facilement toutes ses connections] mais d'un autre côté tout se passe dans ladish...
Et puis il y a le problème Dbus : je ne crois pas, avec mes humbles tests, que Dbus soit réellement prêt pour cela (les contraintes sont très fortes quant même). Au final jackdbus me semble quelque peu inutile, avec un arrière goût de ré-écrire la roue, et avec le danger de voir certains des atouts de jack disparaitre "parceque dbus utilisation" ... Là seul les dev peuvent vraiment dire en fait. En tant que simple utilisateur, j'ai des doutes quant à son utilité réelle.
Ensuite, on peux comprendre sans mal les réticences d'un côté comme de l'autre et la difficulté de rester objectif. Par exemple ce post de Lenard c'est du pur fud. C'est vraiment désolant de lire des billets pareil de la part de gens de cette valeur.
Il repart sans cesse sur son principe (qui n'est pas de base, qui a fait jour suite aux limitations de pulse lors de la confrontation avec l'utilisation IRL) : Jack et PA n'ont pas le même objectif. C'est vraiment chagrin de lire encore ça aujourdhui. Ce n'est pas faux mais c'est de la manipulation mentale : en mettant en avant le fait que Jack soit taillé pour de fortes contraintes, et en ne disant jamais, simplement, que jack peux tout à fait être utilisé en dehors de ces fortes contraintes. Un jack de base avec de grosses latences, un gros buffer, et avec tout simpement les softs qui se connectent à l'entrée système, c'est possible,.. Jack n'oblige nullement son utilisateur à avoir l'énorme panoplie décrite. Il peux le faire, il peux encaisser ces contraintes. Mais il peux aussi se contenter d'un pc de base et d'une utilisation de base.
Tout comme on peux comprendre la réaction des autres développeurs de jack1 devant le fait que jackd de jack2 est en train de remplacer jack1.
Moi je regrette juste que les distributions grands publics n'aient pas fait l'effort de porter jack au niveau Michu. Et se contenter de copier aveuglement le taf de redhat, dont ce dernier ce contre-fout : ni l'embarqué ni le desktop ne l'importe.
Voilà un constat dénué de prise de position :
D'un coté on a PA qui commence seulement à marcher normalement... pour faire le taf de base, mais qui ne sera jamais capable (dixit son auteur : c'est pas pour ça que PA est fait) d'assurer un cahier des charges à fortes contraintes.
D'un autre côté on à Jack, qui est capable de tout faire mais qui ne bénéficie pas de l'intégration nécessaire pour être michu compliant par défaut.
Actuellement aucun des deux n'est réellement valables pour un "meilleur desktop".
Alors que franchement, un icone "volume" lorsque tu cliques dessus ça te sort une interface où il suffit de glisser déposer pour modifier les entrées et sorties de tout les logiciels entre eux... je vous laisse imaginer l'impact que ça aurait pu avoir, c'est pas du volume par applil ça monsieur, ça va bien plus loin si vous le souhaiter.
mes 2 cents.
[^] # Re: non pas 3 jack, mais 4
Posté par claudex . Évalué à 3.
Est-ce qu'il est possible, avec Jack, lors d'un appel entrant de Ekiga, de couper le son (sauf pour Ekiga) et de rediriger son + micro sur le casque bluetooth.
Parce que si j'ai bien compris, c'est le but de pulse audio
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: non pas 3 jack, mais 4
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Tu soulèves le point essentiel : l'intégration michu-ready.
Pulseaudio a toujours eu cela en ligne de mire, en objectif primaire (avant même un fonctionnement correct). On a tous constaté que PA faisait des trucs sympas de ce style, mais que d'un autre côté il était capable de consommer 12% de 2 xeon à 3ghz juste pour mixer 2 sources. Y a du bon et du moins bon. J'essaye de ne pas juger. Après toutes ces années, PA commence tout juste à faire ce genre de choses.
Il s'agit là d'un exemple de scénarios de fonctionnement. Un de ces exemples qui rendent le desktop linux meilleur. Meilleur dans la mesure où cela ne l'ampute pas ailleurs... Parceque si c'est juste pour couper le son de la musique quant un appel est reçu et que cela se fait au détriment des développeurs audio de linux, je ne sais plus quoi penser.
Il a peut être là une grave erreur de design, mais je ne peux pas vraiment le savoir, je n'ai pas les compétences pour.
Pour revenir à ton exemple, il illustre la demande de routage automatique de flux audio, ainsi que de politiques appliquées par défaut à ces flux. Revenons sur terre : il s'agit là de théorie, car même la dernière Ubuntu, la dernière Fedora et la future Mandriva ne permettront pas cela par défaut. Nous sommes donc dans un exemple d'objectifs, et pas un exemple de réalité.
La dissociation des flux audio et d'informations sur l'audio dans jack2 permet de pouvoir jouer sur cela sans perturber les capacités réelles du serveur de son. Jack peux déjà faire de la "synchronisation" de fonctions sur les flux, en fait il a toujours pû. Il est possible de stopper la lecture d'une piste (et donc de toutes les applications de cette piste) en en gardant une autre. Il est possible de faire une appli par pistes ou une multitudes d'applis sur une piste. Donc en théorie c'est possible aussi... Mais là encore on est dans la théorie car jamais personne n'a proposé des scénarios de fonctionnement pré-établis par défaut permettant de faire cela "automatiquement out-of-the-box). Théorie car Jack ne s'occupe pas de cela, il permet de le faire, nuance de taille. On peux reprendre l'adage "il fait une chose et la fait bien".
Par contre il est intéressant de regarder du côté de la "grande bataille des sessions" (des solutions permettant de faire cela : enregistrements de sessions et prévision-intégration de fonctionnements, de scénarios) car une excellente nouvelle est tombé récement : un mouvement d'unification des solutions jusqu'alors disparates :
http://linuxmao.org/tikiwiki/tiki-read_article.php?articleId(...) (lien en Français d'un des meilleurs sites au monde de musique sur linux (!) renvoyant vers les archives des diverses ML en anglais pour suivre l'évènement)
Jack fait une chose, et la fait bien. Jack_session en fait une autre et commence à bien la faire ... En fait on est dans le cheminement inverse de pulse : ils ont d'abord fait quelque chose de solide et de stable, consommant quasiment rien tout en répondant à un cahier des charges 'pros', et maintenant il est question d'intégration et de facilités... qui bénéficeront à tous y compris à moi ou mr michu...
[^] # Re: non pas 3 jack, mais 4
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: non pas 3 jack, mais 4
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: non pas 3 jack, mais 4
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: non pas 3 jack, mais 4
Posté par pepone (site web personnel) . Évalué à 2.
Plusieurs carte avec jack, c'est possible, mais ça ressemble un peu à du bricolage: http://www.linuxmao.org/tikiwiki/tiki-index.php?page=Jack+et(...)
C'est un des avantages de pulseaudio je trouve.
[^] # Re: non pas 3 jack, mais 4
Posté par bad sheep (site web personnel) . Évalué à 6.
Maintenant, pour avoir utilisé les 3 (jack, jack2 et PA) :
- PA : plein de bonnes idées, implémentation parfois malheureuse (sans doute due aux drivers hein...)
- jack* : juste ce qu'il faut pour le pro, mais pas simple à configurer pour mme Michu. jack était une super idée à la base, mais qui manquait de fiabilité, problème que jack2 a corrigé. J'ai un peu contribué avec Stéphane à travailler sur jack2 et à corriger quelques trucs (problèmes de design en multi-utilisateurs notamment), et je dois dire que j'en suis assez satisfait, ça marche bien. Maintenant, pour les mecs qui n'aiment pas le camelCase dans le code, je trouve ça un peu dommage, mais bon, qu'ils fassent leur fork si ça les chante.
Lennart a un peu raison dans son post, les deux approches sont assez différentes, il est dommage de ne pas les mixer, idéalement, il faudrait que jackd puisse être un client de PA et que l'inverse soit vrai (j'aurai bien aimé cela au moment où je développais sur jack)... maintenant, il faut voir que ça marche sous OS X... c'est même la plateforme où tout marche le mieux avec Jackd... alors au lieu de ré-inventer la roue, il pourrait regarder un peu ce qu'ils font, je ne suis pas sûr que ce soit si infaisable sous les autres POSIX (modulo le setup forcément un peu plus complexe niveau temps réel car sous Mac, les utilisateurs normaux peuvent chopper les droits RT par défaut)
Bref... rien de bien nouveau ni de constructif, mais jack2, ça marche bien quand même :-)
# Tout ça ...
Posté par dinomasque . Évalué à 8.
BeOS le faisait il y a 20 ans !
[^] # Re: Tout ça ...
Posté par Gniarf . Évalué à 10.
[^] # Re: Tout ça ...
Posté par inico (site web personnel) . Évalué à 1.
[^] # Re: Tout ça ...
Posté par Frédéric Perrin (site web personnel) . Évalué à 9.
[^] # Re: Tout ça ...
Posté par Guillaume Knispel . Évalué à 3.
[^] # Re: Tout ça ...
Posté par bubar🦥 (site web personnel) . Évalué à 4.
Je connais encore moins freebsd que linux, c'est juste que les noyaux ont pris des chemins bien différents et qu'il est est difficile de demander à freebsd de remplir un cahier des charges tel que celui ci : "64 pistes dont de nombreuses sont re-routées et travaillées au moins une fois avant d'être "piste" sur l'enregistreur. Le tout tenant une latence sans faille de 0,002millisecondes (...)". Pourtant jack fonctionne très bien en dehors de ces contraintes un peu folles. "qui peux le plus peux le moins". Et sur un desktop freebsd, avec oss pour le noyau, jack met en valeur ses autres atouts : proposer un routage aisé et efficace. Franchementc'est sympa de faire un seul glisser déposer pour enregistrer une conversation ekiga avec audacity...
[^] # Re: Tout ça ...
Posté par FreeB5D . Évalué à 1.
Comme Linux, par exemple . OSSv4 fonctionne parfaitement sur mon PC (Arch Linux) et je n'ai pas besoin de serveur de son supplémentaire .
d'après ce que je lis
Test rapide :
$ cat /dev/urandom > /dev/dsp
[^] # Re: Tout ça ...
Posté par Albert_ . Évalué à 6.
# Pulseaudio sur des téléphones ?
Posté par benoar . Évalué à 3.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par claudex . Évalué à 10.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pulseaudio sur des téléphones ?
Posté par M . Évalué à 5.
A non même pas ( http://wiki.openmoko.org/wiki/PulseAudio ) du a une trop grosse conso.
PS : C'était mieux quand les cartes son avait des dsp capable de faire du mixage en hard... Comment ca on a des cpu de malade, mais il faut 10% du cpu pour faire ce que l'on faisait avec une vrai carte son (mixage, effet, ...).
[^] # Re: Pulseaudio sur des téléphones ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par _alex . Évalué à 5.
J'ai jamais compris pourquoi maintenant, le mixer hard n'a plus utilisé...
Même si de temps en temps, il y a du routage vers une autre carte son (oreillette bluetoth etc.), ca n'empêche pas de faire d'utiliser les possibilités de mixages hardware d'une carte quand c'est possible.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par NickNolte . Évalué à 2.
C'est parce que la batterie de ton tel est tombée en rade dés l'entrée en action de PulseAudio.
Si c'est 40% de charge sur un Core2, qu'est-ce que ça doit être sur un pov ARM :)
j'quitte le saloon ----> _|][|_
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
cet exemple de conso cpu excessive est souvent lu parceque tout simplement on est nombreux a l'avoir vu, et souvent.
mais cela ne va pas dire que pa consomme *tout le temps* beaucoup.
moi j'ai juste du mal à saisir le pourquoi ...
pourquoi pa parfois se met à bouffer 15 de 2 xeons à 3ghz alors qu'il ne mixe que 2 flux. 2 flux. Et paf il se fait une monté sur les cpu, comme ça, pendant qq secondes. Cela fait un peu peur.
Pour rendre justice, j'ai collé les 2 mêmes xeon à 96% d'utilisation chacun pendant plusieurs heures d'affilé avec Jack. Mais jack a un côté rassurant : il s'emballe pas tout seul. C'est proprotionnel à la charge demandé : pour 64 pistes dont de nombreuses qui sont trafficotés avec des effets ou d'autres sots, avant d'atterir dans l'enrgistreur, et le tout avec une config de jack un peu folle... Jack bouffait alors 96% des cpu pour faire ça, tenir ce cahier des charges.
Par contre je n'ai jamais vu jack se faire des montées sur cpu tout seul sans raison, sans demande.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 3.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par NickNolte . Évalué à 0.
"Lanus Tordable" est le pendant porno de Linus :), comme souvent dans ce domaine, ça calambour grave avec les noms.
oué... on me dit que ça bourre grave aussi! rooooo, suffit!
En gros, j'avais changé la phrase pour coller au mieux à la citation de Linus qui met plutôt en avant la plus value du LL.
Le côté "poil" fait référence aux "troll velus" qui pullulent autour du LL.
Ça donne donc ces 2 propositions qui sont néanmoins toutes deux vraies :):
Version 1:
"Le logiciel libre c'est comme le sexe: c'est souvent poilu"
Il y a souvent des poils sur le sexe et y a souvent pleins de "troll velus" autour des LL
Version 2 qui correspond mieux à l'idée:
"Le logiciel libre c'est comme le sexe: c'est meilleur sans poil"
Le logiciel libre c'est tout de même meilleur sans "troll", non?
CQFD!
Je sais, je sais, elle est vraiment tirée par le poil cette signature! :-]
-->[]
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . Évalué à 2.
Lors du dernier Linux Plumbers Conferences, deux conférences portaient sur PA et l'embarqué (dont l'une plus particulièrement avec le N900)
[^] # Re: Pulseaudio sur des téléphones ?
Posté par benoar . Évalué à 4.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . Évalué à 3.
Jusqu'à présent, LiMo se concentre sur les mobiles en milieu de gamme donc ça chiffre pas mal en volumes. La plateforme est mature, les composants sont standardisés (notamment téléphonie), mais ils ont manqués d'ambition (ils ont loupés le coche des smartphones) et le côté consortium industriel fermé n'a pas aidé à constituer une communauté autour.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par benoar . Évalué à 2.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par GeneralZod . Évalué à 3.
Note que motorola a quitté LiMo fin 2009 et que Samsung investit de plus en plus dans Android, les derniers mobiles LiMo sont des Necs principalement vendus au Japon.
Ce n'est pas surprenant vu qu'ils n'ont pas su vendre leur plateforme auprès du grand public (malgré le succès commercial de certains mobiles), des développeurs, l'arrivée tardive des smartphones.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
PA sur des téléphones ? Non pas exactement. PA sur les systèmes de certains téléphones. Systèmes. Les contraintes GSM et téléphonie pure mettent ko pulseaudio. PA se contente de mixer la sonnerie avec la musique, et de couper cette dernière lorsque le bouton "répondre" est actionné. PA ne peux pas supporter les hautes contraintes de gsm, il travaille à plus haut niveau.
En fait, PA est utilisé là où il excelle absolument : la politique. Il ne devrait pas faire serveur de son, il est pas bon pour ça. Il devrait se "contenter" de donner des ordres au serveur de son. Mais comme "ils ont des objectifs différents" (sic) p.a et jack continueront de se marcher sur les pieds sur les fonctions essentielles.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
Vu qu'on peut utiliser les deux en même temps, est-ce vraiment grave ?
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 3.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 1.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 4.
le sink-jack n'utilise pas jackd.
il utilise jackdbus.
PA, au démarrage de l'ordinateur, va lancer jackdbus. Jackdbus se retrouve alors client de pa.
Impossible donc de faire de la mao, car jack va être contraint par les limites de pa en terme de latence et de capacités de traitement. Enfin les lmitations liés à jackdbus lui même, en plus de celles de pa. Bref ça a marché chez toi pour faire pouet, mais n'essaye pas de relever un défi de latences pour faire de la mao, ni d'installer ça chez le pote qui a un home-studio.
De plus je veux bien te croire "ça marche chez moi", mais sur trois distributions (ubuntu, mandriva et fedora) ce montage amène rapidement des crash de l'ensemble. Alors même si ce montage était viable en terme de réponse aux besoins (ce qu'il n'est pas) il ne serait de toute façon pas possible de l'utiliser en l'état actuel.
Il n'y aurait qu'un seul moyen de faire cela proprement, pour contenter tout les types d'utilisations : que pa soit client de jackd.
Et propre le mot est vite dit puisque dans les fait la situation n'a finalement pas évoluée d'un pouce : on a toujours un gros fatra pour le son sous linux. Un gros fatra qui est plus joli qui fait le Flash, certes, mais un fatra quant même :(
Moi pa ou jack la question n'est pas là. (si je rale après le choix de pa c'est parcequ'au moment du choix jack était déjà meilleur). PA ou Jack on s''en fout. Juste un truc qui marche bien pour tous. Mais c'est trop attendre visiblement.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par boq . Évalué à 3.
C'est PA qui est client de jack. Les applications qui ne connaissent pas jack utilisent PA. Les application de MAO utilisent jack.
(Et ça marche chez moi aussi)
En fait je crois que je sais comment tu t'es démerdé: ce module est sûrement prévu pour jack1, pas jack2.
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
/me est étonné vu que y a confirmation par un dev de pa...
[^] # Re: Pulseaudio sur des téléphones ?
Posté par boq . Évalué à 2.
J'ai d'ailleurs découvert via l'edito sonore de ce mois-ci qu'il y a un tuto sur linuxmao avec plus ou moins les même manips que moi.
http://linuxmao.org/tikiwiki/tiki-index.php?page=pulseaudio+(...)
[^] # Re: Pulseaudio sur des téléphones ?
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.