Interactions Software/Harware, quels effets sur le son ?
- 113 réponses
- 14 participants
- 6 244 vues
- 25 followers

Phil443

Mastering : Hardware ( Vieux con.) ou Software ( jeune inconscient)
Pour ceux qui n'auraient pas le courage de tout lire (paix à leur âme), on peut résumer la question à ceci :
La piètre qualité d'un harware est-elle à même d'influer sur la qualité finale du son en numérique ?
Certains prétendent que non, que tous les "zéros" et les "uns" seront de toutes manières générés et qu'en digital, le son sera nickel ou ne sera pas.
D'autres (dont je fais partie), estiment que le hard peut provoquer des erreurs à même d'altérer le son, même de façon inaudible dans un premier temps, mais à même d'engendrer de réels soucis à force de manipulation des fichiers par exemple, où lorsqu'on travaille en temps réel.
Je ne saurais que trop vous engager à vous installer avec une bonne bière et trois paquets de clopes en réserve pour lire l'ensemble des argumentations déjà développées dans le thread ci-dessus, car elles sont nombreuses et déjà fort instructives.
J'ai personnellement peut-être commencé à introduire le doute dans certains esprits en citant des résultats de tests effectués par moi-même en labo tout ce qu'il y a de plus sérieux, et en citant en référence des documents comme ceux-ci :
https://www.cs.york.ac.uk/~djp/publications/mcd-pumf.pdf
http://www-rocq.inria.fr/syndex/pub/ts97/ts97.pdf
http://biblion.epfl.ch/EPFL/theses/2006/3626/EPFL_TH3626.pdf
http://www.ccm.ece.vt.edu/papers/steiner_2005_RAW05_hsi.pdf
Mais je ne prétends pas avoir forcément raison, j'accepterai de remettre en cause jusqu'aux constats que j'ai faits par moi-même à condition que l'on me sorte une argumentation reposant sur du (très) solide, preuves indéniables à l'appui.
Donc, les adeptes du "parce que c'est comme ça" peuvent passer leur chemin, cqfd...
Ce qui ne veut pas dire que les gens qui n'ont pas un doctorat en sciences informatiques ne peuvent pas poster : souvent, des questions qui paraîssent ingénues comme ça soulèvent de bons lièvres.
Pour finir, ce type de questions est à même de générer de grandes passions, voire l'emportement (on l'a un peu vu sur le thread initial). Je demande intamment aux participant de bien vouloir garder leur sang froid même en face de ce qu'ils jugent comme étant une ineptie : ce ne sont pas les agressions qui feront avancer un tel débat. Et je n'hésiterai pas à faire appel aux modos pour fermer le thread si ça dérape, soyez-en sûrs.
Alors gentlemen, bons posts !
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

ihbar

Je ne suis que partiellement d'accord avec Phil :
1) Sur le sujet : il faudrait definir "la piètre qualité d'un hardware". Perso, je parle d'un hardware de pc qui fonctionne normalement, et qui ne plante pas toutes les heures. D'autre part, je parle de traitement non temps réel, donc si le Pc fait une "pause", cela n'altère pas le fichier de sortie. ( Donc pas d'utilisation des I/O de la carte son, traitement fichier vers fichier)
2 ) D'accord avec Phil : une toute petite erreur sur un bit de poids fort peut être très audible. Et sur un fichier compressé, le fichier peut devenir inaudible.
3 )Désaccord: Je fais des compilations lourdes ( >1 millions de lignes de code ~ 500MO) sur pc ou stations sun. On vérifie périodiquement le checksum de la compilation et on a jamais repéré une erreur de calcul du system pc ou sun.
Donc pour du traitement audio, la probabilité d'avoir un resultat corrompu est très faible. Si vous voulez être sur de votre coup : faites 2 fois les processing et vérifiez que vous avez bien le même fichier résultat à la fin.
4 )Désaccord : Pour l'impact des controlleurs de disques, mémoire, bus : si il y a des defauts sur les transfers de données, il y aura une aussi une forte probabilité de défaut sur le code machine. Or une corruption de code machine entraine souvent un plantage de la machine, donc si le hw est pourri cela se verra plus par du plantage de pc.
5 ) D'accord avec Phil : Si le soft est mal concu, le résultat sur des hardware différent peut donner un résultat different. Mais ce cas est un bug Soft (driver incorrect?), et pas un problème hardware pur. L'utilisation d'un harware dedié evite ce problème a 100% car il n'y a qu'un driver possible !
Donc pour résumer mon opinion : Oui le hardware peut influencer le résultat final, mais la probabilité d'une erreur est extrèmement faible. Et il est plus probable d'avoir un plantage du soft qu'un fichier corrompu.

Phil443

Bon, alors vu qu'il m'était difficile de résumer tout ce qui s'est passé précédemment dans l'autre thread (un peu long...

1/ Il est hors de question de mettre de côté le travail en temps réel. Le débat a été soulevé dans une filière traîtant de pre-mastering. Or chacun sait qu'en la matière, on peut être amené à faire tourner plugs et hardware dédié simultanément. L'informatique se doit par conséquent de pouvoir suivre le reste...
2/ On définira par hypothèse de départ que hard de bonne qualité = PC de marque référenciée (donc reconnue) ou Mac, équipé de périphs internes ou externes un tant soit peu "pros". Mauvais hard = PC acheté en soldes chez Lidl avec périphs grand public ou venant de je-ne-sais-trop-où.
Citation : Si vous voulez être sur de votre coup : faites 2 fois les processing et vérifiez que vous avez bien le même fichier résultat à la fin.
Certains tests cités dans le thread précédent ont accusé des écarts en code machine ou dans le binaire.
Citation : Si le soft est mal concu, le résultat sur des hardware différent peut donner un résultat different.
Sous-entendrais-tu qu'un soft parfait existe ?
Citation : L'utilisation d'un harware dedié evite ce problème a 100% car il n'y a qu'un driver possible !
Là, je pense que l'on se rejoint assez bien.
PS : As-tu pris le temps d'examiner le thread de départ et les documents mis en lien plus haut ?
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Pov Gabou

Un autre exemple tout con: si tu utilises du SIMD, genre SSE, tu vas pas avoir les memes resultats qu'avec la FPU normale, parce que meme si tu fais tous les calculs a la meme precision (32 ou 64 bits), en interne, c'est pas tout a fait pareil (la FPU normale sur x86 utilises 80 bits en interne).
Maintenant, pour le temps reel: si ca decroche pas, je vois pas pourquoi il pourrait y avoir un quelconque probleme. Et surtout, si probleme il y a, comment ca pourrait changer le caractere du son. Si tu changes certains bits aleatoirement sur ton fichier wav, ca va pas sonner plus rond, plus clair: ca va sonner degueu, avec des clics, etc... C'est pour ca que l'argument du sur mac, le mp3 sonne plus clair, meilleur, c'est 100 % auto suggestif pour moi.

Anonyme


Pov Gabou



Anonyme



saimonn

Je suis assez d'accord avec Ihbar.
Je pense qu'on est à peu près tous d'accord sur le fait qu'il est possible d'obtenir des résultats faux avec un hardware X ou Y. Mais pour moi la vraie question c'est : quelle est la probabilité que ça arrive en utilisation réelle (en dehors du labo justement) ? Posée autrement : est-ce que la fréquence des erreurs est propre à alterer le son (de façon pernicieuse) ?
Mais là on est toujours dans des suppositions. Et je me disais que vu qu'il est assez peu probable qu'on réussisse à démontrer logiquement une thèse ou l'autre, il serait peut-être interessant, en parallèle du débat, de mettre ça sur le terrain de l'expérience, pour éventuellement arriver à une démonstration empirique

Ca veut dire qu'il faudrait se mettre d'accord sur une série de calculs (incluant la contrainte temps-réel) et faire un programme qui effectue ces calculs et qui stocke les résultats. On lance tous ça chez nous et sur autant de machines qu'on peut, et on compare.
Je précise que je n'aurais pas le temps de m'y coller


Phil443

Citation : Phil, honnetement, je vois pas trop le lien entre les trucs dont on parle et le probleme present.
Et moi, franchement, je ne vois pas à quoi tu fais allusion...

Citation : Oui, il y a des differences entre differents hardware pour les calculs,
Nous sommes donc d'accord, ce qu'il nous manque, c'est de pouvoir quantifier cette différence et en apprécier les conséquences exactes.
Citation : Maintenant, pour le temps reel: si ca decroche pas,
Voilà : pour moi, un son qui coupe, c'est une affectation notoire de la qualité.
Maintenant, je soumets une pure hypothèse à votre opinion ou expérience :
Admettons qu'un bon hard réalise des calculs en temps réel sur un fichier donné. Tout se passe bien, évidemment, le son en sortie est nickel.
Et on renouvelle l'opération sur une bécane de supermarché. Ce dernier arrive à se démmerder à peu près mais pas tout à fait : il est un peu juste parce que la piètre qualité de ses composants lui fait perdre un peu de vitesse processing alors qu'il aurait besoin de toute sa puissance (une RAM "exotique" peut altérer la vitesse d'un proc, j'espère que l'on est d'accord là dessus sans démonstration...). Au résultat, plein de micro-coupures inaudibles à l'oreille, certes, mais repérables à l'examen du fichier résultant.
Pensez-vous que ce type d'aventure n'est pas de nature à modifier la perception qualitative du son en sortie (impression de dureté, ou de ramollissement, altération de la dynamique etc...).
L'expérience proposée par Saimonn serait intéressante à réaliser dans ce sens, effectivement, mais je n'aurais pas le temps de my coller non-plus, du moins en ce moment...
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Anonyme

Citation : Ce dernier arrive à se démmerder à peu près mais pas tout à fait : il est un peu juste parce que la piètre qualité de ses composants lui fait perdre un peu de vitesse processing alors qu'il aurait besoin de toute sa puissance (une RAM "exotique" peut altérer la vitesse d'un proc, j'espère que l'on est d'accord là dessus sans démonstration...). Au résultat, plein de micro-coupures inaudibles à l'oreille, certes, mais repérables à l'examen du fichier résultant.
Mais on a tellement de puissance a dispo que c'est negligeable. de plus, en imaginant que t'aies des microcoupures dans ce que tu entends (ce que je n'ai jamais vu, en general, quand ça decroche, c'est maousse, et pas elegant), ton fichier final n'en comportera aucune vu qu'il ne sera pas calculé en temps reel.
Il peut y avoir des corruptions de temps en temps, de etites erreurs d'arrondis, mais pas de consequences a un ralentissement brutal d'un systeme, si ce n'est le decrochage (et la encore une fois, c'ets spectaculaire, mais aucune machine en utilisation normale n'en soufre).

Phil443




Bon, ben on va dire que le fichier est récupéré par une autre bécane : DAT, autre ordi, workstation, balladeur MP3 (

NA !!!
Citation : en general, quand ça decroche, c'est maousse, et pas elegant
Ca, c'est bien vrai. Mais au même titre que l'on peut avoir des "chtics" numériques, ne peut-on pas avoir des micro-coupures, de l'ordre de un ou quelques échantillons, ce qui nous fait des trous de 1/44,100° de seconde, difficiles à entendre mais modifiant le signal puisque le rendant incomplet ?
As-tu des infos qui relateraient que les coupures numériques ne peuvent pas être inférieures en temps au seuil audible ?
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

saimonn

Citation : pour moi, un son qui coupe, c'est une affectation notoire de la qualité.
Je trouve ça un peu tiré par les cheveux et pas tellement dans le sens du débat. Un son qui coupe est inutilisable, donc on fait le necessaire pour corriger ça dans la config. Il n'y a pas moyen de le laisser passer, donc pas moyen d'être lésé par la qualité des composants à ce niveau là.
Les éventuels problèmes (subtils) qui nous intéressent peuvent survenir à partir du moment ou le son semble globalement bon.
Citation : une bécane de supermarché. Ce dernier arrive à se démmerder à peu près mais pas tout à fait : il est un peu juste parce que la piètre qualité de ses composants lui fait perdre un peu de vitesse processing alors qu'il aurait besoin de toute sa puissance
Hmmm c'est là-dessus que j'ai des doutes...
Si c'est un problème de vitesse, on retombe sur le point précédent : ça va s'entendre par des saccades ou des clicks.
Pour que ça passe inaperçu, il faudrait que ça ne fasse pas de "trous" dans le signal, et que ça modifie uniquement des bits de poids assez faible, et ce, de façon très fréquente (si ça arrive une fois pas minute, ça ne changera rien au son).
C'est pour ça que je parlais de probabilités tout à l'heure. J'imagine mal comment une telle altération "ciblée" peut se produire...
Il faut aussi penser que la notion de temps réel est relative dans le son, car le signal est bufferisé. Donc si une baisse de performances se produit, même régulièrement, le buffer assure la continuité du signal.

saimonn

Citation : de l'ordre de un ou quelques échantillons, ce qui nous fait des trous de 1/44,100° de seconde, difficiles à entendre mais modifiant le signal puisque le rendant incomplet ?
C'est justement ça le truc : Un trou de 1 seul échantillon est parfaitement audible par un petit clic. Si tu en as à répétition, c'est insupportable.
Donc pas moyen de le laisser passer...

Phil443

Citation : Je trouve ça un peu tiré par les cheveux et pas tellement dans le sens du débat.
Pas tant que ça : beaucoup d'entre nous ont déjà dû faire l'expérience du CD qui passe nickel dans le lecteur "Truc", qui coupe ou fait des chtics dans le lecteur "bidule", et qui refuse carrément de tourner sur le lecteur "machin".
Il s'agit bien d'un problème qualitatif de lecteur hardware, non ?
Citation : Pour que ça passe inaperçu, il faudrait que ça ne fasse pas de "trous" dans le signal, et que ça modifie uniquement des bits de poids assez faible, et ce, de façon très fréquente
Intéressant ce que tu dis là : sais-tu comment s'attribuent les erreurs dans un paquet de données : tombent-elles totalement par hasard ou certaines informations seraient-elles susceptibles d'être plus fragiles que d'autres et seraient corrompues plus facilement ?
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Phil443

Citation : C'est justement ça le truc : Un trou de 1 seul échantillon est parfaitement audible par un petit clic.
Exact, faudrait que je trouve un autre exemple...
Citation : Si tu en as à répétition, c'est insupportable.
Rassure-toi : un, c'est déjà de trop pour moi.

Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

saimonn

Citation : Pas tant que ça : beaucoup d'entre nous ont déjà dû faire l'expérience du CD qui passe nickel dans le lecteur "Truc", qui coupe ou fait des chtics dans le lecteur "bidule", et qui refuse carrément de tourner sur le lecteur "machin".
Je vois pas trop ce que tu veux dire...
Si le CD saute (et à fortiori s'il est refusé), tu n'en es plus à juger de la qualité du son. C'est pourri, donc tu changes de CD ou de lecteur.
Citation : Intéressant ce que tu dis là : sais-tu comment s'attribuent les erreurs dans un paquet de données : tombent-elles totalement par hasard ou certaines informations seraient-elles susceptibles d'être plus fragiles que d'autres et seraient corrompues plus facilement ?
Tout dépend de l'erreur en question. On peut imaginer une erreur qui ne ciblerait que certains bits, donc par exemple les bits de poids faible.
Mais bon, dans tous les cas, si tu as un bit faux par seconde, c'est pas que le matériel est un peu limite, c'est qu'il est carrément défaillant, et l'erreur en question se manifestera probablement dans d'autres calculs, rendant la machine inutilisable.
Je dois filer, a+ !

Pov Gabou

Si une baisse de puissance CPU arrive et que ca pose probleme pour le traitement temps reel, c'est un bug. Un rendu en temps reel different d'un rendu offline, c'est un bug. Et ca n'est pas propre aux softs sur PC: ca peut arriver aussi avec le hardware. Par exemple, quand j'avais achete mon Q (waldorf), l'OS au depart etait tres bugge, et dans certaines conditions, ca donnait des trucs bizarres. Le Hard n'a pas de protection special contre ca: comme c'est plus simple, et qu'une erreur coute plus cher, c'est vrai qu'il y a en moyenne moins de bugs. Mais ca renvoit plus a un probleme de fiabilite.
Des micro coupures qui donnt un son plus ou moins clair, j'ai jamais vu un quelconque test qui le laisserait passer. Les cd qui passent sur une platine ou une autre, si ce probleme apparaissait sur PC, que penses-tu qu'il arriverait ? Dans ce cas la, faut bien voir qu'un seul bit de changer peut rendre le tout inutilisable (typiquement, un bit foireux dans un header de fichier audio).

Phil443

A l'écoute, il y avait une différence, pas gigantesque certes, mais audible.
Alors d'où qu'c'est qu'ça vient b**del ?
Pov Gabou, tu rapportes ces problèmes à des bugs, mais où est la limite dans ce cas ?
En effet, aucun soft n'est parfait, et je pense que les imperfections sont plus sensibles sur certaines machines que d'autres, qu'on appelle ça bug ou autre chose n'ayant finalement que peu d'importance. Non ?
Et c'est là que la qualité du harware peut faire une différence, enfin c'est ce que j'ai cru constater...
Citation : Dans ce cas la, faut bien voir qu'un seul bit de changer peut rendre le tout inutilisable (typiquement, un bit foireux dans un header de fichier audio).
Ok, mais là, on est dans un cas extrême...
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Anonyme

Citation :
ce qui nous fait des trous de 1/44,100° de seconde, difficiles à entendre mais modifiant le signal puisque le rendant incomplet ?
C'est pas impossible, mais d'abord y'aurait aucune raison pour que le trou soit d'une durée "logique", vu que dans le cas d'un decrochage le systeme attend juste de raccrocher les wagons avant de renvoyer la sauce (et ça peut parfois prendre du temps). ça ne doit pas arriver en usage normal. Si ça arrive, augmenter la taille du buffer suffit en general a ecarter le probleme. Sinon c'est qu'on en demande trop (ça arrive moins souvent sur du hard ou la puissance est a l'echelle du traitement). Franchement les decrochages, c'est gros et crades, tu peux pas les rater.
Honnetment, je le redis, les erreurs dont on parle ne sont pas significatives en audio. Elles sont 1)tres rares, 2)insignifiante sur le signal
L'exemple de l'header de cd est tres bon: tu sais qe si tu rates un bit, le cdest inutilisable. pareil dans le cadre d'un soft, si un mauvais bit est affecté, tu peux aller au plantage bien violent. pourtant, ça n'arrive jamais.

Anonyme


Phil443

Citation : Les cds qui sautent, c'est souvent un probleme d'optique plutot que dedonnées corrompues.
Euh ? J'ai un lecteur de salon qui se démmerde comme un manche avec certains CD gravés (c'est pas une histoire de protection...) mais qui est nickel avec les prods du commerce ou les CD gravés en vitesse lente...
Citation : et d'ailleurs c'est souvent les lecteurs les moins exigeants (ou a l'optique la plus mal réglée) qui passent au dessus de certains defauts du support.
Ca arrive, ça, c'est vrai.

Sinon, j'ai eu une carte son qui a flanché y'a pas longtemps. Au début, ça m'a fait planter certains softs (traîtement de textes, navigateur internet...), mais curieusement les logiciels orientés son tournaient tous sans problème !
Puis ça s'est aggravé, l'ordi a fini par refuser de booter, point.
Ce n'est qu'après que j'ai constaté que certains fichiers -sauvegardés alors que ma carte commençait à flancher- ne chargeaient plus, plantaient carrément le soft, ou comportaient des erreurs (style un dessin où les intersections de droites n'étaient plus respectées etc...). Troublant non ?
Citation : Honnetment, je le redis, les erreurs dont on parle ne sont pas significatives en audio. Elles sont 1)tres rares, 2)insignifiante sur le signal
C'est là que subsiste un doute dans mon pauvre esprit torturé, aaargh !
Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Phil443

Citation : mais si tu changes un gain sur une piste de 0.01 db, ton fichier a la sortie est completement different(ou presque),
Nein, achtung : toutes les opérations étaient strictement identiques, des informaticiens de haut niveau se sont occupés des moindres détails pour respecter ce point capital : garanti.
(J'aime bien le "ou presque"...

Malgré tous les progrès scientifiques, force est d'admettre que le pet reste quelque chose qui nous échappe...

Anonyme


Citation :
Nein, achtung : toutes les opérations étaient strictement identiques, des informaticiens de haut niveau se sont occupés des moindres détails pour respecter ce point capital : garanti.
ce que je voulais dire c'est qu'un changement apeine audible modifit le fichier completement, alors deux fichiers presque semblables, y'a de bonnes chances qu'ils sonnent pareils, malgréles quelques bits de difference.
Citation : Ce n'est qu'après que j'ai constaté que certains fichiers -sauvegardés alors que ma carte commençait à flancher- ne chargeaient plus, plantaient carrément le soft, ou comportaient des erreurs (style un dessin où les intersections de droites n'étaient plus respectées etc...). Troublant non ?
hey moi il m'arrive ça je fais venir un exorciste!! le dessin (s'il s'agit d'un format bitmap ou d'un de ses cousin compressé) dont les intersections se deplacent suite a des données corrompues, c'est un peu comme si tu jetais un tas de briques en l'air et qu'elles retombaient en forme de maison...

ihbar

Phil, peux-tu nous décrire plus précisement la manip du post precedent ?
Citation : Hélas non Silicon, car là où je bossais lors des tests dont je parle, il y avait des informaticiens de haut niveau. Avec eux, on s'est livrés à une analyse qualitative des données informatiques après traîtement, et on ne s'est pas contenté d'un simple checksum : passage au crible sous MasterFile (les connaisseurs verront tout de suite de quoi je parle), avec analyse comparative en language machine (hexadécimal) et relevé des codes binaires, c'est imparable. Il y avait des différences trop importantes pour les laisser au rang de "négligeables".
Si les comparaisons ont été faites en utilisant les cartes audio des machines, ce n'est pas la peine de comparer les résultats en hexa : la tolèrance des "bons" composants électroniques tournant dans les 1%, la simple numérisation du signal entraine donc une erreur sur plusieurs bits !

ihbar

La première est interessante pour ce topic, car elle décrit une etude de fiabilité sur un système informatique. Cependant, elle ne nous aide pas énormement : Le sujet est un système de controle critique pour un avion. Forcément, dans ce cas on a besoin du risque 0. On ne peut pas demander la même fiabilité pour un outil de traitement de son. (à moins d'être millionaire et de doubler tout le cablage du studio

D'autre part, l'exemple de la table 5 montre que le défaut analysé conduit à un plantage/ redémarrage du calculateur ("this will lead to bus exception being raised,followed by orderly shutdown of affected processor."; "Processors remaining in sync. will force orderly shutdown of affected processor"; ....) Donc si on applique cette analyse à notre cas, on aura pour le defaut étudié un plantage du soft et pas une corruption de l'audio.
La deuxieme et la troisième sont moins intéressantes : Elle traitent de la répartition software/hardware flexible de systemes électroniques.
-Deuxième doc : Une modélisation unifiée des traitements à effectuer dans un ensemble hard+soft afin de pouvoir l'implementer avec plus ou moins de parties softwares et hardwares. Intéressant pour la description d'un péripherique de mastering HW, mais pas trop applicable à un PC complet.
- La troisème :
Citation : Les systèmes intégrés sur puce (“Systems-on-Chip”) reconfigurables offrent la possibilité d’accélérer des applications en combinant du logiciel avec des accélérateurs spécifiques implémentés en matériel.
Cette docs est sur le même thème que le précedente, mais traite de la facon dont les accélérateurs matériels peuvent profiter d'un Os virtuel pour avoir acces à des ressources similaires à celle utilisée dans les process software.La quatrième doc est intéressante, mais quelque peu philosophique. (Je conseille de regarder les ppt sur le site indiqué dans la doc, c'est plus digeste). Cette présentation met en évidence la dualité software/hardware, la notion plutot floue de limite entre HW et SW, et la difficultée d'avoir une interface bien definie, structurée, assurant un bon fonctionnement de l'ensemble. Mais cela reste très philosophique et ne va pas nous aider énormement. Au moins, cela confirme qu'on peut débattre longuement de la question !
Finalement, je n'ai pas trouvé de partie très enrichissante pour ce débat, mais j'ai peut-etre raté un chapitre. Si quelqu'un voit un point intéressant, ce serait sympa de préciser la page / chapitre.
J'ai quand même changé d'avis : finalement, les sytèmes dédiés en HW (le cas du calculateur d'avion ou un processeur de mastering) sont aussi affectés par un problème de fiabilité de calcul. Donc la difficultée sera d'évaluer l'écart de fiabilité entre le processeur hardware dedié et le PC.

- < Liste des sujets
- Charte