Se connecter
Se connecter

ou
Créer un compte

ou

Sujet Retour sur le moteur audio : 32 vs 64 bits, flottant vs fixe...

  • 112 réponses
  • 24 participants
  • 15 748 vues
  • 84 followers
Sujet de la discussion Retour sur le moteur audio : 32 vs 64 bits, flottant vs fixe...   fusion
Loin de moi l'idée de vouloir relancer un thread qui est bien parti dans tous les sens et je laisse le soin aux modérateurs d’en ouvrir un nouveau si nécessaire.

J’avais promis il y a quelques 400 commentaires plus tôt (!!) d’essayer d’avoir le point de vu scientifique d’un développeur audionumérique tierce partie sur les incidences possibles des évolutions technologiques (48 bits fixe, 32 ou 64 bits float) sur la qualité audio.

Ce fût donc pour moi un immense bonheur de converser avec Gaël Martinet de Flux:: lors du Satis 2011 et on en a profité pour parler de bien d’autres choses…

Voilà, chose promise, chose due.


Aurélien

 

[ Dernière édition du message le 06/12/2011 à 13:26:53 ]

[ Ce message faisait initialement partie de la discussion "Commentaires sur le dossier : In studio with Blanc-Francard & Schmitt" qui a été fusionnée dans ce sujet le 07/12/11 ]

Afficher le sujet de la discussion
101
Citation :
Donc jusqu'à preuve du contraire, on peut conclure que toutes les infos que l'on a entre les mains disent que ça ne s'entend pas spécialement.


Je trouve qu'il n'y a pas que le problème de l'audibilité des hautes résolutions. La question se pose aussi en terme de travail.
Je n'en ai pas les capacités techniques, mais j'aimerais bien calculer l'"équivalence de résolution" entre le 32float et le réglage d'un EQ par exemple. Parce que celui qui manipule les machines a aussi son approximation, et j'aimerais bien savoir quelle précision il faut avoir sur le réglage de gain d'un EQ (1dB, 0,1dB, 0,01dB?) pour être gêné par le 32float... A quel point la justesse d'un envoi réverb est faussé par les erreurs de calcul...

L'intervention de Gaël est intéressante sur ce point: on peut chiffrer le défaut du moteur audio, et donc le comparer. Ce qui est la base de tout jugement.

Personnellement, quand je fais des travaux, que ma scie sauteuse soit précise à 1 ou 10 microns, je m'en fiche, c'est pas ça qui me fera couper droit. :D:

Citation :
Après, il y a plein d'autres raisons, probablement bien meilleures, de passer de protools HD à protools HDX.

Oui moi j'ai hâte. Pour plein d'autres raisons. ;)
102
Petit retour sur l'architecture x86, par ordre chronologique (je simplifie/laisse de côté certains trucs, le post est déjà assez compliqué comme ça) :

- on a d'abord l'unité de calcul en nombre entiers, avec des registres 32 bits sur les processeurs anciens, et 64 bits sur les processeurs récents. Ce sont les mêmes registres qui servent aussi pour l'adressage mémoire, ce qui explique qu'il faille un processeur 64 bits pour exploiter 4 Go de RAM et plus.

- on a ensuite le coprocesseur arithmétique. C'est une puce à acheter à part jusqu'au 386/486SX, puis directement intégrée dans le 486DX, Pentium et processeurs ultérieurs. Celui-là fait des calculs en 80 bits flottants (mais il accepte aussi de traiter du 32 et 64 bits flottants). Ça permet de faire plein de calculs mathématiques tordus (trigo, etc.), mais c'est beaucoup plus lent que les calculs sur les entiers.

- puis vient le MMX, qui utilise les mêmes registres que ceux du coprocesseur arithmétique, mais pour traiter des entiers cette fois. L'avantage c'est qu'il permet de faire plusieurs calculs de même type en parallèle (on appelle ça le SIMD), par exemple 2, 4 ou 8 multiplications simultanément (suivant la taille des entiers à traiter). C'est très utile pour le traitement audio et vidéo. Par contre, l'inconvénient du fait que les registres soient partagés avec le coprocesseur arithmétique, c'est qu'on ne peut pas facilement utiliser les deux modules ensemble (il faut sauvegarder et restaurer tous les registres à chaque fois qu'on passe de l'un à l'autre, ce qui est coûteux au niveau des perfs).

- ensuite, on a le SSE. C'est le même principe que le MMX, sauf que cette fois on a de nouveaux registres dédiés à ça, et qu'on traite des flottants sur 32 bits. C'est moins précis que les 80 bits du coprocesseur arithmétique et il y a moins de fonctions mathématiques dispo, par contre c'est beaucoup plus rapide.

- enfin, le SSE2. Toujours le même principe, avec cette fois la possibilité d'utiliser des flottants 64 bits.

Pour les évolutions ultérieures (SSE3, etc.), je n'ai pas encore regardé ce qu'il y avait dedans.
103
Citation :
Personnellement, quand je fais des travaux, que ma scie sauteuse soit précise à 1 ou 10 microns, je m'en fiche, c'est pas ça qui me fera couper droit.


J'aime bien cette image, parce que c'est exactement ça.
Mais avec 32bits tu es déjà au micron, 64bits te fait passer au nanomètre.


Pourquoi est-ce que les concepteurs passent de 32 à 64bits ? Tout simplement parce qu'ils n'ont pas vraiment le choix.
Il arrivera un jour (relativement proche) où il n'y aura plus d'outil de développements 32bits. Pour sortir un soft, une dll, etc. sur un PC (ou sur les mac qui suivent le mouvement) il faudra bosser en 64bits ou gérer des problèmes croissants d'obsolescences qui auront un impact significatif sur la rentabilité du produit...

Bien sûr, faire migrer un moteur 32bits vers un moteur 64bits c'est une évolution majeure du logiciel, avec un coût de développement notable.
Alors autant faire un peu de marketing en nous expliquant que c'est un vrai "plus" pour l'utilisateur de façon à justifier le tarif important de l'évolution dont le véritable but et d'assurer une rentabilité.
104
Encore une fois... les 32/64 bits (flottants) dont il question ici ne sont pas lié aux 32/64 bits de l'architecture du processeur. On pourrait très bien continuer à faire des moteurs 32 bits flottants sur les processeurs 64 bits (alors que ne pas gérer le 64 bits pour l'accès mémoire, par contre, ça la fout mal pour un soft moderne). Mais ça n'a pas vraiment d'intérêt maintenant que les processeurs savent faire des calculs rapides avec des nombres 64 bits flottants, et en plus ça fait un bullet point supplémentaire sur la plaquette commerciale.

[ Dernière édition du message le 11/12/2011 à 22:53:01 ]

105

T'as pas fini d'y revenir Zerosquare  mrgreen. Cette confusion est courante et souvent entretenue par les marketeux du logiciel.

JM

106
x
Hors sujet :
Les marketeux... le pire cauchemar des ingénieurs depuis toujours :-D

[ Dernière édition du message le 13/12/2011 à 00:08:10 ]

107
Tiens, visiblement même des gens qui devraient savoir se mélangent les pinceaux : https://www.pebkac.fr/pebkac-4457.html
108
Citation :
Encore une fois... les 32/64 bits (flottants) dont il question ici ne sont pas lié aux 32/64 bits de l'architecture du processeur.
Encore une fois pour qui ?

Je ne parle pas d'un problème technique mais du problème d'obsolescence.
https://fr.wikipedia.org/wiki/Obsolescence

Nous sommes d'accord : c'est la mode et le marketing qui tord le bras du concepteur.
Le client est assez couillon pour payer au prix fort une évolution qui ne lui sert à rien tout en amortissant le prix de l'évolution des outils de dev qui menacent, eux aussi, de devenir obsolètes.
Mais de toute façon, ça fait aussi bouffer le concepteur, alors pourquoi se plaindrait-il ?

[ Dernière édition du message le 13/12/2011 à 00:30:21 ]

109
Le calcul 32 bits flottants n'est pas obsolète, contrairement à l'architecture 32 bits. Et le passage 32 bits flottants->64 bits flottants est nettement moins problématique du point de vue du développeur que le passage architecture 32 bits->architecture 64 bits.
110
Du docks
Citation :
D'une manière générale, de toute façon, même si le sujet présente des intérêts (pour sa culture personnelle) ramené à l'utilisation in situ des DAW, on fait clairement dans l'empapaoutage de Lucilia Caesar dans ce débat, vu les rapports signal/bruit dont il est question, déjà largement suffisant pour répondre à nos besoins quotidiens même pour les plus exigeants.


Tout est dit. J'adore.

[ Dernière édition du message le 13/12/2011 à 01:04:00 ]