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

[Pc Fan]

Une application peut faire du streaming mais le DD lui n'en fait pas.
l'ASIO et le EASI sont effectivement des protocoles de streaming, de flux pour parler français, tu ouvres un canal ASIO (ou EASY) et tu peux déverser en continu des données isochrones dedans.

Excellente contribution ! C'est vrai qu'il est plus approprié de parler de streaming (je dirais plutôt "diffusion en flux continu" que flux tout court) pour un mode d'utilisation des données audio. Dans ce cas, le disque dur est un maillon de la chaîne (quelquefois le maillon faible )
Mais pour moi, en mode DMA, on fait du streaming. Question de définition

C'est vrai en plus que l'appli fait du streming mais pas le DD.
Plus précisement entre l'appli et la carte son (+l'éventuel réseau audio-numérique derrière) les communications sont isochrones c'est du streaming.
(c'est valable pour la vidéo aussi).
Entre l'appli et le DD, les communications se font sur un bus asynchrone ce n'est pas du streming.

Ce n'est pas histoire d'ergoter sur le vocabulaire, c'est que la nature et les propriétés de ces modes de communications sont fondamentalement différents.

L'ASIO, l'AES, l'ADAT sont des protocoles de streaming, des vrais isochrones.
Ce que l'on cherche avec un tel protocole c'est que le numérique se comporte "comme" de l'analogique:
En temps réel les données pouvant arriver à n'importe quel moment. Pour faire cela on ouvre un canal de transmission synchrone (on envoit en permanence une horloge) et l'on envoie les données dessus quand elles se présentent.
Cela a plusieurs conséquences. Comme tu l'a dit il est impossible de retransmettre une donnée éronnée. Donc il n'y a aucun accusé de réception de la destination et les les signaux de controle s'appliquent uniquement à la partie synchrone du canal pas aux données.
Il est impossible de multiplexer les canaux plusieurs données pouvant arrivés au même moment. (A cet égard la stéréo de l'AES est "limite").
Une autre implication est qu'étant isochrone tout le monde a le même temps et que les réseaux sont très difficiles à synchroniser. C'est pour cela que l'on emploie des "horloges universelles" comme la WorldClock.
La perte de données informatiques n'est pas génante en tant que telle sur un tel canal. Cela revient toujours a un signal analogique (que ce soit la voix de Florent Pagny ou la température d'un four à pizza), Quand on perd un bit ce qui compte c'est quelle dégradation cela va amener au signal analogique numérisé. Ces liaisons s'étudient exactement comme des liaisons analogiques en Bande Passante, THD, phase et Jitter (au lieu de pleurage et scintillement).
La bufferisation existe parce qu'un ordianteur est actuellement incapable de traiter les données plus rapidement que le "pas de l'horloge".Mais c'est une bufferisation synchrone (une latence constante).

Dans le cas d'un transfert sur le DD c'est toujours un transfert asynchrone. Le problème est là de recopier un paquet de données à travers une liaison le plus rapidement possible. Si on arrive à le faire avec un débit moyen supérieur au débit du flux audio isochrone on peut faire du DtD.
Mais cela reste une liaison asynchrone. A savoir le controleur peut initier une commande à n'importe quel moment mais tout ce qui va se passer lors de la commande obéi à des délais et des actions dont les timings sont entièrement décris par le protocole.
Le moment où les données sont transférés ne dépend pas d'une horloge donc en cas d'erreur les données peuvent être renvoyés ou dans le cas du burst la transmission interrompue et reprise une donnée avant. Il peut dans ces conditions avoir des dialogues controlant le processus (donnée disponible en sortie, donnée reçue, donnée valide etc...). Dans le cas du mode burst si une erruer intervient la commande est stoppé puis reprise à la dernière donnée valide.
Ce qui fait que le taux d'erreur de ce type de liaison est proche de zéro (de l'ordre de 10^-15/-20, 1 sur un milliard de milliard).
Comme ce type de liaison n'est pas dépendante du temps on peut bouncer plus vite que le temps réel chose impossible à travers un asio par exemple.
De même les réseaux sont "faciles" à faire. il n'y a pas besoin d'une horloge globale comme le worldclok.
La bufferisation peut-être énorme et permet de traiter les données quand on a le temps de le faire contrairement à la bufferisation isochrone qui ne permet que de reporter , mettre un délai fixe sur les données.
On peut faire tous les multiplexaages que l'on veut, là encore il suffit que la vitesse de traitement soit suffisante. C'est aussi ce qui explique que le nombre de canaux est limité de façon absolu sur une carte Asio et dépend uniquement des limites de performances de l'ordinateur dans les cas du nombre de pistes sur DD. (Les logiciels imposent certaines limites parfois genre Nuendo 200 pistes).


Voilà pourquoi aussi je dis que de l'isochrone sur du Firewire, entièrement asynchrone, c'est loin d'être gagné.

Par contre tu as raison le Firewire isochrone est plus rapide que le firewire asynchrone, comme tu l'a expliqué parce que les données en erreurs ne sont pas réémises. Je pense que ce n'est pas la raison de l'utilisation de l'isochrone seulement un avantage induit, le but est plutôt l'isochronisme afin de piloter un ampli Hi-fi ou une TV avec des entrées Firewire ou d'interfacer une liaison isochrone comme l'ASIO.