Sur la latence (des consoles numériques et autres...)

[Barbe Grise]

Super les gussss!!!
J'avais fait des mesures en E/S ADAT sur 01V, pas foutu de les retrouver...

Je recommence dès que j'ai 5mn.

Et puis il faudrait que je fasse la latence de la F32... Maiiiis non gros balots, pas sur la table elle même mais sur l'interface Firewire intégrée. A vue de nez un aller/retour sur PC, ça doit être assez la cata...

[Barthedoc]

Super test audio
que Ziggy a réalisé.
et 0.1 ms donne un beau peigne autour des 4-6 khz
J'ai réalisé le même avec la GLD
et c'est pareil.....
Autre test sur les direct-out
Entre la sortie après préampli et la sortie après EQ, gate compress la mesure donne 0.19 ms d'écart donc
le process dynamique prends 0.19 ms chez la GLD.

Sur ce que nous a donné Ziggy comme échantillons sonores
Nous pouvons nous questionner
à propos du recalage temporel physique.
Doit-on recaler lorsque l'on capte par exemple un instru avec un
capteur ou micro de proximité et un autre micro sur pied à 40 cm ?
En analogique je ne l'ai jamais fait pour sûr car pas de delay...et comme le dosage n'était pas égal, si filtre en peigne il y a, celui-ci rentre dans la couleur du mixage.
Sur une console numérique, comme il est facile de corriger, c'est à mon avis au choix du sondier.
En ce qui concerne le routage interne, c'est une autre affaire.
Sur les consoles modernes les affectations des entrées peuvent être multiples et donc la sommation des sources décalées va forcément entrainer
des artefacts...
Les diagrammes de L'AES (merci MO) ont permis de visualiser des situations
que nous connaissons et pour lesquelles nous avons nos tolérances sans jamais avoir vraiment pu les quantifier.
(Ces anglosaxons c'est du lourd, leurs docs c'est des mines d'or...)

[ziggy]

hello Bart
concernant la question de "devoir" (ou vouloir) recaler/delayer certaines sources, je pense qu'il faut déjà bien faire la différence de ce qui est naturel et voulu et ce qui ne l'est pas...
je connais des mecs qui essayent de recaler tous les micros de la batterie sur les OH ce qui est une entreprise assez fastidieuse au résultat pas forcément heureux !!
(perso je ne le fais jamais; mais j'ai déjà fait quelques essais juste pour m'amuser et écouter l'éventuel résultat sonore)

mais je pense qu'il faut surtout réfléchir à ceci :
dans la vie réelle de la prise d'ambiance et de la repisse de signaux captés par plusieurs micros : le positionnement et l'atténuation jouent un rôle décisif (pour le remix finale et la cohérence du résultat !) !
exemple la batterie; les micros de proximité prennent les sources avec leur impact et transitoires; les autres micros (OH et même le micro du chanteur) prennent l'ambiance (donc la source avec la reverbe naturelle et sans les transitoires (ou fortement atténuées) et peu d'impact et autres atténuations/colorations dues au cheminement acoustique du son etc)
entre un micro qui est à 5cm de la source et un deuxième qui se trouve à 1,50M ou 2M ou plus, la différence de gain est énorme et l'effet de filtrage en peigne est très atténué ! (malgré le delay naturel des 4 à 6msec induit par la distance)

quand on parle de nos questions sur la latence la base de réflexion est tout autre !!
le décalage par le delay n'est pas une chose voulue et surtout que les deux sources seront maintenant identiques au niveau gain et transitoires, mais juste délayé virtuellement (et le filtrage en peigne sévit sévèrement et de plein fouet !!

quelques exemple concrets :

un chanteur devant un wedge entendra sa propre voix crânienne à l'intérieure de sa tête et sa voix venant du wedge (donc extérieur), colorée et délayé (selon la distance du wedge) le cerveau en fera un "mix" cohérent entre sons intérieures et extérieures !
avec une console analogique et in-ear, les deux sources se trouvent maintenant à l'intérieur de la tête mais il n'y a plus de "distance" entre elles => les deux sources se mixent en une seule source cohérente !
avec une console numérique c'est différent et encore plus quand la latence augmente par exemple quand on insère un ordi et des plug-ins externe etc... le mix finale dans la tête devient très vite très "coloriant" avec des trucs artificiels et un doublage bizarre ! (il y a une distance virtuelle sans aucun autre "effet de distance" apart le delay)

autre exemple : envoyer le chant par une tranche et parallèlement par une autre tranche ou un bus pour avoir une réserve de gain dans les passages chargés
sans souci sur une analogique (on gagne 6dB); presque impossible sur une numérique qui va de suite générer des filtrages en peigne importants et très coloriant
ou : faire une compression parallèle sur la batterie ou sur les voix ! aucun souci sur une analogique mais sur une console numérique sans compensation de latence cela colore de suite désagréablement la source (filtrage en peigne etc)
ou d'avoir deux circuits de wedges qui se trouvent proches physiquement sur la scène mais ayant des temps de latence différente; cela va créer un mixage bizarre entre les deux pour les sources qui seront communes dans les deux wedges....!!

une petite image : imaginez deux HP qui émettent le même signal et au même gain; les HP sont assez directif et espacé de disons 10 mètres
vous vous trouvez devant l'un deux celui de gauche ; son son arrive sur l'oreille gauche et en contournant la tête aussi sur l'oreille droite (après quelques 20cm)
le cerveau en conclu que la source se trouve à votre gauche et l'oreille droite entendra éventuellement en plus un signal très faible, sourd et délayé venant de droite ! (qui va s'intégrer dans l'espace naturel et environnant)
la même chose se produit en sens inverse quand vous vous trouvez presque devant le HP de droite....
mais imaginez maintenant que vous vous trouvez toujours devant le HP à gauche mais vous entendez celui de droite comme si vous étiez devant (donc orienté vers vous et avec un gain de +20dB par rapport à l'autre) mais en plus avec un delay de 30msec... ce n'est ni du mono ni du stéréo ni un truc naturel et le cerveau ne comprendra pas ce phénomène incohérent... sans parler du terrible filtrage en peigne qui va se créer acoustiquement !
et ceci va devenir encore plus bizarre lors d'une mono-sommation (un mix mono de console ou une écoute avec une seule oreille...!!)

il faut donc focaliser son attention sur les deux points importants :
1,) le décalage temporelle (et artificiel car non accompagné par les phénomènes naturels comme l'atténuation du gain et absence ou atténuation de transitoires et de réverbération naturelle etc) qui posera des soucis dont l'impact sera dépendant de la source (rythmique, percu, chant etc etc) et du dégrée de précision de jeu (classique, jazz pro amateur rock etc)
dans l'extrême c'est équivalent à la différence entre des musiciens pro qui jouent ensemble et "sur le point" et d'autres qui restent dans le vague et le floue.... (mettez des traitements divers sur la caisse claire ou le kick et sans compensation de latence et le meilleur batteur du monde aura l'air d'un apprenti débutant! et quelques msec suffisent pour créer le désastre!!)
et puis :
2,) la colorisation par filtrage en peigne qui surgit dès qu'une même source est présente sur plusieurs voies de mix dont certaines sont délayé en gardant tous les attributs (le gain, les transitoires, absence de réverbération naturelle etc etc...)

[Barthedoc]

Ziggy


Absolument

Et une attention particulière lorsque nous captons avec deux micros comme le souligne Ziggy ( 5cm et 1.5m par exemple), nous réalignons souvent les gains avec les préamplis à la console, et ensuite nous mélangeons les signaux, et nous apportons alors notre touche sonore... en bien ou en pire... et le tout risque de retourner au ziccos dans les wedge ou in-ear....

Il y a une remarque sur le tempo, dans le fichier AES, au delà de 11ms, les ziccos vont commencer à se dérégler.
Alors sur scène le positionnement des ziccos et des "wedges" doit être cohérent.
Tu as rappelé que toute source splittée empruntant des voies avec des latences différentes va à la sommation provoquer des artefacts.
Pour corriger cela, on peut donner un délai supplémentaire aux voies directes pour les recaler, ce qui a pour corolaire de délayer la voie complète.
Peut-être sans importance, sur un retour "wedge".
Sur une scène live, avec un bon placement des micros, nous pouvons donner de la profondeur à la scène audio, ce qui donc voulu, par contre le décalage temporel des routages, c'est une altération indésirable.....lorsqu'elle n'entre pas dans la construction sonore....

J'ai refais les test de latence entre les in/out de la surface et les in/out de l'audiorack, et le résultat donne 0.08ms en plus pour l’unité déportée.
En ce qui concerne les pas de valeurs de délai sur le logiciel c'est des pas de 0.31ms et sur la console c'est des pas de 0.02, alors pas de problème pour recaler précis.

[ziggy]

Pour corriger cela, on peut donner un délai supplémentaire aux voies directes pour les recaler, ce qui a pour corolaire de délayer la voie complète..

en fait c'est exactement ce qui se passe quand on a la compensation automatique de latence ! un delay supplémentaire est appliqué à certaines voies (pour réaligner tout le monde et "effacer" les différences de latences individuelles) et la latence globale augmente en conséquence (c'est le cas pour pratiquement tous les DAW professionnels et aussi certaines consoles comme les Midas et les Avid et Innovason etc)
exemple : activer une boucle insert sur une seule tranche réalignera également la latence de toutes les autres tranches sans insert activé à la même valeur etc...

[joke_r]

salut tout le monde.
Je viens de faire les mesures avec un S16 et une X32 Rack (pas le courage de remonter la X32 Standart dans le salon lol )

In Rack --> out Rack = 0,90 ms (et 1,62 ms avec un GEQ)
In Rack --> out S16 = 1 ms (et 1,73ms avec un GEQ)
IN S16 --> out S16 = 1,12 ms ( et 1,85 avec un GEQ)

Sur la X32 Producer, j'ai mesuré en 48khz selon 3 cas de figure:

1/ Analog IN -> Main Out => 0,83 ms
2/ Analog IN -> BUS -> Main Out => 0,83 ms
3/ Analog IN -> BUS -> Out avec True GEQ en insert => 1,50 ms

Tous les eq , gate et dyn activés ou pas sur le chemin audio ne changent rien à la latence

Nb : du coup je me suis amusé a tester les autres effets en inserts comme en cas 3, et voila ce que j'ai constaté
Precision limiter Ajoute 1,08 ms (2,58 ms au total)
Wave designer + 0,75 ms ( 2,25ms au total)
stereo exiter. + 0,23 ms
Dual guitare amp. + 0,15 ms
Sound maxer. + 0,02 ms
Tous les autres effets inserts font plafonner la latence totale à 1,50 msec .

Le mood filter lui oscillait entre environ 2,40 et 2,77 au total

J'ai éte surpris de l'absence de délai supplémentaire en transitant par un bus, vu que d'autres on l'air d'en ajouter
Je l'ai même muté pour être sûre que je m'étais pas fait une blague... Les DSP doivent traiter piste et bus en parallèle ...

Par contre en direct out on reste a 0,83ms : j'ai assigné la sortie Out6 en direct out depuis la piste concerné, branché la ligne de mesure smaart dessus, et oui, les Eq et autres n'on plus d'effet, mais la latence reste identique.

[luciolis]

Le délai n'est pas à cause d'un "calcul" du processing, mais bien parce que certains filtres ont besoin de données dans le "futur".

Par exemple la fonction de transfert d'un filtre récursif simple est Y/X = H = (b + c*z^-1)/(1-a*z^-1)

cela revient à

Y*(1-a*z^-1) = X*(b+c*z^-1)

dans le domaine temporel ceci revient à
y[k] - a*y[k-1] = b*x[k] + c*x[k-1]
donc
y[k] = b*x[k] + c*x[k-1] + a*y[k-1]

y étant le sample de sortie et x le sample d'entrée.
pour sortir le sample k, il faut savoir le sample suivant (x[k-1]).
Il y a donc un délai sur la sortie y afin d'avoir le sample suivant.

Bien sûr il y a des filtres plus complexes avec plus de zéros et de pôles, et pour chaque tranche d'EQ le délai s'additionne (d'où le délai sur le GEQ avec 31 bandes).

également, il faut savoir que lorsqu'on applique un filtre, on a modifier le temps de propagation de groupe et au niveau fréquentiel certaines fréquences vont "sortir" à un temps différent (d'ou la modification de la phase après conversion)


Au niveau des bus, il n'y a pas de délai vu que c'est une simple addition non récursive.
a[0] = d[1] prend le même temps (l'addition est faite pour le sample 0 et est retournée au sample suivant) que
a[0] + b[0] + c[0] = d[1]

[Fish]

Le délai n'est pas à cause d'un "calcul" du processing, mais bien parce que certains filtres ont besoin de données dans le "futur".

Ben, elle est un peu curieuse ta remarque... le fait d'avoir besoin de données dans le futur pour effectuer les calculs d'un filtre, ça ressemble bien à un "calcul du processing", non ? C'est juste deux manières de dire la même chose!

Il me semble que "les données dans le futur" c'est valable uniquement pour les filtres FIR, dont l'avantage est de ne pas introduire de variation de phase avec la fréquence. En IIR, il n'y a pas de délais important, par contre le déphasage dépend de la fréquence. Les filtres FIR sont déjà assez rares sur les processeurs de diffusion, ils doivent l'être encore plus dans les consoles.

D'autres calculs que les filtres peuvent avoir besoin de données dans le futur (limiteur look-ahead par exemple).

Mais dans tous les cas, le calcul impose bien une petite latence, même s'il n'est pas le seul contributeur.

[luciolis]

dans un DSP, le temps de calcul est inférieur à la durée d'un sample, le résultat est directement released sans délai. Je fais la distinction entre un processing "lourd" qui a besoin de plus d'un cycle CPU pour être effectué (genre une résolution d'équations différentielles) et la latence induite "volontairement" par l'algorithme de filtrage.

Les filtres IIR à phase minimale ont également besoin de données dans le futur, cf ma démonstration ci-dessus. Les filtres à phase linéaire ne sont pas forcément FIR, mais plus souvent IIR, et ont en effet besoin d'un délai beaucoup plus grand (plus grand support de la fonction de transfert).
Avec un filtre FIR on a théoriquement moins besoin de décaler, car l'impulsion à convoluer est elle même finie (finite impulse réponse). Théoriquement, la convolution avec une réponse impulsionnelle IIR n'est pas possible (somme sur support infini), mais souvent on "coupe" la réponse à partir de quelques coefficients.

En passant, j'ai jamais vu de limiteur lookahead dans une console numérique

[Barthedoc]

Réflexions sur le temps synchro
issus de mes réflexions et non basé sur des tests
(Il me faudrait un oscillo 40MHz au pire).

Pour moi, les latences machines et processeurs ne sont pas sur les mêmes valeurs:
le sample tourne sur 21 µS en arrondi (10 samples ne font que 210 µS)
alors qu'en ce qui concerne le cycle lecture/ écriture d'un DSP (admettons qu'il tourne au pire la fréquence d'un quartz soit 24 ou 25 Mhz) il est de 0.04µS.
IL faut 525 cycles à 25 Mhz pour avoir la valeur d'un sample.
Et nous sommes encore loin des 1.6 ms de latence machine qui représentent environ 760 samples à 48 Khz.

Les DSP, les CAN et CNA sont quasi identiques sur les petites consoles standard, c'est pour cela que les latences se tiennent dans un mouchoir.
Après il y a des différences sur les logiciels, les algorithmes, les possibilités,
le nombre des processeurs DSP.
Ce que nous remarquons, c'est que sur la X32 les sorties sont hors GEQ et ont par conséquence une petite latence mais avec le GEQ inséré la latence revient aux mêmes valeurs que celle des consoles qui possèdent un GEQ affecté sur toutes les sorties.
Perso cette latence n'est pas rédhibitoire bien au contraire car elle recule la façade d'une soixantaine de cm vers le groupe.



HS
Le détail sur les algorithmes est super intéressant mais absconse sans avoir d'exemples concrets.

PS Un sujet sur la numérisation est en cuisine, il va faire l'objet d'un autre post et vos lumières vont être plus que nécessaire)
/HS


Le régisseur fait des maths, il ne réussit pas toujours mais il n'est pas rancunier.

[joke_r]

Hello Bart,
En fait un DSP actuel tourne à plus de 200 Mhz , par exemple ceux de la x32 sont des Analog Device Shark 21371 *
Dixit le site (266 MHz SIMD SHARC Core, capable of 1596 MFLOPS peak performance)
Sans compter qu'ils sont capable de traiter une instruction qui prend normallement 3 cycles sur un processeur standard, en un cycle seulement.

Apres comme tu le dis, c'est sur que l'efficacité, latence variera selon comment l'algorithme est programmé et sur combien de dsp il va s'appuyer , leur puissance .

A mon humble niveau (mathematique), c'est intéressant de voir comment la latence joue selon le plug utilisé (le mood filter est "marrant" pour pas dire exotique dans la sono live )

au niveau des bus, il n'y a pas de délai vu que c'est une simple addition non récursive.
a[0] = d[1] prend le même temps (l'addition est faite pour le sample 0 et est retournée au sample suivant) que
a[0] + b[0] + c[0] = d[1]

Pourtant sur certaines tables, un transit via un bus, qui inclu dyn gate et eq, engendre parfois une latence , parfois pas ... Le traitement d'un bus dans certaine console serait alors peut être traité comme un insert .
Ou peut etre que la x32, par exemple, dispose d'un paramètre de compensation de latence pour piste et bus, activé et non modifiable , mais qui ne tient pas compte des insert effet...

* source : sound forum

[ziggy]

hello
concernant ce débat très intéressant je viens de faire quelques mesures et vérifications sur ma Pro-1 qui , je l'espère, ajouteront quelques infos en plus....
au lieu de mesurer une latence absolue j'ai mesuré quelques latences relatives (donc en faite différences de latence sur ma Midas Pro-1 et j'ai trouvé quelques résultats intéressants

pour commencer j'ai désactivé toute compensation de latence pour avoir les valeurs brut (sans correction interne de l'OS de la console)

et puis pour rappel ce que j'ai déjà dit plus haut : le simple cheminement IN vers Main-OUT (ou Bus-Out) prend 1,6msec (tant qu'il n'y a pas de GEQ activé !)

en premier lieu je voulais vérifier si ce que Midas prétend, est vrai: ils disent d'avoir développé des effets spécialement pour la série Pro et l'OS d'exploitation (un Linux) pour :
primo avoir une latence minimale ajoutée et en secundo avoir surtout une latence indépendante de l'effet utilisé (c-à-d même latence quoi qu'on utilise comme effet)
et ceci est vrai (sur les deux points)
en insérant un effet (interne!) dans une tranche de console ou dans un BUS on y ajoute environ 0,5msec et cela quelque soit l'effet inséré comprenant également les GEQ !!! (ceci ne concerne évidemment pas les "pures delays" ni le prédelay de reverbe etc)
par contre ces 0,5msec s'ajoutent seulement quand l'effet ou le GEQ sont activé (ce qui semble logique) - mais là aussi la compensation automatique, quand elle est activé, remettra les choses en cohérence mutuelle - dès qu'un insert est utilisé une compensation se mettra en place sur la totalité des tranches et indépendamment si l'insert ou l'effet est activé ou pas...!!)

puis j'ai mesuré quelques latences relatives, comme par exemple :
le point de sortie Direct-Out peut être sélectionné soit avant processing (donc juste après le convertisseur) ou après processing (donc post eq, comp, gate etc mais encore pré-fader, et également au choix un post-fader et post-mute

en mettant ma référence zéro latence en Direct out avant processing et en mesurant celle du Main OUT on obtient 1,19 msec
entre le Direct-Out Post-Processing et Main-Out on a seulement 0,85msec (ce qui laisse à deviner que le processing de tranche-console (eq, comp, gate etc) prend une latence d'environ 0,34 msec en sachant que contrairement aux effet FX et GEQ dont la latence s'ajoute seulement en activant le module; la latence de tranche de console est fixe et indépendant de l'activation ou bypass de tous les modules se trouvant sur la tranche ! (ce qui est parfaitement logique, soit dit en passant !)

en passant par un Bus supplémentaire (exemple source->sous-groupe->Main-Out) on y ajoute environ 0,5msec et en plus : pour chaque GEQ inséré et activé on y ajoute encore une fois 0,5 msec sur le chemin (le PEQ de tranche par contre n'y ajoute aucune latence !!)
exemple un peu extrême :
IN vers OUT = xx msec de latence
mais : IN (avec insert FX ou GEQ activé)-> Sous-Groupe (avec insert FX ou GEQ activé) -> Main-Out (avec insert FX ou GEQ activé) donnera xx+1,5msec de latence

et un dernier mot pour finir : il s'agit là de pure mesures basiques; l'OS de la console Pro de Midas prévoit une compensation de delay (pour compenser les différences de latences à divers points de la console) ce qui augmentera en fin de compte la latence globale de la console et donc du cheminement IN vers OUT mais ce qui remet aussi tout le monde internement en phase; en fait ça ressemblera un peu au cheminement dans une console analogique où il n'y a ni latence ni déphasage causé par le routing etc
(en activant toutes les otpions cela peut monter la latence globale du IN vers OUT à 8msec, ce qui est déjà assez énorme; mais en même temps je pense qu'on n'a pas non plus besoin d'avoir absolument toutes les options de compensation activé et que dans le quotidien du mix (incluant aussi les obligations et exigences pour le In-Ear monitoring on s'en sort avec 2 à 3 msec... ce qui est parfaitement jouable)

exemple pour le routing Bus; en activant cette compensation (Monitor->Main) on obtient une latence de 2,23msec de IN Vers Main-OUT et ceci indépendant si on passe par un ou plusieurs BUS supplémentaire comme par exemple sous-groupes etc..
=>valeur valable uniquement sans aucun GEQ activé !!!

et si on veut insérer un effet sur une ou plusieurs tranches de consoles il vaut mieux aussi d'activer la compensation "INSERT" pour remettre toutes les tranches à nouveau en phase entre elles
exemple concrète : avec la compensation INSERT activé on passe de 1,6msec à 2,4msec de latence du IN vers le OUT mais dans ce cas précis il s'agit de la latence globale et désormais indépendant du fait si FX ou GEQ sont inséré ou non dans une tranche ou un BUS; toutes les tranches seront en phase entre elles...

[ziggy]

en ce qui concerne le(s) DSP dont vous avez parlé plus haut
les Pro-1 et Pro-2 ont des DSP intégrés et en fixe (non extensible)
je peux rentrer dans les entrailles de l'OS et j'y trouve deux FX-DSP et six Main-DSP
sur une page Diagnostic (Inspecteur et rapport) on peut surveiller les performances, les éventuelles erreurs (overrun, overflow, exceptions etc) et aussi la température pour chacun des DSP (FX 1 et 2 et Main-DSP 1 à 6)

pour les consoles à partir de la Pro-3 les DSP sont modulable et il est possible d'ajouter des DSP ce qui correspond en fait à un upgrade vers les modèles Pro-6 et Pro-9
le châssis et le reste du hardware restant strictement le même entre toutes les versions 3 à 9 ! (il me semble que la Pro-X soit à part !)

on connait déjà ce système chez d'autres fabricants qui proposent des DSP modulables; par exemple Vi6 ou tous les DSP et autres processeurs se trouvent dans un appareil externe de la console (appelé chez Soundcraft le Local-Box)
il me semble que le I-Live ont également les DSP et tout le processing en externe (dans ce cas le Stagebox)
les anciennes Innovason fonctionnaient comme ça également

[Barthedoc]

holla

Bien vu la mesure de la latence relative
Il y a aussi 2 dsp FX + 6 main DSP dans la GLD.
C'est sûrement un modèle spécifique avec une gestion Mini PC Linux.
mais pas vu de support pour un upgrade DSP.
Je referai le même protocole que celui que tu as utilisé pour tester la latence relative dès que j'ai le temps.

[ziggy]

mais pas vu de support pour un upgrade DSP.

..c'est sans doute une des raisons parmi d'autres, pourquoi le matériel GLD est incompatible avec le matériel I-Live (concernant aussi les Stage-Box par exemple, qui contiennent pour les I-Live des DSP)