Sujet Commentaires sur la news : Conductive Labs annonce le MRCC, un beau bébé dédié au MIDI

Citation de BulletZ :

tu sous-estimes largement l'influence du firmware. S'il est codé avec les pieds il peut insérer un jitter considérable

J'ai l'impression que c'est surtout une question de confiance ici...(et de présupposés)
yomanfree a confiance aux gars de Conductive Labs de part leurs références et leur précédent produit (NDLR), et toi tu sembles douter car si tout n'est pas annoncé dans les specs c'est forcément qu'il y a une zone d'ombre..
A mon avis quand il y a un doute comme ça il ne vaut mieux pas souscrire au kickstarter et attendre sagement les premiers retours... Le principe de kickstarter c'est précisément d'accorder sa confiance à une marque/un produit, donc si ça commence par un tel problème de confiance.....

Citation de yomanfree :

C'est juste une evidence

Citation de BulletZ :

Tout le monde n'est pas obligé d'être d'accord avec tes évidences .

Vous parlez du MRCC et du Blokas??
Bah oui, ça me parait évident à moi aussi que ce sont 2 utilisations très différentes étant donné que l'un est full standalone et l'autre non
(à la limite le blokas serait plutôt à mettre en concurrence avec les produits d'iConnectivity...)

Citation de BulletZ :

x

Hors sujet :

Citation de yomanfree :

"un débit faible impose une latence minimum entre 2 messages" -> Non. le temps entre 2 messages n'engendre pas de contrainte de latence

Un peu si. Mais à lire ce qui suit je pense qu'on ne parle pas de la même. Je ne parle pas de la latence "dure", au niveau électronique. Je parle de la latence sur les communications MIDI.
Quant au lien entre bande passante et latence, il est assez simple à comprendre: si j'ai une BP de 10 bits par seconde et qu'il me faut 100 bits pour passer un message complet entre 2 devices, ma latence minimale unidirectionelle est de 10 secondes, pour simplifier: il faut 10 secondes pour que le message soit entièrement transmis (et donc qu'il puisse être entièrement reçu).

Non, ca n'est pas la definition de la latence qui est unique (meme donnee dans tes propres liens).
Ca n'est pas l'intervalle de temps que les 100bits necessitent pour etre transmis (ca c'est lie au debit), c'est le temps que mettront ces donnees pour aller d'un point A a un point B.
En resume, si tu as 100bits a transmettre, il faudra certes 10s pour transmettre le paquet.
Sans latence, les donnees arriveront entre 0s et 10s. Avec une latence de 30s, elles arriveront entre 30s et 40s.
Si ton paquet de donnees fait 1000s, sans latence elles arriveront entre 0 et 1000s, avec une latence de 30s, ca arrivera entre 30s et 1030s.

1 de tes liens d'ailleurs le dit tres bien, tu peux t'y referer : "Latency is a short constant delay that is introduced between the occurrence of an event and the actual perception of the audio."

C'est comme en audio: si tu as une latence de 50ms, tu entends tout ton audio integralement mais decale de 50ms.

Pour le firmware, il donne des ordres au hardware (la latence vient techniquement du HW). Il n'y a une influence du firmware que dans le cas ou tu fais faire aux hardware des operations qui ne servent a rien (les operations hardware inutile ou mal optimisee augmente la latence). Mais si ton hardware est suffisamment puissant, la latence restera contenu (temps de traitement rapide).

Mais cette fois j'arette la. La latence/skew/jitter c'est un focus permanent dans mon boulot pour construire des arbres d'horloge, et je ne suis pas au boulot. Et cette discussion va faire chier tout le monde a juste titre : je m'en excuse on n'aurait pas du deborder

Citation de yomanfree :

Citation de BulletZ :

Citation de yomanfree :

"un débit faible impose une latence minimum entre 2 messages" -> Non. le temps entre 2 messages n'engendre pas de contrainte de latence

Un peu si. Mais à lire ce qui suit je pense qu'on ne parle pas de la même. Je ne parle pas de la latence "dure", au niveau électronique. Je parle de la latence sur les communications MIDI.
Quant au lien entre bande passante et latence, il est assez simple à comprendre: si j'ai une BP de 10 bits par seconde et qu'il me faut 100 bits pour passer un message complet entre 2 devices, ma latence minimale unidirectionelle est de 10 secondes, pour simplifier: il faut 10 secondes pour que le message soit entièrement transmis (et donc qu'il puisse être entièrement reçu).

Non, ca n'est pas la definition de la latence qui est unique (meme donnee dans tes propres liens).

La définition de la latence est unique, ses sources sont multiples.

Citation :

Ca n'est pas l'intervalle de temps que les 100bits necessitent pour etre transmis (ca c'est lie au debit), c'est le temps que mettront ces donnees pour aller d'un point A a un point B.
En resume, si tu as 100bits a transmettre, il faudra certes 10s pour transmettre le paquet.

Ce qui représente une latence de 10 secondes. S'il faut 10s pour que l'expandeur réagisse à la pression d'une touche sur un contrôleur MIDI, il y a 10 secondes de latence.

Citation :

Sans latence, les donnees arriveront entre 0s et 10s. Avec une latence de 30s, elles arriveront entre 30s et 40s.
Si ton paquet de donnees fait 1000s, sans latence elles arriveront entre 0 et 1000s, avec une latence de 30s, ca arrivera entre 30s et 1030s.

Je vais la faire courte pour pas saouler tout le monde mais c'est une peu triste de lire ça, il faut vraiment que tu lèves le nez de ton assiette électronique. La latence ne concerne pas uniquement le temps de changement d'état d'une porte logique par exemple, i.e. la latence de propagation électronique sur laquelle tu sembles totalement bloqué (et oui, tu vois, je sais exactement de quoi tu parles).

Les ingés sons seront donc ravis d'apprendre que dans un stade il n'y a aucune latence liée à la vitesse limitée (la "bande-passante") de déplacement du son dans le support que constitue l'air.

Citation :

1 de tes liens d'ailleurs le dit tres bien, tu peux t'y referer : "Latency is a short constant delay that is introduced between the occurrence of an event and the actual perception of the audio."

C'est comme en audio: si tu as une latence de 50ms, tu entends tout ton audio integralement mais decale de 50ms.

Précisément. S'il faut 50ms pour que le message circule entre un point A et un point B parce que la BP ne permet pas d'aller plus vite, il y a 50ms de latence, quelle que soit la source/cause de cette latence. Si tu es assez vieux pour te souvenir d'internet à l'heure des modems 56k tu dois savoir exactement ce que je veux dire

Citation :

Pour le firmware, il donne des ordres au hardware (la latence vient techniquement du HW).

Non. Tu raisonnes en latence électrique/électronique pure, il y a d'autres sources de latence. C'est pour ça qu'on se casse le cul à développer des OS "low latency" voir "temps réel dur" pour pouvoir notamment garantir les temps de latence introduits par le software.

Citation :

Il n'y a une influence du firmware que dans le cas ou tu fais faire aux hardware des operations qui ne servent a rien (les operations hardware inutile ou mal optimisee augmente la latence). Mais si ton hardware est suffisamment puissant, la latence restera contenu (temps de traitement rapide).

C'est faux, et je sais de quoi je parle, mais je n'insiste pas.

En tout cas mon principal sujet par rapport au MRCC c'est précisément de savoir s'ils ont un firmware qui assure ou pas (ou s'ils tournent sur un linux embarqué de base avec une surcouche en java, par exemple, histoire de rire un peu), et je n'ai pas eu de réponse. Je vais donc suivre le conseil de JeffX et attendre les premiers retours.

Citation :

Mais cette fois j'arette la. La latence/skew/jitter c'est un focus permanent dans mon boulot pour construire des arbres d'horloge, et je ne suis pas au boulot. Et cette discussion va faire chier tout le monde a juste titre : je m'en excuse on n'aurait pas du deborder

Comme je le pensais tu es complètement focus sur ton VHDL et tu n'entends pas (sic!) qu'il existe d'autres sources/causes à la latence subie par un signal. Désolé effectivement pour ceux que cette conversation n'intéresse pas mais il me semble important d'apporter ces quelques précisions pour éviter que les rares lecteurs que ça intéresse retiennent des erreurs manifestes.

Bisous