Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Mastering
Agrandir
Mastering
Techniques du Son
Mastering
Actu 52 52
Articles 64 64
Médias 542 542
Tutoriels Tutos 1 1
Forums 924 924

Sujet Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .

  • 185 réponses
  • 23 participants
  • 27 233 vues
  • 31 followers
Sujet de la discussion Moteurs audio, 32 bits / 64 bits, distinguer le vrai du faux .
Bonjour à tous les audacieux qui auront le courage de se lancer dans cette réflexion ...

voilà, je me pose la question suivante :

a-t-il déjà été fait un comparatif sérieux des moteurs audio qui animent les DAWs les plus réputées (ou les plus répendues ...) ?

Depuis quelques temps, on voit apparaître comme principal argument de renouvellement de certains logiciels, le fait que leur moteur audio passe au 64 bits. Y'a-t-il un gain réel à se lancer dans le 64 bits en tant que moteur de mixage (et pas en tant que moteur de système d'exploitation ... :clin: ) ?

Personnellement, je pense bien qu'il doit y avoir un avantage net puisque nous massacrons joyeusement de plus en plus le signal à coup de plug-ins déjantés, et qu'une précision accrue dans les calculs permet de conserver une cohérence dans le signal traité (ne serait-ce qu'au niveau de sa phase ...). Sans compter que des logiciels aux ambitions très modestes comme Tracktion 2 se sont armés de ces moteurs 64 bits, alors que des plates-formes considérées comme "haut de gamme", comme ProTools, pour ne pas le citer, en reste pour l'instant au 32 bits (alors que ses prétentions qualitatives et pécuniaires sont pour le moins beaucoup plus élevées). Et en outre, des logiciels comme Samplitude ou Pyramix ont des moteurs en 32 bits mais extrêmement réputés (car très bien programmés semble-t-il) pour leur respect du signal. Une vache n'y retrouverait pas son veau ...

Un rapide état des lieux :

moteurs 64 bits :
Sonar 6
Cubase 4
Sequoia 9
Tracktion 2

moteurs 32 bits : (je vais en oublier c'est sûr)
Samplitude 9
Pyramix 5
Nuendo 3
Pro Tools ??? (je me perds dans les versions)
Kristal Audio Engine (faudrait pas oublier les gratuits ...)

voilà, merci à ceux qui voudront bien partager cette réflexion avec moi ...

:bravo:
Si vis pacem para bellum
Afficher le sujet de la discussion
101
Salut,

Citation : ben pour info, je joue sur scene (enfin pas tant que ça en ce moment) avec ableton live, ou je declenche des samples et joue de synthé, pendant qu'en meme temps le son d'un bassiste et d'une chanteuse le traverse pour les effets, qui sont mofifiés en temps reel. 11 ms de latence, on y voit que du feu.



puisque ça cause de ça, juste mon experience : je suis en train de tester le nouveau Samplitude, pour le live, ça m'a toujours titillé cette histoire de mixer en live avec un ordi...
J'ai mixé quelques voies importantes (kick, snare, 3 voies), pour pas prendre de risques pendant le concert j'ai utilisé les direct out de la console dans une Fireface, 2 rev, des inserts partout, 96 samples de latence... (2,5 ms). Retour vers des tranches de libres de la console ... impec !
La prochaine fois, je pousse + loin, avec des snapshots pour pouvoir encore plus charger, maintenant que j'ai vu à peu près les limites de l'ordi... et je pourrai aussi sans que ça s'entende, monter un poil la latence... faut pas pousser ...
ça marche mieux que Virtual Console Mixer, qui est fait pour normalement !
Ca s'annonce plutôt bien, pour le studio mobile, j'aurai plus de latitude de travail pour les mixs casques avec fx pour les musiciens.

voilà c'était tout...



a+
Phil

Symmetry (electrified folk songs)

Quantum Crash (rock prog solo project)

Lussy Bless (rock-metal)

Po&sic (slam)

102
T'inquiètes live, je connais et j'apprécie beaucoup aussi. Les effets consomment très peu en ressources donc ça permet effectivement de ne ne pas trop monter la latence.
Mais 11 ms ça reste trop pour un enregistrement. Imagines que t'es un batteur et un bassiste à enregistrer. T'équalises certaines pistes de la batterie et tu la renvoies dans le casque du bassiste. Bah si t'as pas une latence très courte, ça va pas être simple pour eux de jouer ensemble.

Citation : Et si PT sais comme tous les systèmes à base de DSP avoir une latence suffisament faible pour être négligeable pour l'utilisateur, la puissance des machines natives permettent des latences de moins de deux millisecondes actuellement pour les meilleures, ce qui est parfaitement acceptable.



Bah oui c'est tout a fait jouable, sauf que pour avoir ces 2ms de latence bah t'as pas grand chose en plugins d'activé donc les buffers au minimum ???
D'ou ma remarque sur le prix du système HD ou de Pyramix qu'est pas si prohibitif que ça compte tenue du confort de travail que cela apporte ;)
M'enfin bon, je suis pas près d'en avoir les moyens, non plus :((
103

Citation :
Quand à ma question initiale sur le délicat sujet des "moteurs" (pour ma part, ça incluait l'espèce d'OS qui fait le lien entre les étapes de mixage de lecture et de gestion des traitements, plugins ou pas), elle peut paraître anodine, mais d'après ce que disent certains ici, les différents moteurs audio ne peuvent pas se distinguer les uns des autres de manière audible ... ce qui revient à dire que Tracktion (150 brouzoufs) sonne exactement ou pas différemment à proprement parler de Protools HD (10000 brouzoufs) ou de Pyramix (3000 brouzoufs). Alors, la vraie question derrière tout ça est : où commence la raison marketing et où finit la fièvre commerciale ?



Pour vraiment comprendre et etre d'accord sur ce que signifie le moteur audio, il faudrait que tout le monde sache comment marche un sequenceur, et qules sont les problemes qu'il resout. En fait, le moteur audio, tu peux voir ca comme un OS: son boulot, c'est de faire une interface entre la carte son, les plugins, et l'interface utilisateur (en general graphique).

Par exemple, si tu veux programmer un effet VST (ou audio unit, etc.., ca change rien au probleme la), tu n'as pas a te soucier de la carte son, du nombre d'entrees de la carte son, et de sa relation avec l'exterieur, y compris du type de sequenceur. Tous les VST ont une meme maniere de "parler" a l'hote: c'est exactement le but du VST.

Donc le moteur audio, lui, il doit:
* gerer la(les) carte son (en general a travers un autre protocole, par exemple asio, core audio, etc..),
* etre capable de se voir plugge pleins de plugs: insert, etc... Tout ce qui est le routing, quoi.
* gerer la latence: faire en sorte que tous les plugs in soient synchronises
* etre efficace: pour avoir une faible latence, tu as pleins de parametres a prendre en compte dans l'interacation vis a vis de l'OS, c'est un peu complique de rentrer dans les details pour les non informaticiens, mais disons que c'est pas trivial.

Tous ces problemes sont complexes, mais *pas du tout tout au niveau traitement audio*. Pour changer le volume d'une piste, c'eest toujours la meme operation, qui est triviale, a savoir la multiplication du signal par un gain. L'aliasing ne joue absolument pas la dedans. La ou l'aliasing intervient, c'est lorsque le signal d'entree a une frequence differente que la frequence de fonctionnement (par exemple utliser un wav @ 44.1 Khz, et une frequence de fonctionnement de l'hote a 48 khz).

Apres, la plupart des sequenceurs incluent des effets (Eq, reverb, etc...), et la, ils sont tous differents, y compris sur le plan sonore.

Citation :
Alors, il y a deux approches, soit la station DtD haut de gamme, avec un "moteur audio" bétonné (optimisation du calcul, dégradation du signal nul même avec de nombreux traitements simultanés (la phase, bordel, la phase !),



Non mais le sequenceur, il a aucune influence sur la phase, tant que tu utilises que les faders.

Citation :
Non, cela fait parti des bases de l'audio-numérique, la latence théorique mini est obligatoirement d'un échantillon. En pratique, l'utilisation de DSP permet d'avoir un environnement optimisé permettant de diminuer la latence, pas de l'annuler.



C'est pas tant la base de l'audio numerique que des contraintes d'implementation. La latence a plein d'origines:

- deja, au niveau de la conversion. Pour ca, faut savoir un peu comment marche la communivation carte son - OS. Tout carte audio ne convertit pas sample par sample, mais remplit un buffer de n samples, et une fois que le buffer est rempli, il dit au CPU: hello, le buffer est rempli, tu peux lire son contenu maintenant (c'est une interruption, passee par les fameux IRQ). A ce moment la, l'OS lit le contenu du buffer, le copie (concretement, il le copie pas forcement, mais ca change pas grand chose a l'idee generale), et le file a travers un protocole style ASIO, etc... aux logiciels qui en ont besoin, comme par exemple ton hote. Le n, c'est ce que tu regles dans ton panneau de carte son, et c'est au moins egal a 64 autant que je sache (pour les RME). 64 samples a 44.1 Khz, ca veut dire 1.5 ms de latence, deja.
- ensuite, le temps d'ecoulement entre l'operation "la carte son signal son buffer plein" et "l'OS traite l'information et file le contenu du buffer aux applications" n'est pas nul. La, ca depend beaucoup de l'OS, en particulier de son algorithme de scheduling. Windows est particulierement mauvais, Mac os X et linux nettement meilleurs pour prendre ca en compte. La, l'hote peut deja faire une difference, car c'est difficile de pouvoir faire ca bien.
- enfin, les traitements audio en eux meme: la aussi, il y a de la latence, qui depend totalement du plug, etc... Recemment, les sequenceurs sont devenus capables de realigner les plugs au niveau de la latence (latency compensation): la latence des plugs etant calculable, le sequenceur lui file les donnes en avance (lorsque les parties audio sont deja enregistrees, evidemment) d'un nombre exactement egal a la latence.

Et la dedans, tu dois prendre en compte le fait que les sequenceurs ajoutent leur propre latence lorsque tu changes les parametres (les traitement audio sont presque toujours faits par bloc; plus le bloc est grand, plus tu as de la latence), etc...

Un systeme DSP fonctionnant sur un OS tres limite, il a beaucoup moins de problemes de latence en general (sous DOS, t'as tres peu de latence aussi :) ), mais le probleme de la carte son demeure par exemple, autant que je sache.

D'ailleurs, faut voir que de plus en plus de constructeurs hardware sont interesses par linux, pour differentes raisons. C'est extremement couteux de faire son propre OS (dit embarque, car a l'interieur d'un hardware specifique, par exemple table de mixage, etc...), et linux offre pas mal d'avantages. Parmi les noms connus du public, il y a quand meme SSL, Harrison/GLW ou Korg (l'OASYS fonctionne sous linux).
104
Quand je disais que la latence théorique est de un échantillon, je voulais juste dire que le simple fait de le prélever dans le flux, et de le réintroduire dans le circuit après une quelconque opération ne peut se faire sans au moins un cycle d'horloge du CPU, et que ce temps très faible mais non négligeable empèche cet échantillon de rester à la même position temporelle, que ce soit du natif, ou du DSP provenant d'une DAW ou d'une console.

Ce que j'appelle les bases, quoi.

JM
105
...sans compter les temps de conversion A/D - D/A ...
106

Citation :
Quand je disais que la latence théorique est de un échantillon, je voulais juste dire que le simple fait de le prélever dans le flux, et de le réintroduire dans le circuit après une quelconque opération ne peut se faire sans au moins un cycle d'horloge du CPU, et que ce temps très faible mais non négligeable empèche cet échantillon de rester à la même position temporelle, que ce soit du natif, ou du DSP provenant d'une DAW ou d'une console.



Oui mais cette latence est justement pas d'un echantillon (un echantillon du signal sonore, d'ailleurs, dont la frequence est bien plus faible que celle du CPU: on parle de plusieurs dizaines de micro seconds pour un echantillon sonore, alors que pour un CPU, c'est de l'ordre de la nano seconds; le CPU n'ar rien a voir dans l'operation dont tu parles).

Le probleme que tu souleves est en fait fondamental, mais pas pour le probleme de la latence dont on parle le plus souvent dans un contexte utilisation de l'ordinateur. C'est un probleme lorsque l'on utilise plusieurs unites hardware numeriques reliees entre eux numeriquement.
107
Euh, je voudrais pas insister, mais je dois mal me faire comprendre.

Je ne confonds pas la fréquence CPU avec la Fe, je dis simplement que même si l'ordi ou le DSP est très très très rapide, il ne calcule pas à vitesse infinie, que par conséquent il ne peut qu'introduire une latence minimum théorique d'un échantillon, parce qu'il n'est pas possible que ce soit zéro, et qu'entre zéro et un, il n'y a pas d'alternative.

Ce qui n'empêche pas d'autre phénomènes d'en rajouter, notamment la conversion AD/DA.

JM
108

Hors sujet :

Citation : T'équalises certaines pistes de la batterie et tu la renvoies dans le casque du bassiste. Bah si t'as pas une latence très courte, ça va pas être simple pour eux de jouer ensemble.


11 ms, pour un batteur c'est largement sufisant, meme pour de la guitare jouée res rapidement, en general, le guitariste n'y voit rien (sur scene, si t'es a 5 metres de ton retour, t'as plus de "latence" que ça!!), il est possible de descendre autout de 5, je ne le fais pas en live pour ne pas prendre de risque,parce que justement j'ai une charge consequente (au passage, les effets de live ne consomme pas tant que ça, certes, mais a coté y'a une dizaine de pistes en timestretching temp reel, des instruments, et des plug ins non natifs, mon cpu tape pas loin des 75%), mais en situation d'enregistrement, on eut tout a fait envisager de descendre, en freezant le reste par exemple.
vraiment, hein, je le fais regulierement, et meme a 11 ms, personne s'est jamais plaint, surtout pas les batteurs.

109

Citation :
Je ne confonds pas la fréquence CPU avec la Fe, je dis simplement que même si l'ordi ou le DSP est très très très rapide, il ne calcule pas à vitesse infinie, que par conséquent il ne peut qu'introduire une latence minimum théorique d'un échantillon, parce qu'il n'est pas possible que ce soit zéro, et qu'entre zéro et un, il n'y a pas d'alternative.



Ah, Ok. Tu as raison, mais une fois encore, c'est totalement negligeable par rapport aux autres origines de la latence: buffer hardware de la carte son, latence de l'OS, etc... En general, la latence est de l'ordre de plusieurs centaines de samples, et les convertisseurs ne convertissent jamais sample par sample autant que je sache (je peux me tromper, je connais pas grand chose au hardware mis en jeu pour les convertions; pour les carte sons, j'en suis certain par contre).

Par contre, la ou c'est pas negligeable du tout, c'est dans les problemes de feedback. Par exemple, c'est une des raisons pour lesquelles les filtres numeriques sonnent pas pareil que les filtres analogiques (qui eux peuvent meme pas etre sans feedback), et selon les designs des filtres numeriques, on va pouvoir diminuer cet effet ou pas.
110
C'est pour ça que j'insistais sur l'aspect théorique, parce que les problèmes de bufferisation par exemple relèvent de choix technologiques. Il serait, toujours théoriquement, possible de s'en passer, même si d'un point de vue rendement et sécurité, ce ne serait pas une bonne idée.

Et cela remettrait beaucoup de chose en question, c'est certain. Notamment la gestion de fichiers et les accès au disques durs. C'est le résultat de l'adaptation de technologie issues de l'informatique à l'audio, qui necessite une gestion de flux continu. A un autre niveau, on retombe dans la même problèmatique que la téléphonie sous IP, mais avec des débits beaucoup plus importants.

JM