LMMS je pense que ça a été fait pour concurrencer fruity loops, l'ergonomie semble un peu similaire.
Concurrencer à proprement parler je ne pense pas, mais ouvertement inspiré de celui-ci, tout à fait.
Après, chaque logiciel permet de s'exprimer différemment, c'est aussi l'intérêt de passer de l'un à l'autre.
Je suis entièrement d’accord.
Jack est vraiment pas mal pour router tous les flux audio / midi, et ça reste indispensable pour des faibles latences avec un noyau *-lowlatency
Tu auras toujours la possibilité d’avoir une latence encore plus courte avec ALSA seul qu’avec Jack par-dessus. Donc non, Jack n’est pas strictement « indispensable » pour la latence. Ceci étant :
Par rapport à la latence d’un Pulseaudio (qui fonctionne, à l’instar de Jack, au dessus d’ALSA), c’est sûr que c’est incomparable. Jack, à condition d’être bien configuré, n’introduit qu’une latence absolument négligeable, c’est son but. Par contre, pas toujours facile de trouver, en fonction du matériel considéré et de sa configuration ALSA, les réglages qui vont bien (framerate, taille de tampon, etc...) pour être à la fois à ce niveau de « pas de latence (ie: supplémentaire par rapport à ALSA en pratique) » et sans « festival de xruns » (qui signifie que des frames du signal audio sont juste dropées pour préserver la latence).
Même s’il est absolument modéré, c’est surtout un overhead CPU qu’introduit Jack. Alors même si aujourd’hui les CPU ont quand même des performances de ouf, dès fois, les 5% ou 10% de CPU pris pas Jack tu voudrais bien qu‘ils servent plutôt à faire tourner cette ultime track MIDI qui malheureusement est la goutte de calculs qui fait déborder ton CPU :). Enfin pour relativiser, j’ai fini par changer de PC parce que j’arrivais au max de ses capacités CPU, aujourd’hui, même avec Jack j’ai pas encore réussi à saturer le machin. Et j’ai de la marge :)
Mais là ou Jack est probablement « indispensable » en pratique, c’est pour son côté intuitif et l’aspect « temps-réel » dans le sens où tu peux « patcher/dépatcher » n’importe quelle appli sans arrêter le son (je parle pas ici de la capacité temps-réel du noyau dont tu as besoin avec l’un comme avec l’autre). Le fait que tu puisses faire ça avec une belle UI en branchant des câbles entre les entrées et les sorties des programmes que tu veux, en ajouter en retirer, etc... c’est quand même utile ya pas à dire.
Alors qu’avec seulement ALSA, sans couche logicielle intermédiaire, même si tu peux faire les mêmes « branchements », c’est, d’abord, absolument pas intuitif (même pour une configuration par fichiers textes je trouve que c’est nébuleux...), et ensuite, si tu veux modifier un seul des branchements alors tu dois arrêter l’audio pour réinitialiser le driver de la carte son... (fût une époque où il fallait même rebooter Linux). Et autant j’ai appris à me servir de Jack sans lire plus de documentation que ça, autant ALSA je n’aurais jamais réussi à faire un truc aussi con qu’enregistrer dans un fichier le flux en même temps qu’il sort sur une carte son si je n’était pas tombé sur un document qui explique pas à pas comment faire et de manière claire. Je crois que j’aurais pu « RTFM » autant que je pouvais je n’y serais jamais arrivé.
Juste un extrait du contenu du fichier /etc/asound.conf pour illustrer le merdier :
WTF?! Et ça ça concerne une seule carte son, en bête stéréo... J’ose même pas imaginer la tronche du fichier s’il y a deux cartes son 5.1...
J’utilise parfois une deuxième carte son, mais je n’ai même pas eu le courage de la configurer pour ALSA comme la carte principale. Quand je veux m’en servir j’indique son index et les paramètres utile au client Jack que je citais plus haut et j’utilise Jack ! ^^
ALSA date d’une époque ou le fait que l’informatique soit compliquée était bien accepté par les utilisateurs... mais ça reste le composant de la pile audio directement lié au noyau Linux, celui qui s’interface avec le matériel. Ça changera p-e un jour, avant ALSA il y a eu OSS, aujourd’hui encore supporté par Linux mais quasiment plus utilisé à ma connaissance. À part par les systèmes BSD pour lesquels la MAO n’est pas la priorité des priorités je pense. Faudrait que je me renseigne d’ailleurs, ils ont peut-être fait d’OSS quelque chose de comparable à ALSA, ou du moins, plus avancé que ne la été OSS sous Linux ? (mais ça m’étonnerait).
[^] # Re: Excellent soft de mémoire
Posté par Marotte ⛧ . En réponse au lien De la synthèse audio modulaire, pour ceux qui ont kiffé AMS, essayez donc celui-là. Évalué à 4.
Concurrencer à proprement parler je ne pense pas, mais ouvertement inspiré de celui-ci, tout à fait.
Je suis entièrement d’accord.
Tu auras toujours la possibilité d’avoir une latence encore plus courte avec ALSA seul qu’avec Jack par-dessus. Donc non, Jack n’est pas strictement « indispensable » pour la latence. Ceci étant :
Par rapport à la latence d’un Pulseaudio (qui fonctionne, à l’instar de Jack, au dessus d’ALSA), c’est sûr que c’est incomparable. Jack, à condition d’être bien configuré, n’introduit qu’une latence absolument négligeable, c’est son but. Par contre, pas toujours facile de trouver, en fonction du matériel considéré et de sa configuration ALSA, les réglages qui vont bien (framerate, taille de tampon, etc...) pour être à la fois à ce niveau de « pas de latence (ie: supplémentaire par rapport à ALSA en pratique) » et sans « festival de xruns » (qui signifie que des frames du signal audio sont juste dropées pour préserver la latence).
Même s’il est absolument modéré, c’est surtout un overhead CPU qu’introduit Jack. Alors même si aujourd’hui les CPU ont quand même des performances de ouf, dès fois, les 5% ou 10% de CPU pris pas Jack tu voudrais bien qu‘ils servent plutôt à faire tourner cette ultime track MIDI qui malheureusement est la goutte de calculs qui fait déborder ton CPU :). Enfin pour relativiser, j’ai fini par changer de PC parce que j’arrivais au max de ses capacités CPU, aujourd’hui, même avec Jack j’ai pas encore réussi à saturer le machin. Et j’ai de la marge :)
Mais là ou Jack est probablement « indispensable » en pratique, c’est pour son côté intuitif et l’aspect « temps-réel » dans le sens où tu peux « patcher/dépatcher » n’importe quelle appli sans arrêter le son (je parle pas ici de la capacité temps-réel du noyau dont tu as besoin avec l’un comme avec l’autre). Le fait que tu puisses faire ça avec une belle UI en branchant des câbles entre les entrées et les sorties des programmes que tu veux, en ajouter en retirer, etc... c’est quand même utile ya pas à dire.
Alors qu’avec seulement ALSA, sans couche logicielle intermédiaire, même si tu peux faire les mêmes « branchements », c’est, d’abord, absolument pas intuitif (même pour une configuration par fichiers textes je trouve que c’est nébuleux...), et ensuite, si tu veux modifier un seul des branchements alors tu dois arrêter l’audio pour réinitialiser le driver de la carte son... (fût une époque où il fallait même rebooter Linux). Et autant j’ai appris à me servir de Jack sans lire plus de documentation que ça, autant ALSA je n’aurais jamais réussi à faire un truc aussi con qu’enregistrer dans un fichier le flux en même temps qu’il sort sur une carte son si je n’était pas tombé sur un document qui explique pas à pas comment faire et de manière claire. Je crois que j’aurais pu « RTFM » autant que je pouvais je n’y serais jamais arrivé.
Juste un extrait du contenu du fichier /etc/asound.conf pour illustrer le merdier :
WTF?! Et ça ça concerne une seule carte son, en bête stéréo... J’ose même pas imaginer la tronche du fichier s’il y a deux cartes son 5.1...
J’utilise parfois une deuxième carte son, mais je n’ai même pas eu le courage de la configurer pour ALSA comme la carte principale. Quand je veux m’en servir j’indique son index et les paramètres utile au client Jack que je citais plus haut et j’utilise Jack ! ^^
ALSA date d’une époque ou le fait que l’informatique soit compliquée était bien accepté par les utilisateurs... mais ça reste le composant de la pile audio directement lié au noyau Linux, celui qui s’interface avec le matériel. Ça changera p-e un jour, avant ALSA il y a eu OSS, aujourd’hui encore supporté par Linux mais quasiment plus utilisé à ma connaissance. À part par les systèmes BSD pour lesquels la MAO n’est pas la priorité des priorités je pense. Faudrait que je me renseigne d’ailleurs, ils ont peut-être fait d’OSS quelque chose de comparable à ALSA, ou du moins, plus avancé que ne la été OSS sous Linux ? (mais ça m’étonnerait).