Historique: JACK-MIDI

Cette page est toujours pas complète.

En commençant par répondre à une question : Pourquoi avoir créer une implémentation MIDI par JACK alors qu'il y en avait déjà par ALSA (voir ALSA-MIDI) ?

JACK MIDI a été créé entre autre parce que l'implémentation d'ALSA n'est plus développée depuis environ 10 ans, et c'est pour cela qu'on appelle ALSA parfois "legacy". Du point de vue des développeurs de JACK, un défaut d'ALSA réside dans le fait qu'il est implémentée dans l'espace kernel. En effet, vous l'avez remarqué, la couche ALSA vient sous formes de modules du kernel. Mais il y a surement d'autres raisons.
L'implémentation d'un transport de données autres qu'audio dans JACK est une alternative à ALSA qui a certains avantages et des desavantages (du moins pour l'instant).
Parmi les avantages on remarque les points suivants:

• Une implémentation entièrement dans l'espace utilisateur de la mémoire.
• Une implémentation plus légère et une interface logicielle moins lourde pour le développeur.
• Une liaison directe du timing des flux de MIDI aux flux audio passant par JACK, donc la possibilité d'accrocher des évênements MIDI avec une grande précision aux ondes audio générés par des synthés. C'est la fameuse histoire du "sample accurate timing", qui est pourtant soumise à beaucoup de conditionnels dans le monde réel.
• JACK MIDI est pour l'instant la seule possibilité de gérer le MIDI des cartes son firewire à travers ffado.

Parmi les desavantages on peut citer:

• Pour les developpeurs: Contrairement à ALSA, JACK MIDI ne possède pas de séquenceur intégré. En effet, ALSA décharge les logiciels clients de s'occuper du timing effectif des notes envoyées ou reçues par un mécanisme de pré-stockage d'évênements MIDI dans une "queue", et c'est le module ALSA lui même qui jouera l'évênement avec le timing souhaité par le logiciel. Ceci est fait avec une énorme précision. Dans JACK, comme pour l'audio, le logiciel doit lui même réagir en envoyant des données "quand c'est le temps", c'est à dire quand JACK demande le prochain block de données, elles doivent être accessibles et correcte. En réalité ceci n'est pas extrêmement compliquée non plus pour le développeur, mais nécessite quelques précautions.
• Le timing du MIDI dans JACK est aussi bon que la latence de JACK, et les flux sont intérrompus de la même façon que les flux audio quand il y a des "xruns".
• JACK MIDI ne gère actuellement pas d'évênements SYSEX permettant une communication de données avancées aux instruments réels (synthés et boites MIDI externes), comme par exemple l'échange et la sauvegarde de patches.

Dans l'ensemble les deux implémentations sont très performantes, avec une plus grande facilité pour les développeurs avec ALSA quand il s'agit de séquenceurs (grâce à la présence d'une queue de stockage) et une plus grande facilité quand il s'agit de synthés et processeurs de données MIDI.

Pour l'instant, on a les deux à gérer sous linux, selon les choix des développeurs. Heureusement il existe un pont entre les deux systèmes ALSA MIDI et JACK MIDI. a2jmidid permet d'accéder aux clients à partir des deux cotés et de faire fonctionner les logicils ALSA MIDI et JACK MIDI entre elles.


Il faut aussi dire que dans :

• qJackCtl, il y a 2 onglets midi :
  • l'onglet "MIDI" qui correspond au midi de JACK
  • l'onglet "ALSA" qui correspond au midi d'ALSA
• Patchage, il y a 2 couleurs :
  • vert pour le midi d'ALSA
  • rouge pour le midi de JACK
• LADISH, on ne voit pas le MIDI d'ALSA