réactions à la news Conductive Labs annonce le MRCC, un beau bébé dédié au MIDI

Citation de BulletZ :

Citation :

La latence et le jitter intrinsequement n'ont effectivement pas avoir avec le debit (et encore ce que j'ecris est faux car en microelectronique il peut y avoir une relation car la latence a un impact direct sur les marges d'implementation donc la performance),

Je dirais plutôt qu’un débit faible impose une latence minimum entre 2 messages, dans le cas du MIDI à 32kbps on doit tourner autour de la milliseconde il me semble. Le jitter en revanche c’est une toute autre histoire et c’est plutôt plus important.

"un débit faible impose une latence minimum entre 2 messages" -> Non. le temps entre 2 messages n'engendre pas de contrainte de latence
Tu peux avoir une latence longue et garder un meme debit (sauf en sub micronique ou la latence peut avoir des impacts sur la performance, mais la on sort allègrement du sujet) = c'est juste le temps que met un signal a se propager.
La latence c'est surtout que tu n'ai pas trop de temps entre les donnees qui rentrent et celle qui sortent apres traitement.
Sinon tu sentiras un decalage entre le moment ou tu tapes les notes et le moment ou elles sortent. La lantence vient du temps de traitement des donnees (je passe sur la propagation du signal ultra faible habituellement).
Et 1ms ou 2ms ou 3ms tu ne percevras rien (compare a une carte son). Les synthe engendre plus d'ailleur que 1 ou 2 ou 3ms.
Le jitter ne sera pas plus un probleme. Le long term sera imperceptible humainement, le court term sera trop faible aussi.
Bon j'arrete la on est amplement HS.

Citation de BulletZ :

Citation :

cependant quand un debit est faible comme dans le midi, et que le hardware avec une puissance de calcul correct, la latence et le jitter engendre par le hardware seront certainement faible par rapport au debit du bus.

Je regrette mais autant pour la latence ça peut se défendre, autant pour le jitter si le firmware (dont la présence est la plupart du temps inévitable) n’est pas très bien conçu la situation peut vite devenir très crade.

Pour simplifier, le jitter existe surtout dans le hardware, le firmware n'est rien d'autre que du code pour commander le hardware. Ce qui genere une clock par exemple a du long term et short term jitter, ou des chemins logiques peut ajouter du jitter, de l'agitation thermique etc...

Quand tu implementes a des 100aines de MHZ (ou GHz) oui le jitter est critique (le jitter en realite peut avoir un impact sur la performance a frequence elevee, car ca fait parti des marges que tu dois garder lors de l'implementation, mais la on parle de frequence n'ayant rien a voir ici).
Dans notre cas, sur du matos dedie midi, je suis tres peu inquiet par le jitter (il faudrait vraiment faire de grosses conneries pour en avoir suffisemment et qu'il soit perceptible).
J'ai regarder le CV des mecs derrieres conductive labs, et ils ont passe une partie de leur carriere dans une boite concurrente de la mienne. Et crois moi ils sont loins d'etre novices.

Citation de BulletZ :

Citation :

Quand aux connecteurs, tu en penses ce que tu veux (tu en sais certainement plus que moi et les gars de conductive labs), mais le fait est que le MRCC comme par hasard est rackable avec des connecteurs verticaux, et pas le midihub avec des connecteurs horizontaux sur 2 cotes.

J’ai une vieille interface usb-midi (ESI M8U XL), rackable, avec des connecteurs horizontaux sur face avant et arrière. Comme je l’ai dit, tout est une question de choix de conception.
Et oui le tarif des connecteurs MIDI j’ai un peu l’habitude il se trouve que je produis des appareils de ma conception qui en ont
Mon point est facilement vérifiable chez Farnell ou Mouser.

Oui tu as raison sur les choix de conception, on peut toujours tout faire.
Mais je voulais surtout dire que le MRCC a fait le choix d'etre rackable par le midihub, et que les choix de connecteurs en decoule.
Quand au tarifs des connecteurs verticaux les conductive labs l'ont clairement etablis. Et comme j'ai constate la meme chose de mon cote, je suis d'accord avec eux. Mais bon, il est possible que chacun ait des sourcing differements. LA qu'importe c'est ce qu'on paye a la fin qui compte.

Citation de BulletZ :

Citation :

Par ailleur je maintiens que l'utilisation de ces 2 devices n'ont rien a voir entre eux dans le cadre de la musique. Et qu'il est normal que le MRCC coute plus cher ...

C’est ton opinion.

[/quote]
C'est juste une evidence

bon moi j'arette la. J'ai l'impression d'etre au boulot

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).

Citation :

Tu peux avoir une latence longue et garder un meme debit (sauf en sub micronique ou la latence peut avoir des impacts sur la performance, mais la on sort allègrement du sujet) = c'est juste le temps que met un signal a se propager.
La latence c'est surtout que tu n'ai pas trop de temps entre les donnees qui rentrent et celle qui sortent apres traitement.
Sinon tu sentiras un decalage entre le moment ou tu tapes les notes et le moment ou elles sortent. La lantence vient du temps de traitement des donnees (je passe sur la propagation du signal ultra faible habituellement).

Nous sommes d'accords

Citation :

Et 1ms ou 2ms ou 3ms tu ne percevras rien (compare a une carte son). Les synthe engendre plus d'ailleur que 1 ou 2 ou 3ms.
Le jitter ne sera pas plus un probleme. Le long term sera imperceptible humainement, le court term sera trop faible aussi.
Bon j'arrete la on est amplement HS.

La latence et surtout le jitter sont perceptibles (et gênants) dès quelques millisecondes (c'est bien documenté dans la littérature, bien référencée dans le 2è paragraphe de la "General Discussion" de cet article). Et la question porte sur l'interaction que ça crée entre différents instruments et différents sons, la comparaison avec une carte son n'a pas de rapport.

Citation :

Pour simplifier, le jitter existe surtout dans le hardware, le firmware n'est rien d'autre que du code pour commander le hardware. Ce qui genere une clock par exemple a du long term et short term jitter, ou des chemins logiques peut ajouter du jitter, de l'agitation thermique etc...

Alors encore une fois je pense que tu te focalises trop sur ton rayon de crèmerie (que je comprends être le design d'ASIC ou équivalent), pour ma part dans mes compétences sur lesquelles je m'étendrai pas il y a aussi la conception de firmware embarqué et je peux te dire que tu sous-estimes largement l'influence du firmware. S'il est codé avec les pieds il peut insérer un jitter considérable (exemples dans le cas qui nous concerne: temps de traitement différents entre MIDI messages différents, mauvaise gestion du buffering, etc).

Citation :

Quand tu implementes a des 100aines de MHZ (ou GHz) oui le jitter est critique (le jitter en realite peut avoir un impact sur la performance a frequence elevee, car ca fait parti des marges que tu dois garder lors de l'implementation, mais la on parle de frequence n'ayant rien a voir ici).
Dans notre cas, sur du matos dedie midi, je suis tres peu inquiet par le jitter (il faudrait vraiment faire de grosses conneries pour en avoir suffisemment et qu'il soit perceptible).

As-tu seulement lu les 2 articles que j'ai postés au début?

Citation :

J'ai regarder le CV des mecs derrieres conductive labs, et ils ont passe une partie de leur carriere dans une boite concurrente de la mienne. Et crois moi ils sont loins d'etre novices.

Des anciens d'Intel si j'ai bien lu. Tu bosses chez Freescale?

Citation de yomanfree :

Citation de BulletZ :

C’est ton opinion.

C'est juste une evidence

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

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