Des photos de vos home-studios et les discussions qui vont avec

Citation de Tikky :

La distance dans ce cas doit être réduite pour assurer la qualité de la transmission, pas son délai. A 300 000 km/s une différence 10 mètre même en comptant un aller-retour du signal c'est de l'ordre de 0,00007 ms d'écart, autant dire 0.

C'est un peu plus compliqué que ça, il y a quelques éléments intermédiaires entre le protocole BLE-MIDI et l'onde électromagnétique.

D'une part, la baseband Bluetooth utilise un protocole où chacun parle à tour de rôle, pendant la tranche de temps de 625usec qui lui est allouée. Si ce n'est pas ton tour de parler, tu attends. C'est pour ça que tu ne pourras jamais garantir un jitter de moins de 1.4ms sur Bluetooth. Ensuite, il y a des CRC pour vérifier l'intégrité des messages. Ça veut dire que tu ne peux pas commencer à délivrer le premier bit d'un message à l'utilisateur tant que tu n'as pas reçu son dernier bit et vérifié son CRC. Là encore, il faut attendre. Ensuite, il y a le cas où une erreur est détectée et où il faut re-transmettre. Badaboum, on se prend quelques dizaines de millisecondes dans la vue. Et enfin, le truc le plus pervers : le choix de la couche physique, en fonction de l'environnement. Grosso modo, tu as plusieurs façon d'encoder les données (LE1M, LE2M, LE coded), avec plus ou moins de redondance, pour tolérer plus ou moins de parasites. Et plus ton protocole va loin en portée, plus tu as de redondance, moins tu fais passer de bits dans une fenêtre de temps donnée, avec un facteur 16 entre le plus lent et le plus rapide.

D'où le raccourci : quand tu es près, pas beaucoup de latence (LE2M, temps d'une trame, et temps d'au plus deux slots) ; quand tu es loin, la latence s'allonge (LE coded, temps d'une trame, éventuel temps de retransmission, et temps de deux slots). Bref, dès qu'il y a de la friture sur la ligne, ça rame.

Citation :

D'une part, la baseband Bluetooth utilise un protocole où chacun parle à tour de rôle, pendant la tranche de temps de 625usec qui lui est allouée. Si ce n'est pas ton tour de parler, tu attends. C'est pour ça que tu ne pourras jamais garantir un jitter de moins de 1.4ms sur Bluetooth. Ensuite, il y a des CRC pour vérifier l'intégrité des messages. Ça veut dire que tu ne peux pas commencer à délivrer le premier bit d'un message à l'utilisateur tant que tu n'as pas reçu son dernier bit et vérifié son CRC. Là encore, il faut attendre. Ensuite, il y a le cas où une erreur est détectée et où il faut re-transmettre. Badaboum, on se prend quelques dizaines de millisecondes dans la vue. Et enfin, le truc le plus pervers : le choix de la couche physique, en fonction de l'environnement. Grosso modo, tu as plusieurs façon d'encoder les données (LE1M, LE2M, LE coded), avec plus ou moins de redondance, pour tolérer plus ou moins de parasites. Et plus ton protocole va loin en portée, plus tu as de redondance, moins tu fais passer de bits dans une fenêtre de temps donnée, avec un facteur 16 entre le plus lent et le plus rapide.

D'où le raccourci : quand tu es près, pas beaucoup de latence (LE2M, temps d'une trame, et temps d'au plus deux slots) ; quand tu es loin, la latence s'allonge (LE coded, temps d'une trame, éventuel temps de retransmission, et temps de deux slots). Bref, dès qu'il y a de la friture sur la ligne, ça rame.

Ensuite il reste a multiplier tout ça par la complexité du message envoyé... comme je disait plus haut pour jouer quelques notes et accords ça le fait, si tu joue quelues notes accord avec en plus du cc ça commence a broncher, si tu joue quelques notes et accord avec plus de deux ou trois cc là ça devient carrement lent voir bouchonné !
Faite le test avec deux ou trois pad xy qui envois donc chacuns au moins 2 cc, on ressent tres bien le "ralentissement" !