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

[Michel Geiss]

Michel tu nous fais froid dans le bas du dos Je suis ravis, va falloir que je refasse tout le mix !

Je confirme l'existence de problèmes éventuels de jitter dans une liaison Firewire. Mais sorry... mon post n'était pas complètement en rapport avec le sujet des drives.
Le jitter concerne comme on le sait l'arrivée d'informations au mauvais moment, mais essentiellement par rapport à une horloge.
Ce qui veut dire qu'en AES/EBU, S/PDIF, ADAT ou autre mode de transmission d'audio numérique, en FireWire l'audio risque fort d'être affecté sans précautions particulières au niveau du protocole de communication.
Mais en ce qui concerne le flux d'informations d'un disque dur, et pour rester dans le sujet des différences possibles entre types de disques (ce qui était quand même le sujet d'origine), le problème ne se pose pas de la même façon. Les données sont transmises par paquets, bufferisées, et si le débit est suffisant, il ne devrait pas y avoir de problème dans l'audio.
Il serait malgré tout intéressant de connaître la charge CPU pour la gestion d'un drive FireWire par rapport à celle d'un IDE ou d'un SCSI.

En conclusion, ça m'étonnerait que tu doive refaire ton mix

[Pc Fan]

Bonjour

Un Troll

Ide vs SCSI. Je ne vais pas pouvoir m'empécher de répondre.

Je reprends en vrac, je ne cite pas toujours les auteurs.

Michel Geiss  le: Aug 8 2002, 12:21

Je confirme l'existence de problèmes éventuels de jitter dans une liaison Firewire. Mais sorry... mon post n'était pas complètement en rapport avec le sujet des drives.
Le jitter concerne comme on le sait l'arrivée d'informations au mauvais moment, mais essentiellement par rapport à une horloge.

Bonjour
Il y a 2 types différents de DD qui peuvent se connecter sur du firewire. Les DD classiques fiables "à 100%" et les "DD" AV/C Audio/Video isochrone (temps réel en gros) qui eux du fait de leur caractéristique isochrone sont plus sujets aux erreurs. Quelques infos ici:
http://www.1394ta.com/Download/Technology/...HDD1.0Final.pdf
Peut-être que Digi fait une norme dérivée de celle-ci mais adapté à l'audio pro histoire de vérouiller la tour d'ivoire comme dit le petit martien.

Les DD Firewire actuels sont les mêmes que ceux des comptables donc vous pouvez y aller tranquille, ils sont parfaitement valables en support de sauvegarde.
Les problèmes de jitter que peuvent rencontrer les interfaces audio, tables de mix, etc... ne viennent pas de là simplement ce n'est pas toujours évident de faire de l'isochrone sur de l'asynchrone.

celmo  le Aug 6 2002, 12:10
Ceci confirme ce que nos oreilles avaient ressenti avant nous.
Bon, on peut supposer que ca va s'arranger dans l'avenir.

De l'isochrone sur de l'asynchrone c'est vraiment mal parti. Ca sera toujours un platre sur une jambe de bois. Il faut attendre que la norme évolue, comme rien n'est intégré au 1394b, ce sera au minimum avec le 1394c. Entretemps des techniciens géniaux auront troucés des bisouilles pour améliorer la situation mais la nature des transmissions reste foncdamentalement différente.

wfplb Ecrit le: Jul 27 2002, 16:35
Le sampling jitter (maintenant qu'on peut préciser ) serait donc bien la source de tous nos maux

Le Sampling Jitter est une erreur induite par l'horloge des convertisseurs. Au lieu d'échantilloner tous les 1/44100s , c'est un coup un peu plus un coup un peu moins.

Michel Geiss  le: Jul 26 2002, 09:32  
The Power Mac G4 computer has an Ultra DMA/66 (ATA-5) interface and an ATA-3 interface for internal mass storage and removable media devices. (../..)
The enclosure has data and power connectors for the internal ATAPI DVD-ROM or DVD-RAM drive and an internal ATAPI Zip drive. Those drives are connected to the ATA-3 interface.

J'en déduis que le second bus est surtout destiné aux sauvegardes.

Je constate aussi qu'Apple mentionne sur le port Ultra DMA/66 la compatibilité PIO Mode 4. Je me demande donc s'il faut en déduire que ce mode peut être utilisé actuellement, et dans quelles conditions.

Qu'il y ai du ATA-3 pour les lecteurs de CD/DVD/Zip est "normal", enfin pas génant.
Pour la compatibilité PIO4 c'est tout à fait normal qu'il soit présent, cela fait partie de la norme ATA5 donc sans compatibilité PIO4 pas d'ATA5.
Cela signifie que les softs (y compris l'OS) peuvent envoyer au choix des commandes PIO ou des commande DMA. C'est surtout pour une histoire de compatibilité des vieux softs et vieux DD, donc le mode DMA est utilisé par tous les softs qui ne demandent pas expréssement du PIO.

Michel Geiss  le:Jul 25 2002, 08:33
Sur Windows, il a été depuis un moment fortement recommandé d'activer le mode DMA pour faire de l'audio. On dit très peu de choses à ce sujet sur le Mac, et donc on peut admettre qu'on est d'office en DMA.

Oui sur Windows le mode DMA était désactivable uniquement pour des histoires de compatibilité avec de vieux DD. Encore une fois cela n'empèchait pas un vieux soft d'envoyer des commandes PIO (généralement les softs ne pilotent pas directement les DD, ils font appel a des fonctions du système d'exploitation qui elles utilises le mode DMA ou PIO de façon transparente).

phhelard le: Jul 24 2002, 10:17  
un PC sous Windows 2000 Pro.
Le contrôleur qui gère les ports IDE et la carte RAID est un ... SCSI Adaptec 2930 CU PCI. La carte RAID est classée dans : "périphériques SCSI et RAID".
Ce qui, à mon avis, prouve qu'il y a de moins en moins de différences entre IDE et SCSI. D'ailleurs, c'est plutôt la norme IDE qui a repris les avantages du SCSI à son compte.

Le SCSI doit être l'un des standards les plus copiés.
Pourquoi réinventer la roue?
Donc actuellement dans l'UDMA on trouve TOUT ce qui existe dans le SCSI (en ce qui concerne les DD/CD/DVD le SCSI est plus flexible) à l'exception de la réorganisation des files d'attentes, ce qui sert uniquement pour l'utilisation intensive des bases de données.
Par contre le protocole RAID n'est pas un protocole ATA c'est un protocole RAID et le RAID vient du SCSI.
Il a été ensuite adapté pour supporter des DD IDE.

Stef44 Ecrit le: Jul 23 2002, 23:35  
es disques Scsi sont effectivement bien souvent basés sur la même mécanique que les disque durs IDE, mais les plateaux sont utilisés sur une plus faible surface. Ah vi, on pert en capacité, mais la chute de débit lorsqu'on se rapproche du centre est moins sensible puisqu'on s'arrête plus tôt. Le débit reste plus constant qu'une mécanique utilisée sur un disque IDE

C'est surtout une histoire de marché. Les DD SCSI dont le marché haut de gamme. En partie parce que du SCSI tu en mets jusqu'à 16 dans un serveur, en partie pour une histoire d'image (comme les Mac , bon je m'arrête là avec les sujets qui fachent ).
Donc effectivement les dernières technologies ne se retrouvent que sur les DD SCSI. En SCSI on trouve du 15000tr/min à 4,5ms de temps d'accès, sur du IDE c'est 7200tr/min avec 7ms de temps d'accès.
Les petits plateaux sont dus aux vitesses élevées (contraintes mécaniques) et à la recherche de temps d'accès faible. Actuellement d'ailleurs c'est un peu de l'arnaque car la densité de données ne doit pas être tellement différente (pour ne pas dire égale) entre un SCSI 15000 mais 36Go et un UDMA 72000 mais 120Go.

phhelard Ecrit le: Jul 22 2002, 20:58  
Les nappes utilisées en ATA 100 ou 133 sont différentes des nappes IDE ordinaires : elles ont leurs conducteurs doublés chacun par un cable de "masse" qui permet d'éviter les perturbations électro-magnétiques. Elles sont plus dures, et plus chères, et les connecteurs sont dédiés (carte-mère - master - slave)

Exactement plus on monte en fréquence plus les signaux sont "affaiblis" et plus les rayonnement sont importants. Le blindage des cables à partir d'une certaine fréquence est tout à fait normal.

[Pc Fan]

Première chose, puisqu'ici, on est sur Macmusic, on parle de l'ATA disponible sur les G4, et pas sur les PCs.

Cela ne change pas grand chose les normes ATA sont un standard.
http://www.t13.org/project/d1410r3a.pdf
Les 496 pages de normes.

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

C'est en effet un temps court mais pas critique pour l'électronique moderne. La norme PCI en 66Mhz impose des contraintes non pas de 30ms mais de 3 ms. Là ça devient "chaud". 30ms ça va, il suffit de prendre quelques précautions, ce qui est fait dans les normes.

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.

Pas tout à fait. Il y a des systèmes de correction d'erreurs depuis le PIO0. Par contre les CRC ont étés ajoutés avec le mode Burst. Dans ce mode on envoie une grande quantité de données en une fois. Ce qui est plus beaucoup moins fiable, d'où l'utilisation des CRC.

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é).

Il y a pleins d'endroits dans un ordinateur où les données ne sont pas controlés. En mémoire et dans le CPU notamment (à part dans le cas des mémoires ECC pour serveur). Bien sur le taux d'erreur n'est pas nul, mais suffisament faible pour être négligeable. Les systèmes de correction ou de détection d'erruers ne sont nécéssaires que si des erreurs apparaissent à une fréquence génante.

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.

Exactement, la consommation CPU baisse considérablement en UDMA. Mais les sauvegardes DD ne sont pas vraiment soumises aux contraintes temps réel du traitement audio. Tant que le cache n'est pas plein ce n'est pas génant. Les transferts peuvent être différés.

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.TE]

Les DD ne font pas de streaming. Rien dans la norme ATA ne permet de différencier un enregistrement de guitare d'une feuille de calcul.
Il n'existe pas de mode streaming comme l'UDP sur Internet par exemple. Sur un bus électronique il y a des phénomènes équivalents au Jitter (ils ne s'appellent pas comme ça) mais le protocole avec ses divers signaux d'aquiescements par exemple et les erreurs retournés si il n'es pas respecté s'assurent de l'intégrité des données. Cette partie ne pas de problème.

[Pc Fan]

[quote=wfplb,Jul 22 2002, 00:31][QUOTE=Stef44,Jul 21 2002, 17:15]
et il sait mieux que tout le monde que l'informatique n'est que du calcul arrondi (donc approximatif)... pas la musique [/quote]
Oui et non. Je préfères erreur quantifiable.
Il se trompe mais il sait de combien. :-)
L'arrondi du numérique n'est pas vraiment génant, il se situe (ou devrait se situer) en dessous du "flou" (du bruit) de l'analogique.
Cela dit le numérique ajoute d'autres erreurs que l'analogique n'a pas.

[Pc Fan]

- Il n'y a pas de correction d'erreur sur les CD audio, en tout cas pas au niveau du CD, contrairement aux CD données (ce qui explique la différence de place dispo), après, dans le lecteur, dans le soft de lecture… et dans le convertisseur N/A qui va abreuver nos beaux amplis à tubes qui luisent et nos belles enceintes BW… ou nos écoutes amplifiées.

Si il y a aussi une correction d'erreurs sur les CD audio: CIRC (Cross Intervalle Red Solomon). Elle est moins importante que dans les CDROM où là la moindre erreur est catastrophique.

[Pc Fan]

bien, l'explication des tests:
sachant que le processeur central gere notamment l'IDE, donc se trouve oblige de bosser pas mal lors des acces disque (voir les vu metres de consommation de processing), lorsque deux ou quatre pistes sont jouees simultanement, la demande n'est pas monstrueuse, mais lorsqu'on demande au logiciel de gerer 64 voire plus (jusqu'a 128 pistes actuellement), le HD sollicite un maximum de processing et le son se comporte un peu comme lors de l'utilisation d'un demultiplexeur gerant plusieurs canaux sur une paire de convertisseurs. Comme c'est un travail effectue (quoi qu'on en dise) en mode série, les informations sont traitees l'une apres l'autre, et tout ce petit monde arrive a se bousculer au portillon.
Si on utilise une machine ultra puissante, ca posera evidemment moins de problemes qu'avec une becane "standard". de la meme maniere, tout ce qui peut aider les differents flux d'information sera bienvenu dans ce cas . genre DSP's divers, cartes acceleratrices de HD, SCSI ou IDE en RAID, etc.

Mouais.
Je n'y crois pas trop.
Simple test: Réduit la taille des buffers au maximm et tu entends des craquements "en charge".
Preuve que ce n'est pas lissé comme avec la lecture d'un CDA.

Je ne vois pas trop l'intérêt théorique. Perdre du temps à surveiller des niveaux de partout alors que de toute façon le résultat final sera dégradé. Surtout qu'un crak en bisouillant on le répare avec certainement plus d'intelligence qu'un soft.

D'autre part ce n'est pas pour rien que les softs audio sont équipés de jauge CPU/DD. (Ce sont les seuls softs qui on ce genre de joujoux). Autrement dit on demande à l'utilisateur de surveiller son ordinateur de façon à ne pas risquer un "trop-plein".
Parce que de toute façon si le traitement demande plus de 100% du temps algo où pas l'ordinateur sera incapable d'effectuer le boulot en temps réel.

Actuellement l'ATA est un poil plus gourmand en ressources CPU que le SCSI. Le problème ne vient pas de là (c'est de l'ordre de 1 à 2).
Les 2 standards sont parfaitement surs. Encore une fois il n'y a pas de différences entre la sauvegarde de l'état d'un compte bancaire et l'enregistrement audio (du point de vue DD).

Je ne connais pas tous les logiciels du marché mais ce pour les raisons explicitées plus haut cela me parait improbable (jusqu'à preuve du contraire )

Ce qu'il reste comme possibilité:
Psycologique? pourquoi pas.
Mécanique? DEs problèmes de vibrations du nouveau DD entraineraient un disfonctionnement autre part? Pourquoi pas
Electronique. Des commutations pas trop bien filtrées (un moteur comme celui d'un DD est avant tout un bobinage fortement inductif), possible dans le cadre d'uin dsyfonctionnement du DD ou d'une alim à genoux. Il faudrait mettre un oscilloscope sur l'alim et comparer avec les SCSI.
A distance cela restent des hypothèses.

[Michel Geiss]

Il y a 2 types différents de DD qui peuvent se connecter sur du firewire. Les DD classiques fiables "à 100%" et les "DD" AV/C Audio/Video isochrone (temps réel en gros) qui eux du fait de leur caractéristique isochrone sont plus sujets aux erreurs

A ma connaissance, "isochrone" concerne non pas un type de disque, mais un mode de fonctionnement de transmission de données. La norme FireWire comporte ce mode isochrone en plus du mode asynchrone.
En isochrone, une partie de la bande passante de transmission (jusqu'à 80%) peut être réservée au streaming. Cela garantit l'efficacité de transferts à densité d'informations élevée, comme en audio ou en vidéo, un peu comme le fait le DMA.
Ce qu'on appelle habituellement "AV" pour un disque dur concerne spécifiquement les recalibrations thermiques intempestives, qui peuvent se produire pendant un transfert de données critique sur un disque ordinaire.

[Michel Geiss]

Première chose, puisqu'ici, on est sur Macmusic, on parle de l'ATA disponible sur les G4, et pas sur les PCs.

Cela ne change pas grand chose les normes ATA sont un standard

Comprenons-nous bien ! De même que SCSI est un standard autant que l'ATA, les machines n'ont pas le même type de performances de communication.
Comme je le disais sur l'un de mes posts, sur le g4, c'est de l'ATA-66, ce qui n'est pas la même chose que de l'ATA-100 ou 133 ! Ca fait quand même une différence !

[Michel Geiss]

Les DD ne font pas de streaming. Rien dans la norme ATA ne permet de différencier un enregistrement de guitare d'une feuille de calcul.
Il n'existe pas de mode streaming comme l'UDP sur Internet par exemple

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.
La feuille de calcul n'a évidemment pas besoin des mêmes performances

[Pc Fan]

A ma connaissance, "isochrone" concerne non pas un type de disque, mais un mode de fonctionnement de transmission de données. La norme FireWire comporte ce mode isochrone en plus du mode asynchrone.
En isochrone, une partie de la bande passante de transmission (jusqu'à 80%) peut être réservée au streaming.
Cela garantit l'efficacité de transferts à densité d'informations élevée, comme en audio ou en vidéo, un peu comme le fait le DMA.

Désolé d'avoir été aussi confus.
Oui isochrone permet cela. Basiquement c'est une transmission de données asynchrone sur un canal de transmission synchrone. Cela ne garantit pas vraiment un gros débit mais permet de faire passer des données dépendant du temps comme l'audio ou la vidéo.C'est pour cela que ce mode de transmission est utilisé en streaming et non pas pour une histoire de débit.
Le problème avec le firewire c'est qu'il est entièrement asynchrone, l'isochronie n'est qu'une bidouille, alors forcément pour les transmissions isochrones cela pose problème lorsque l'on a besoin d'excellentes performances.
Le DMA c'est autre chose, un bus interne n'a pas vraiment les mêmes contraintes, à commencer par le fait que c'est un bus parallèle (voir post suivant).

J'ai parlé d'isochronie dans le cadre des DD AV/C.
C'est bien particulier ce sont les futurs DD embarqués dans les appareils multimédias, des magéntophones ou des magnétoscopes sous formes de DD. Pour faire cela ces DD n'utilisent plus les commandes PIO, UDMA ou SCSI mais les commandes AV/C. En fonctionnalité c'est très proche d'un lecteur/enregistreur de Mp3. Record, Play, Pause, Stop, Aller à telle position et pour les fonctions avancées faire un catalogue des pistes, créer des marqueurs etc....
Cela permettra par exemple de remplacer les K7 DV des camescopes numériques et de lire directement les enregistrements en branchant le DD sur une TV. Dans ces conditions les communications doivent être isochrones, mais c'est un cas particulier.
J'évoquais la possibilité pour Digidesign de proposer un "standard" équivalent non pas pour du multimiédia grand public mais pour de l'audio pro.

Ce qu'on appelle habituellement "AV" pour un disque dur concerne spécifiquement les recalibrations thermiques intempestives, qui peuvent se produire pendant un transfert de données critique sur un disque ordinaire.

Oui. Mais c'est obsolète tous les HD modernes ce passent de recalibration thermique.