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

[Pc Fan]

Un disque dur peut stocker des données en bloc, de façon statique et les restituer de la même façon. Exemple : un fichier audio qu'on copie d'un disque vers un autre.

Mais ce même fichier peut être lu (et éventuellement traité) en temps réel, à partir du disque dur, qui à ce moment-là fonctionne en streaming. Il doit débiter en permanence suffisamment d'informations pour faire face à la demande correspondant au nombre de pistes, à la résolution et à la fréquence d'échantillonnage.
C'est pour cette raison que le DMA existe, entre autres.

Ce n'est pas du streaming c'est du burst (mode rafale).
C'est d'ailleurs aussi utilie pour la copie de fichier que pour la lecture temps réel (voir plus).
DMA signifie Direct Memory Access. Les informations passent du DD à la mémoire sans transiter par le CPU. Le CPU n'a pas a s'en ocucper il donne juste les ordres et va récupérer les données.
Il y a 3 modes DMA. Normal, multiword et burst.
Normal transfère une donnée par commande, multiword un nombre fixe de données par commandes.Il faudra que je vérifies mais je pense que c'est ce mode qui est utilisé en Audio/vidéo.
Le nom mode rafale est image bien ce qu'il se passe.
Tu appuie sur la gachette, ca part à intervalle régulier, jusqu'à ce que tu relaches la gachette à ce moment la commande est finie.
Il n'y a absolument rien d'isochrone là-dedans, ce n'est absolument pas du streaming, tu ne peux pas décider de la vitesse de transmission c'est celle du bus PCI.
Comme "particularité" par rapport à une mitrallette le receveur indique qu'il a bien reçu chaque donnée en envoyant un signal Stobe ce qui permet à l'emmeteur d'envoyer la suivante.Tout ça doit rentrer dans des timings précis, si le strobe tarde trop cela provoque une erreur.
Et 2eme particularité les 2, emmetteurs et récepteurs, peuvent arréter le transfert, dans le cas d'une écriture par exemple, le DD peut arrêter la commande burst parce que son cache est plein donc il n'arrive plus à écrire les données ou le controleur peut stopper cette commande parce que la fin du fichier est atteinte. Le mode burst se ternmine alors et dans le cas d'une interruption par le DD, c'est le controleur UDMA qui lance une nouvelle écriture en burst, une nouvelle commande.

Que ce soit un fichier de tableur (contrainte l'utilisateur qui attend la fin du chargement de sa feuille par exemple) ou un fichier audio en temps réel (j'espère d'ailleurs que tu m'enverras une copie de tes dernières productions, même en streaming ), c'est exactement le même processus.

[Michel Geiss]

Un disque dur peut stocker des données en bloc, de façon statique et les restituer de la même façon. Exemple : un fichier audio qu'on copie d'un disque vers un autre.

Mais ce même fichier peut être lu (et éventuellement traité) en temps réel, à partir du disque dur, qui à ce moment-là fonctionne en streaming. Il doit débiter en permanence suffisamment d'informations pour faire face à la demande correspondant au nombre de pistes, à la résolution et à la fréquence d'échantillonnage.
C'est pour cette raison que le DMA existe, entre autres.

Ce n'est pas du streaming c'est du burst (mode rafale).

On n'a peut-être pas la même définition du streaming...
Pour moi, le mot streaming, souvent utilisé en diffusion web, s'utilise aussi dans toutes les applications DTD, où on débite de l'audio en continu, avec un ou des buffers intermédiaires.
S'il faut que je cite un exemple, voici un petit extrait de texte :
Now suppose you have an activity known as "streaming" going on which is pulling lots of data from the drive in real time while the application doing the streaming is simultaneously attempting to process the data as it arrives.
Et puis il y a aussi les définitions de l'ASIO et de l'EASI :
Audio Stream Input Output
Enhanced Audio Streaming Interface

[Pc Fan]

On n'a peut-être pas la même définition du streaming...
Pour moi, le mot streaming, souvent utilisé en diffusion web, s'utilise aussi dans toutes les applications DTD, où on débite de l'audio en continu, avec un ou des buffers intermédiaires.
S'il faut que je cite un exemple, voici un petit extrait de texte :
Now suppose you have an activity known as "streaming" going on which is pulling lots of data from the drive in real time while the application doing the streaming is simultaneously attempting to process the data as it arrives.
Et puis il y a aussi les définitions de l'ASIO et de l'EASI :
Audio Stream Input Output
Enhanced Audio Streaming Interface

C'est un peu ça.
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.

[Michel Geiss]

Juste pour revenir un peu sur l'utilisation éventuelle de disques FireWire en DTD, il me semble quand même que c'est loin d'être idéal.
Deux modes peuvent être utilisés pour la transmission des données : le mode isochrone et le mode asynchrone.
En mode isochrone, on envoie beaucoup de données, avec un débit maximum, mais sans possibilité de correction d'erreurs ni de renvoi d'informations mal transmises.
En mode asynchrone, les corrections d'erreurs sont possibles, mais le traffic est bien plus lent.
L'UDMA n'a pas ces inconvénients. Ma conclusion : entre un disque IDE interne et le même monté dans un boîtier FireWire, y compris avec un chip Oxford 911 (visiblement ce qu'il y a de mieux aujourd'hui), en faveur de la version FireWire, je ne vois que l'avantage du disque externe. D'autres avis ?

[Michel Geiss]

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

[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.

[Michel Geiss]

En cherchant des infos sur les disques FireWire, je suis tombé sur un site qui m'a rendu perplexe. Avec un disque identique, visiblement, les vitesses de transfert FireWire sont très différentes, en fonction du type de machine (et de processeur).
Résultats du test : en "Sustained Read" (lecture continue) le G4 533 Bi-Processeur 35.8 MB/s, le Sawtooth G4 500 34.5 MB/s, mais le Powerbook Titanium plafonne à 22.9 MB/s.
En "Sustained Write" (écriture continue) le G4 533 Bi-Processeur 32.9 MB/s, le Sawtooth G4 500 22.1 MB/s, et le Powerbook Titanium 16.4 MB/s seulement ! Du simple au double ! Et la différence est certainement encore bien plus considérable avec les Bi-Processeurs 1 GHz.
Par ailleurs, ce qui est plus inquiétant, c'est qu'en matière de drives, il semble que les performances réelles ne soient pas forcément celles indiquées par le constructeur. Il peut visiblement y avoir des rapports du simple au double en vitesse d'écriture continue sur un modèle identique ! Donc... normalement, quand on achète un drive (ce que je vais faire dans les heures qui viennent), il est conseillé de le tester immédiatement (genre Express Pro Tools "Benchmark Volume"), et d'envisager son retour au magasin en cas de problème.

[Michel Geiss]

Autre info qui me semble intéressante. Dans le numéro d'août de SOS, un test est publié sur les performances de disques FireWire en audio. Les tests ont été faits sur Logic et DP3.
On se rend compte qu'entre les 2 softs, la gestion du débit audio est différente. DP3 a tendance à pénaliser les sessions avec de nombreux fichiers audio, alors que Logic semble moins bien optimalisé pour les fichiers longs et ininterrompus. Résultat : un nombre de pistes disponibles en rapport avec le contenu des sessions.
A préciser que les tests en question ont été réalisés sur 2 Macs, un iMac 800 et un iBook 600.
Je constate au passage qu'on a utilisé le FireWire sur des machines qui n'ont pas d'autre option pour des disques supplémentaires. Par ailleurs, les tests ne montrent pas d'avantage significatif de la solution FireWire sur le disque interne, pourtant pas très performant.

[burns]

Au fait le jour ou vous trouvez le bon disque dur qui fait vendre 25 million d'albums, j'achete la cargaison

Burns

(Promis, à Noël je commande des oreilles pour entendre les différences entre SCSI,IDE,FW,RAID etc)

[jeff parent]

Salut à tous,

Parrallèlement à ce débat, si j'enregistre toutes mes pistes sur des disques durs SCSI (2x18 Go pour un projet 56 pistes) mais que je les stocke après coup sur un disque dur Ide ou FW, je ne risque rien en faisant des allers-retours si j'en crois la discussion. Les fichiers ne sont apparement altérables/affectés qu'à la lecture ?

En allant un peu plus loin, je peux travailler sur mon gros disque IDE tout le temps de l'édition (un percussioniste qui parle à son voisin tout en jouant du triangle !! imaginons ce que je vais découvrir sur 56 pistes:=)

Par la suite, dès que le mixage ou les reports ont lieu, je repasse en SCSI

Caisse zan Panccez ?????????????????