Il faut aussi compter le doublon présent dans Jack2 :
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.
# non pas 3 jack, mais 4
Posté par bubar🦥 . En réponse au journal Pulseaudio vs JACK. É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.