bubar🦥 a écrit 6974 commentaires

C'est parcequ'on projete ce qu'on connait en france sur l'angleterre. Nombre de bureaux de votes et mode de fonctionnements des bureaux (et du vote lui même) sont différents. Ici la démocratie c'est une luxueuse organisation, avec de grands moyens. Ici on fait rarement la queue plus de 30mn même dans un grand bureau même aux heures de pointes.
Demandez vous pourquoi il y a de si longues files d'attentes là bas...

/mode ironie
bah de toutes façons on a plus besoin d'hommes politiques : c'est tous des pourris c'est bien connus. Le marché peux réguler nos vies, on s'en portera mieux et ça coutera moins cher. Et puis les grands patrons, grands actionnaires et sous ensemble de clubs, eux ils sont honnêtes et détachés de tout intérêts personnels, c'est bien connus. La démocratie, les fonctionnaires, la sncf, tout ça, zou au chomdu. Le libéralisme n'a pas besoin d'eux.

J'suis d'accord et apprécie ton humour, néanmoins permet moi de présenter les choses sous un autre angle : en fait c'est toi, là, qui fait de ton bureau informatique une extension par extrapolation de ton bureau physique : un bureau "rangé".

Car pour la machine et son système le rangement par ordre alphabétique ou thématique ou whatever, excuses moi, mais elle s'en tape le coquillard. Pour elle c'est juste un gros tas de fichiers, de données.

Qu'elle te montre où ils sont par une abstraction de type console, gestionnaire de fichiers ou résultat de recherche : tout ceci reste, du point de vue système, qu'un gros tas de données.

Avoir ses fichiers rangés et classés sur son bureau et dans ses dossiers c'est de l'informatiquomorphisme. Seul compte l'accès, sa facilité et sa rapidité.

Quant tu as 700 pdf, en vrac ou pas, tu es bien content de disposer de l'outil informatique et d'utiliser celui-ci également pour ça et non uniquement pour la dématérlisation des documents : pouvoir demander à l'ordinateur de rechercher des occurences sur des chaines *dans* tout les fichiers, cela va nettement plus vite et est nettement plus efficace.

Moi ce qui me laisse perplexe c'est le bureau sémantique d'aujourdhui : à mon avis cela n'a absolument aucune utilité pour le moment : car il s'agit d'ajouter des données aux données. Cela deviendra intéressant quant l'indexation initiale sera capable seule d'élaborer des stats et des recoupements, de trouver par elle même les mots clefs. Sinon c'est juste ajouter à la main des données aux données. Non ?

quelques explications :

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.

Tu n'as jamais été homme d'affaire ? c'est pour la coc et les putes bien sûr.

(irlande, étudiant, toussa)

Sa vision et peut être faussé, mais la tienne c'est carrément de l'utopie. Reviens sur terre, t'es pas sur la planête bisounours ici...

Ils me font marrer les libéraux àlanoix. Ben vas y tiens, va leur parler de société libérale chez mdv. C'est un peu comme le coq, même les 2 pieds dans la merde il continue d'aimer sa condition. "pas content"(des élections) ha bon ? ben tant pis pour toi, hein.

et c'est tout ?

Tu nous expliques comment s'il te plait ?

Encore une fois il joue sur les mots.
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.

Comme quoi, même les utilisateurs les plus avancés n'aiment pas les changements imposés, même les plus simples, et sur les interfaces les plus simples

(...)

Imr, je crois (il me semble) qu'on est d'accord sur pas mal de choses, et entre autre là, sur ce bourrage de mou permanent qu'opèrent certains. Quant les mêmes ne s'amusent pas à faire touner en bourrique les utilisateurs... (du genre passer une demi heure avec un utilisateur sur un bug, en le disant lourdement bien dire à chaque moment "toi utilisateur tu es en bas et tu a de la chance que je t adresse la parole."
Mandriva a trop changé, du moins certains ont trop changés pour moi. Moi aussi certainement, mais je reste simplement le pragmatique que j'ai toujours été. Quant Debian ou la FSF écrit "c'est pas libre ça pu" j'écoute et je lis, ça me fait réflechir. Mais tout le monde n'est pas Debian ou la fsf. L'illustration au dessus c'était juste pour dire que tout le monde dit ou fait des conneries, on ne peux pas juger de manière lapidaire et définitive sur qq mots ou qq conneries.
Enfin, pour rebondir (en h.s ici) sur ton questionnement sur les developpeurs et les choix qu'ils font, moi avant d'aller critiquer les dev je critiquerais l'encadrement de certaines boites du "libre" qui n'hésitent pas à virer, à laisser partir, à ne pa retenir juste parcequ'ils se disent "c'est libre on retrouvera qq un" et finir par vider un projet de tout les gens qui en sont l'essence réelle, le vrai coeur.
Imr, merci pour tout, pour ton accueil à l'époque, pour ta constance, pour ta patience pour ta compréhension, et c'est vraiment dommage qu'il n'y en pas plus des imr...

en même temps, il est très facile, imr, de retrouver certains de tes posts sur un forum où tu le fait aussi le coup du "c'est pas liiiibre" .... Donc, bon...

Tiens, : google recherche "imr libre pas libre" sur le fofo en question :
http://forum.mandriva.com/viewtopic.php?t=60885
Où tu fais la leçon de morale "c'est pas libre en plus reversent rien c'est que des méchants" à un utilisateur qui trouve ça juste bien d'avoir des jeux sur son linux... Et la recherche, elle en donne des exemples ou tu cris "c'est pas liiiibre" aux autres.

moi j'me casse et regarde avant tout mes erreurs, et ne rejete pas ce qui me fait me casser sur les autres même si certaines m'ont vraiment gonfler, oui, du genre le très bon exemple que tu donnes ailleurs sur linuxfr. Mais je regarde d'abord *mes* erreurs. Après tout chacun est liiiibre.

C'est intrinsèquement lié à la notion même de groupe.

"C'est comme dans Lost,
Il y a les autres, et ils sont bizarres"
(...)

ps : le "c'est souvent poilu" il s'est pris un coup de rasoir ? :)

ouhai certainement qu'on exprime mal par demi exagération.
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.

FreeBSD et OSS sont les meilleurs exemples que Jackd peux tourner sans problèmes sur des systèmes où les contraintes seront plus simples (attention me faite pas dire ce que j'ai pas dit :p) que le "super studio" et illustrent parfaitement que jack peux aussi remplir à merveille le rôle d'une belle "interface" pour tous.

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...

pour moi c'est pas au core du serveur de son de s'occuper de cela. C'est à kio / Dbus ou whatever, parfois épauler par / ou directement udev, de s'en occuper : en charge d'une politique de fonctionnement. Le serveur de son lui il sert du son, il le route. Il reçoit un ordre "coupe tout sauf x" ou "additonne x et y et route vers z", et exécute cet ordre. Mais ce n'est pas à lui de réflechir au pourquoi.

Vivi
Et sur ce même évènement on peux dire que Canonical en sort en fait grandi, grâce à l'attitude cette personne. Elle a pas "pété plus haut que son cul" si vous me permettez l'expression, en ne se trompant pas de hierarchie pour lui, en posant la question ailleurs d'abord. Donc Canonical a du personnel compétents et attentifs. Pas du gros cadors partout, malheureusement pour eux (vais pas paraphraser ce qu'as dit GeneralZ un peu plus haut sur ça précis) et pour tout le monde. N'empeche que le type il s'est pas pris pour dieu le père et a fait son taf convenablement, proprement, à hauteur de ses moyens. Par cela il 'grandi' canonical (et tempère les insupportables triades de leur dictateur bienveillant).
Et puis ... faut reconnaitre que ce bug il est découvert chez ubuntu. Preuve s'il en est que ubuntu rempli son role, là : pas la distro pour entreprises certes, mais la distro la plus usitée et la plus active en terme d'utilisateurs.

c'est effectivement possible. Si tu dé-installes quelques briques de pulseaudio, tu va alors retrouver uné dé-configuration complète des couches dessous. C'est bizarre j'ai pas creuser pourquoi le retrait de certaines briques de pa touchait et cassait la config de la brique au dessous, mais avec les paquets mandriva c'est effectivement possible. La solution est de relancer une interface pour alsa et dmix, comme aumix, afin de remonter les potards, sur la ou les cartes sons.

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.

Voyons comment utiliser Jack. Lançons lash_control
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.

Que je sois con pour ton toi c'est ta constatation ou ton droit.

'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 ?

oui c'est vrai tu as raison, dans tout les sens à cette phrase, c'est vrai, désolé, oui

Oui mais c'est également vrai qu'il s'agit là d'un comportement d'une personne. Donc c'est vrai que la manière trollesque de présenter l'évènement (que j'adore :p ) c'est exagéré. Auriez vous préféré que la personne ai fait ce post sur le bugzilla du projet directement ? Peut être que cette personne a juger judicieux par rapport à ses connaissances du sujet de soumettre en premier lieu à redhat (heu pardon, fedora) afin de voir ce que fedora en pense et de le reporter au projet ensuite ou de laisser fedora faire selon son choix. Sur cet acte réel et bien concret, effectivement cela découvre ubuntu (heu pardon canonical) comme n'ayant pas les compétences recquises sur le sujet, mais peut être que cette personne au final a eu raison de procéder ainsi ? Pourquoi reporter au projet si ce n'est pas assez précis, avec des pistes de solutions voir mieux, et si cela ne puisse être fait sur un terme plus long qu'un seul rapport ? On peux voir le même évènement comme quelque chose de positif, du moins pour la personne chez canonical qui a procédé ainsi.
non ?

/mode jeje/
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/

Non, jackd ne fait pas cela par défaut.

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...

PA permet le temps réel. Ils ont même fait rtkit, qui a aussi été implémenté très rapidement, afin d'éviter des rt-bombs. bon franchement rtkit il est moins réactif que le simple code de 200 lignes de das_watchdog... mais bon voilà, tout le monde s'est jetté dessus comme des morfales sur une tartiflette...

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.