Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Informatique musicale
Agrandir
Informatique musicale
Instruments et matériels audio
Informatique musicale
Produits 30 664 30,7k
Actu 26 756 26,8k
Articles 1 312 1,3k
Médias 311 669 311,7k
Tutoriels Tutos 1 372 1,4k
Avis 23 513 23,5k
Petites annonces Annonces 2 297 2,3k
Forums 142 183 142,2k

réactions au dossier Qu'est-ce que la latence en MAO ?

  • 95 réponses
  • 41 participants
  • 6 264 vues
  • 42 followers
Sujet de la discussion Qu'est-ce que la latence en MAO ?
qu-est-ce-que-la-latence-en-mao-3127.jpg
2 minutes : C'est tout le temps laissé à Los Teignos pour vous expliquer ce que sont la latence audio et le buffer en MAO. Top chrono !


Lire l'article




Ce thread a été créé automatiquement suite à la publication d'un article. N'hésitez pas à poster vos commentaires ici !

__________________________________________________________________________________
Le GIEC chiffre à 3,3 milliards le nombre de victimes du réchauffement climatique. On en parle ?

 

Afficher le sujet de la discussion
61
x
Hors sujet :
j'ai découvert ça récemment aussi pour du travail à distance avec audio de qualité, pas encore testé:
https://cleanfeed.net/
et ici le test et explication en anglais:


62
A propos de la comparaison entre usb, FireWire, thunderbolt 3... ayant une uad apollo silver (donc firewire) j’ai longtemps bosser avec en me disant vivement que je puisse bosser en th3 ... j’aurais presque plus de latence...

C’est Faux... la carte firewire comme le thunderbolt passe par le port pcie physique ou non (ça a été dit plus Haut) .

Lorsque j’ai reçu ma carte uad thunderbolt qui se glisse à côté des connecteurs firewire j’etais Comme un dingue. Tu te rends compte ce que je vais gagner !

Voici le résultat
à 512 samples sur firewire c’est 13 ms de latence.

A 512 samples sur th3 c’est 12 ms et des poussières sur th3.

La problématique ne se trouve pas dans les taux de transfert et la seule chose que l’on est faite avec ses normes successives qui coûtent cher c’est d’augmenter la grosseur du tuyau et sa solidité.

Plus gros tuyaux = plus de pistes enregistrables en même temps pour l’audio

Solidité = stabilité

Mais on ne gagne pas grand chose en latence parce que ce qui compte c’est bien le temps de cycle du processeurs. Ainsi si j’ai 28 cœurs à 2,3 GHz mon temps de latence va augmenter par rapport à un processeur qui tourne à 5ghz sur tous les cœurs type i9 9990k...

Par contre en lecture de vsti je jouerai plus d’instruments avec mon 28 cœurs si j’augmente ma taille de buffer qu’avec mon i9.... mais vu que ça n’est pas un concours au nombre de pistes ecoutables en même temps ben on s’en fou un peu!

Pour finir à titre d’exemple AMD va sortir son 4950x avec des performances plus élevées... y a t’il un espoir pour la MAO ? Oui les cycles d’horolge Ont été réduits..

Ce que ça change ? C’est la capacité à remplir totalement le carton avant qu’il ne soit parti. On a donc deux paramètres important . Le premier auquel nous ne pouvons rien faire c’est la structure même du processeur (mon moteur de xsara Picasso restera un moteur de xsara Picasso mais je peux changer la puce électronique qui modifie la compression de l’injection et donc booster un peu les performances de mon moteur).

Ça correspond à l’augmentation de la fréquence d’horloge... c’est le second paramètre.

Attention la fréquence boost c’est bien mais ça ne dure pas longtemps même si ça règle quelques glitsch et autre désagréments en tous genres.

Donc à titre d’exemple puisque le 4950x aura une meilleure fréquence et un cycle d’horloge optimisé et donc plus court, les performances audio seront plus réjouissantes, et les glitsch audio seront repoussés un peu... ma latence baissera un peu puisque les temps de rendu entre j’appuie sur la note, ça calcule tout et j’entends le son, sera optimisé.

Mais celui qui pense que les 15% de performances annoncées entre un 3900x actuel et un 4950x à venir dans quelques jours se trompe... ça ne fera pas gagner beaucoup de centième de millisecondes...

Je férai le test (si je suis encore de ce monde) pour donner le résultat avec la
même carte mère, même mémoire celle ci étant déjà optimisée pour les am4 et je reviendrai donner le résultat.

Mais dernier point important à force d’amélioration des procs on pourra un jour passer des 512 samples des buffers à
256 sans que Le processeurs ne décroche et ne glitsch dans tous les sens... mais ça ne se fait pas en une génération de processeurs, et en plus les développeurs de soft profite de l’explosion de la puissance de calculs pour faire des vsti ou vstfx ou des cubase et autres plus puissant ou offrant plus de fonctionnalités... du coup ça mange du temps cpu et mon glitsch peut arriver plutôt que prévu !

Ha oui j’allais oublié oui la couche OS et logiciel sont aussi un facteur important... un OS dédié à la musique et seulement à la musique aurait bossté les performances de façon significative. BEOS a faillit y a très longtemps offrir une telle solution... win xp n’aurait pas fait le poids mais le problème au delà des intérêts commerciaux c’est qu’il nous faut à nous autre musicien un système clés en main... mais on peut optimiser un windows.. Darkmoon qui est sur AF (formum Top config MAO 2019) a fait plusieurs vidéos sur ce point. Dan s sur YouTube.

Au départ je me suis demandé si ça allait vraiment jouer beaucoup... et la réponse et oui! Un grand bravo à Darkmoon d’ailleurs pour ce travail. Son idée était d’arreter Tous les services Windows qui ne nous servent pas et mangent du temps processeurs qui au lieu de s’occuper de remplir les cartons va par exemple voir si il n’y aurait pas une petite mise à jour Windows à faire...

Le résultat c’est entre 20 et 50% de puissances ou temps cpu délivrés...

par’contre Il faut faire attention à ce que l’on fait et Prendre des notes. A titre d’exemple j’ai coupés tout y compris les services réseau... ça a bossté ma machine de
Façon inattendue... sauf que quand j’ai acheté une nouvelle bank’de sons j’etais bien incapable de savoir quels services remettre en route pour ma prise rj45 fonctionne!!! Ça m’a coûté une réinstallation de Windows avec tous le reste mais c’est sans regrets. 1) j’ai appris. 2) ça a fait du nettoyage. 3) j’ai pu de nouveau faire cette optimisation de Windows mais cette fois en étant plus attentifs aux risques et en ne
Coupant que services après services en’verifiant les Conséquences... je serais d’ailleurs bien incapable de le refaire sans les vidéos tuto en question !

En tous cas c’est une bonne chose que d’expliquer ce que c’est La latence... pour nous c’est le temps’que L’on met à répondre à notre femme quand on lit AF...

Eric

[ Dernière édition du message le 03/10/2020 à 08:06:47 ]

63
Citation :
à 512 samples sur firewire c’est 13 ms de latence.

A 512 samples sur th3 c’est 12 ms et des poussières sur th3.

Ben selon ta fréquence échantillonnage ça parait normal :facepalm:
La durée du buffer à une fréquence donnée est assez incompressible.
64
Citation de Ericmusicstrasbourg :

Voici le résultat
à 512 samples sur firewire c’est 13 ms de latence.

A 512 samples sur th3 c’est 12 ms et des poussières sur th3.


Ça c'est normal. Le passage d'un bus à l'autre ne va pas changer la durée d'un buffer. Mais ça permet de descendre plus bas car il y a moins d'aléas sur le bus.

Citation de Ericmusicstrasbourg :

Mais dernier point important à force d’amélioration des procs on pourra un jour passer des 512 samples des buffers à
256 sans que Le processeurs ne décroche et ne glitsch dans tous les sens... mais ça ne se fait pas en une génération de processeurs


J'ai un Core i7 920 de 2009, et sur les projets "simples", je tourne à 128 samples sans problème depuis 10 ans.

65
Citation :
Citation de Ericmusicstrasbourg :


Voici le résultat
à 512 samples sur firewire c’est 13 ms de latence.

A 512 samples sur th3 c’est 12 ms et des poussières sur th3.



Ça c'est normal. Le passage d'un bus à l'autre ne va pas changer la durée d'un buffer. Mais ça permet de descendre plus bas car il y a moins d'aléas sur le bus.

Citation de Ericmusicstrasbourg :


Mais dernier point important à force d’amélioration des procs on pourra un jour passer des 512 samples des buffers à
256 sans que Le processeurs ne décroche et ne glitsch dans tous les sens... mais ça ne se fait pas en une génération de processeurs



J'ai un Core i7 920 de 2009, et sur les projets "simples", je tourne à 128 samples sans problème depuis 10 ans.


oui on peut même descendre à 64. après ça dépend du vsti utilisé... de l'audiomodeling par exemple consomme plus que vsl par exemple et du coup le nombre de pistes peut vite être réduite. sur du sampling standard ca n'est pas un problème, sur du vsti à modélisation physique ou tout est calculé par le cpu c'est une autre histoire...

quand au passage d'un bus à un autre et bien oui tu as raison, c'est normal mais avant essai j'avais imaginé qu'il y aurait quand même un beau changement... entre le manque de connaissances et le marketing bien ficelé on s'imagine vite des choses qui ne sont pas si vraies que ça...

c'est exactement ce que l'on vit avec les benchmarck cpu ou AMD explose intel. mais sur le real time quand ton amd plafonne à 30% et se met à faire des glitschs ben on s'en fou du benchmark, parce que si à la fin intel fait aussi bien avec des scores benchmark moins flatteurs alors on nous vend du vent (en partie). A faible latence intel fait souvent mieux.

Eric

66
Citation :
Plus gros tuyaux = plus de pistes enregistrables en même temps pour l’audio

oui.
C'est d'ailleurs très amusant que des gens s'exitent sur le passage au TB pour des cartes son dont le nombre de canaux est de toutes façons inférieur à celui que l'USB 2 était déjà largement capable de faire passer. :mrg:
67
Là où le Thunderbolt fait la différence, c'est sur la latence, pas sur le débit.
68
Citation :
Citation :

Plus gros tuyaux = plus de pistes enregistrables en même temps pour l’audio


oui.
C'est d'ailleurs très amusant que des gens s'exitent sur le passage au TB pour des cartes son dont le nombre de canaux est de toutes façons inférieur à celui que l'USB 2 était déjà largement capable de faire passer.


exacte et le plus drôle c'est d'avoir une apollo 8 ou même 16 dans sa chambre sans aucune cabine d'enregistrement... alors à moins d'avoir x synthés hardware et quelques guitares toujours pluguées...

Eric

[ Dernière édition du message le 03/10/2020 à 15:43:51 ]

69
Bon, la question de la latence (des latences ?), ce n'est pas précisément ma priorité, à titre personnel, mais, deux minutes... je pouvais bien tenir deux minutes, n'est-ce pas.
Et bien m'en a pris !
Le sketch des cartons, de la première à la dernière image, c'est génial !
Ce qui s'appelle de la pédagogie bien comprise.
(La latence, je m'en fiche, mais la pédagogie, non :clin:)

"Le jugement est un outil à tous sujets, et se mêle partout... "  (Montaigne / Essais I / chap L)

http://patrickg75.blogspot.fr/

https://patrickg.bandcamp.com/

 

70
Citation :
Là où le Thunderbolt fait la différence, c'est sur la latence, pas sur le débit.


definition du débit: "Le débit est la quantité d'une grandeur qui traverse une surface donnée par unité de temps. Il permet de quantifier un déplacement de matière ou d'énergie."

Donc y a aucune différence sur la latence l’expérience de mon apollo le démontre... je peux enregistrer plus de pistes en même temps en th qu'en firewire (ma capacité de debit en Th est donc plus grande) mais ma latence sera quasi identique moins d'une ms de différence expérience faite avec mon ordinateur et ma carte apollo 8 silver puis passage en thunderbolt avec la carte optionnelle.

Donc le risque de décrochage du flux de données sera atteint plus vite avec du firewire que le th... mais rien d'autres.

je vais prendre une analogie.

je fais du vélo sur un chemin puis sur une départementale, sur une 2x2 voies...
je fais toujours du vélo et je roule à la même vitesse quelque soit la grosseur de la route du chemin ou de l'autoroute que j'utilise.

les deux paramètres vitesse à laquelle je roule et combien de cyclistes je peux mettre sont bien distinctes...

ceci dit alors pourquoi UAD a été se prendre la tete avec du TH?

plusieurs raisons:

1) le marketing
2) en revanche sur un système apollo la bande passante est tout de même très importante puisque au delà des données audio (signal enregistré il y a aussi les données traitées par les cartes uad inclus dans les apollos. et au fil des prises et des pistes de notre composition ben y a de plus en plus d'aller retour des données du daw vers la carte puis de la carte vers le daw pour que les effets vstfx soient calculés. voilà pourquoi réellement UAD a choisi de passer en th parce qu'avec une carte octo ben y a beaucoup de données à faire passer entre le daw et la carte puisque je peux insérer plus de plugins...

3) le TH va devenir la norme des années à venir le firewire non. et l'usb 4 le démontre puisque il intègre le TH pas le firewire

en revanche ça n'ira ni moins vite ni plus vite contrairement à ce que je pensais avant d'avoir l'option Th.
petit détail on peut régler le taux de bande passante pour l'audio et pour les effets...

Eric