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 bubar🦥 . En réponse au journal Pulseaudio vs JACK. É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...