a) D’abord, on peut utiliser Jack comme serveur de son général par défaut, mais... si quasiment tous les programmes dédiés à la production musicale supportent Jack, c’est loin d’être le cas de tous les programmes pouvant avoir besoin d’émetre du son ; et à ma connaissance, il n’y a pas de couche de compatibilité permettant aux programmes ALSA d’utiliser Jack de façon transparente, comme c’est le cas avec PulseAudio.
b) PulseAudio et Jack n’ont pas du tout les mêmes objectifs, ce sur quoi s’accordent leurs développeurs respectifs : voici ce qu’en dit Lennart Poettering, et ce qu’en dit Paul Davis (beaucoup plus succintement, dans le deuxième paragraphe). Les deux serveurs ne sont donc pas interchangeables.
Par exemple, là où PulseAudio s’accommode de sources utilisant des formats différents (fréquence et taille des échantillons), Jack impose un format unique à tous ses clients, ce qui n’est pas forcément judicieux pour un serveur de son qui serait destiné à être utilisé par toutes les applications du bureau (alors que c’est parfaitement acceptable pour les quelques applications dédiées à l’audio pro).
Du coup, le principe du « qui peut le plus peut le moins » n’est pas applicable ici, ou du moins pas dans le sens que tu souhaites : en fait c’est PulseAudio qui en fait « plus » que Jack (d’où sa plus grande complexité).
c) Enfin, et sur un plan non-technique : PulseAudio est en bonne passe de devenir le serveur de son standard sous GNU/Linux, ce à quoi ses prédécesseurs comme arts ou esd ont toujours échoué. Maintenant qu’on est sur le point d’avoir une solution unifiée (qui a dit « enfin » ?), est-ce vraiment le moment de changer de direction et de partir sur une autre base ? Si PulseAudio n’est pas parfait, corriger ses défauts me semble une bien meilleure option que de le remplacer complètement par autre chose. Et je dis ça en n’étant pas un grand fan de PulseAudio, que je n’utilise personnellement pas.
d) Enfin (pour de bon cette fois), rien ne dit que si Jack connaissait la même utilisation intensive que PulseAudio, il ne serait pas exposé aux mêmes critiques (usine à gaz, couche supplémentaire inutile-parce-qu’après-tout-avec-ALSA-ça-marche-déjà-très-bienTM, personne n’a besoin de pouvoir envoyer du son à travers le réseau, c’est nul mon programme préféré ne peut pas accéder à la carte son parce que Jack la monopolise, etc.). Jack ne fait pas l’objet de critiques (ou alors elles sont vraiment très discrètes) parce que tout ceux qui s’en servent en avaient besoin et l’ont choisi ; impose-le à tous les utilisateurs de distribution généraliste comme s’est imposé PulseAudio, je ne suis pas sûr qu’il serait mieux accueilli.
[^] # Re: comment connaître le serveur de son utilisé
Posté par gouttegd . En réponse au sondage Votre solution pour le son. Évalué à 8.
Rapidement, quelques éléments de réponse.
a) D’abord, on peut utiliser Jack comme serveur de son général par défaut, mais... si quasiment tous les programmes dédiés à la production musicale supportent Jack, c’est loin d’être le cas de tous les programmes pouvant avoir besoin d’émetre du son ; et à ma connaissance, il n’y a pas de couche de compatibilité permettant aux programmes ALSA d’utiliser Jack de façon transparente, comme c’est le cas avec PulseAudio.
b) PulseAudio et Jack n’ont pas du tout les mêmes objectifs, ce sur quoi s’accordent leurs développeurs respectifs : voici ce qu’en dit Lennart Poettering, et ce qu’en dit Paul Davis (beaucoup plus succintement, dans le deuxième paragraphe). Les deux serveurs ne sont donc pas interchangeables.
Par exemple, là où PulseAudio s’accommode de sources utilisant des formats différents (fréquence et taille des échantillons), Jack impose un format unique à tous ses clients, ce qui n’est pas forcément judicieux pour un serveur de son qui serait destiné à être utilisé par toutes les applications du bureau (alors que c’est parfaitement acceptable pour les quelques applications dédiées à l’audio pro).
Du coup, le principe du « qui peut le plus peut le moins » n’est pas applicable ici, ou du moins pas dans le sens que tu souhaites : en fait c’est PulseAudio qui en fait « plus » que Jack (d’où sa plus grande complexité).
c) Enfin, et sur un plan non-technique : PulseAudio est en bonne passe de devenir le serveur de son standard sous GNU/Linux, ce à quoi ses prédécesseurs comme arts ou esd ont toujours échoué. Maintenant qu’on est sur le point d’avoir une solution unifiée (qui a dit « enfin » ?), est-ce vraiment le moment de changer de direction et de partir sur une autre base ? Si PulseAudio n’est pas parfait, corriger ses défauts me semble une bien meilleure option que de le remplacer complètement par autre chose. Et je dis ça en n’étant pas un grand fan de PulseAudio, que je n’utilise personnellement pas.
d) Enfin (pour de bon cette fois), rien ne dit que si Jack connaissait la même utilisation intensive que PulseAudio, il ne serait pas exposé aux mêmes critiques (usine à gaz, couche supplémentaire inutile-parce-qu’après-tout-avec-ALSA-ça-marche-déjà-très-bienTM, personne n’a besoin de pouvoir envoyer du son à travers le réseau, c’est nul mon programme préféré ne peut pas accéder à la carte son parce que Jack la monopolise, etc.). Jack ne fait pas l’objet de critiques (ou alors elles sont vraiment très discrètes) parce que tout ceux qui s’en servent en avaient besoin et l’ont choisi ; impose-le à tous les utilisateurs de distribution généraliste comme s’est imposé PulseAudio, je ne suis pas sûr qu’il serait mieux accueilli.
Mes deux cents.