Historique: JACK-MIDI
Aperçu de cette version: 11
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é 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 désavantages (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 très directe du timing des flux de MIDI aux flux audio passant par JACK, donc la possibilité d'associer des événements MIDI et ondes audio générés par des synthés avec une grande précision. C'est la fameuse histoire du "sample accurate timing", qui est pourtant soumise à beaucoup de conditionnels dans le monde réel, d'où parfois quelques désaccords entre les développeurs.
- JACK MIDI est pour l'instant la seule possibilité de gérer le MIDI des cartes son firewire à travers ffado.
Parmi les désavantages on peut citer:
- Pour les développeurs: 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 bloc 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.
- Quand on envoie du MIDI à l'extérieur par USB, le timing du MIDI dans JACK est aussi bon que la latence de JACK, et les flux sont interrompus 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 patchs.
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é avec JACK 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 logiciels 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 sauf quand on lance a2j en tant qu'application
[+]
