IDE / SCSI / Firewire, Le son n'est pas le même?!! Options

[Francois Déchery]

Mister Celmo ecrivait, dans un autre sujet:

Tiens pour attaquer dans le gras du sujet, apres avoir il y a quelques annees, mis un certain souk en emettant l'"idee" que les logiciels eux memes n'avaient pas tous le meme son( helas et heureusement a la fois), un sujet interessant est a lancer: C'est la difference dans la qualite du son en fonction du disue dur utilisé. Eh oui, Un de nos camarades (canadien pour ne pas le citer) avait remarqué qu'un nouveau disque installe n'avait pas le meme son que celui d'origine. il avait simplement change son disque et c'en est reste la, je crois. mais depuis ce moment, j'ai fait quelques tests, et le resultat est qu'il est evident que le systeme de disques durs utilisé est tres responsable de la qualite du son. par exemple l'IDE (ou le firewire qui en decoule) est cause de degradations en fonction du nombre de pistes utilise. En revanche, le SCSI (cette chierie de skuzzi) , s'il est bien configure, respecte plus facilement le timbre original. Ca vous en bouche pas un coin ca?
helas, a qualite equivalente, le SCSI est toujours beaucoup plus cher. et plus chiatique.
En bref, ce que je voulais aussi dire par la, c'est que les systemes respectant au maximum le son tel qu'il a ete enregistre, et dans n'importe quelles conditions coute toujours tres cher, et que la regle qui fait que pour avoir dix pour cent de mieux on paie souvent dix fois plus est toujours valable.
Bon, le debat est lancé, si ca interesse quelqu'un..

En voila un loup interressant

[Michel Geiss]

[QUOTE]48 pistes en 16bits 44.1Khz, représente un débit d'environ 4Mo/s, comparé aux 133Mo/s de la dernière norme Ata, c'est ridicule.

Première chose, puisqu'ici, on est sur Macmusic, on parle de l'ATA disponible sur les G4, et pas sur les PCs. Petite précision (je me répète) : il s'agit d'ATA-66 et pas d'ATA-133. Par ailleurs, le débit spécifié par la norme est seulement théorique. Le débit continu qu'on peut obtenir d'un ATA-66 est certainement plus proche de 20 Mo/s que de 66 Mo/s.
Par ailleurs, les fameux 4 Mo/s sont en réalité des mouvements électriques de 34 MBits/s. En effet, un ordinateur, c’est de l’électronique avant d’être de l’informatique. Dans notre contexte de recherche de causes d’erreurs, il me semble donc plus approprié de parler de mouvements électriques que de bytes. En ATA-66, puisqu’on est dans ce cas, les impulsions à transmettre font seulement 30 nanosecondes de largeur ! On voit bien la précision nécessaire pour les capturer au vol (et l’incidence du bruit électrique récupéré par les câbles).
Autre chose : l'accélération des transferts sur les disques IDE a récemment conduit les fabricants à remplacer la nappe précédente à 40 conducteurs par une nappe à 80 conducteurs, les 40 supplémentaires servant à intercaler des masses entre les fils actifs. Ceci pour diminuer au maximum les interférences. Celles-ci ne sont pas pour autant supprimées en totalité. La meilleure preuve, c'est qu'on a estimé nécessaire de rajouter un système de correction d'erreurs.

[QUOTE]Si transmettre ces 4Mo/s sur une nappe Ide n'est pas évident, je me demande comment une chaine Ata peut fonctionner, et même comment l'ordinateur peut il rester stable puisque dans les Os moderne, une partie du contenu de la mémoire vive fait régulièrement des aller-retours dans les fichiers de Swap sur les disques durs.

Qui peut affirmer que le fonctionnement d'un ordinateur est parfaitement stable ? La corruption de données ou de fichiers, ça existe ! Et de toute façon, ça me semble assez difficile de comparer les accès disques du fonctionnement classique d'un ordinateur, avec le streaming intense d'un système DTD en pleine activité (et qui plus est sur un disque certainement fragmenté).

[QUOTE]Je me demande même si le fonctionnement en streaming modifie quoique ce soit à la facon dont l'intégrité des donnée est préservée par rapport à un fonctionnement "normal".

En mode IDE standard, les transferts de données entre disque et CPU utilisent un protocole qu’on appelle Programmed Input/Output. Dans ce mode, on impose au CPU d’être très impliqué dans le processus, pour échanger des données entre la RAM et le drive. Le CPU est donc condamné à aller chercher des données et à les déverser dans la mémoire, en permanence et n'importe quand. De plus, le temps nécessaire pour mettre les données dans le cache, de lire chaque bloc de 8 bits avec le CPU, de le retourner vers le cache et de l’envoyer à la bonne adresse ralentit sérieusement les transferts.
En informatique usuelle, l’affaire se passe plutôt bien, puisque le CPU n’a pas grand chose d’autre à faire pendant ces transferts. Mais ça se gâte sérieusement quand on demande à notre machine de tranférer en continu des quantités considérables de données, et de les traiter (plug-ins, sampleurs, etc...). Le CPU est alors obligé de s’occuper simultanément du transfert de données et de leur traitement dans l’application audio elle-même, qui, du coup, se voit amputée d’une part importante de possibilités de processing audio.
Je vois là une autre possibilité de modifications de l’audio, par surcharge du processeur. En effet, il est tout à fait possible que certains algorithmes de logiciels audio incluent une détection de surcharge CPU et produisent malgré tout un son écoutable, mais au prix de certains compromis de qualité.
Un remède possible le DMA (Direct Memory Access), où la responsabilité du transfert de données est sous-traitée à des processus intelligents, qui soulagent substantiellement le processeur.

[QUOTE]Dans le cas ou il y aurait un réel problème d'intégrité des données, ca voudrait dire qu'une station audio fonctionnant avec des HD Udma aurait un meilleur son sur un Pc avec Windows !!??
Whouahh !! vous imaginez !!

Whouahh ??
Certes, certes...
Mais même si j'aime travailler avec mon G4, jje ne crois pas qu'on soit ici pour prêcher la supériorité d'une marque, mais plutôt pour chercher des raisons à un phénomène constaté par quelqu'un qui a entendu des différences.

[QUOTE]Partons du principe que les systèmes de correction d'erreur et de controle de parité font correctement leur travail, sinon on ne s'en sort plus.

Ignorer la réalité ne l'empêche pas d'exister... Partir du principe que les systèmes de correction d'erreur font correctement leur travail, c'est ignorer qu'il n'y a peut-être pas de correction ! Si j'ai parlé du lien entre l'Ultra DMA et la correction d'erreurs CRC qui lui est associé, c'est parceque lorsque ce mode n'est pas implémenté dans une machine, la correction d'erreurs en question ne peut pas se faire.

[QUOTE]Où peuvent eventuellement se créer les erreurs ? A mon avis, je ne vois qu'un endroit : le couple Bus Pci -> Carte audio et encore, je serait très très étonné qu'il n'y ait pas de vérification, de la même manière qu'il y a un contrôle de parité dans un simple signal Sp/dif

Rappelons que la question posée à l’origine de cette discussion n’est pas de chercher des dysfonctionnements dans le couple Bus PCI/carte audio, mais de se demander pourquoi l’utilisation de 2 types de transferts, IDE ou SCSI, pourrait produire des différences de qualité audio.

[QUOTE]Et bien justement, un 0 à la place d'un 1 dans un échantillon audio modifiera complètement sa valeur et aura de grande chance de provoquer un click, à moins que cette erreur se produise sur les bits de poids les plus faible. Au final, il y a quand même peu de chances que nous n'entendions pas l'erreur.

Une affirmation un peu rapide ! L’un des phénomènes perturbateurs en audio numérique s’appelle le jitter. Celui-ci produit des erreurs dans l’échantillonnage des bits, donc dans l’exactitude des informations. Ce n’est pas pour autant qu’on peut distinctement entendre l’effet produit (diminution du rapport signal/bruit, rétrécissement de l’image stéréo…). Et dans mon hypothèse d’erreurs de streaming, on est dans ce type de conditions.